Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
"D. J. Bernstein" <djb@cr.yp.to> Fri, 13 March 2015 22:58 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 8D7E71A8741 for <dnsop@ietfa.amsl.com>; Fri, 13 Mar 2015 15:58:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.695
X-Spam-Level: **
X-Spam-Status: No, score=2.695 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_51=0.6, 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 FLbAi3YBK9KZ for <dnsop@ietfa.amsl.com>; Fri, 13 Mar 2015 15:58:20 -0700 (PDT)
Received: from calvin.win.tue.nl (calvin.win.tue.nl [131.155.70.11]) by ietfa.amsl.com (Postfix) with SMTP id 5EAFB1A8738 for <dnsop@ietf.org>; Fri, 13 Mar 2015 15:58:20 -0700 (PDT)
Received: (qmail 13143 invoked by uid 1017); 13 Mar 2015 22:58:39 -0000
Received: from unknown (unknown) by unknown with QMTP; 13 Mar 2015 22:58:39 -0000
Received: (qmail 31870 invoked by uid 1000); 13 Mar 2015 22:58:11 -0000
Date: Fri, 13 Mar 2015 22:58:11 -0000
Message-ID: <20150313225811.31868.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: <21757.51472.935664.712590@tale.kendall.corp.akamai.com>
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/VhG3VmWCEgCJpY_0W9k9SThmO5A>
X-Mailman-Approved-At: Fri, 13 Mar 2015 16:08:35 -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: Fri, 13 Mar 2015 22:58:23 -0000
I remain puzzled at the entire technological motivation that CloudFlare claims for this deliberate creation of interoperability problems. In particular, what exactly is the programming difficulty that they claim they're encountering in implementing QTYPE=*? Are they also having trouble implementing NXDOMAIN, which from a programming perspective is a very similar unification of data across all types? The rest of this message identifies specific rules that CloudFlare's threatened plan will violate in IETF's mandatory DNS standards. David C Lawrence writes: > RFC 1035 explicitly allows for a server to indicate that a kind of > query is not implemented. Whether it is a good idea to respond to ANY > this way is a separate argument that is worth having. You just won't > win on the foundation that it is a violation of the standard. Let's look at what the standards actually say. RFC 1034 clearly defines QTYPE=* to match "all RR types", along with, e.g., QTYPE=A to match "just that type". It explicitly says that "the name server looks for matching RRs". CloudFlare's stated plans will violate this rule. This "matching" for QTYPE=* is precisely what CloudFlare claims is too hard to implement! You claim that this violation of a rule in IETF's mandatory DNS standards doesn't constitute a violation of the standards. Evidently you believe that the standards contain some relevant exception to the rule. What exactly do you claim that this exception is? The foundation for your argument, apparently, is the fact that RFC 1035 defines a syntax for a NOTIMP response. But why do you think this is of any relevance to the "matching RRs" rule? The rule doesn't say "the name server looks for matching RRs, except for types that the server doesn't want to bother implementing". Where exactly, and what exactly, is the CloudFlare exception? Do you believe that the availability of a NOTIMP syntax overrides all other rules and frees the server to use this syntax for anything that it doesn't want to implement? Here's a hypothetical example to consider: * A very large cache operator is opposed to the usage of DNSSEC. (The operator's reason for this isn't relevant to this example.) * To deter usage of DNSSEC, the cache operator decides to create large-scale DNSSEC interoperability problems, augmenting DNSSEC's existing fragility. * Specifically, the cache operator issues DNSSEC queries to servers; and then, if a server response shows DNSSEC support, the cache operator returns NOTIMP to clients for _all_ of the server's data. * To avoid any sudden changes, the cache operator slowly ramps up this behavior, turning on the DNSSEC queries with higher and higher probability as time passes, but jumping immediately to probability 1 for servers that don't show DNSSEC support. * To justify the use of NOTIMP, the cache operator claims that it _wanted_ to implement actually returning DNSSEC records to clients but found this too complicated given geoip blah blah blah, so it had to return NOTIMP. It quotes your claim that RFC 1035 "explicitly allows" returning NOTIMP. Would you call this cache behavior compliant with the mandatory DNS standards? No? Why not? Why isn't the cache free to use NOTIMP whenever it hasn't implemented something? Are you quite sure that you've thought through what you're claiming? Let's continue looking at the mandatory DNS standards. RFC 1034 explicitly allows not-implemented queries in _some_ cases, such as inverse queries: Implementation of this service is optional in a name server, but all name servers must at least be able to understand an inverse query message and return a not-implemented error response. RFC 1035 is also quite clear about this: Inverse queries are an optional part of the DNS. Name servers are not required to support any form of inverse queries. If a name server receives an inverse query that it does not support, it returns an error response with the "Not Implemented" error set in the header. While inverse query support is optional, all name servers must be at least able to return the error response. If the RFCs had meant to say that _all_ DNS features are optional (leaving interoperability up to the whim of bullies, apparently what you're endorsing), then why didn't the RFCs simply say that? Why did they explicitly highlight particular features as being optional? Furthermore, RFC 1123 explicitly requires DNS software to "support all well-known, class-independent formats". This is another mandatory rule that CloudFlare's plan clearly violates. What exactly do you think this "support" requirement means, if servers are free to use NOTIMP whenever they want, for example for QTYPE=*? RFC 1034 explicitly says that a server "is free to refuse to perform recursive services for any or all clients" (and also explicitly says that an AXFR "may cause an error, such as refused") but explicitly says that "All name servers must implement non-recursive queries". Do you think a server is allowed to use NOTIMP for non-recursive queries? Do you think that "implement" prohibits NOTIMP while "support" doesn't? Frankly, your position looks _extremely_ difficult to defend. ---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