I have DNS service from a third party, which provides an webapp for changing the DNS. I changed the DNS settings to point one of the domains I control to our new IP, but it's been hours and there was no change to the status.

Not being very familiar with how DNS changes work, I'm tring to debug what's happening - or rather not happening. I'm in the understanding that DNS takes a while to get distributed globally as caches expire, but I would like to confirm that the change has happened on my provider's DNS sever and thus that the change is underway.

The previous IP was and the new is (changed for this article)

First I confirmed that the domain is actually using the nameserver that I can make changes to:

ilari@alux:~$ dig mydomain.fi NS

; <<>> DiG 9.7.3 <<>> mydomain.fi NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6569
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 4

;mydomain.fi.           IN  NS

mydomain.fi.        77916   IN  NS  dns2.myprovider.com.
mydomain.fi.        77916   IN  NS  dns3.myprovider.com.
mydomain.fi.        77916   IN  NS  dns.myprovider.com.
mydomain.fi.        77916   IN  NS  dns4.myprovider.com.

dns.myprovider.com. 1582    IN  A
dns2.myprovider.com.    1442    IN  A
dns3.myprovider.com.    1715    IN  A
dns4.myprovider.com.    1457    IN  A

(I originally used whois mydomain.fi for this, but I now realize that was not the proper way, since it doesn't actually query the DNS, only what's written about it in the whois record, if anything.)

After that, I tried using host to fetch results directly from the provider's server. I assume it should immediatly result in displaying the new IP, but instead:

ilari@alux:~$ host mydomain.fi dns.myprovider.com
Using domain server:
Name: dns.myprovider.com

mydomain.fi has address

This was after many hours. I thought it should have changed to immediately since it should query the exact server I'm making changes to from the web interface. What should I expect to see as results?

How do I make sure the web interface at my provider has worked, and the DNS has changed properly at their server?

It turns out this was a problem at their end. The web interface hadn't made the change properly, and the IP wasn't actually changed at their DNS server.

After their problem was solved, there was still a few minutes delay after the change was seen with host mydomain.fi dns.myprovider.com (and of course longer until the change is seen globally).

  • 2
    Do the lookup directly from your canonical nameservers: serverfault.com/questions/372066/…
    – Ladadadada
    Mar 29 '12 at 18:13
  • Without going off on a tangent, DNS DOES NOT PROPAGATE.
    – joeqwerty
    Mar 29 '12 at 20:01
  • @joeqwerty I always try to use the correct terminology when I'm aware of it, and I'm also interested in techical subtleties conveyed by language. Please point me to some source where I can read details on why DNS information being slowly distributed to an increasing area due to cache aging should not be called "propagation", so that I can fix both the terminology used in the question and also any further use in my own language. Mar 29 '12 at 20:54
  • @joeqwerty Edited my question. It seems "propagation" means something more specific to the sysadmin people, and using it with DNS changes is misleading in the professional context. Mar 30 '12 at 6:27

A DNS change is "active" as soon as you make it and verify that all of the authoritative servers (as listed in the zone's NS records) are serving the new record. Ladadadada pointed you at a question/answer that explains how to check this.

A DNS change is "propagated" once the caches on all servers around the world have expired and they've retrieved the new information from the authoritative servers. ("propagation" is technically the wrong word - it's actually cache expiration - but it's the commonly used term).

You can control the first of these. You cannot control the second (the TTL (Time To Live) value on the record should theoretically limit how long it takes for caches to expire, however there are ISPs out there that simply don't respect TTL values -- AOL in particular is notorious for this).

  • Doesn't running dig @authorative.dns.com mydomain.fi produce the same results than host mydomain.fi authorative.dns.com which is what I did in the question? Mar 29 '12 at 19:06
  • @IlariKajaste It should, yes.
    – voretaq7
    Mar 29 '12 at 19:51
  • So.. in the case of my question, the change can be confirmed as "active" (= not yet globally available, but can already be trusted to get eventually distributed to the DNS network) by checking with relevant dig or host command that all the dnsX.myprovider.com listed by the dig mydomain.fi NS give the new ip instead of the old Further, this method of determination only works after the TTL values listed in the dig NS query have been observed to reach zero (and jump back up) at least once? Mar 29 '12 at 21:13
  • @IlariKajaste Correct, with the exception of waiting for the TTL to expire. If you are querying an authoritative name server it should always return the data it has in the zone file - no caching (and thus no decreasing TTL) should be involved. If it doesn't you may have messed something else up (like not incrementing the zone serial number), and if the TTL is decreasing on subsequent queries you're not querying the true primary authoritative NS (you're getting someone's cache data - possibly off a shadow NS).
    – voretaq7
    Mar 30 '12 at 16:11

What's the time to live (TTL) setting for the mydomain.fi record? If the TTL is, say, one day, you would not see changes until tomorrow.

  • cjc is correct. It lot depends on the TTL. However, your ISP can cache. Check the Root Servers ( dns.squish.net ) or OpenDNS Cache ( opendns.com/support/cache ) to get an overview on how it is getting resovlved currently. Mar 29 '12 at 18:27
  • Is there a way to check the TTL? It's probably 15 min though, since they said it should only take that long to be active. Mar 29 '12 at 19:01
  • 1
    @IlariKajaste, if you do a dig on the authoritative name servers, you'll see the TTL counting down, e.g., dig google.com ns1.google.com
    – cjc
    Mar 29 '12 at 19:24
  • using dig command ( eg: dig ycombinator.com ) will show the TTL in Answer Section. The number next to the domain, is the TTL. It is in seconds. Mar 29 '12 at 19:26
  • 1
    @cjc Note that you will only see the TTL decreasing on cached data. Building on your Google example: dig @ns1.bsd-box.net bsd-box.net will query my system for its own DNS data - run it a few times and you'll see the TTL stays the same (3600). dig @ bsd-box.net will query Google's public DNS, and if you run it a few times you'll see the TTL decrease (It may take a number of tries and be slightly inconsistent as is not just a single DNS server/cache)
    – voretaq7
    Mar 30 '12 at 16:16

I like to use dig to check this:

dig hostname.to.check @dns.myprovider.com 

Make sure to check all of the nameservers to see that they all respond with the same.

Squish.net also has a great tool for DNS traversal and it will tell you how the active nameservers are going to respond to your request.

  • 1
    Add the +trace option to dig to avoid possible DNS caches.
    – pkhamre
    Mar 30 '12 at 7:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.