> On 13 Apr 2023, at 06:44, Mark Andrews <ma...@isc.org> wrote: > > > >> On 13 Apr 2023, at 03:19, Fred Morris <m3...@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@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: ma...@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@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: ma...@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@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
