Regarding the statement "query type ANY 'matches all RR types CURRENTLY IN THE
CACHE'."
Actually, there's nothing in RFC 1034 that clearly *mandates* this behavior --
Section 3.7.1 says only that a QTYPE of * "matches all RR types", whereas
Section 5.3.3 ("Algorithm") says to return "the answer" or "the data" if it's
in the cache, but this is ambiguous with respect to QTYPE=* (other than the
highly-improbable case that we have RRsets for every possible RR type, how can
we know we have "the answer"/"the data" in our cache, given that the QTYPE
"matches all RR types" at the node and there might be other RRsets extant which
don't happen to be cached at the time? Is an answer really "the" answer if we
can't be sure that it satisfies the matching rule of the QTYPE definition?).
People cite the examples of Section 6.2.2 as definitive evidence that QTYPE=*
queries can always be satisfied by whatever happens to be laying around in a
cache, but they don't seem to notice that those were *non-recursive* queries in
the examples, and it's their *non-recursiveness* that gives rise to the lack of
rigor in returning a response (as it is whenever a non-recursive query is sent
to a DNS entity that doesn't happen to be authoritative for the relevant zone).
The required fetching behavior of a caching resolver in response to a
*recursive* QTYPE=* query, is basically undefined by RFC 1034. Common practice
is to treat QTYPE=* queries as effectively non-recursive, despite RD being set
to 1, if *any* relevant RRset exists in the cache. Possibly, this is because
the Section 6.2.2 examples were misunderstood. Or, simply because it was easier
to code that way. A more modern concern would be that this rigor could be
abused for possible DoS attacks. But, at this point in DNS histor
y, I doubt we can roll back the clock and force everyone to be rigorous in
fetching answers for QTYPE=* queries. So the answers are inherently unreliable,
and that situation is not likely to change, unless and until someone invents an
"ALL" QTYPE/RR-type/meta-type.
- Kevin
-----Original Message-----
From: DNSOP [mailto:dnsop-boun...@ietf.org] On Behalf Of Paul Wouters
Sent: Monday, March 09, 2015 10:48 AM
To: D. J. Bernstein
Cc: dnsop@ietf.org; dns-operati...@dns-oarc.net
Subject: Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS
standards
On Mon, 9 Mar 2015, D. J. Bernstein wrote:
> My "qmail" software is very widely deployed (on roughly 1 million SMTP
> server IP addresses) and, by default, relies upon ANY queries in a way
> that is guaranteed to work by the mandatory DNS standards.
And you've been told for two decades that this was wrong?
> Specifically, query type ANY "matches all RR types" for that node on
> that server.
Wrong, query type ANY "matches all RR types CURRENTLY IN THE CACHE". So the
result of qmail's ANY query is completely meaningless and qmail cannot derive
any conclusion from the absence of any record from that query.
So if the MX or AAAA record has expired from the cache but another RRtype with
larger TTL (say NS) is still in there, your ANY query will fail to find
records. qmail with this feature is broken.
Additionally, Tony Finch did a write up of qmail's ANY problems too:
https://fanf.livejournal.com/122220.html
> In new software today I would sacrifice these efficiency benefits for
> the sake of simplicity, but this doesn't mean that I'm going to
> frivolously inflict retroactive punishment upon administrators who
> have installed standards-compliant software and done nothing wrong.
You have had 10 years to fix it. Luckilly, I believe most distributions
shipping qmail add the patch to fix this already.
> I understand how a sufficiently large site might acquire the
> impression that it can safely take radical action at its own whim,
> violating the existing protocol standards
Uhm, we pointd out qmail's _bug_ for a decade. I'm quite sure even you do not
need to interop with BIND4 anymore.
> Apparently Firefox recently deployed ANY queries. I haven't looked at
> the details but I gather that they're related to the well-known
> annoyances of handling AAAA etc. Firefox was browbeaten into reverting
> this change on the basis of highly questionable claims regarding
> amplification: "It can return enormous result sets, and some
> authoritative servers have taken to refusing ANY queries because of
> the frequency with which such queries show up in amplification
> attacks" -> "I'm concerned about amplification and the perception
> thereof by security monitors."
No, they were also told that ANY queries only return data from the cache, and
using ANY queries means you might miss actual A or AAAA records. This has
nothing to do with ANY queries and amplification.
> The common theme of CNAME/MX/A and A/AAAA is that there's widepread
> interest in being able to easily retrieve multiple record types. What
> I'm saying is not that query type ANY is the ultimate answer (clearly
> it can be improved); what I'm saying is that these are protocol
> issues, and that protocol changes need to be handled by an
> appropriately chartered IETF working group.
I agree there is a use for this. I tried a few years ago to introduce a new
EDNS0 option that would allow you to query for a bitmap number of RRsets, but
people did not like it. Perhaps the WG is ready for something like this now.
Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
