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

Paul Vixie <> Tue, 17 March 2015 06:31 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 19FE91A005F for <>; Mon, 16 Mar 2015 23:31:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.589
X-Spam-Status: No, score=0.589 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MRSmCs_7oZvX for <>; Mon, 16 Mar 2015 23:31:24 -0700 (PDT)
Received: from ( [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 196E31A0099 for <>; Mon, 16 Mar 2015 23:31:16 -0700 (PDT)
Received: from [] (unknown []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 71BAA1814C; Tue, 17 Mar 2015 06:31:15 +0000 (UTC)
Message-ID: <>
Date: Tue, 17 Mar 2015 15:31:07 +0900
From: Paul Vixie <>
User-Agent: Postbox 3.0.11 (Windows/20140602)
MIME-Version: 1.0
To: Michael Sinatra <>
References: <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/alternative; boundary="------------090506040006060100040609"
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: Tue, 17 Mar 2015 06:31:26 -0000

removing dns-operations@ as a cc. one mailing list at a time, please?

Michael Sinatra wrote:
> On 3/16/15 4:15 PM, P Vixie wrote:
>> > Michael, what attacks do you think we can stop by limiting ANY? Paul 
> ...
> * These domains are DNSSEC-signed with NSEC3.  Many tools set the TTL of
> NSEC3PARAM to 0 when signing zones with NSEC3.  The NSEC3PARAM RR is
> part of the ANY response.

well, that's part of your problem right there. but i can see how ANY is
involved, now.

> * The public recursive servers use an implementation that clears all
> records from the cache when the TTL of one record expires, so the next
> time the recursive server gets an ANY query, it must re-query the
> authoritative server.

this is an internet-affecting bug and i hope you report it as such.
RRsets are to be purged when the lowest TTL therein expires, but the
other RRsets sharing that name should not be affected. can i ask which
public facing dns service has mandated that the rest of us juggle their
chainsaws for them in this way? (this is even worse than the jerk who
decided that EDNS could use IP fragmentation -- but i think that guy has
apologized at least.)

> In this situation, if I set TC=1 for all ANY queries on my authoritative
> server, but the public recursives don't, then the victim still gets hit
> with a pretty big amplification attack, and my authoritative servers get
> hammered with TCP queries.

"hammered" sounds like a volume greater than that which would be
detected and strangled with DNS RRL. what am i missing here, that makes
this your problem, rather than the public recursive dns operator's problem?

> ...
> So my point is that if we're going to specify TC=1 for ANY queries, it
> has to be mandatory, and all implementations have to handle it the same:
> Send an empty NOERROR and set TC=1.  If I am the only one setting TC=1,
> it won't doing any good for the attack described above, even if my
> domains are the ones being used in the attack.
> The other option is to allow the authoritative servers to control what
> gets set out in response to QTYPE=ANY.  But I see devils in the details,
> just as with NOTIMP and other proposals.

i think there's no saving ANY at this point. we're deciding how it dies
and where to bury it, that's all.

however, you've provided an example of an ANY attack that can't be
trivially switch to TXT, so, thank you.

Paul Vixie