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

Paul Vixie <> Mon, 16 March 2015 14:53 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 300B11A87AA for <>; Mon, 16 Mar 2015 07:53:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PY_ckR_-Pamr for <>; Mon, 16 Mar 2015 07:53:29 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 88A161A87E7 for <>; Mon, 16 Mar 2015 07:53:24 -0700 (PDT)
Received: from [] ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 091E61814C; Mon, 16 Mar 2015 14:53:23 +0000 (UTC)
Message-ID: <>
Date: Mon, 16 Mar 2015 23:53:17 +0900
From: Paul Vixie <>
User-Agent: Postbox 3.0.11 (Windows/20140602)
MIME-Version: 1.0
To: bert hubert <>
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/alternative; boundary="------------000900000705030108010800"
Archived-At: <>
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, 16 Mar 2015 14:53:31 -0000

> bert hubert <>
> Monday, March 16, 2015 11:23 PM
> On Mon, Mar 09, 2015 at 04:18:12PM +0100, bert hubert wrote:
>> On Mon, Mar 09, 2015 at 11:08:03AM -0000, D. J. Bernstein wrote:
>>> My "qmail" software is very widely deployed (on roughly 1 million SMTP
>>> server IP addresses) and, by default, relies upon ANY queries in a way
>>> that is guaranteed to work by the mandatory DNS standards.
> (...)
>> Do you think I read 4.3.2 wrong? Or is there another RFC that updates the
>> algorithm?
> Thanks to some clarification from Dan, I now understand that one can indeed
> rely on ANY queries to resolvers to either deliver a CNAME or no CNAME, in
> which case there is no CNAME. 

i'd like to see those clarifications. if any non-CNAME RRset had existed
and been cached, and then replaced by a CNAME, then ANY would not see
the CNAME until the last non-CNAME RRset had expired from that cache.

which is why, when i want to know if there is a CNAME, i ask if there's

i realize that this only matters when the non-CNAME TTL's are one to two
weeks long, and weren't trimmed before replacement with the CNAME.
however, that situation is common enough that i dispute the phrase
quoted above, "guaranteed to work by mandatory DNS standards."

> Separately, I fail to see why we actually need to outlaw ANY queries when we
> can happily TC=1 them. 

TC=1'ing them would be a way to prevent them from being used as an
amplifying reflector. that is not the use case for this. the updated
document makes clear that the iteration complexity in split-authority
systems having a lightweight front end, is the situation where ANY is

there never was an ANY-related problem for which TC=1 was the solution.

Paul Vixie