0

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 1.1.1.1 and the new is 2.2.2.2 (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

;; QUESTION SECTION:
;mydomain.fi.           IN  NS

;; ANSWER SECTION:
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.

;; ADDITIONAL SECTION:
dns.myprovider.com. 1582    IN  A   10.11.12.13
dns2.myprovider.com.    1442    IN  A   10.11.12.14
dns3.myprovider.com.    1715    IN  A   10.11.12.15
dns4.myprovider.com.    1457    IN  A   10.11.12.16

(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
Address: 10.11.12.13#53
Aliases: 

mydomain.fi has address 1.1.1.1

This was after many hours. I thought it should have changed to 2.2.2.2 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).

Ilari Kajaste
  • 135
  • 6
  • 2
    Do the lookup directly from your canonical nameservers: http://serverfault.com/questions/372066/dig-force-resolving-without-cache/372071#372071 – 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. – Ilari Kajaste Mar 29 '12 at 20:54
  • @joeqwerty Edited my question. It [seems](http://chat.stackexchange.com/transcript/message/4027275#4027275) "propagation" means something more specific to the sysadmin people, and using it with DNS changes is misleading in the professional context. – Ilari Kajaste Mar 30 '12 at 06:27

3 Answers3

3

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).

Community
  • 1
voretaq7
  • 79,345
  • 17
  • 128
  • 213
  • 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? – Ilari Kajaste 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 `2.2.2.2` instead of the old `1.1.1.1`. 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? – Ilari Kajaste 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
1

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
  • 24,533
  • 2
  • 49
  • 69
  • cjc is correct. It lot depends on the TTL. However, your ISP can cache. Check the Root Servers ( http://dns.squish.net/ ) or OpenDNS Cache ( http://www.opendns.com/support/cache/ ) to get an overview on how it is getting resovlved currently. – Shyam Sundar C S 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. – Ilari Kajaste 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. – Shyam Sundar C S 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 @8.8.8.8 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 8.8.8.8 is not just a single DNS server/cache) – voretaq7 Mar 30 '12 at 16:16
  • @voretaq7 The google.com example is a little weird. I see ns1.google.com in the SOA, but that appears to cache www.google.com, as I see a decrementing TTL when I do `dig www.google.com. ns1.google.com.` It may be how google manages their DNS more than anything else. – cjc Mar 30 '12 at 16:38
0

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.

Dave Drager
  • 8,315
  • 28
  • 45