> From: Mark Andrews <ma...@isc.org> > One problem with DiS is that assumes that address records in the additional > section *always* come from the delegating zone (see how the hash is created). > This is not how DNS works. Address records can, correctly, come from other > sources, even when the name is *below* the zone cut. > > Take a server that serves example.net and sub.child.example.net. That A > record > comes from sub.child.example.net not example.net when the name of the server > is > a.sub.example.net. > > child.example.net NS a.sub.example.net > a.sub.example.net A 1.2.3.4 > > Mark
"a.sub.example.net" is not a "in-domain" glue. (it is "sibling" glue). Then, DiS RR for child.example.net will be generated from "child.example.net NS a.sub.example.net". Authoritative server of "child.example.net" responds child.example.net NS a.sub.example.net in authority section with/without a.sub.example.net A 1.2.3.4 as a glue in additional section. Sibling glue "a.sub.example.net A 1.2.3.4" is not a target of DiS RR for "child.example.net NS". Validator can validate "child.example.net NS a.sub.example.net". Validating resolver can accept the sibling glue "a.sub.example.net A 1.2.3.4". Or, validating resolver may reject the sibling glue "a.sub.example.net A 1.2.3.4", and treat it similar to out-of-bailing domain name, then, resolve "a.sub.example.net" A/AAAA from root (or child.exapmle.net). Then I think the idea works. -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> >> On 4 Nov 2020, at 15:31, fujiw...@jprs.co.jp wrote: >> >> I submitted draft-fujiwara-dnsop-delegation-information-signer-00. >> >> Name: draft-fujiwara-dnsop-delegation-information-signer >> Revision: 00 >> Title: Delegation Information (Referrals) Signer for DNSSEC >> Document date: 2020-11-03 >> Group: Individual Submission >> Pages: 6 >> URL: >> https://www.ietf.org/archive/id/draft-fujiwara-dnsop-delegation-information-signer-00.txt >> >> DNSSEC does not have a function to validate delegation information. >> I think it is a large missing peace of DNSSEC. >> >> I have a question why we did not include signature validation function >> to delegation information ? >> >> Probably, because it is non-authoritative information. >> Or, because it was difficult to define the necessary and sufficient >> delegation information. >> >> It is now widely agreed (although not explicitly documented) that the >> delegation information is the information used for name resolution and >> does not result in name resolution. >> >> We have a word "in-domain" glue which is the necessary and sufficient glue. >> >> And the idea may offer the signature for root priming data. >> >> If someone interested the document, I would like time slot at dnsop WG >> meeting. >> >> Regards, >> >> -- >> Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> >> >> _______________________________________________ >> DNSOP mailing list >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > -- > Mark Andrews, ISC > 1 Seymour St., Dundas Valley, NSW 2117, Australia > PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org > > _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
