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
