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.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
