Re: [DNSOP] More work for DNSOP :-)

Paul Vixie <> Fri, 06 March 2015 19:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5AAC41A1BE4 for <>; Fri, 6 Mar 2015 11:42:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.309
X-Spam-Status: No, score=-1.309 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_32=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_47=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 6F05NeBFrZ1g for <>; Fri, 6 Mar 2015 11:42:11 -0800 (PST)
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 5F7471A6F3A for <>; Fri, 6 Mar 2015 11:42:11 -0800 (PST)
Received: from [IPv6:2001:559:8000:cb:b015:3cb0:25ba:df77] (unknown [IPv6:2001:559:8000:cb:b015:3cb0:25ba:df77]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 8CAF61851C; Fri, 6 Mar 2015 19:42:11 +0000 (UTC)
Message-ID: <>
Date: Fri, 06 Mar 2015 11:42:08 -0800
From: Paul Vixie <>
User-Agent: Postbox 3.0.11 (Windows/20140602)
MIME-Version: 1.0
To: Bob Harold <>
References: <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.2.3
Content-Type: multipart/alternative; boundary="------------000205060406000905000901"
Archived-At: <>
Subject: Re: [DNSOP] More work for DNSOP :-)
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: Fri, 06 Mar 2015 19:42:12 -0000

> Bob Harold <>
> Friday, March 06, 2015 11:37 AM
> I would be concerned about blocking RD=0 (non-recursive).  That would
> prevent me from check to be sure an entry was NOT in the cache, in
> some DNS server my clients are using. That would make troubleshooting
> more difficult.  Let's not automatically include that in some group to
> get easily blocked.  A separate command to block RD=0 is fine, if
> someone chooses to use it, to make life difficult for others, that is
> their choice, but don't recommend it or make it part of a group.

i feel, and share, the pain you're describing. however, we're in a
post-snowden era, and any information leaks (such as RD=0 queries to
recursive-only servers) have to be reconsidered on the new risk:benefit
model. i find that giving every one of my users and customers the
ability to find out the presence and if present the TTL of anything in
my cache is something more likely to be used against me than to be used
for me. the fact that this will make reasonable things like what you're
describing also broadly impossible is no different from all the
reasonable things that ubiquitous perfect forward secrecy will also make

as you say, fine grained acl's should be the recommendation. but the
default ACL for all meta types should be recommended as "nobody". this
is further evidence that abuse breeds overcompensation, like with ANY
itself. (if mozilla hadn't abused ANY, we would not be having this

Paul Vixie