Re: DNSSEC architecture vs reality

[Michael Thomas <[e-mail]>]

On 4/12/21 6:16 PM, John C Klensin wrote:
> --On Monday, April 12, 2021 17:48 -0700 Michael Thomas
> <[e-mail]> wrote:
>
>
>
> You also wrote:
>
>> The problem is that it's not this simple. Software needs to
>> change to implement new RR types which inevitably begs the
>> question "what's in it for me?"
> Sure.  But (different) software also has to change to implement
> (to use the comments that started us down this thread) DANE.
> Those changes are to mail software, systems, and configurations,
> not DNS support, but they are changes nonetheless.  Yes, other
> changes are needed for anything that requires that
> authentication or authorization information be stored in the
> DNS, but that raises the question of whether DANE's designers
> could have put that information somewhere else and whether that
> would have been worth it (my guess is that the answer to the
> former is "probably" and, to the latter, "probably not", but
> that is what gets us to the rant in RFC 8324).
>
> So the answer to your question is "The enterprise has decided
> DANE is useful and DNS updates are as much part of the price as
> email changes" and, if that is not enough, then either DANE is
> not actually needed or the second part of the answer is "want to
> keep your job?".
>
I think part of the key of success with new protocols is how few players 
need buy-in. The fewer the better. Had we had to get buy in from the 
folks that maintained our DNS with DKIM too, our likelihood of failure 
would have been a *lot* higher. It wasn't even a given that they'd give 
us TXT. The overarching point of my initial blog post is that when you 
have an opportunity to route around fiefdoms to get something done, you 
have a much higher chance of success. That is really the lesson we 
should take away with Google re: Quic. That's why I think it's a 
realistic opportunity for quic+dane. But finding out that Google doesn't 
sign their zones is disappointing.

Mike