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

Jared Mauch <jared@puck.nether.net> Mon, 09 March 2015 15:40 UTC

Return-Path: <jared@puck.nether.net>
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 2DAD41A8A82 for <dnsop@ietfa.amsl.com>; Mon, 9 Mar 2015 08:40:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.912
X-Spam-Level:
X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 z2nJsc9GJP6l for <dnsop@ietfa.amsl.com>; Mon, 9 Mar 2015 08:40:45 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) by ietfa.amsl.com (Postfix) with ESMTP id 53CB91A8F35 for <dnsop@ietf.org>; Mon, 9 Mar 2015 08:36:05 -0700 (PDT)
Received: from [IPv6:2601:4:f02:6c00:6007:e340:a853:78b7] (unknown [IPv6:2601:4:f02:6c00:6007:e340:a853:78b7]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id 49EE55406EA; Mon, 9 Mar 2015 11:36:04 -0400 (EDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2087\))
Content-Type: text/plain; charset=utf-8
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <D1232D95.992E%edward.lewis@icann.org>
Date: Mon, 9 Mar 2015 11:36:01 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <3BDB9CDE-6048-4FDD-B1C5-6DFF6F223D43@puck.nether.net>
References: <20150309110803.4516.qmail@cr.yp.to> <D1232D95.992E%edward.lewis@icann.org>
To: Edward Lewis <edward.lewis@icann.org>
X-Mailer: Apple Mail (2.2087)
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.5.11 (puck.nether.net [0.0.0.0]); Mon, 09 Mar 2015 11:36:04 -0400 (EDT)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/mWqRSDpAAMDxGy4ibW5QtME7wac>
Cc: "dnsop@ietf.org" <dnsop@ietf.org>
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 15:40:47 -0000

> On Mar 9, 2015, at 11:16 AM, Edward Lewis <edward.lewis@icann.org> wrote:
> 
> On 3/9/15, 7:08, "D. J. Bernstein" <djb@cr.yp.to> wrote:
> 
>> 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.
> 
> (I removed the dns-operations list from this because this needs to be
> discussed on DNSOP.)
> 
> 
> Dan,
> 
> You're right.  But.
> 
> Operators are not bound to comply with what the IETF documents.
> 
> As much as operators shouldn't bully the IETF nor the public for which the
> serve, the street goes two ways.  The IETF is not able to and should not
> bully them.  The IETF is supposed to provide us with an interoperable way
> to operate and is supposed to have documents that reflect "running code.”

I would be interested in hearing the results you had from disabling ANY
queries, or anyone else results.  

This isn’t standing in opposition to change, but trying to understand the true
scope and nature of this problem.  Perhaps I’m missing parts of the problem, but
the qmail issue has existed for 10 years.  Firefox recently turned on and back off
ANY queries in 36.0 and 36.0.1 to try to keep performance what it should be
for websites that have low TTLs vs being ‘sticky’ to an old A/AAAA record.

>> * 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.
> 
> 
> If operators find that a protocol needs to be modified to be properly
> operated, the IETF ought to adjust the protocol definition.  Having a
> migration path would be a plus too.  (Said tongue in cheek.)
> 
> But - "finding that a protocol needs to be modified" is not as easy as
> that - hence my quoting of your words above.

I’m concerned a change of this sort will cause a number of people to see
something as ‘broken’ where it really is not.  If we are dealing with code
that will break things for existing users, giving them broad warning is
important, even if they are using/abusing this capability of the DNSs
system today.

- Jared