Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
"D. J. Bernstein" <djb@cr.yp.to> Mon, 09 March 2015 23:18 UTC
Return-Path: <djb-dsn2-1406711340.7506@cr.yp.to>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D7E1A01C6 for <dnsop@ietfa.amsl.com>; Mon, 9 Mar 2015 16:18:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.196
X-Spam-Level:
X-Spam-Status: No, score=0.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nAO7zYUjMKCY for <dnsop@ietfa.amsl.com>; Mon, 9 Mar 2015 16:18:47 -0700 (PDT)
Received: from calvin.win.tue.nl (calvin.win.tue.nl [131.155.70.11]) by ietfa.amsl.com (Postfix) with SMTP id CE1601A8AE8 for <dnsop@ietf.org>; Mon, 9 Mar 2015 16:18:46 -0700 (PDT)
Received: (qmail 28202 invoked by uid 1017); 9 Mar 2015 23:19:05 -0000
Received: from unknown (unknown) by unknown with QMTP; 9 Mar 2015 23:19:05 -0000
Received: (qmail 14142 invoked by uid 1000); 9 Mar 2015 23:18:37 -0000
Date: Mon, 09 Mar 2015 23:18:37 -0000
Message-ID: <20150309231837.14140.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: dnsop@ietf.org
Mail-Followup-To: dnsop@ietf.org, dns-operations@dns-oarc.net
In-Reply-To: <D1232D95.992E%edward.lewis@icann.org> <alpine.LSU.2.00.1503091438050.23307@hermes-1.csi.cam.ac.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/PIicqCTipx90VbnzvuysXgyEScI>
X-Mailman-Approved-At: Mon, 09 Mar 2015 16:20:18 -0700
Cc: dns-operations@dns-oarc.net
Subject: Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Mar 2015 23:18:49 -0000
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
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Vixie
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Colm MacCárthaigh
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Vixie
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Ted Lemon
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Mark Andrews
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Vixie
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Nicholas Weaver
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… David Conrad
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… bert hubert
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Vixie
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… bert hubert
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Vixie
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Ray Bellis
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… bert hubert
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Ray Bellis
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… P Vixie
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Michael Sinatra
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Mark Andrews
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Michael Sinatra
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Vixie
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Vixie
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Tony Finch
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Wouters
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Yunhong Gu
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Yunhong Gu
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Michael Sinatra
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Vixie
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Michael Sinatra
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Michael Sinatra
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Vixie
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Wouters
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Vixie
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Olafur Gudmundsson
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Florian Weimer
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Wouters
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Tony Finch
- Re: [DNSOP] dnsop-any-notimp violates the DNS sta… Stephane Bortzmeyer
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Edward Lewis
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… bert hubert
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Jared Mauch
- [DNSOP] dnsop-any-notimp violates the DNS standar… D. J. Bernstein
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Jared Mauch
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Tony Finch
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Tony Finch
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… David C Lawrence
- Re: [DNSOP] dnsop-any-notimp violates the DNS sta… John Levine
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Edward Lewis
- [DNSOP] clarification on DNSOP charter Re: [dns-o… Suzanne Woolf
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… D. J. Bernstein
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Darcy Kevin (FCA)
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Darcy Kevin (FCA)
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Tony Finch
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… D. J. Bernstein
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Michael Graff
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Mark Andrews
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Vixie
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Randy Bush
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Masataka Ohta
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Vixie
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Wouters
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Morizot Timothy S
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Paul Wouters
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… David Conrad
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Morizot Timothy S
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Robert Edmonds
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Nicholas Weaver
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Morizot Timothy S
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Mark Andrews
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… Darcy Kevin (FCA)
- Re: [DNSOP] [dns-operations] dnsop-any-notimp vio… D. J. Bernstein