If an attacker is spoofing responses, it seems that they could send a different NS and A record, and a new calculated DS hash. So this provides no protection against spoofing?
We would need instead (or in addition) an RRSIG record to actually protect this. An example would help. -- Bob Harold DNS and DHCP Hostmaster - UMNet Information and Technology Services (ITS) rharo...@umich.edu 734-512-7038 On Tue, Nov 3, 2020 at 11:31 PM <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 >
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
