[19113] in Kerberos_V5_Development
Re: Proposal for using NAPTR/URI records
daemon@ATHENA.MIT.EDU (Nico Williams)
Thu Feb 26 11:56:02 2015
Date: Thu, 26 Feb 2015 10:55:55 -0600
From: Nico Williams <nico@cryptonector.com>
To: Nathaniel McCallum <npmccallum@redhat.com>
Message-ID: <20150226165554.GB9895@localhost>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <1424966237.2830.22.camel@redhat.com>
Cc: krbdev@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu
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.
Nico
--
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
