Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards

Paul Vixie <paul@redbarn.org> Mon, 16 March 2015 15:16 UTC

Return-Path: <paul@redbarn.org>
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 5C6851A87EF for <dnsop@ietfa.amsl.com>; Mon, 16 Mar 2015 08:16:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 jUhvG6yowFas for <dnsop@ietfa.amsl.com>; Mon, 16 Mar 2015 08:16:06 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [24.104.150.213]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 174C71A8821 for <dnsop@ietf.org>; Mon, 16 Mar 2015 08:15:56 -0700 (PDT)
Received: from [192.168.11.65] (OFSfx-13p9-14.ppp11.odn.ad.jp [39.3.162.14]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 0746F1814C; Mon, 16 Mar 2015 15:15:55 +0000 (UTC)
Message-ID: <5506F3A6.5080304@redbarn.org>
Date: Tue, 17 Mar 2015 00:15:50 +0900
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 3.0.11 (Windows/20140602)
MIME-Version: 1.0
To: bert hubert <bert.hubert@netherlabs.nl>
References: <20150309110803.4516.qmail@cr.yp.to> <20150309151812.GA14897@xs.powerdns.com> <20150316142350.GB26918@xs.powerdns.com> <5506EE5D.3000408@redbarn.org> <20150316150510.GA21645@xs.powerdns.com>
In-Reply-To: <20150316150510.GA21645@xs.powerdns.com>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/alternative; boundary="------------060302090700000607040008"
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/ejZMbBHc0w4yL3V6_vU5GAd_t0c>
Cc: dnsop@ietf.org, 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, 16 Mar 2015 15:16:07 -0000


> bert hubert <mailto:bert.hubert@netherlabs.nl>
> Tuesday, March 17, 2015 12:05 AM
>
> Sorry? We solve implementation hardship by standards action now?

as with client-subnet, we recognize that people will do what they want,
or stop doing what they don't want, especially if they are CDN providers
with a lot of revenue and a lot of expense riding on their choices. i
don't love this situation but i can tell you that quoting specifications
at folks and using words like "mandatory" isn't the way to change their
minds (or their deeds.)

noting that there's a more-than-ten-years-old CNAME patch to qmail that
just about everybody is supposedly running, i expect the operational
impact of phasing out ANY to be ~0. also, a lot of operators foolishly
patched their BIND servers to stop answering ANY because they considered
it a DDoS risk (which is patently insane but please don't shoot the
messenger) and not a single qmail user was heard from on the matter.

the internet works by cooperation. often, first mover advantage is
sticky. but almost as often, somebody like the mozilla dev team decides
that something like ANY is the solution to their API layering problem,
and the rest of us rip the bandaids off and study the underlying wound.
so it is in this case. now, mozilla has backed off, but the underlying
wound remains a visible topic of conversation.

to me the use case is, it's an information leak, and i don't want my
cache probed, and i can't tell the difference between a cache prober and
qmail, so into the same stew pot they both must go. (along with RD=0 on
an RA=1 server.)

-- 
Paul Vixie