Proposal for using NAPTR/URI records

[Nathaniel McCallum]

----- Original Message -----
> I didn't say anything about failure.
> 
> 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.

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

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 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.

Would MIT be interested in doing the above but making it a lower priority than SRV (for now)?