Skip to main content

Automatic DNSSEC Bootstrapping using Authenticated Signals from the Zone's Operator


Warren Kumari

No Objection

Jim Guichard
John Scudder
Mahesh Jethanandani

Note: This ballot was opened for revision 08 and is now closed.

Paul Wouters
(was Discuss) Yes
Comment (2024-05-27 for -10) Sent
Thanks for addressing all my DICSUSS items and comments. I have updated my ballot to Yes,

One last comment left on the new text:

       If all else fails, the domain owner might have to request the removal of
        all DS records (e.g., by using the special-value CDS/CDNSKEY RRset
        specified in [RFC8078] Section 4) and have the transfer performed

I think the "e.g." sentence should be removed. This is "in case the dns operator
is not cooperating", so in that case one would assume they wouldn't update these
records either (and the domain owner would need to go through their registrar
website, which would cause the records to be removed at the parent via EPP.
Warren Kumari
Erik Kline
No Objection
Comment (2024-05-04 for -08) Sent
# Internet AD comments for draft-ietf-dnsop-dnssec-bootstrapping-08
CC @ekline

* comment syntax:

* "Handling Ballot Positions":

## Comments

### S7

* Should there be some kind of registration or reservation for the "_dsboot"
  meaning and usage described in this document?
Gunter Van de Velde
No Objection
Comment (2024-05-08 for -08) Not sent
# Gunter Van de Velde, RTG AD, comments for draft-ietf-dnsop-dnssec-bootstrapping-08.txt

Please find documenting the handling of ballots.


## idnits: There seems to be an obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499)
Jim Guichard
No Objection
John Scudder
No Objection
Mahesh Jethanandani
No Objection
Murray Kucherawy
No Objection
Comment (2024-05-15 for -09) Sent
I support Paul's DISCUSS especially with respect to Section 2.  It's peculiar to say a past process is obsolete and you SHOULD NOT use it, because then continuing to use it is technically still supported by this document.  Don't we want to say that new implementations MUST NOT do the old thing and MUST do the new thing?  Using SHOULD effectively leaves two systems "live" rather than one.

This may be some ignorance talking, but: In Section 4.2, if it's found that the child is already securely delegated, should this be an error, or just treat the whole thing like a no-op?  Redundant verification returning an error seems an odd choice, but I'm probably missing some context.

I think the SHOULD in Section 4.3 should really be more like "Parental agents normally trigger ...".  I'm not clear on why this is a normative SHOULD.  What if I don't do it in those circumstances, but possibly in others?  I'm still compliant with a SHOULD then, right?  Why might I do it in other situations?  The text doesn't say.
Orie Steele
No Objection
Comment (2024-05-16 for -09) Not sent
I agree with Eric Kline's comment regarding reservation for the "_dsboot".
Roman Danyliw
No Objection
Comment (2024-05-12 for -08) Sent
Thank you to Peter Yee for the GENART review.

** Section 6.  Editorial.
   The level of rigor in Section 4.2 is needed to prevent publication of
   a half-baked DS RRset

Is “half-baked DS RRset” a term-of-art?  To improve readability, I recommend not using an idiomatic expression.

** Section 7.  Editorial. Per the reference to [draft-ietf-dnsop-dnssec-bootstrapping], this should likely be something like “[This RFC]” and subsequent comment of that string being replaced by the RFC Editor.  

** idnits reports:
  ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499)
Zaheduzzaman Sarker
No Objection
Comment (2024-05-15 for -08) Not sent
Thanks for working on this specification. No objection from transport protocol considerations.
Éric Vyncke
No Objection
Comment (2024-05-16 for -09) Sent
# Éric Vyncke, INT AD, comments for draft-ietf-dnsop-dnssec-bootstrapping-08

Thank you for the work put into this document, if widely used then it could help the deployment of DNSSEC.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Tim Wicinski  for the shepherd's detailed write-up including the WG consensus *but* it lacks the justification of the intended status and uses an old template.

Other thanks to Benson Muite, the Internet directorate reviewer (at my request), please consider this int-dir review: (and I have read Peter's reply)

I hope that this review helps to improve the document,



# COMMENTS (non-blocking)

I am sympathetic to Paul Wouter's comments about 'bailiwick' and the use of "_signal". The latter is probably to late to be changed.

## Section 2

Two normative "SHOULD" but no reason/suggestion on when the SHOULD can be bypassed.

## Section 4.1.1

"" is not a IANA/IETF reserved domain name. Suggest to use an actual reserved domain name.

Suggest to also add the RR type in the example.

Perhaps explain `Publication of signaling records under the in-bailiwick domain is not required`.

## Section 7

Like Erik Kline, I wonder whether the IANA considerations should include a request for _dsboot. The use of _dsboot is only briefly mentioned in section 1.1, which is rather weak for a proposed standard document (I was close to open a DISCUSS on this topic).