On 4/12/21 5:42 PM, John C Klensin wrote:
--On Monday, April 12, 2021 15:43 -0700 Michael Thomas
<mike@xxxxxxxx> wrote:
The one thing that bugs me about DANE is its use of a native
RR type. This is a well trodden argument of doing it proper
and doing it in a deployable way. We know what happens when
you do it the "right way" which is usually nothing at all. If
it started to get popular, we could gin up a TXT record
alternative though, I suppose. When we were doing DKIM at
Cisco, our IT folks were incredibly accommodating, but
implementing a new RR type in their infrastructure would have
probably been a bridge too far. Heck, I wouldn't be surprised
if Mark at Y! got told the same thing :)
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.
Mike
