Proposal for using NAPTR/URI records

[Greg Hudson]

On 02/26/2015 11:53 AM, Petr Spacek wrote:
>> 1. Additional latency for a protocol which nobody is (yet) using.
> Oh no! This reminds me DNS-milisecond-wars we have with web browsers
> (DANE/TLSA) which then spend seconds executing Flash or Javascript ...

I'll me speak directly so Nathaniel doesn't have to interpret my statements.

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.

I am less concerned about adding an additional lookup to the case where
a realm doesn't exist.  That is, where we are currently doing two
failing SRV lookups and giving up, adding a third failed URI lookup
doesn't seem likely to cause trouble.

For unfortunate reasons, Kerberos realm KDC discovery can be repeated
multiple times during a single user operation, due to fallbacks or other
concerns.  In the past I investigated a performance issue where ssh was
taking three seconds to perform 96 DNS requests and 12 KDC requests to
decide that a server didn't support Kerberos.  (There were no timeouts,
and each request was satisfied pretty quickly.)  That led me to
implement deferred hostname lookups and remove some unnecessary realm
traversal logic in the TGS code.

Of course we could implement internal DNS caching, but that would add a
lot of complexity.  And of course the right answer is a local caching
DNS resolver with proper negative caching, but that doesn't seem
terribly common yet.

Nico's type=ANY approach is interesting, but concerning if it could
result in failures (especially timeouts) due to servers disabling
type=ANY queries.