Subject: [DNSOP] draft-ietf-dnsop-refuse-any: points from Petr Špaček

From: Joe Abley <[email-masked]>
Date: Tue, 25 Jul 2017 16:53:07 -0400

Hi Petr, all,

With reference to:

  https://mailarchive.ietf.org/arch/msg/dnsop/lZDOOOOnD1kCZQ1Zvm0YF6wbWtg

> 1. The casse QTYPE=RRSIG should be made more prominent so it is
> understood and not misused as ANY. There are implementations like Knot
> Resolver which are work around missing RRSIG records in replies using
> QTYPE=RRSIG.
> 
> Personally I would rename the document from
>   Providing Minimal-Sized Responses to DNS Queries that have QTYPE=ANY
> to
>   Providing Minimal-Sized Responses to DNS Queries
>         that have QTYPE=ANY or QRTYPE=RRSIG
> 
> ... and extend Abstract as well:
>    The Domain Name System (DNS) specifies a query type (QTYPE)
>    "ANY" or "RRSIG". The operator of an authoritative DNS server might
>    choose not torespond to such queries for reasons of local policy,
>    motivated by security, performance or other reasons.
> 
> 2. Section Updates to RFC 1035 should use normative language, especially
> regarding RRSIG. Proposal follows:
>    RRSIG queries have the same potential as ANY queries of generating
>    large answers as well as extra work.  In the wild there are
>    implementations that return REFUSE, others return single RRSIG, etc.
>    It is RECOMMENDED returning a single RRSIG in this case.
> 
> 
> 3. Text about necessity of fallback in applications trying to use ANY
> query is burried under non-descriptive section name "Motivation". Given
> the confusion is caused among application developers, I would like to
> see it mentioned and explained again in section "Behaviour of DNS
> Initiators".
> 

I understand the points you're making, and I've read fanf's subsequent reaction to it (and your reaction to that).

I don't have any objection to any of those suggestions, and I'm quite happy to come up with text for them in the next rev of the draft (thanks for your suggestions in 1 and 2). If anybody else here has thoughts about specific text or violent objections to including QTYPE=RRSIG in general, please let me know (I looked in the mail archive but couldn't find any there).

The general approach I am picturing is one in which the issues for ANY and RRSIG are both described, but that implementors are free to address just one if they have particular circumstances that make that sensible. As we discuss (see Stephane's points) in the case of multiple transports, perhaps we can also recommend that implementors provide configuration options to allow administrators to deal with ANY, RRSIG, neither or both. That way we get flexibility that matches deployment, but we also get a reference for handling RRSIG in a predictable way.

Joe

---

From: Tony Finch <[email-masked]>
Date: Wed, 26 Jul 2017 11:56:41 +0100

Joe Abley <[email-masked]> wrote:
>
> If anybody else here has thoughts about specific text or violent
> objections to including QTYPE=RRSIG in general, please let me know (I
> looked in the mail archive but couldn't find any there).

I think it's helpful to mention RRSIG explicitly since it isn't
immediately obvious that it's a stealth ANY query. (It becomes
apparent to implementers fairly rapidly tho!)

> As we discuss (see Stephane's points) in the case of multiple
> transports, perhaps we can also recommend that implementors provide
> configuration options to allow administrators to deal with ANY, RRSIG,
> neither or both. That way we get flexibility that matches deployment,
> but we also get a reference for handling RRSIG in a predictable way.

I think the draft should recommend a simple on/off switch and describe
sensible behaviour when it is on. Mainly because I think we know what
that sensible behaviour is, and I don't think it's a big enough feature
to deserve a lot of configuration and documentation complexity.

Having said that, the initiator side (section 5) needs a bit of work.
Something like,

   ANY queries SHOULD be sent using the same choice of transport as other
   queries (typically, try UDP first, and only use TCP if the response is
   truncated). As an exception, debugging and diagnostics tools MAY have
   a special case for ANY queries.

(bleeding-edge versions of `dig` use TCP for ANY)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
Bailey: East becoming cyclonic, 6 to gale 8. Moderate or rough, becoming rough
or very rough. Rain or showers. Good, occasionally poor.