Proposal for using NAPTR/URI records

[Petr Spacek]

On 26.2.2015 16:57, Nathaniel McCallum wrote:
> On Thu, 2015-02-26 at 15:17 +0100, Petr Spacek wrote:
>> 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.
> 
> MIT has expressed (on a phone call) two concerns with moving URI to 
> the default lookup (with SRV as secondary):
> 1. Additional latency for a protocol which nobody is (yet) using.
Oh no! This reminds me DNS-milisecond-wars we have with web browsers
(DANE/TLSA) which then spend seconds executing Flash or Javascript ...

Keep in mind that even non-existence of record is cached in DNS infrastructure
so answer for one client on the same site will be (most likely) served from
site-local cache to other clients.

Trade-offs are certainly possible but should be weighted carefully.

E.g. clients can start with classical SRV query and try URI later. It might be
possible to use SRV results for first communication with KDC and move to
servers specified by URI later but I see two problems with this approach:
- This will lead to timeouts in cases where only MS-KDCPP is usable (because
the first try will go to wrong servers or over a wrong protocol).
- It will be harder to debug and people have problems with debugging even today.

> 2. DNS stacks which drop queries for unknown QTYPEs.
There should be always fallback to SRV so I do not see it as a huge problem.

You will either wait for timeout for URI and fall back to SRV or do it the
other way around and disgust users who will depend on URI.

Support for unknown RRtypes is mandated by RFC 3597, after all. Users will
complain and that should be very good reason for fixing your DNS stack :-)


I think we are over-engineering this a little bit. Does MIT Kerberos
distribution have something like 'experimental' label for features?

Would it be possible to use some simple and straightforward approach for the
first release with URI support and make it more complicated only if really
really necessary?

I have fear that all the complexity we would have to add for (I hope) unlikely
cases is unnecessary and will lead to poor user experience.

Petr Spacek  @  Red Hat

> What is your take on adding URI records for the _kerberos._(udp|tcp) 
> prefixes? Is there precedent for this? It would allow for a single 
> query to produce both results (SRV, URI). But it seems (to me, a DNS-
> newbie) odd to put a URI record under SRV prefixes.
> 
>> 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.
> 
> I agree.