Proposal for using NAPTR/URI records

[Nico Williams]

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
https://lists.dns-oarc.net/pipermail/dns-operations/2015-February/012886.html

and
b) the linked report:
https://bugzilla.mozilla.org/show_bug.cgi?id=1137628

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

Nico
--