> From: Bob Harold <rharo...@umich.edu> > 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.
Thanks for reading the draft. I'm assuming that DiS RR is treated as the DS RR, so if the parent side is signed, DS (+DiS) RRSet will be signed. > An example would help. Yes. I will add examples in next version. example.com. IN NS ns.example.com. ns.example.com. IN A 2001:dc8::53 example.com. IN DS 12345 8 2 (hash of DNSKEY RR) example.com. IN DS 00000 0 100 (hash of (example.com IN NS | ns.example.com IN AAAA)) example.com. IN RRSIG DS (signature of DS RRSet (2 DSes)) DNSSEC signer may generate DiS RR and signature of DS RRSet (including DiS RR). -- Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp> > -- > 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
