Proposal for using NAPTR/URI records

[Petr Spacek]

On 25.2.2015 21:58, Nico Williams wrote:
> On Wed, Feb 25, 2015 at 03:22:20PM -0500, Nathaniel McCallum wrote:
>>> Use URI RRs, but not NAPTR.  That's my take.
>>>
>>> SRV RRs don't fit well because of the lack of a URI scheme (could be
>>> http: or https:, but hopefully just http:) and the lack of a local
>>> part (which can be overcome by using the port number and a fixed local
>>> part, though it will upset some people, and perhaps rightly so).  If
>>> SRV RRs are already in use for this use-case, so be it, but URI would
>>> be more fitting for a standard.  NAPTR seems a little overwrought for
>>> this use case, and anyways, it's the tool I'd reach for last: when
>>> nothing else will work.
>>>
>>
>> The problem is that SRV RRs are currently used for KDC discovery. But
>> they can't represent a MS-KKDCP endpoint.
> 
> We agree violently: your reply to this point restates mine without the
> details :)
> 
>> I'm happy to have a scheme like this and just use URI RRs:
>>   * krb5+https://kdc.example.com/kdc
>>   * krb5+http://kdc.example.com/kdc
>>   * krb5+tcp://kdc.example.com
>>   * krb5+udp://kdc.example.com
>>   * krb5://kdc.example.com
> 
> Wait a minute.  You want to _replace_ the existing SRV-based discovery
> method for the _kerberos _udp and _tcp cases?  Is that right?  If so,
> why?
> 
> My guess: to economize on DNS queries.  Of course, one could
> send three queries concurrently, but the full set of possible
> optimizations would be difficult to achieve.
> 
> So do one query for _kerberos.realm.name. looking for URI RRs, and let's
> define a krb5 URI scheme, so that then we'd have:
> 
>   _kerberos.example.com. IN URI 1 1 http://kdc.example.com:1234/local-part
>   _kerberos.example.com. IN URI 1 1 kdc:kdc.example.com:88/udp
>   _kerberos.example.com. IN URI 1 1 kdc:kdc.example.com:88/tcp
>   ...
> 
> One query gets you all the answers (or some, if you truncate, though if
> you want DNSSEC you're probably not truncating).  If you find nothing,
> then you query _kerberos.{_udp, _tcp}.example.com. and benefit from all
> the cached records for ., com. and example.com.
> 
> BUT, since SRV is what existing installations have, the better way
> forward would be to reverse this and first query for _kerberos.{_udp,
> _tcp}.example.com. then _kerberos.example.com.
> 
> AND, since the client would start with the "legacy" queries, might as
> well publish URI RRs there too:
> 
>   ; SRV RR for UDP
>   _kerberos._udp.example.com. IN SRV 1 1 88 kdc.example.com.
> 
>   ; URI RRs for proxy, UDP, and TCP, why not?
>   _kerberos._udp.example.com. IN URI 1 1 http://kdc.example.com:1234/local-part
>   _kerberos._udp.example.com. IN URI 1 1 kdc:kdc.example.com:88/udp
>   _kerberos._udp.example.com. IN URI 1 1 kdc:kdc.example.com:88/tcp
> 
>   ; SRV RR for TCP
>   _kerberos._tcp.example.com. IN SRV 1 1 88 kdc.example.com.
> 
>   ; URI RRs for proxy, UDP, and TCP, why not?
>   _kerberos._tcp.example.com. IN URI 1 1 http://kdc.example.com:1234/local-part
>   _kerberos._tcp.example.com. IN URI 1 1 kdc:kdc.example.com:88/udp
>   _kerberos._tcp.example.com. IN URI 1 1 kdc:kdc.example.com:88/tcp
> 
> Publishing extra RRs is cheap; extra queries are not.
> 
> This way we can have a single query get the client all the answers.
> 
> Let's call that the goldilocks proposal.
> 
> (A bit presumptuous.  Maybe it isn't quite just right yet.)
> 
>> However, that wouldn't provide backwards compatibility with SRV. Also,
>> MIT seems to be hesitant about adding any new method with higher
>> priority than SRV search. Also, in the past MIT has expressed a
> 
> No kidding: SRV is what existing clients do and what sites publish.
> 
>> dislike of the above types of URI schemes. I do think that the above
>> scheme has the advantage of being able to set priorities (between
>> transports) with a single RR.
> 
> I'm with them on this :)
> 
>> Would MIT be interested in doing the above but making it a lower
>> priority than SRV (for now)?
> 
> See my goldilocks proposal above.

Personally I very much agree with Nico's proposal (or my understanding of it):
Keep current SRV tcp/udp records + add URI which can hold the same information
as SRV tcp/udp.

My expectation is that URI-aware client will do DNS query for URI record first
and get all the information at once instead of doing 3 separate queries.
Fallback to 'classic' SRV tcp/udp should be done only if no URI records exist.

Also, I do not buy argument that an admin who is not able to properly
configure SRV+URI records will be able to configure NAPTR records. There is
little operation experience with NAPTR in comparison with SRV.

-- 
Petr Spacek  @  Red Hat