Re: [DNSOP] Questions on draft-ietf-dnsop-delegation-only

[Paul Wouters <[e-mail]>]

On Thu, 30 Jul 2020, Joe Abley wrote:

> My sense is that this is a nice idea in theory but doesn't solve a problem that anybody actually has, and the camel is starting to look a little bit fraught. But I don't think any proposal should succeed or fail based on anybody's uninformed sense, hence the request for more data.

This proposal is meant to increase the amount of trust people can place in
DNSSEC by decreasing the hard trust that is currently required of ICANN,
Verisign and the TLD operators. I understand in our community, we do
not see this as a big problem. Unfortunately outside our community it is.

It is further interesting that you raise your point of "the risk analysis
shows we can never afford to deploy this" when a few months ago you
raised the reverse point that "we dont want to be forced to have to use
this to be seen trustworthy". Both arguments cannot be true.

As for the DNS camel, we are talking about 1 bit and many 20 lines of
code in the resolver. Looking at the rest of the current drafts in
DNSOP, I think this isn't going to break the camel's back.

As for your single issue, the glue issue, you could also change your take
down system.  You could bring up a take-downXXX.org. zone and update
the NS glue for the GOODDOMAINS.org to use that, give out the original
IP and sign it with take-downXXX.org's key. It would even work with
resolvers that insist on hardening and confirming glue, so you would
actually improve your .org deployment independently of this draft.

What I'm trying to avoid is adding complexity to support this already
unstable "run on glue" domains. Sure, we could add an exception for
A/AAAA since these records are of low value to protect because onpath
attacks can just NAT/route it to them anyway, but doing so would
actually increase the complexity of the code and muddle the expectation
of the protetion of "delegation only" zone.

Paul