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.
Specifically, query type ANY "matches all RR types" for that node on
that server. There's an example in RFC 1034 of how a CNAME record is
returned by "a type CNAME or * query". There's nothing telling clients
to avoid this query type; it's perfectly valid for a client to treat a
server that refuses this query type as a broken server, because that's
exactly what the server is. Of course, there's no guarantee of which RR
types for a node are available at a cache, but a client is guaranteed to
be able to detect CNAME records from responses to query type ANY (as
qmail does), since a CNAME type prohibits all regular RR types.
I started using these standard ANY queries for interoperability reasons
(working around a BIND bug and matching sendmail behavior at the time)
but the choice continues to provide some efficiency benefits, larger
than many of the efficiency benefits used as rationales in IETF
protocols. 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.
Let's now take a look at draft-ogud-dnsop-any-notimp-00.txt with this
background in mind. The I-D specifies behavior that
* violates the existing mandatory DNS standards and that
* breaks interoperability with this standards-compliant use of ANY.
An accompanying blog post says that "in a few weeks" the author's
organization will begin deploying this standards violation---with the
effect of immediately damaging Internet email delivery. The blog post
and ID contain a number of dubious assertions attempting to justify this
change.
I don't mean to suggest that protocols must never change in incompatible
ways. However, modifications to IETF's standard protocols need to be
handled through the established IETF procedures, with appropriate
respect for the existing standards and the installed base:
* First: The proposed protocol modification has to be taken to an
IETF working group chartered to modify the protocol, so that
stakeholders will have a proper chance to evaluate and comment on
the proposal.
* Second: The merits of the protocol modification have to be properly
discussed in that working group, to evaluate the costs and benefits
of the protocol modification---and to consider whether there are
better ways to achieve the same benefits.
* Third: _If_ the benefits of the modification are judged to outweigh
the costs, a sunset period---in this case, a timeline for the
client to stop using ANY queries---has to be specified, to avoid
interoperability problems. This period has to be several years,
recognizing the time required for client administrators to hear
about and carry out the necessary redeployment. (It's not as if
we're talking about an emergency security change.)
* Fourth: After the sunset period expires, the server will be free to
use the modified protocol---in this case, to refuse ANY queries.
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 and as a result creating interoperability
problems---but this is making a mockery of the IETF standardization
process. This is _not_ a mere operational change within the existing
protocol; it is _not_ a private extension using the standard negotiation
mechanisms; it is a flagrant violation of the required DNS standards.
My understanding is that dnsop@ietf.org is not chartered to make DNS
protocol changes, so any discussion here will have to be repeated in an
appropriate working group, but let me nevertheless comment on the two
benefits claimed for having servers refuse ANY queries:
* Refusal would reduce DNS amplification: This argument already seems
to have been dismissed by various people, and doesn't seem to be
defended. It's obviously less effective than standards-compliant
approaches such as limiting UDP responses to 512 bytes.
* "Attempting to handle ANY queries creates enormous complexity in
our DNS server code base": This is a quite puzzling claim,
especially since the specified features (load balancing, geoip,
etc.) have been supported for many years by other software that has
no trouble handling ANY. What exactly is the claimed difficulty in
copying records from, e.g., the "A" key to the "*" key in the
underlying database?
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."
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.
---Dan
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
