Proposal for using NAPTR/URI records

[Petr Spacek]

On 26.2.2015 17:55, Nico Williams wrote:
> On Thu, Feb 26, 2015 at 10:57:17AM -0500, Nathaniel McCallum wrote:
>> On Thu, 2015-02-26 at 15:17 +0100, Petr Spacek wrote:
>>> 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.
> 
> Mine is that the *new* clients will do a single type=ANY query for
> _kerberos.{_udp, _tcp}.domain.name. and will get all the answers they
> need (if using TCP or EDNS0 for their DNS queries).
> 
>> 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.
> 
> There would be no addtional latency for my proposal (type=ANY queries
> for a domainname for which there should be only SRV (legacy) and URI
> (new) RRs.
> 
> (If the _kerberos label is a zone apex there will also be other RRs, and
> that could make these lookups marginally slower, but frankly, zone cuts
> at that point or the _udp or _tcp labels will tend to slow things down
> anyways, and anyways, who will bother doing this?)
> 
>> 2. DNS stacks which drop queries for unknown QTYPEs.
> 
> type=ANY.

I forgot to comment on this:
QTYPE=ANY is unreliable because admins are disabling it in hope that it will
mitigate DNS-amplified DDoS attacks. (It would be better to implement
source-address filtering but what you can do ...)

Unfortunately I do not have any data at hand but I believe that Viktor
Dukhovni or other folks interested in DNS and mail server could add some details.

Maybe this whole discussion should be moved to IETF dnsop mailing list? After
all, there is nothing Kerberos-specific, all the questions seems to be about
DNS service discovery.

-- 
Petr Spacek  @  Red Hat