1

Is there a standard or RFC saying NS records are not to be pointed to zone apex (with appropriate glue in parent zone)?

For example:

test.test. IN NS test.test.
test.test. IN A 192.0.2.1
KMerk
  • 15
  • 1
  • 6
  • 1
    Afaik, the answer is "no". But is there some specific background to this question coming up? – Håkan Lindqvist Dec 28 '20 at 14:42
  • 1
    At least one of them can't be. "There must be at least two NS records listed in a delegation, and the hosts must not resolve to the same IP address.", https://www.iana.org/help/nameserver-requirements – tater Dec 28 '20 at 15:09
  • @tater What you cite are IANA requirements, not rules coming from the DNS specifications. – Patrick Mevzek Dec 28 '20 at 18:24
  • @h%c3%a5kan-lindqvist Got a sandbox for networking experiments. One registrar I use allows such records, while the other one doesn't. Decided to raise a ticket with the latter, just wanted to be sure I didn't miss something obvious. – KMerk Dec 28 '20 at 18:25
  • @PatrickMevzek I don't think I've ever seen this specified in an RFC and I can't find it in one now. Nevertheless it has been a best practice since the first DNS RFCs were published back in the 1980s. Back then we would usually go even farther and locate the second (and sometimes third) DNS servers on completely separate networks. I had informal agreements with colleagues at various institutions as late as the late 1990s to cross-host secondary DNS zones for each other. Of course, back then changing your domain's registered nameservers required _literal_ paperwork... – Michael Hampton Dec 28 '20 at 18:58
  • "best practice " Yes (and I don't disagree), but out of context they become irrelevant which is why I think things like that should not presented just as table of laws, but explained. They were also written before anycast was a thing. What do you gain for example if you have two nameservers in same AS and same physical POP? Absolutely nothing. IANA does try to enforce various things for TLD operators, but rules for TLD operators and rules for other DNS operators are not the same. There is RFC7720 for root servers, and RFC 6168 for everyone else (maybe one other for TLDs but I don't find it) – Patrick Mevzek Dec 28 '20 at 19:12
  • (For context, with any hardcoded rules like that I have seen people going around it by having two names... resolving to the same IP address, or 2 names with separate IP addresses... reaching the exact same physical boxes; on all those cases having two nameservers does not add anything to the stability/security of the setup; even worse it gives the feeling of having achieved something good while the reality is the opposite) – Patrick Mevzek Dec 28 '20 at 19:18
  • @Patrick Mevzek based on RFC882, "The domain must provide redundant (i.e., two or more) name servers to provide the name to address resolution service. These name servers must be accessible from outside the domain (as well as inside) and must resolve names for at least all the hosts in the domain." – tater Dec 28 '20 at 21:23
  • Yes, but written before anycast existed. Do you really think that 2 nameservers resolving to two IP addresses going to one physical box or 2 boxes in the same datacenter with same POP and AS is in any way better than one nameserver only but with an anycast IP address? I don't personally, hence old rules have to be put in perspective (and not be given out of context) with modern way of doing things. Also 882 is superseed by 1034+1035 and that specific sentence has disappeared then, closest being "although a particular data item will be stored redundantly in two or more name servers." – Patrick Mevzek Dec 28 '20 at 21:32

1 Answers1

3

You certainly can create nameservers with the name being the zone name (apex), it works and is used by some. There is no specific reason to prohibit that, and hence I don't think you can find an RFC forbidding that because, technically, there is nothing wrong there per se.

However, expect some major head scratching at least. Doing things like that will expose you to many bugs at both registries and registrars that won't accept, by error, a nameserver with such a name, and also remember that you will, like for any glue, need to update the IP address at registry as needed (a regular case of DNS errors, which points towards avoiding glues like that when possible most often), and have more difficulties in updating this specific domain.

In short, as I see little benefits in those setups and many possible drawbacks this is certainly something I suggest to avoid, outside of local tests or being an absolute master in DNS and domain name management.

The subject is however mentioned is the most up to date standardized document on DNS things aka RFC 8499, as such:

  • In-domain: a modifier to describe a name server whose name is either subordinate to or (rarely) the same as the owner name of the NS resource records. An in-domain name server name needs to have glue records or name resolution fails. For example, a delegation for "child.example.com" may have "in-domain" name server name "ns.child.example.com".

Note the (emphasis mine): "or (rarely) the same as the owner name of the NS resource records."

Community
  • 1
Patrick Mevzek
  • 9,273
  • 7
  • 29
  • 42
  • Like you said, there is a registrar which fails to properly process such a record. Wanted to get my facts straight before texting support, even if for a minor bug. – KMerk Dec 28 '20 at 18:55
  • 1
    @KMerk except if you have the luck on reaching a real technical guy at the registrar (and note that registrar and DNS operator are separate jobs in fact) and not just customer service, you might get very off topic answers with people not understanding this very arcane part... – Patrick Mevzek Dec 28 '20 at 19:14
  • Additional thanks for updating the answer with a reference to the RFC mentioning the case. – KMerk Dec 28 '20 at 19:14
  • It isn't a big registrar (it's accredited though, not a reseller), so I hope I'll get to speak to the right guy. – KMerk Dec 28 '20 at 19:24