Proposal for using NAPTR/URI records
simo at redhat.com
Fri Feb 27 11:52:43 EST 2015
On Fri, 2015-02-27 at 10:38 -0600, Nico Williams wrote:
> On Fri, Feb 27, 2015 at 02:58:33PM +0100, Petr Spacek wrote:
> > On 26.2.2015 20:20, Nico Williams wrote:
> > > On Thu, Feb 26, 2015 at 06:02:11PM +0100, Petr Spacek wrote:
> > >> 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 ...)
> > >
> > > I see, and it's probably a good idea, but in a DNSSEC world this is
> > > equivalent to timing out, no?
> > There are some 'legal' options how to avoid answering QTYPE=ANY queries:
> > Either send REFUSED to the client or set TC=1 in the answer and force client
> > to re-try over TCP.
> REFUSED and TC would do if they were the only _and_ uncommon failure
> scenarios. More below.
> > Anyway, Firefox folks started an interesting (and possibly unintentional)
> > experiment with ANY queries so we can watch how it works in practice.
> > See https://bugzilla.mozilla.org/show_bug.cgi?id=1093983
> See also:
> a) the thread starting at
> b) the linked report:
> RFC1035 doesn't say much about QTYPE=* queries (it says a lot more about
> the arguably useless QCLASS=* queries).
> These two reports at bugzilla.mozilla.org will be worth watching over
> the next few weeks, but my guess is that we're not likely to get much
> more data out of them, and the we're likely to see the code for type=ANY
> queries dropped.
> I'm not sure now what to suggest as to ways forward, but I'll note that
> KDC-over-HTTP protocols are not widely needed yet, and where they are,
> local configuration can be expected to work for the time being.
> We should list the constraints:
> - A very strong desire to keep DNS queries to a minimum.
> - KDC-over-HTTP protocols require all that a URI delivers: a scheme,
> authority, local part, maybe even queries (though not fragments).
> - Infeasibility of mapping SRV RRs to URIs: SRV RRs do not express
> scheme nor local part. It's not entirely infeasible, but it's quite
> distasteful (it would require either hardcoding of the local part or
> additional discovery of it) and will elicit objections.
> Using SRV RRs would require using a different domainname than
> currently used for the other KDC SRV RRs anyways, which increases the
> number of DNS queries needed.
> - Lack of universal async DNS query libraries.
> This means we can't just do concurrent queries (nor can we do a query
> for the parent domainname then two concurrent queries for the
> domainname of interest).
> We probably have to assume nothing better than the traditional ISC
> resolver found in all the BSDs, glibc, Solaris/Illumos, and so on.
> I think this adds up to: multiple DNS queries, with some local
> configuration will be needed to decide on a DNS query order.
> And we've not even begun to discuss any concept of client-side HTTP
> proxies that might need to be different for KDC exchanges than for other
> uses (let's avoid this).
My preference would be to implement the URI protocol, but not enable
querying for it by default in 1.14, add a tunable in [libdefaults ]
called something like dns_uri_lookup_kdc = false|true|only and set it to
false by default, change it to true later on ? (let downstream change
the default if they so desire)
Simo Sorce * Red Hat, Inc * New York
More information about the krbdev