Re: [DNSOP] AD review of draft-ietf-dnsop-multi-provider-dnssec

[Shumon Huque <[e-mail]>]

Hi Warren,

Sorry for the delay - I just got back from a vacation, and am catching up
with email.

I will respond to your comments in the next day or two. Thanks for your
patience!

Shumon.

On Sat, Jan 18, 2020 at 5:58 PM Warren Kumari <[e-mail]> wrote:

> Checking in again...
> W
>
> On Sun, Jan 12, 2020 at 9:23 PM Warren Kumari <[e-mail]> 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.
> >
> > 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.
> >
> > 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 :-))
> >
> > 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...
> >
> > 4: The document uses one inceanse of RFC2119 language (RECOMMENDED) -
> > please either drop this, or add the 2119 / 8174 boilerplate.
> >
> > Again, I'm willing to start IETF LC, or wait till you've posted a new
> > version, but please let me know.
> > W
> >
> >
> > --
> > I don't think the execution is relevant when it was obviously a bad
> > idea in the first place.
> > This is like putting rabid weasels in your pants, and later expressing
> > regret at having chosen those particular rabid weasels and that pair
> > of pants.
> >    ---maf
>
>
>
> --
> I don't think the execution is relevant when it was obviously a bad
> idea in the first place.
> This is like putting rabid weasels in your pants, and later expressing
> regret at having chosen those particular rabid weasels and that pair
> of pants.
>    ---maf
>