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?

    
<http://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-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 ...

Doug

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to