1

I have recently migrated one of my .com-domain zones from DNS provider A to DNS provider B, however the TTL on the NS-records for the zone on provider A is very high = 432000 (5 days), and thus I feel sad thinking that I might have to keep (and potentially update) the zone at the old provider for almost a weeks time.

Question is: Since WHOIS for the domain is already updated with the new nameservers of provider B, can I safely delete the zone at provider A, even though NS-record TTL might not have expired for clients?

Secondary question: What exactly happens when clients contact NS provider A and it doesn't respond with authority anymore? Provider A should just call Provider B and relay a non-authoritative response to the client, right?

Johan Thomsen
  • 33
  • 4
  • WHOIS results have no bearing on the discovery of your name servers or DNS resolution for your domain. What matters is that your name servers are listed with the domain Registrar for your domain. Your Registrar has the responsibility to update the parent servers of your name server changes. You have to ask your registrar how long their updates will take. – Gmck Apr 05 '17 at 08:40
  • *What I meant was:* When I query the WHOIS-server of my registrar, it responds with the new NS-servers included in the WHOIS-response. Same happens when I NS-query my registrar DNS-servers. I thus assume that the parent records have been updated. Now; my questions above still apply. – Johan Thomsen Apr 05 '17 at 08:53
  • You should not query whois to debug DNS resolution cases, use `dig` for that. Also what is the problem of maintaining the zone at the old provider for a few days? You could have lowered the TTL in the zone before doing the change, but what matters most is the TTL in the parent zonefile. – Patrick Mevzek Apr 06 '17 at 18:38
  • - I know what dig is, and I use it. Thanks anyway. - No problem in maintaining the zone. Only problem is knowing what happens if I don't, hence my question. - I can't lower the TTL on the NS-records on my old provider. Those are read-only in their interface. – Johan Thomsen Apr 07 '17 at 08:45

2 Answers2

1

can I safely delete the zone at provider A, even though NS-record TTL might not have expired for clients?

No. The old servers must remain online for the duration of the TTL associated with the NS records.

What exactly happens when clients contact NS provider A and it doesn't respond with authority anymore? Provider A should just call Provider B and relay a non-authoritative response to the client, right?

No, authoritative servers do not relay responses between each other. If the recursive server has cached the old nameserver data, it will attempt to communicate with the old servers. If all of those authoritative nameservers fail to respond, or return REFUSED, your domain is dead in the water until the old data is invalidated from cache.

Andrew B
  • 31,858
  • 12
  • 90
  • 128
0

You should check the TTL of the NS-record for your domain. Which is actually part of the parent zone. Looking at the .com zone I get a refresh of 1800 seconds. Whereas the negative TTL is at 86400. So it takes 1800 seconds to move your .com domain from one provider to another but 86400 hours for a retry once one of the Servers says that the record is no available (NXDOMAIN) . See Wikipedia eplanation of a SOA resource record

So to answer your second question first: It would be a bad idea, as the domain will be unavailable for longer than if it existed at the wrong place.

To your first question: As 1800 seconds is 30 Minutes your domain should already be served by the new provider. Just to be sure ask an open domain to IP service (google "domain to ip").

Andrew B
  • 31,858
  • 12
  • 90
  • 128
user2563336
  • 116
  • 4
  • Negative TTL doesn't apply here. If `com` delegates to a set of nameservers which either fail to respond or return `REFUSED`, that falls under "Other Negative Responses" as defined by [RFC 2308](https://tools.ietf.org/html/rfc2308#section-7). This period of time will not exceed five minutes, and in practice will usually be less. – Andrew B Apr 05 '17 at 14:46