2

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   @
  • 1
    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 - For the love of all that is holy do some reading up on DNS and stop referring to it as propagation. There is no such thing. Your DNS records don't get propagated anywhere. Your DNS records don't propagate to my name server, my name server has to ask for them. – joeqwerty Apr 30 '14 at 15:36
4

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.

  • Thanks for the detailed reply. I guess what's tripping me up is why I'm getting so many red crosses on the whatsmydns.net propagation check. If anything, shouldn't a check during an in-progress propagation return the old IP instead of -no- IP? I apologize if this is a really basic question. – Will03 Apr 30 '14 at 10:44
  • At this time it is mostly a question waiting for cached DNS records to time out, but typically the best approach not to combine changes of the IP-addresses of your servers with a change of name servers (or registrars). Make the contents of the zone on the new DNS servers identical to the one on the old DNS server. Then change the DNS server at the registrar level (or transfer the domain to the new registrar). Leave the zone active on the old DNS server until the changes have propagated. That is the rub though, most registrars will remove the old zone automatically when the transfer is complete – HBruijn Apr 30 '14 at 13:48
1

Your low TTL for your addresses is causing your records to age out of cache long before the nameserver records get updated. Your TTL should be at least as long as the TTL for your NS records.

If you can keep your records up on the old server until the NS records time out you should be OK. The old NS records will time out within a couple of days and your propagation issues will resolve themselves. Things should clear up after 2 days (172800 seconds).

It is good practice to shorten the TTL on records before you change them. I am not sure whether your providers allow you to change the TTL on the NS records. At lease two days before the change I would have reduced the TTL on the NS records to about an hour (or 1800 as that is what you are using on your records).

This is the process I follow:

  • Reduce the TTL on changing records to about an hour well in advance of the change. (At least 1 TTL.)
  • Reduce the TTL significantly (down to 5 minutes or so) at least 1 TTL in advance of the change.
  • Make the change and verify propagation. Make any fixes (should propagate in minutes).
  • Increase TTL to an hour or two and re-verify propagation.
  • Increase TTL to a couple of days or more once things are stable.

Some of the major DNS servers will override your TTL to avoid supporting fast-flux DNS servers.. You will likely want to reachable on the old IP address for a day or so.

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.