0

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?

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 5 '17 at 8: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 5 '17 at 8: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 6 '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 7 '17 at 8:45
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.

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

1
  • 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. This period of time will not exceed five minutes, and in practice will usually be less. – Andrew B Apr 5 '17 at 14:46

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.