Re: DNSSEC architecture vs reality

[Michael Thomas <[e-mail]>]

On 4/12/21 5:42 PM, John C Klensin wrote:
>
> --On Monday, April 12, 2021 15:43 -0700 Michael Thomas
> <[e-mail]> 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