Delegation NS-records when zones share an authority server

Wed Apr 12 20:58:08 UTC 2023

> On 13 Apr 2023, at 06:44, Mark Andrews <marka at isc.org> wrote:
> 
> 
> 
>> On 13 Apr 2023, at 03:19, Fred Morris <m3047 at m3047.net> wrote:
>> 
>> TLDR: NS records occur above and below zone cuts.
>> 
>> On Wed, 12 Apr 2023, John Thurston wrote:
>>> 
>>> We have authority over state.ak.us, which we publish as a public zone. We also publish challenge.state.ak.us as a public zone.
>>> 
>>> The public NS records for state.ak.us are: ns4.state.ak.us and ns3.state.ak.us The NS records for challenge.state.ak.us are the same.
>>> 
>>> I recently noticed there were no NS records _in the state.ak.us zone_ for challenge.state.ak.us.
>> 
>> So nothing above the zone cut == there is no zone cut. (IMO)
>> 
>>> This had me scratching my head . . "how can this be working?", until I remembered the same instances of BIND were serving out both zones. There _were_ NS records in the challenge.state.ak.us zone, BIND had them, was authoritative, so would answer with them; BIND didn't need to look in the state.ak.us zone to find them.
>> 
>> Yup.
>> 
>>> Some experimentation shows that even if I insert NS records into state.ak.us (for challenge.state.ak.us), BIND does not add them to its answer when asked "dig NS challenge.state.ak.us". I interpret this to mean that while this instance of BIND is authoritative for both zones, it answers with information from the most specific zone it has, and ignores values in the delegating zone. And that makes sense to me.
>> 
>> Yup.
>> 
>>> Now the question is, should I insert NS records into state.ak.us (for challenge.state.ak.us) anyway?
>>> [...]
>>> 
>>> Unknown:
>>> 
>>> * Does the answer change if we want to start signing either zone?
>> 
>> 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. Glue records (above the cut) are essentially the same NS record(s) published on nameservers above the zone cut as within the zone on the nameservers for the zone proper (below the cut).
>> 
>> On the other hand maybe whatever software you're using to manage / serve DNS does something with those records (or requires them since / if the two namespaces are loaded as separate zones).
>> 
>> In terms of NXDOMAIN and SOA queries, both state.ak.us and challenge.state.ak.us seem to do the right thing in terms of pretending to be separate zones, e.g. in the first case returning the correct domain in the AUTHORITY and in the second case returning the relevant SOA records directly in the ANSWER.
> 
> You need NS records in the parent domain to give correct answers to DS queries (DATA or NODATA NOERROR vs NXDOMAIN) and to generate valid NSEC and NSEC3 chains.  Additionally if the parent zone is ever transferred to server without the child zone clients will see a Schrödinger zone.  Always add delegating NS RRset and keep it consistent with the child zone.

To demonstrate what I mean about DS.  While named has code to handle this inconsistency other recursive servers may not as it is NOT a RFC requirement.

% dig ds challenge.state.ak.us
;; BADCOOKIE, retrying.

; <<>> DiG 9.19.11-dev <<>> ds challenge.state.ak.us
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 34581
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 13281432cf7c77c80100000064371a0bdc1c24b7a7f4aaf4 (good)
;; QUESTION SECTION:
;challenge.state.ak.us. IN DS

;; AUTHORITY SECTION:
state.ak.us. 3600 IN SOA ns3.state.ak.us. hostmaster.state.ak.us. 1681251385 3600 900 7776000 3600

;; Query time: 1484 msec
;; SERVER: ::1#53(::1) (UDP)
;; WHEN: Thu Apr 13 06:52:27 AEST 2023
;; MSG SIZE  rcvd: 129

% dig soa challenge.state.ak.us
;; BADCOOKIE, retrying.

; <<>> DiG 9.19.11-dev <<>> soa challenge.state.ak.us
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9228
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 5babd4f25d9125570100000064371a19b455b75c97d45a2c (good)
;; QUESTION SECTION:
;challenge.state.ak.us. IN SOA

;; ANSWER SECTION:
challenge.state.ak.us. 21600 IN SOA ns3.state.ak.us. hostmaster.state.ak.us. 2018034113 3600 300 86400 120

;; Query time: 255 msec
;; SERVER: ::1#53(::1) (UDP)
;; WHEN: Thu Apr 13 06:52:41 AEST 2023
;; MSG SIZE  rcvd: 129

%

>> --
>> 
>> Fred Morris, internet plumber
>> 
>> 
>> -- 
>> 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 at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/bind-users
> 
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742              INTERNET: marka at isc.org
> 
> -- 
> 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org