On 4/12/21 6:16 PM, John C Klensin wrote:
--On Monday, April 12, 2021 17:48 -0700 Michael Thomas
<mike@xxxxxxxx> 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
