Re: [DNSOP] Refusing NS queries, was Barry Leiba's Yes on draft-ietf-dnsop-qname-minimisation-08: (with COMMENT)

"John Levine" <> Mon, 28 December 2015 03:20 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 846B61A87CD for <>; Sun, 27 Dec 2015 19:20:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 1.663
X-Spam-Level: *
X-Spam-Status: No, score=1.663 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 9qy1ltAsxubX for <>; Sun, 27 Dec 2015 19:20:46 -0800 (PST)
Received: from ( [IPv6:2001:470:1f06:1126::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8CCAB1A86EE for <>; Sun, 27 Dec 2015 19:20:46 -0800 (PST)
Received: (qmail 19456 invoked from network); 28 Dec 2015 03:20:45 -0000
Received: from unknown ( by with QMQP; 28 Dec 2015 03:20:45 -0000
Date: Mon, 28 Dec 2015 03:20:23 -0000
Message-ID: <20151228032023.48153.qmail@ary.lan>
From: John Levine <>
In-Reply-To: <>
X-Headerized: yes
Mime-Version: 1.0
Content-type: text/plain; charset="utf-8"
Content-transfer-encoding: 8bit
Archived-At: <>
Subject: Re: [DNSOP] Refusing NS queries, was Barry Leiba's Yes on draft-ietf-dnsop-qname-minimisation-08: (with COMMENT)
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, 28 Dec 2015 03:20:47 -0000

>>>>    For instance, some authoritative name servers embedded in load
>>>>    balancers reply properly to A queries but send REFUSED to NS queries.

>> If my policy is not to tell you about NS records, that's my policy.
>> It may be a stupid policy that causes downstream problems, but it's my
>> right to be stupid.
>Being listed as nameserver while unconditionally refusing all NS queries
>leads to a guaranteed failure with DNSSEC as there would not be a signed
>NS RRset published anywhere.

Yes, we agree it could have bad results.

> 	The NS RR states that the named host should be expected to have a zone
> 	starting at owner name of the specified class.
>I would interpret that to mean that a parental NS glue record signifies
>that the RDATA target must point to something that has that zone at the
>owner name. Thus the NS queries at that target should return proper
>results for NS queries (to itself)

Unless, of course, the target doesn't like you and refuses your
queries for policy reasons.  Maybe they don't want you to be able to
tell if there are delegated subzones, or they just think you're ugly.
It's still their policy, so they can refuse the queries.

The language in section 4.1.1 of RFC 1035 that defines the refused
RCODE is simple, and in a quick look at other RFCs that update 1035, I
didn't see anything that updates the definition.