Document: draft-ietf-dnsop-delext Title: DNS Protocol Modifications for Delegation Extensions Reviewer: Patrick Mevzek Review result: Ready
I have been selected as the DNS Directorate reviewer for this draft. The DNS Directorate seeks to review all DNS or DNS-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the ADs. For more information about the DNS Directorate, please see https://wiki.ietf.org/en/group/dnsdir After review, I do not have any substantiative comments, just maybe some nits: 1) Maybe explicit documentation on behavior a resolver should implement if getting DE=1 back without having asked for that (as it means the answer is not as "usual"), which makes sense of course only for a resolver really parsing that EDNS but deciding for a given query to NOT send DE=1. 2) Add in introduction that this specification also add a new EDE INFO-CODE (section 4.1) as all other changes are mentioned in the introduction except this one. 3) "To avoid a downgrade attack, where the Delegation Type RRsets and NSEC (or NSEC3) records can be replaced by unsigned NS records, causing the resolver to use unencrypted transport" This seems to equate "no signed records mean unencrypted transport" which might be true for only a very specific subset of delegation type RRsets, aka DELEG. I would maybe slightly rephrase the "causing" part as saying more generally that this in turn might/could force the resolver to ignore existing more secure options and transports in favor of going back to usual DNS over 53. But as one outcome possible, and not sole one nor always being the case anyway. [this is in fact correctly explained in §8.2.1 so maybe just reference it above?] 4) not sure, but in same section, maybe discuss consequences of adding ADT flag in existing DNSKEY vs just starting with new DNSKEY with the flag. As the flag value will impact the key tag, hence if changed on an existing key, key tag will change hence DS record needs to change, depending on which DNSKEY record it is (see next point) 5) §4.2 "When the DNSKEY-ADT flag is set to 1 in any DNSKEY record in the DNSKEY RRset of the delegating zone" In the spirit of focusing on delegation, shouldn't this be only on the KSK and not all keys? And in fact, shouldn't the ADT flag be irrelevant/ignored on ZSKs? If this has been already all discussed and decided, maybe just add a terse explanation (on why using all records and not a subset). 6) "Authoritative servers SHOULD include an Extended DNS Error [RFC8914] code in NXDOMAIN responses" Reference §9.5 there? 7) Appendix A is a bit short and not conveying really detailed examples but more just ideas. The document feels otherwise ready to be published. I found the document well written and extensive for all interoperability details that are needed to be taken into account for an important DNS change like that, properly protected under explicit signaling to allow smooth upgrades. _______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
