Proposal for using NAPTR/URI records

[Simo Sorce]

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

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.

-- 
Simo Sorce * Red Hat, Inc * New York