Proposal for using NAPTR/URI records

[Nico Williams]

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

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

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

Nico
--