What could cause DNS to un-propagate

domain-name-systemupdate

I moved a Godaddy domain (ihearthawaii.com) to a digital ocean droplet around 15 hours ago. Tracking the DNS Propagation through sites like (whatsmydns.net), I notice that the propagation is struggling. It will propagate to certain servers, but after an hour or so it will disappear from them. This has been happening all day. It's almost like something is simultaneously undoing the propagation. An hour ago, I had 8 green check marks, and now I only have 5.

Has anyone seen anything like this before? Is there anyway to fix this?

I am using digitalocean name servers and they appear to be okay. I've also tried intodns and dnscheck looking for configuration problems but nothing really sticks out.

In DNS failing to propagate worldwide it seemed like the problem went away by itself. But I am wondering how to figure out the cause of such occurrences.

My zone file from Digital Ocean

$TTL    1800
@       IN  SOA NS1.DIGITALOCEAN.COM.   hostmaster.ihearthawaii.com. (
        1398835453 ; last update: 2014-04-30 05:24:13 UTC
        3600 ; refresh
        900 ; retry
        1209600 ; expire
        1800 ; ttl
        )
         IN      NS      NS1.DIGITALOCEAN.COM.
                 NS      NS2.DIGITALOCEAN.COM.
                 NS      NS3.DIGITALOCEAN.COM.
@   IN A    128.199.249.146
www CNAME   @

Best Answer

A change of the DNS servers by your registrar will generally take up to 48 hours to propagate, regardless of the TTL you set on the NS records in your zone. 

dig +trace www.ihearthawaii.com

shows that for me the updates have propagated correctly and your domain resolves as you expect.

; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1 <<>> +trace www.ihearthawaii.com
;; global options: +cmd
.                       8843    IN      NS      a.root-servers.net.
.                       8843    IN      NS      b.root-servers.net.
<snip>
.                       8843    IN      NS      m.root-servers.net.
;; Received 228 bytes from 8.8.4.4#53(8.8.4.4) in 145 ms

com.                    172800  IN      NS      a.gtld-servers.net.
com.                    172800  IN      NS      b.gtld-servers.net.
<snip>
com.                    172800  IN      NS      m.gtld-servers.net.
;; Received 510 bytes from 192.36.148.17#53(192.36.148.17) in 141 ms

ihearthawaii.com.       172800  IN      NS      ns1.digitalocean.com.
ihearthawaii.com.       172800  IN      NS      ns2.digitalocean.com.
ihearthawaii.com.       172800  IN      NS      ns3.digitalocean.com.
;; Received 153 bytes from 192.48.79.30#53(192.48.79.30) in 295 ms

www.ihearthawaii.com.   1800    IN      CNAME   ihearthawaii.com.
ihearthawaii.com.       1800    IN      A       128.199.249.146
;; Received 68 bytes from 198.199.120.125#53(198.199.120.125) in 94 ms

This trace option shows how resolving works, from the root servers, down through the .com top-level domain root servers, where the ihearthawaii.com domain is delegated to ns<1-3>.digitalocean.com with a TTL of 48 hours, until www.ihearthawaii.com is resolved.

The low TTL on your DNS records in your own zone may contribute to the flaky behavior, as some of the root servers (for example a.gtld-servers.net) will have already been updated with your new DNS servers, and others (for example m.gtld-servers.net) may not.

So when a caching DNS server may might have been using a.gtld-servers.net and have found ns1.digitalocean.com as the authoritative DNS server, when the 30 minute cache period expires it may have been directed to m.gtld-servers.net and found the old registrar NS record pointing to your old name servers.

Related Topic