Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Days since it was DNS

dayssince.itwasdns.net

Post reply on HN
Print view View original

21–30 of 38 posts

Re: Days since it was DNS

#21

Post by fanf2 »

xyst wrote: post #11

I was setting up my own mail server the other day and re-realized how long global DNS propagation really takes. I’m in the US so it was almost instantaneous between updating the dns records in domain register any being able to verify the changes with my own rDNS server. But using a UK or NL dns server didn’t immediately pick up those recent changes. Had to wait an additional 48 hrs for global dns propagation.

A change to a record in your zone should propagate to all your authoritative servers within a few seconds, using the DNS NOTIFY feature. If it doesn’t, that’s a bug in your provider’s setup.

Caches rely on the TTL of records in your zone, or the SOA negative TTL field for negative answers. You control these TTLs, so don’t set them to 48 hours. In most cases there’s little benefit to having TTLs longer than 1 hour. (I use 24 hours for TTLs on NS records and nameserver addresses, because they tend to be more stable, and it’s good for tail latency to keep them in caches longer.)

Re: Days since it was DNS

#22

Post by xyst »

bluejekyll wrote: post #15
xyst wrote: post #11

I was setting up my own mail server the other day and re-realized how long global DNS propagation really takes. I’m in the US so it was almost instantaneous between updating the dns records in domain register any being able to verify the changes with my own rDNS server. But using a UK or NL dns server didn’t immediately pick up those recent changes. Had to wait an additional 48 hrs for global dns propagation.

This is surprising. What was the TLD for your name? And can you share your SOA config for your zone? (don't need the names, I'm curious about the TTLs in all the SOA fields)

tld is .dev

localhost:~# dig dev soa … ; > DiG 9.16.39 > dev soa ;; global options: +cmd ;; Got answer: ;; ->>HEADER;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;dev. IN SOA

;; ANSWER SECTION: dev. 299 IN SOA ns-tld1.charlestonroadregistry.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300

This is the soa config?

> SOA ns-tld1.charlestonroadregistry.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300

Re: Days since it was DNS

#23

Post by xyst »

fanf2 wrote: post #21
xyst wrote: post #11

I was setting up my own mail server the other day and re-realized how long global DNS propagation really takes. I’m in the US so it was almost instantaneous between updating the dns records in domain register any being able to verify the changes with my own rDNS server. But using a UK or NL dns server didn’t immediately pick up those recent changes. Had to wait an additional 48 hrs for global dns propagation.

A change to a record in your zone should propagate to all your authoritative servers within a few seconds, using the DNS NOTIFY feature. If it doesn’t, that’s a bug in your provider’s setup. Caches rely on the TTL of records in your zone, or the SOA negative TTL field for negative answers. You control these TTLs, so don’t set them to 48 hours. In most cases there’s little benefit to having TTLs longer than 1 hour. (I…

By “zone”, is this regional? It was for a .dev tld. So that makes sense as to why I (someone in US) was able to see changes immediately.

Re: Days since it was DNS

#24

Post by silisili »

xyst wrote: post #23
fanf2 wrote: post #21

Earlier quoted context omitted.

A change to a record in your zone should propagate to all your authoritative servers within a few seconds, using the DNS NOTIFY feature. If it doesn’t, that’s a bug in your provider’s setup. Caches rely on the TTL of records in your zone, or the SOA negative TTL field for negative answers. You control these TTLs, so don’t set them to 48 hours. In most cases there’s little benefit to having TTLs longer than 1 hour. (I…

By “zone”, is this regional? It was for a .dev tld. So that makes sense as to why I (someone in US) was able to see changes immediately.

No, zone in DNS parlance basically means your domain name (and its records).

Re: Days since it was DNS

#25

Post by xist »

When will this tired meme be retired?

There's almost 300 RFCs related to DNS. It can do many things, and some of them are complex. But human error is almost always the root cause.

Your inability to configure DNS properly speaks more about you, then the service itself.

Re: Days since it was DNS

#26

Post by gumby »

fanf2 wrote: post #21
xyst wrote: post #11

I was setting up my own mail server the other day and re-realized how long global DNS propagation really takes. I’m in the US so it was almost instantaneous between updating the dns records in domain register any being able to verify the changes with my own rDNS server. But using a UK or NL dns server didn’t immediately pick up those recent changes. Had to wait an additional 48 hrs for global dns propagation.

A change to a record in your zone should propagate to all your authoritative servers within a few seconds, using the DNS NOTIFY feature. If it doesn’t, that’s a bug in your provider’s setup. Caches rely on the TTL of records in your zone, or the SOA negative TTL field for negative answers. You control these TTLs, so don’t set them to 48 hours. In most cases there’s little benefit to having TTLs longer than 1 hour. (I…

> Caches rely on the TTL of records in your zone, or the SOA negative TTL field for negative answers.

Sadly the word "should" ought to have appeared in your sentence.

A lot of resolvers ignore the TTL, either because of the number of misconfigured TTL entries (too short), because they resolve a LOT of names and figure they can't afford to keep looking up certain names, or out of sheer orneryness.

I don't update frequently so when I do plan to make updates I adjust my TTL to a short period, wait a few days, then make the updates, then after a week turn the TTL way up again. I've noticed that this is pointless with some big sites.

Re: Days since it was DNS

#27

Post by toast0 »

bluejekyll wrote: post #15
xyst wrote: post #11

I was setting up my own mail server the other day and re-realized how long global DNS propagation really takes. I’m in the US so it was almost instantaneous between updating the dns records in domain register any being able to verify the changes with my own rDNS server. But using a UK or NL dns server didn’t immediately pick up those recent changes. Had to wait an additional 48 hrs for global dns propagation.

This is surprising. What was the TLD for your name? And can you share your SOA config for your zone? (don't need the names, I'm curious about the TTLs in all the SOA fields)

Most TLDs serve glue records with 1-3 day ttls. It's not surprising to me that some servers had the old glue cached (well, I'm assuming they've got traffic... I would be surprised if my domains' glue were cached anywhere of note)

If you can configure your old nameservers to serve the new NS records, sometimes that's helpful.

Re: Days since it was DNS

#29

Post by bluejekyll »

xyst wrote: post #22
bluejekyll wrote: post #15

Earlier quoted context omitted.

This is surprising. What was the TLD for your name? And can you share your SOA config for your zone? (don't need the names, I'm curious about the TTLs in all the SOA fields)

tld is .dev localhost:~# dig dev soa … ; > DiG 9.16.39 > dev soa ;; global options: +cmd ;; Got answer: ;; ->>HEADER ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;dev. IN SOA ;; ANSWER SECTION: dev. 299 IN SOA ns-tld1.charlestonroadregistry.com. cloud-dns-hostmaster.google.com. 1 21600 3600 259200 300 This is the soa config? > SOA ns-tld1.charlestonroadregistry.com. cloud-dns-hostma…

I was thinking that maybe you had a large TTL for either the SOA or the minimum TTL field, but both of those are pretty reasonable at 5 minutes and 1 minute.

See this RFC, https://www.rfc-editor.org/rfc/rfc2308#section-4

Re: Days since it was DNS

#30

Post by hi-v-rocknroll »

xist wrote: post #25

When will this tired meme be retired? There's almost 300 RFCs related to DNS. It can do many things, and some of them are complex. But human error is almost always the root cause. Your inability to configure DNS properly speaks more about you, then the service itself.

I'm also a huge fan of the blog posts that suggest throwing away fundamental technologies and replacing them with half-bakery without understanding the problem domain or the problems that have been encountered and solved before.
Post reply on HN