this is my first post here, so excuse me if I don't post everything quite right.

anyway, my question is about zone files in parent and child zones. 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?

hope you understand my question.

thanks in advanced.

  • Also see: What is the role of NS records at the apex of a DNS domain? Would have marked this as a dupe, but we've got good dialogue between answers here and one is accepted. – Andrew B Dec 18 '16 at 21:10
  • 1
    Another thing: keep in mind that the parent zone will not always contain a glue record. Glue records are only strictly necessary when the child zone overlaps with namespace of the parent zone. – Andrew B Dec 18 '16 at 21:19

The way it works

The authoritative NS records reside inside the zone itself (and provided in ANSWER 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 glue A/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 the NS records are in the AUTHORITY 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.


You need the same NS records both in your zone and as delegation information in the parent zone. Much the same way, any glue A/AAAA records also need to actually exist as real authoritative records.


Much as I hate to disagree with my esteemed colleague, the NS records within the zone do serve some purposes. For example, the 1ary NS needs to know who all the other NSes are so that in the event of a zone update it can send them all DNS NOTIFYs, so they know to perform zone transfers. This information it gets from those in-zone NS records.

As for DS records having no in-zone counterpart, the DS is a simple digest of the in-zone KSK DNSKEY record. That record, just like the NS records, would have been mirrored in- and out-zone were it not for the considerable length of KSK records, and the performance implications for domains with tens of millions of child entries, such as .com, of maintaining a similar number of records of arbitrary length. Thus the decision to keep only a digest in the parent zone - but they are still the same record, and the in- and out-zone copies must match, just as with NS records.

tl; dr

Håkan is right; you need those in-zone records, and they really ought to match the out-zone (glue) copies. Generally, don't violate RFCs unless you're really sure you know what you're doing.

  • Regarding this typical default of who to notify, even though you have the NS records readily available it's still quite common that you will need to consult the outside world to actually resolve those names anyway. Regardless, you could just list the addresses of the other servers, much like you do when you override this default. Also, the notify functionality was only introduced long after these design decisions. I think another case, that may be a stronger one, is how to prime recursors with the servers for the root zone. That is an area that would HAVE to work somewhat differently. – Håkan Lindqvist Dec 18 '16 at 14:14
  • As for DS records maybe I could improve my phrasing (I'll take a close look), but the point I was trying to make is simply that DS records is an example where it was done done differently; it is a record where the servers for the parent zone answer authoritatively and the child zone has no record for something that traditionally would be considered part of the child zone. – Håkan Lindqvist Dec 18 '16 at 14:15
  • If I didn't make it clear, my take is that the data in the DS record is indeed in both parent and child zones. It's in full form in the child, and in digested form in the parent, but the datum is present in both zones. As for who to notify, I agree the 1ary name server could have that information configured in some other way, but it still has to be configured in locally. They will only be resolved outwith the 1ary if they are outside its authoritative zones - and if that is the case they are not amongst the set of data stored both in- and out-zone, and not relevant to the question. – MadHatter Dec 18 '16 at 14:31
  • I think one point where our views of this diverge is whether records of different types at all can be equal, strictly speaking. – Håkan Lindqvist Dec 18 '16 at 14:54
  • Anyway, I edited my answer to hopefully make it more clear what I meant regarding DS records. – Håkan Lindqvist Dec 18 '16 at 15:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.