On Mon, 20 Mar 2017, Jim Reid wrote:
The traditional understanding of ANY == ALL is well ingrained in developers.
[Citation needed.]
draft-ietf-dnsop-refuse-any is about something completely different. In case
you hadn't noticed, the draft's about a server-side issue.
Funny, how in this discussion about ANY there is already confusion about
what kind of ANY we are talking about. It seems that is all the
citation that is needed here :)
I can confirm that only DNS geeks understand the limitations of ANY and
its relation to what's in the cache or not. It is very prone to be
misunderstood by non DNS geeks.
It's not going to make the slightest difference to idiot/lazy applications that
make ANY queries instead of doing The Right Thing. They'll still be getting
answers which might or might not contain the data they're looking for.
That is correct. But it will confuse the human operators, especially:
If a DNS operator prefers to reduce the potential for information
leaks, they MAY choose to not to send large ANY responses.
However, I think that the abuse versus the gain here has been decided
many years ago, and whether or not we will state this in a document,
this kind of behaviour is going to happen or rather, has already
happened. So let's standarize it.
So below is my review of draft-ietf-dnsop-refuse-any-04. I'm still a bt
undecided over whether to use HINFO or allocate a new special RRTYPE.
One of my concerns is that attackers may try to find or create zones
that happen to have a real HINFO record in them, possibly tweaked to
their use, like an HINFO with different CPU/OS values and a zero TTL.
Section 4:
At section 4, item 3, it could give advise based on source-verified
transport, so that ANY queries received over TCP or with DNS-COOKIES
could include more data then potentially spoofed UDP packets. But perhaps
that is not worth it, because ANY queries shouldn't really be used by
applications, and humans will likely use dig without tcp or cookies
enabled. So I am fine with the current text as well. But I think it
would be cleaner if we no longer refer to UDP and TCP when we really
mean "source IP verified transport" when we say that.
In section 4.2:
I'm not sure what this is refering to:
understanding that a TTL that is too long might make policy changes
relating to ANY queries difficult to change in the future.
And:
In the case of DO=0, the RRSIG SHOULD be omitted.
Why is that not a MUST ? What is the use case for the "not SHOULD"
branch? And which DNSSEC RFC would need to be Updated: by this document
as well :)
In Section 4.3:
As in the first one if the zone is signed
is pretty ackward to read :P
In some cases it is possible to guess what the initiator wants
I'm not sure if I want any DNS RFC to claim it is ok to guess what the
client wants. Instead, I would write some text that either refers to
one of the efforts to ask for multiple types of records in one query,
or if we think those drafts aren't mature enough and might obsolete,
I would rewrite this section to:
Some implementations already reduce ANY query responses by
returning CNAME or the set of MX, A plus AAAA RRsets, and
filtering out any other existing RRsets at the QNAME. The
main drawback is that such a response can still result in
a useful amplification effect.
If the zone is signed and the query has the DO bit set, the
response MUST include RRSIGs for all RRsets returned.
Section 4.4:
I would change "TCP" to be "Source address verified transport" so it also
includes queries received with DNS COOKIES. I would also add a note
here about the real problem, which is that DDOS attacks not using
spoofing would still cause an amplification attack when using a source
address verified transport.
Section 5:
I would rewrite this to make the distinction between a caching resolver
and a stub client clearer. That is currently done indirectly with the
MAY keyword which I think is wrong. eg something like:
A caching resolver MUST cache the resulting RRsets of a QTYPE=ANY
query in the same way it caches non-ANY QTYPEs, and MUST use the
HINFO record similar to any other record for the purpose of
answering any further QTYPE=ANY requests from its cache.
A non-caching stub or resolver MUST process or replay the obtained
DNS reply to a QTYPE=ANY request similarly to a non-ANY QTYPE response.
Section 5 and Section 6:
I'm unclear why the document wants different caching resolver behaviour
based on the CPU value of the HINFO record. Why does it matter? I fear
it might allow attackers to use zones that cannot reply with the answer
needed to suppress further ANY queries. If it has anything in its cache,
it should just return that anyway as per normal QTYPE=ANY processing?
So I don't understand the warning for Section 6 either?
Section 7:
I would add a quick sentence about HINFO and the TC bit to the
introduction. The TC bit behaviour seems quite important, and I
think an implementer who reads a section names "Updates to RFC 1035"
might skip reading this thinking it is not that important.
and implementation of the guidance provided by this document is
OPTIONAL.
This OPTIONAL use is again a bit confusing with the RFC2119 language
used. I'd prefer to see strong language like MUST/MUST NOT for
implementations of this document. Obviously the whole document is
optional to implement.
Section 8:
This should get a marker for the RFC Editor to remove this section as
per RFC 7942. At least I hope this was the intent :)
Section 9:
I find this section more describes the goal of the document, and not so
much the security considerations of the implementation of this draft.
I think this section should really only talk about implementation
concerns (which I don't know of any) or concerns about the ANY query
having turned into a "lie" (which I think has been considered and while
it is deemed to confuse some human operators for a little while, it is
not expected to have an operational effect on properly implementd or
inpromperly implemented consumers of ANY responses.
NITS:
- A few language issues which I'll send as xml diff to the authors
- Should it be "RRset" instead of "RRSet" ?
- "a small one(s)" reads a bit ackward.
- In 4.2, the "SHOULD" is a bit confusing as this is only one of 3
methods suggested, so it feels more like a MAY? Or perhaps this
is better rewritten without RFC2119 language?
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
