Proposal for using NAPTR/URI records

[Nathaniel McCallum]

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.
2. DNS stacks which drop queries for unknown QTYPEs.

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.