If we have example.com we would setup things something like this:
$ORIGIN example.com.
@ 1D IN SOA ns1.example.com. hostmaster.example.com. (
2002022401 ; serial
3H ; refresh
15 ; retry
1w ; expire
3h ; nxdomain ttl
)
IN NS ns1.example.com.
IN NS ns2.example.com.
since in the parent zone .com. there is already NS record for the example.com. child zone and A glue record for the ns1.example.com. for what purpose do we state NS records again in the child zone?
and also, do we need to state A record for the name servers in the child zone itself?
Best Answer
The way it works
The authoritative
NS
records reside inside the zone itself (and provided inANSWER
section when the authoritative server is queried), just like all other records that are part of that zone.To be able to traverse the tree, referral/delegation/authority information (
NS
and any glueA
/AAAA
records necessary) is also added to the parent zone.This information, however, is not treated as the "real answer", the answer lacks the
AA
(authoritative answer) flag and theNS
records are in theAUTHORITY
section to indicate that this is just information on who has the actual answer.One implication of this is that if you do a direct lookup of
NS
records you will follow this referral and query the authoritative server despite having just seen what should be the same information.Why was it defined to work this way?
Presumably because it was considered proper/clean/logical that all authoritative records reside inside the zone that they belong to and that there should be authoritative records also for
NS
.Could this have been defined differently?
Yes. Look at for instance how
DS
records were defined when introduced much later. In that case there is no such record inside the child zone, instead it's the parent that is authoritative.Can I do it differently?
No. Because it was defined the way it was and all the software out there works based on how it was defined, things will break (often in subtle ways) if you don't do it properly.
tl;dr
You need the same
NS
records both in your zone and as delegation information in the parent zone. Much the same way, any glueA
/AAAA
records also need to actually exist as real authoritative records.