Bug #45416 for bind9-public: named and named-checkzone don't recognise out-of-zone RRsets that are below a delegation point [ISC-Support #11674]

Reported on 9.10.3-P2 and tested/confirmed on 9.11.1-P1 Neither named nor named-checkzone throw any kind of warning for records in a zone that are "below" a delegation zone cut. $ cat example.com.zone $TTL 86400 example.com. IN SOA a0.nic.example.com. noc.afilias-nst.info. 1497203847 10800 3600 2764800 900 example.com. IN NS a0.nic.example.com. example.com. IN NS b0.nic.example.com. example.com. IN NS c0.nic.example.com. a0.nic.example.com. IN A 128.66.0.1 b0.nic.example.com. IN A 128.66.1.1 c0.nic.example.com. IN A 128.66.2.1 sub.example.com. IN NS ns1.afilias.info. sub.example.com. IN NS ns2.afilias.info. out-of-zone.sub.example.com. IN NS ns1.isc.org. out-of-zone.sub.example.com. IN NS ns2.isc.org. $ named-checkzone -i local example.com example.com.zone zone example.com/IN: loaded serial 1497203847 OK When the zone is loaded by named, the out of zone RRset is included and can be seen from a named dump ("rndc dumpdb -all") but the RRset is inaccessible when querying the server - the response is a referral to the nameservers for sub.example.com. ---- This caused some operational problems as the configuration/delegation error was not spotted and not highlighted by named-checkzone, so took some time to uncover. It's probably unrealistic to expect named itself to spot these problems during zone loading (because of the ordering of the RRset in the zone file - the out-of-zone RRset is actually within the zone, except for the delegation. which could appear anywhere. So would it be possible to add an additional feature/option to named-checkconf that causes a second run through the zone file after parsing it the first time and identifying the delegation points?

---

On Thu Jun 22 20:26:14 2017, muks wrote: > RFC 2136 covers this: > > 7.18. Previously existing names which are occluded by a new zone cut > are still considered part of the parent zone, for the purposes of > zone transfers, even though queries for such names will be referred > to the new subzone's servers. If a zone cut is removed, all parent > zone names that were occluded by it will again become visible to > queries. (This is a clarification of [RFC1034].) > > Occlusion is not an error. A similar situation can occur with DNAME > too. > > Mukund Ah OK - in that case, I think there is nothing we can reasonable do here, unless we think it worthwhile to add a warning. Cathy

---

In message <rt-4.4.1-49360-1498565168-1351.45416-4-0@isc.org>, "Cathy Almond via RT" writes: > On Thu Jun 22 20:26:14 2017, muks wrote: > > RFC 2136 covers this: > > > > 7.18. Previously existing names which are occluded by a new zone cut > > are still considered part of the parent zone, for the purposes of > > zone transfers, even though queries for such names will be referred > > to the new subzone's servers. If a zone cut is removed, all parent > > zone names that were occluded by it will again become visible to > > queries. (This is a clarification of [RFC1034].) > > > > Occlusion is not an error. A similar situation can occur with DNAME > > too. > > > > Mukund > > Ah OK - in that case, I think there is nothing we can reasonable do > here, unless we think it worthwhile to add a warning. Well we could add a mode that checks for non-glue below bottom of zone but it would have to be documented as being beyond what it technically required. This policy not correctness enforcement. > Cathy > > -- > Ticket History: https://bugs.isc.org/Ticket/Display.html?id=45416 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

---