Kerberos transport DNS record design

[Petr Spacek]

On 1.6.2016 17:11, Greg Hudson wrote:
> On 06/01/2016 10:31 AM, Petr Spacek wrote:
>> FreeIPA needs to have access to fields 'priority' and 'server
>> name' in the RR so server name can be mapped to location name & priority
>> associated with it.
>>
>> In case of SRV it is easy because RR format is standardized and DNS libraries
>> can work with it directly.
> 
> SRV is not really an interesting comparison unless your viewpoint is
> that MS-KKDCP transport discovery just shouldn't be implemented.
> 
> If we used URI you would have easy access to the weight (assuming your
> DNS library implements the URI RR type), but not to the server name,
> since we would be using a Kerberos-specific URI scheme.

Right, I should have mentioned URI.

With URI we could end up with a regex extracting first name after scheme
specification or something simple like that. That would be generic and safe
enough for URI (keep in mind that failure to match host name means no change
so nothing seriously bad happens).

Unfortunately simple universal regex would not work for TXT RR because even if
we found a name in it we would have to know what bytes have to be changed -
again this requires more knowledge than should be stuffed in a DNS library.


>> Custom format inside TXT record will take away this simplicity and every
>> single system which will want to do something similar will have to implement
>> parser for the custom format.
>>
>> For me as an implementer this is major downside of TXT approach.
> 
> Sure.  Structure is good for consumers who want to know about it,
> especially if they can delegate the understanding of that structure to a
> library.  Structure is bad for producers who want to know as little as
> possible, or for getting through middle-boxes which habitually reject
> structure tags they don't understand.  It's a trade-off.

My point is that URI has better trade-off in this respect and that TXT is
making integration unnecessarily complex and forces implementers to add
Kerberos-specific hacks to otherwise generic solution.

-- 
Petr Spacek  @  Red Hat