Score:-1

Second-level domain as a primary NS server for itself

kr flag

Is there anything in RFCs forbidding me from specifying NS records for mydom.example that go like this:

mydom.example 192.0.2.4
secondaryns.example

as compared to

ns.mydom.example 192.0.2.4
secondaryns.example

Specifically, when the primary NS is on the same domain, can I use mydom.example there or is it strictly necessary to have any third-level domain for NS such as ns.mydom.example?

Score:1
cn flag

Is there anything in RFCs forbidding me

No, nothing forbids you to use a nameserver name whose name is the zone name.

It exists, BUT it is absolutely not recommended. First it is obviously in-bailiwick so you need glue records. This already create some headaches.

But, having the nameserver name equal to the zone name will for sure triggering edge cases, as this is a situation not well known so you will find a lot of software/API/UI choking on this.

So, from experience, I recommend you do not do this. You gain nothing really by doing things like that, so it is best to avoid.

Захар Joe avatar
kr flag
"a lot of software/API/UI choking on this" was what triggered this question.
Patrick Mevzek avatar
cn flag
Using the zone name as the nameserver name does not provide any kind of benefit (on top of using any in-bailiwick nameservers with glues, if you want that), and does create problems so in light of this I think the consequence is clearly: do not do this (outside of experiments and fun cases), even if technically nothing prevents you for doing this, it is legit, and works (normally).
Score:0
za flag

This is not a third level domain. Here ns.example.com is a name of (e.g. points to) the A/AAAA RR, which contains actual IPv4 or IPv6 addresses of the server.

And, because NS should point to precisely A or AAAA records, you can't use the "apex" name as the nameserver host name. A delegated zone always contains at least a SOA record and therefore the zone name is unsuitable as a NS record target.

Your zone (as served by your servers) will be of the form:

example.com. SOA ...
example.com. NS ns.example.org.
example.com. NS ns.example.com.
ns.example.com. A 192.0.2.1
...

If the nameserver RR name itself is inside this example.com zone, you are required to define it (as I did for ns.example.com above), and your upstream zone (com) will add its as a glue record together with delegation records. In this case the com zone will contain the three records for you: 2 delegation NS and 1 glue A. If the nameserver RR is outside of the domain, it cannot be added to this zone (because it doesn't belong to it) and upstream will not have a glue for it (ok, it can have that same record as a glue for another domain, but that's none of your business).

But I don't get why are you concerned. Just do as everybody does it. Don't be pulled by the marketing gimmick, the "level" of the "domain" doesn't mean anything, except technical. When we talk about logically consistent use of names, the use of nested levels of the hierarchy is encouraged.

Захар Joe avatar
kr flag
Thanks for the explanation. A side question though: is a PTR record for an IP pointing to example.com (instead of whatever.example.com) considered "valid"?
Nikita Kipriyanov avatar
za flag
It is. The `PTR` record record points simply to any other records in the domain name tree. ANY record, it even can be not a valid hostname. If you were a little more observant, you could see that the next record explained in the RFC1035 I linked to after `NS` is `PTR`.
Patrick Mevzek avatar
cn flag
"And, because NS should point to precisely A or AAAA records" NS records points to names not addresses. "you can't use the "apex" name as the nameserver host name." This is completely false. You can totally do this, and it happens in the wild.
Nikita Kipriyanov avatar
za flag
Would you mind showing an example in the wild?
Patrick Mevzek avatar
cn flag
Example in the wild right now: `040dns.com.` domain has `040dns.com.` nameserver and works (except an error in TCP handling as you can see in DNSViz: https://dnsviz.net/d/040dns.com/YaaFDQ/dnssec/). I count right now 1130 domains in `.com` zone with same setup (but lot of garbage indeed, that is lame delegation cases)
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.