On Sun, Jan 12, 2020 at 9:24 PM Warren Kumari <war...@kumari.net> wrote:
> Hi there, > > Firstly, thank you for a well written and easy to understand document. > > I have some comments which I think should be addressed before I start > IETF LC, but they are small enough that if you'd much prefer you can > just address them after during / after LC (if changes are needed), or > during IESG review. > Please let me know LOUDLY which you'd prefer. > Hi Warren, Let's just address them now before IETF LC .. > 1: Section 3: 3. Validating Resolver Behavior > I think it would be very useful to mention that this document doesn't > require any changes to the behavior of validating resolvers > themselves. It might also be worth mentioning somewhere that this is > also largely true for authoritative servers - this isn't really a > protocol change, rather an operational / process set of changes. > Okay, we'll mention this. "largely true for authoritative servers" seems a bit imprecise. We could probably clarify that although there are no changes to behavior/protocol for authoritative servers, there is an operational change to how their DNSKEY/CDS/CDNSKEY record sets are provisioned and managed. 2: " Zone owners will want to deploy a DNS service that responds as > efficiently as possible with validatable answers only, and hence it > is important that the DNSKEY RRset at each provider is maintained > with the active ZSKs of all participating providers." > This is somewhat ambiguous - it sounds like the zone owner may want to > deploy a service that is only efficient with verifiable answers (and > might be inefficient with bogus ones :-)) > Fair enough. I will try to word this better. 3: A question -- "Authenticated Denial Considerations" > Some CDNs and similar do funny things with e.g CNAMEs, or may do > something like generate ACME records or similar. What happens if > provider A creates e.g _acme-challenge.example.com (or www.example.com > IN 600 CNAME some-long-account-number.cdn.net) and doesn't tell > provider B? I understand that the owner names *should* be consistent, > but I think it is worth adding some text here along the lines of "here > be dragons" or similar... > I'm not sure I see the dragons here - can you elaborate? It is the zone owner's responsibility to make sure that all data records (i.e. non DNSSEC metadata) in the zone are created identically on every DNS provider, so I don't think we would expect this situation to occur. That includes ACME challenge records. 4: The document uses one inceanse of RFC2119 language (RECOMMENDED) - > please either drop this, or add the 2119 / 8174 boilerplate. > Ok, I'm inclined to lowercase it, since we don't use 2119/8174 keywords anywhere else in this document. > > Again, I'm willing to start IETF LC, or wait till you've posted a new > version, but please let me know. > W Will work on a revision (but please elaborate on 3). Shumon.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
