It depends on the registrar and on who's providing the DNS servers for DOMAIN.NET
In your example .NET
is the top-level domain. Omitting some details, when a computer on the Internet is trying to get to a computer in DOMAIN.NET
- it already knows how to find the nameservers for .NET (and the other top-level domains like
.COM .ORG .CA
and so on), so it goes to one of those and asks for the address of the nameservers for DOMAIN.NET
- the nameservers for
.NET
know the IP addresses of the nameservers for DOMAIN.NET
(those are the glue records)
- and then the nameservers for
DOMAIN.NET
know the IP addresses of computers within your domain
In principle, if you are running your own DNS servers and simply change registrars, the glue records don't change and you could probably switch by doing nothing.
The way your question is worded, it sounds like the registrar is also providing the DNS servers for your domain, in which case the glue records don't need to be transferred, they need to be changed, and that's not going to happen automatically.
If you're relying on your registrar's name servers, you need to talk to the new registrar and find out when they'll change the glue records after you transfer the domain to them. Then you need to talk to the old registrar and make sure they continue to provide services (with the old glue records) until the change takes place.
Let's break it down a little.
The NS records in the TLD zone (for example, example.com NS ...
in com
) are delegation records.
The A and AAAA records in the TLD zone (for example, ns1.example.com A ...
in com
) are glue records.
The NS records in the zone itself (that is, example.com NS ...
in example.com
) are authority records.
The A and AAAA records in the zone itself (ns1.example.com A ...
in example.com
) are address records, plain and simple.
When a (recursive) resolver starts out with no cache of your zone's data and only the root zone cache (which is used to bootstrap the name resolution process), it will first go to .
, then com.
. The com
servers will respond with an authority section response which basically says "I don't know, but look here for someone who does know", same as the servers for .
do about com
. This query response is not authoritative and does not include a populated answer section. It may also include a so-called additional section which gives the address mappings for any host names the particular server knows about (either from glue records or, in the case of recursive resolvers, from previously cached data). The resolver will take this delegation response, resolve the host name of a NS record if necessary, and proceed to query the DNS server to which authority has been delegated. This process may repeat a number of times if you have a deep delegation hierarchy, but eventually results in a query response with the "authoritative answer" flag set.
It's important to note that the resolver (generally, hopefully) won't try to break down the host name being resolved to ask about it piece by piece, but will simply send it in its entirety to the "best" server it knows about. Since the average authoritative name server on the Internet is non-authoritative for the vast majority of valid DNS names, the response will be a non-authoritative delegation response pointing toward some other DNS server.
Now, a server doesn't have to be named in the delegation or authority records anywhere to be authoritative for a zone. Consider for example the case of a private master server; in that case there exists an authoritative DNS server that only the administrator(s) of the slave DNS servers for the zone are aware of. A DNS server is authoritative for a zone if, through some mechanism, in its opinion it has full and accurate knowledge of the zone in question. A normally authoritative DNS server can, for example, become non-authoritative if the configured master server(s) cannot be reached within the time limit defined as the expiry time in the SOA record.
Only authoritative answers should be considered proper query responses; everything else is either a delegation, or an error of some kind. A delegation to a non-authoritative server is called a "lame" delegation, and means the resolver has to backtrack one step and try some other named DNS server. If no authoritative reachable name servers exist in the delegation, then name resolution fails (otherwise, it'll just be slower than normal).
This is all important because non-authoritative data mustn't be cached. How could it be, since the non-authoritative server doesn't have the full picture? So the authoritative server must, on its own accord, be able to answer the question "who is supposed to be authoritative, and for what?". That's the information provided by the in-zone NS records.
There's a number of edge cases where this can actually make a serious difference, primarily centered around multiple host name labels inside a single zone (probably fairly common e.g. with reverse DNS zones particularly for large dynamic IP ranges) or when the name servers list differs between the parent zone and the zone in question (which most likely is an error, but can be done intentionally as well).
You can see how this works in a little more detail using dig
and its +norec
(don't request recursion) and @
server specifier features. What follows is an illustration of how an actual resolving DNS server works. Query for the A record(s) for unix.stackexchange.com
starting at e.g. a.root-servers.net
:
$ dig unix.stackexchange.com. A @a.root-servers.net. +norec
Look closely at the flags
as well as the per-section counts. qr
is Query Response and aa
is Authoritative Answer. Notice that you only get delegated to the com
servers. Manually follow that delegation (in real life a recursive resolver would use the IP address from the additional section if provided, or initiate a separate name resolution of one of the named name servers if no IPs are provided in the delegation response, but we'll skip that part and just fall back to the operating system's normal resolver for brevity of the example):
$ dig unix.stackexchange.com. A @a.gtld-servers.net. +norec
Now you see that stackexchange.com
is delegated to (among others) ns1.serverfault.com
, and you are still not getting an authoritative answer. Again follow the delegation:
$ dig unix.stackexchange.com. A @ns1.serverfault.com. +norec
...
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35713
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3
;; QUESTION SECTION:
;unix.stackexchange.com. IN A
;; ANSWER SECTION:
unix.stackexchange.com. 300 IN A 198.252.206.16
Bingo! We got an answer, because the aa
flag is set, and it happens to contain an IP address just as we'd hoped to find. As an aside, it's worth noting that at least at the time of my writing this post, the delegated-to and the listed-authority name servers lists differ, showing that the two do not need to be identical. What I have exemplified above is basically the work done by any resolver, except any practical resolver will also cache responses along the way so it doesn't have to hit the root servers every time.
As you can see from the above example, the delegation and glue records serve a purpose distinct from the authority and address records in the zone itself.
A caching, resolving name server will also generally do some sanity checks on the returned data to protect against cache poisoning. For example, it may refuse to cache an answer naming the authoritative servers for com
from a source other than one that has already been named by a parent zone as deleged-to for com
. The details are server-dependent but the intent is to cache as much as possible while not opening up the barn door of allowing any random name server on the Internet to override delegation records for anything not officially under its "jurisdiction".
Best Answer
Subordinate identification
Apex level NS records are used by a master server to identify its subordinates. When data on an authoritative nameserver changes, it will advertise this via
DNS NOTIFY
messages (RFC 1996) to all of its peers on that list. Those servers will in turn call back with a request for theSOA
record (which contains the serial number), and make a decision on whether to pull down a more recent copy of that zone.NS
section, but this requires server specific configuration directives (such as ISC BIND'salso-notify
directive). The apex NS records comprise the basic list of servers to notify under a default configuration.NS
records, usually resulting in logged refusals. This can be disabled by instructing servers to only send notifies for zones they are masters for (BIND:notify master;
), or to skipNS
based notifies entirely in favor of notifies explicitly defined in the configuration. (BIND:notify explicit;
)Authoritative definition
The question above contained a fallacy:
This is an easy conclusion to arrive at, but not accurate. The
NS
records and glue record data (such as that defined within your registrar account) are not authoritative. It stands to reason that they cannot be considered "more authoritative" than the data residing on the servers that authority is being delegated to. This is emphasized by the fact that referrals do not have theaa
(Authoritative Answer) flag set.To illustrate:
Note the lack of
aa
in the flags for the above reply. The referral itself is not authoritative. On the other hand, the data on the server being referred to is authoritative.That said, this relationship can get very confusing as it is not possible to learn about the authoritative versions of these
NS
records without the non-authoritativeNS
records defined on the parent side of the referral. What happens if they disagree?NS
,A
, andAAAA
records may eventually be replaced when they are refreshed. The refreshes occur as the TTLs on those temporary records expire, or when someone explicitly requests the answer for those records.A
andAAAA
records for out of zone data (i.e. thecom
nameservers defining glue for data outside of thecom
zone, likeexample.net
) will definitely end up being refreshed, as it is a well-understood concept that a nameserver should not be considered an authoritative source of such information. (RFC 2181)NS
records differ between the parent and child sides of the referral (such as the nameservers entered into the registrar control panel differing from theNS
records that live on those same servers), the behaviors experienced will be inconsistent, up to and including childNS
records being ignored completely. This is because the behavior is not well defined by the standards, and the implementation varies between different recursive server implementations. In other words, consistent behavior across the internet can only be expected if the nameserver definitions for a domain are consistent between the parent and child sides of a referral.The long and short of it is that recursive DNS servers throughout the internet will bounce back between destinations if the records defined on the parent side of the referral do not agree with the authoritative versions of those records. Initially the data present in the referral will be preferred, only to be replaced by the authoritative definitions. Since caches are constantly being rebuilt from scratch across the internet, it is impossible for the internet to settle on a single version of reality with this configuration. If the authoritative records are doing something illegal per the standards, such as pointing
NS
records at aliases defined by aCNAME
, this gets even more difficult to troubleshoot; the domain will alternate between working and broken for software that rejects the violation. (i.e. ISC BIND / named)RFC 2181 ยง5.4.1 provides a ranking table for the trustworthiness of this data, and makes it explicit that cache data associated with referrals and glue cannot be returned as the answer to an explicit request for the records they refer to.