--On Monday, April 12, 2021 17:48 -0700 Michael Thomas
<mike@xxxxxxxx> wrote:
>
> On 4/12/21 5:42 PM, John C Klensin wrote:
>>
>> --On Monday, April 12, 2021 15:43 -0700 Michael Thomas
>> <mike@xxxxxxxx> wrote:
>...
>> And I don't want to reopen that argument, but part of it is
>> that the original plan for TXT RR was essentially as a
>> comment field that anyone could put anything into that they
>> wanted to convey to another human. So, if it is used to
>> express protocol information, figuring out which protocol and
>> whether the data field is correct for that protocol is
>> basically a matter for heuristics, no matter how good one can
>> make them. If there is a choice, that is not a really good
>> idea. Also, it has been years since I was involved in
>> large-scale DNS operations (and, by today's standards for
>> "large", I never have been), but it seems to me that, if a
>> particular implementation or operational setup makes it as
>> hard to deal with a new RR type as your comment above
>> suggests, there is something seriously wrong with that setup.
>> And I think the language in 1034/1035 is consistent with that
>> view.
>
> Oh, don't get me wrong: using TXT records is a colossal hack.
> But operational considerations are like stubborn facts. We had
> to bite the bullet and accept NAT's too. You feel unclean and
> want to wash your hands repeatedly, but you do what you have
> to do.
An interesting analogy. The difference is that it was widely
perceived that there was no alternative to NATs other than
conversion to IPv6 and that, unless everyone converted to IPv6
on the same day, NATs would be needed to allow interoperability
between IPv6 systems and the remaining IPv4 ones. If there were
good alternatives, the IETF didn't do a good job of explaining
them and why they were better.
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?".
john
>
> Mike
>
