> 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 ?
Delegating NS records because the zone would become big and people didn’t want to have TLD zones have signatures for each delegation. We could sign delegating NS records as you can determine delegating vs top of zone by looking at the signer field of the NS RRset. You would then have to deal with the case where you have signed parent and unsigned child and a referral to the grand child. You would have to stop following the referral, verify the child is unsigned, then restart following the referral. This is a lot of work for very little benefit. Glue records would need a different signature type and would need to compute the signature differently to prevent it being used in a replay attack when the RRset differ. I suppose you could use the same algorithm as it would encourage people to keep data coherent. You would still have the parent, child, grandchild issues from above. If one wants to stop spoofed referrals being accepted do something like well known TSIG which will stop off path spoofed traffic dead. It will also stop off path reassembly attacks dead as the spoofed reassembled packet will be rejected. On path attackers can just race the server without DNSSEC. Chairs, can you issue a call for WG adoption of my well known TSIG draft please. > 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. It can’t. There is no requirement for addresses records for nameservers for a zone to exist in the zone, as glue or not, even if the nameservers are below top of zone. Glue is only required for delegations. > 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
