0

Say for example during a DNS migration to cloudflare, rather than transfering to "fred.ns.cloudflare.com" you typo'd "ferd.ns.cloudflare.com" or something similar for NS1, and the same kind of thing for NS2.

You realise this after the change has propagated, so you can no longer edit DNS on your original DNS host, but cloudflare never receives the domains.

Is there a way to recover from that kind of situation / would the transfer fail in the first place or something similar, or would you effectively just lose control of your DNS?

-- Not something that's actually happened to me, but something of a potential nightmare scenario that I can't find any information on, which makes me think I may be overly worried about nothing?

Nick
  • 3
  • 1
  • The authoritative name servers for a domain are located/managed by your domain registrar. You would just edit the entries with the correct information. If you are talking about a managed zone for a subdomain, then you would go to your DNS servers and correct the entries. – John Hanley Apr 18 '21 at 03:11
  • As a side note, some registries (and technically registrars could do it as well) do DNS checks upon nameservers change and allow it to proceed only if new nameservers do pass them, like being authoritative on the name delegated to them. .DE and .IT do it for example. It won't cover all cases of misconfiguration but will catch some. – Patrick Mevzek Apr 18 '21 at 21:38

1 Answers1

1

This concern is based on false assumptions that the current authoritative name servers for the domain example.com. would transfer the responsibility to the new authoritative servers and that this would then somehow propagate everywhere. This is not how DNS works. In reality:

  • The parent zone (com.) delegates control with the NS records it has.

    From dig example.com +trace:

    example.com.  172800  IN  NS  a.iana-servers.net.
example.com.  172800  IN  NS  b.iana-servers.net.
;; Received 535 bytes from 192.5.6.30#53(a.gtld-servers.net)

  • DNS does not propagate; the recursive queries are cached for the TTL (RFC 1034, 3.6):

    TTL which is the time to live of the RR. This field is a 32 bit integer in units of seconds, an is primarily used by resolvers when they cache RRs. The TTL describes how long a RR can be cached before it should be discarded.

So, what would happen if the incorrect NS records were updated...

  • to the parent zone? The domain would stop working because the delegated authoritative name servers are inexistent or not responding. This is a recoverable condition, as you can simply give the correct name servers to your registrar to be updated to the parent zone.

    However, this takes some time, because the TTL for the NS records on the parent is rather long: e.g., this 172800 equals 48 hours, so it might take up to 48 hours for the caches to expire.

  • to the current authoritative zone? That would simply be a misconfiguration; DNS inconsistency. It is still the parent zone that delegates the control, so nothing has really changed.

Community
  • 1
Esa Jokinen
  • 46,944
  • 3
  • 83
  • 129
  • Thank you for correcting my missconceptions, it's good to have this worry off my back! – Nick Apr 18 '21 at 08:33