Edward Lewis writes:
> Operators are not bound to comply with what the IETF documents.
As I said before, this is making a mockery of the IETF standardization
process. Instead of
* obeying the existing mandatory standards,
* giving due respect to the installed base relying on the standards,
* trying to build consensus for a transition that demands action from
the installed base, and
* taking the slow steps necessary to maintain interoperability during
a transition if any transition happens,
a large operator is using its market position to violate the standards
and _create_ interoperability failures as a tool to enforce a protocol
change that it wants. Furthermore, a few weeks before this standards
violation is going to be deployed, the stated rationale for the change
is undergoing massive revisions, making serious discussion difficult and
leading observers to wonder how carefully the change was thought through
in the first place.
If you want IETF standards to be taken seriously---if you think that the
basic rules of Internet communication should be established by consensus
in IETF, and not simply overridden by future developers and operators
who think they know better, including cases where you _don't_ agree with
them---then you have to stop endorsing standards violations.
Tony Finch writes:
> qmail uses ANY queries for domain canonicalization on outgoing
> messages, as specified by RFC 1123. But canonicalization is not
> required by the current SMTP specification. It is a waste of time.
I fully agree that this was made optional in SMTP---that qmail is no
longer required to do this. But how do you leap to the wild conclusion
(stated twice in your message) that this is a "bug" in qmail?
More importantly, why do you think this is relevant to anything that I
said? I didn't say that qmail's behavior is currently required for SMTP.
I said that qmail is very widely deployed and relies upon ANY queries in
a way that is guaranteed to work by the mandatory DNS standards. The
dnsop-any-notimp proposal ignores those standards and will create real
interoperability problems with mail delivery.
> Using an ANY query suppresses alias processing, so qmail makes a
> series of queries to follow CNAME chains. This is inefficient and
> wasteful.
No, you have the efficiency picture backwards. CNAME chains have always
been an extremely small fraction of the DNS queries inside mail, while
the QTYPE=ANY side effect of preloading MX/A records has always produced
a significantly larger reduction in DNS queries.
This item is something else that you explicitly label as a "bug". You
keep using that word; I do not think that word means what you think it
means.
> qmail's DNS response buffer is too small to accommodate a complete DNS
> message, so it fails if it gets a large response.
Precisely how many bytes do you believe are in "a complete DNS message"?
65535, the TCP limit? Do you seriously believe that 65535-byte responses
work reliably today, and that any failure to handle such responses is a
"bug"? How about 512, given the fact that the mandatory DNS standards do
_not_ require TCP support? Or maybe 1280, the recommended safe size for
EDNS0 UDP (depending on the network etc.)?
Even in an imaginary world where 65535-byte responses work, what do you
think happens if a server administrator puts _more_ than 65535 bytes of
records at a single node? Do you blame the server administrator? If DNS
implementors handle this use case by introducing a DNS transport capable
of handling 4-gigabyte responses, will you then claim that there's a
"bug" in every DNS client that has less RAM available or that simply
insists on a smaller limit to control its resource use?
In fact, all DNS client and server deployments have size limits on DNS
responses, and these limits have always varied, making the system as a
whole increasingly fragile for the unfortunate administrators pushing
the limits (notably DNSSEC administrators). The only sane way out is for
the protocol to declare a single reasonable size limit to be respected
by all clients and servers---but this implies reengineering large DNS
record types to split data across nodes (the same way that TCP splits
streams across packets), and nobody seems willing to do this work. It's
much easier to stuff all data into one node, pretend that the system
works, and blame the administrators for all of the resulting failures.
I'd be happy to discuss this issue further if anyone is interested in
fixing these aspects of the DNS protocol. I would, however, suggest
starting a separate thread for that, since this really isn't relevant to
how dnsop-any-notimp violates the DNS standards.
---Dan
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
