Proposal for using NAPTR/URI records

[Nathaniel McCallum]

On Thu, 2015-02-26 at 13:15 -0600, Nico Williams wrote:
> On Thu, Feb 26, 2015 at 01:07:17PM -0500, Nathaniel McCallum wrote:
> > On Thu, 2015-02-26 at 12:41 -0500, Greg Hudson wrote:
> > > I would expect trouble if 1.14 came out and, by default, every 
> > > Kerberos realm discovery started doing a failed URI lookup and a 
> > > successful pair of SRV lookups, when previously only the pair of 
> > > successful SRV lookups was required.  That trouble might take 
> > > the form of slightly increased latency multiplied over many 
> > > realm discoveries, or greatly increased latency because the URI 
> > > lookup times out.
> > 
> > My main concern for not finding this compelling is that if the 
> > realm has SRV records it means the realm owners have (at least 
> > some) influence over DNS. Given that assumption, if the failed URI 
> > lookup is problematic, they can just replace the SRV records with a
> > URI record since they have influence over DNS.
> 
> "replace" won't work, because we'll have "legacy" clients still 
> looking for the SRV RRs.  I'm sure you meant "augment".

Yes, of course. I meant "replace" from the client perspective.

> > This is overall a win for them anyway, since they have replaced 
> > two SRV record queries with one URI record query. So if 
> > performance is so critical to them that adding one failed lookup 
> > is a problem, they should be happy to make a small change and cut 
> > their number of queries in half (2 SRV => 1 URI).
> 
> But there's a transition period.  We don't do flag days.

I'm not sure of your point here. Adding a DNS record shouldn't take 
that long unless your TTL is in weeks. :)

> > > Nico's type=ANY approach is interesting, but concerning if it 
> > > could result in failures (especially timeouts) due to servers 
> > > disabling type=ANY queries.
> 
> That's unfortunate.
> 
> One possibility might be to first do a query for some record type 
> (SOA, whatever) for the parent domain (e.g., _udp.domain.name.) then 
> two concurrent queries for the desired domain 
> (_kerberos._udp.domain.name. for SRV, and _kerberos.domain.name. for 
> URI).  This would be a partial QName minimization to make the two 
> concurrent queries less burdensome.
> 
> Or just the two concurrent queries and hope that the cache will be 
> able to optimize them (e.g., if it does QName minimization it will 
> have ample time to coalesce the common part of the two concurrent 
> queries, but if the caching resolver does not do this then the two 
> queries will be burdensome).
> 
> We do have a responsibility to minimize the DNS query burden.
> 
> Speaking of which: it's getting to be time to NOTE WELL and/or move 
> to an appropriate IETF list.  Please acknowledge.

I'm not sure this is necessary just yet since I believe the above 
proposal is simple and workable. If we are agreed, then I can write up 
an ID and propose it to kitten. A request for review from DNS folks at 
IETF can be made as well.

Basically, my proposal as it stands now is a single URI record: 
_kerberos.$REALM. This can return URIs for UDP, TCP and MS-KKDCP. This 
record would be the default, in front of the current SRV record 
lookups on the basis that it provides a superset of the functionality 
and a reduced query load (1 URI vs 2 SRV).

Admins concerned about the performance impact can simply add the URI 
record and receive the same functionality as SRV with less queries.

I don't think was should attempt to work around broken DNS stacks 
(i.e. illegal behavior for unsupported RRs).

Does this sound good to everyone? If so, I'll write up the ID. Speak 
now or forever hold your piece (pun intended).

Nathaniel