Hi Peter, Thanks for addressing the concerns and educating me. On 15/05/2024 15.23, Peter Thomassen wrote: > Hi Benson, > > Thank you for your review. > > On 5/12/24 20:43, Benson Muite via Datatracker wrote: >> Reviewer: Benson Muite >> Review result: Ready with Nits >> >> I am an assigned INT directorate reviewer for >> <draft-ietf-dnsop-dnssec-bootstrapping-08.txt>. These comments were >> written >> primarily for the benefit of the Internet Area Directors. Document >> editors and >> shepherd(s) should treat these comments just like they would treat >> comments >> from any other IETF contributors and resolve them along with any other >> Last >> Call comments that have been received. For more details on the INT >> Directorate, >> see https://datatracker.ietf.org/group/intdir/about/ . >> >> Based on my review, if I was on the IESG I would ballot this document >> as YES. >> >> SUMMARY: >> The draft proposes a mechanism to enable automated initial validation >> of child >> subdomain CDS/CDNSKEY records when an out of balliwick name server is >> available >> and when the child zone name is not too long. >> >> SUGGESTIONS FOR IMPROVEMENT: > > Incorporated changes will show up in the -09 revision (will be published > later today) and are part of this PR: > https://github.com/desec-io/draft-ietf-dnsop-dnssec-bootstrapping/pull/15 > >> 1. May want to minimize number of acronyms in the abstract, for >> example DS >> (Delegation Signer), CDS (Child DS) and CDNSKEY (Child Domain Name System >> public key) > > Those terms are identifiers for DNS record types, rather than acronyms. > As a salient example, the TLSA record type "does not stand for anything" > (RFC 6698 Section 1.2). > > As such, they are typically not expanded in DNS-related RFCs (see for, > for example, RFC 8078 whose abstract uses DS and DNSKEY as well without > expansion). Ok. > >> 2. Too long is not specified though is mentioned in section 4.4 - >> could more details be given > > We've added a reference to RFC 1035 Section 3.1 which defines these > length requirements. Thanks. > >> and do deprecated out of band methods need to be >> used in such cases? > > The document deprecates automatic DNSSEC bootstrapping without > authentication. If it can't be done automatically with authentication, > one can set up DS records manually (by interacting with the parent > operator). > > To do it securely, an out of band channel may be needed (e.g., via the > registrar's web interface). One does not have to use a deprecated > (insecure) automated method. Ok. > >> Any estimates on how often too long names might occur? > I'm not aware of any numbers. It essentially happens when the _dsboot > and _signal labels together with the domain name and longest nameserver > hostname exceed 255 octets. > > As both nameserver names and delegated domain names are usually shorter > than ~120 octets, this is expected to happen very rarely in practice. We > don't have numbers, unfortunately, but I wouldn't be surprised if the > only real examples are experiments set up to prove the point. > Ok. >> 3. >> Will there be a follow on informational best practice document based on >> operational experiences? > Saying this is not in scope for the spec document, but yes, various > people (including some ICANN staff) have expressed interest in writing > up best practices / operational experience on DNSSEC automation, > including (but not limited to) the topic of bootstrapping. > Great. > Thanks, > Peter > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
