[neitsab]

For now DNS information reflect the former address and name servers for most people:

  $ dig krebsonsecurity.com +short
  127.0.0.1
  
  $ dig ns krebsonsecurity.com +short
  ns2.prolexic.net.
  ns1.prolexic.net.

127.0.0.1 points to localhost, which is your local machine.

However if you query the Whois, you'll see that the site changed its name servers from Prolexic's to Google's ones today:

  $ whois krebsonsecurity.com | grep "Name Server"
   Name Server: NS-CLOUD-D1.GOOGLEDOMAINS.COM
   Name Server: NS-CLOUD-D2.GOOGLEDOMAINS.COM
   Name Server: NS-CLOUD-D3.GOOGLEDOMAINS.COM
   Name Server: NS-CLOUD-D4.GOOGLEDOMAINS.COM

And indeed if we query those directly:

  $ dig krebsonsecurity.com @ns-cloud-d1.googledomains.com +short
  130.211.45.45

Such name servers change can take up to 72h to propagate. Meanwhile, you can edit your /etc/hosts file (on GNU/Linux) to hardcode the IP of krebsonsecurity.com:

  # echo "130.211.45.45   krebsonsecurity.com" >> /etc/hosts

(must run as root)

Now browse to krebsonsecurity.com et voilà!

[jsjohnst]

DNS doesn't "propagate" and it certainly doesn't take 72hrs either. You're simply waiting for the cache TTL to expire on the DNS server you are using, then it'll re-query the authoritative servers.

[johncolanduoni]

What about that doesn't sound like propagation? I guess you could try and be pedantic and claim since there's no "push" it's not propagation, but this exact phenomena in DNS is called propagation all the time.

Also many ISP's servers ignore TTLs for certain changes that happen infrequently (like NS changes) and wait a few days. So they might refresh the A record according to the TTL, but they'll still be pulling it from the wrong name server.

[jsjohnst]

More often than not, it's not ISPs ignoring TTLs as you describe, it is an improperly configured SOA record. There's more TTLs you (as owner of domain) control involved in the caching of a record than just the TTL on an A/AAAA record.

As to your point about "propagation", argumentum ad populum applies.

[neitsab]

Could you elaborate more on why propagation is not the right term? Its definition reads:

  The process of spreading to a larger area or greater number; dissemination.

Which is (to my understanding) exactly what happens with DNS information while clients fetch the updated zone.

72 hours is indeed a comfortable upper bound ("up to"), that we would give to customers so as to make absolutely sure every cache down the chain has refreshed its records, and is not the cause of the issue at hand when name servers were changed. 24 hours is common delay.

[fanf2]

"Propagate" is the traditional term for DNS update delays. It dates back to the era before NOTIFY and IXFR when it often took a long time for secondary servers to update their copies of a zone. Nowadays with a good setup that should happen within a few seconds.

Perhaps it is a bit of a misnomer to use it for cache timeouts, but it isn't particularly wrong or confusing unless you have a very pedantic reader.

[jsjohnst]

Propagate implies that the answer isn't readily available everywhere already. Instead of saying "up to 72hrs for DNS to propagate", it's much more accurate and just as easy to say "up to 72hrs for your DNS cache to refresh".

Am I being a bit pedantic? Sure, I'll admit that. But the reason I'm being pedantic is that this mischaracterization implies that there's nothing that can be done to prevent it. That is absolutely not true and if DNS is handled properly, you can get 99.99% or more of the world resolving with the correct records in under 1hr, with most of that being in under 15min. Excusing this as DNS propagation and not handling just looks lazy to me.

But what do I know, based on all the down votes apparently folks disagree with me so I'll gladly bow out from the conversation.