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

Edward Lewis <> Mon, 09 March 2015 16:56 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6E87D1A8BC4 for <>; Mon, 9 Mar 2015 09:56:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OayeIeFLFFwi for <>; Mon, 9 Mar 2015 09:56:01 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id F02311A8AF8 for <>; Mon, 9 Mar 2015 09:56:00 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.847.32; Mon, 9 Mar 2015 09:55:59 -0700
Received: from ([]) by PMBX112-W1-CA-1.PEXCH112.ICANN.ORG ([]) with mapi id 15.00.0847.030; Mon, 9 Mar 2015 09:55:59 -0700
From: Edward Lewis <>
To: Jared Mauch <>
Thread-Topic: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
Thread-Index: AQHQWnR2uDXa0vwttkGLrWqOYN+WYp0UdWYAgABIh4D//9NBAA==
Date: Mon, 9 Mar 2015 16:55:58 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3508750552_15427846"
MIME-Version: 1.0
Archived-At: <>
Cc: "" <>
Subject: Re: [DNSOP] [dns-operations] dnsop-any-notimp violates the DNS standards
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Mar 2015 16:56:03 -0000

On 3/9/15, 11:36, "Jared Mauch" <> wrote:

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

We got a few complaints to the help desk.  To quiet this, we resumed
answering with a mind to stopping again in the future.  The next was to
take on messaging towards a resumption of disabling ANY responses, this
did happen (and there are presentations in some archives as a result of
this) including the set of slides I refer to as my manifesto (DNS-OARC,
Dublin workshop).

Then events overcame concern about the ANY load.  Our system became
over-provisioned enough to handle the extra load we experienced and we
developed a solution to handling DDos flood attacks.  Inside operations,
the ANY queries were no longer a concern.

I'll add that what never rose up as an issue, as is mentioned in the blog
post, was the complication in assembling the ANY response in face of
tailored responses. From this I cannot conclude anything, either we didn't
see the complication or we never looked hard enough.  But I can see that
this could be an issue.

>This isn’t standing in opposition to change, but trying to understand the
>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
>for websites that have low TTLs vs being ‘sticky’ to an old A/AAAA record.

I think you are correct is saying that there are missing parts of the
problem.  Not saying "you are missing" but I believe that there hasn't
been a formal tradeoff analysis documented and made public.  I'm a bit
concerned that some have proposed expanding the scope to include other
queries (meta- and RRSIG) without having the problem fully discussed.

And this opens the door to whether "Firefox was brow-beaten" or observed
load caused Firefox to be convinced to reverse course.

>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.

While I am of the opinion that disabling ANY queries would be a good thing
to do, I'll admit that I am not certain.  I could be wrong.  I haven't
undertaken any such study because my motivation to spend time on this has
evaporated (no longer being an operator for one).  But I will contribute
my experiences and hypothesis to anyone performing the study.