Delegation NS-records when zones share an authority server

Nick Tait nick at tait.net.nz
Wed Apr 12 20:57:45 UTC 2023


On 13/04/2023 5:58 am, Havard Eidnes via bind-users wrote:
>> I suspect you don't need the NS records in challenge.state.ak.us and
>> if you remove them then the records in challenge.state.ak.us are
>> simply part of the state.ak.us zone since they're served off of the
>> same server.
> Unfortunately "not quite".
>
> While a publishing name server will respond with data from the most
> specific zone available to it when queried (e.g. for the NS records
> for challenge.state.ak.us), this "overriding" or "leakage" does not
> happen when you do a zone transfer of the parent zone (state.ak.us).
>
> So ... if you have a publishing name server which is a name server for
> state.ak.us and not for challenge.state.ak.us, it will *not* have the
> delegation NS RRset for challenge.state.ak.us, and if a recursor
> happens to query this particular publishing name server as part of the
> process of resolving a name in challenge.state.ak.us, it will get an
> apparently-spurious NXDOMAIN response.

I think the suggestion was for the other way around - i.e. NS in parent 
zone only?

But that is also not a good idea. I'll defer to RFC 1034 section 4.2.1 
for the details:

    Though logically part of the authoritative data, the RRs that describe
    the top node of the zone are especially important to the zone's
    management.  These RRs are of two types: name server RRs that list, one
    per RR, all of the servers for the zone, and a single SOA RR that
    describes zone management parameters.

    The RRs that describe cuts around the bottom of the zone are NS RRs that
    name the servers for the subzones.  Since the cuts are between nodes,
    these RRs are NOT part of the authoritative data of the zone, and should
    be exactly the same as the corresponding RRs in the top node of the
    subzone.  Since name servers are always associated with zone boundaries,
    NS RRs are only found at nodes which are the top node of some zone.  In
    the data that makes up a zone, NS RRs are found at the top node of the
    zone (and are authoritative) and at cuts around the bottom of the zone
    (where they are not authoritative), but never in between.

The terminology is a bit confusing, but it boils down to this: The NS 
records for the zone must be included in the zone itself, and also in 
the parent zone.

Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20230413/8bba43bd/attachment-0001.htm>


More information about the bind-users mailing list