Re: [DNSOP] Second Working Group Last Call: draft-ietf-dnsop-refuse-any

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Doug Barton wr
ites:
> I think this is a bad idea generally, and that RRL is a better solution
> to the amplification vector issue. But since the "War on ANY" doesn't
> show signs of abating ...
>
> On 03/16/2017 09:27 PM, Richard Gibson wrote:
> > To re-raise my unaddressed points from the first Working Group Last
> Call:
> >
> >   * There is no mechanism for signaling section 4.1/ section 4.3
> >     "partial response" behavior to clients (e.g., a new OPT record EDNS
> >     header flag bit
>
> This is my chief concern. However much the purists don't like it,
> various things in the wild ask for ANY fully expecting that it means
> ALL. If something gets an ANY response that does not include the thing
> it really needs, how is it supposed to know that it needs to ask again?

Well if you are asking a recursive server there is 20+ years of
implemention history where * doesn't give all possible records,
only which is cached.  Retrying with specific types is built into
applications which use *.  They would fail too often otherwise.

So at this point we are only talking about tools that only talk
directly to authoritative servers or look at the "aa" flag to
determine if they are talking to a authoritative server.

Now, there is really only one signal that will work with old software
and that is TC=1.  New software could just use TCP by default for *.

In terms of possible signals, other than TC=1, adding a EDNS
option/flag would require relaxing ban on adding a OPT record to a
non EDNS query.  One could use the last DNS header bit.

> <http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-p
> arameters-13>).
> >   * Insisting that the HINFO OS field SHOULD be empty ("set to the null
> >     string") seems a little too strong; there's room in it for-and value
> >     from-a short explanation (e.g., as can be observed
> >     today: dns.cloudflare.com
> >     <http://dns.cloudflare.com>. 3789INHINFO"Please stop asking for ANY"
> >     "See draft-ietf-dnsop-refuse-any"). I'd prefer text like "The OS
> >     field of the HINFO RDATA SHOULD be short to minimize the size
> >     of the response, and MAY be empty or MAY include a summarized
> >     description of local policy."
>
> Agreed. I'd rather see this flipped, with auth servers encouraged to
> include a brief explanation, or even a URL that explains the issue.
>
> >   * "ANY does not mean ALL" is misleading-RFC 1035
> >     <https://tools.ietf.org/html/rfc1035#section-3.2.3> is clear about
> >     QTYPE=255 being "a request for *all* records" (emphasis mine). That
> >     said, the proposed /response/ behavior is consistent with that RFC.
>
> That may be true technically, but I doubt anyone but a serious DNS RFC
> purist would understand, or agree with that distinction.
>
> Personally I have a lot of sympathy for the school of thought that says
> to send nothing back but the TC bit, and force the requestor to
> reconnect with TCP. But the "War on TCP" doesn't show any signs of
> abating either ...

Or TC once the answer exceeds a threshold.

> Doug
>
> _______________________________________________
> DNSOP mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]