Proposal for using NAPTR/URI records

[Nico Williams]

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.

Nico
--