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

Shumon Huque <> Mon, 28 December 2015 04:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id AA0C61A8853 for <>; Sun, 27 Dec 2015 20:01:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id f8el1G-XtTlH for <>; Sun, 27 Dec 2015 20:01:13 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C9CD21A8852 for <>; Sun, 27 Dec 2015 20:01:12 -0800 (PST)
Received: by with SMTP id k189so192299991qkc.0 for <>; Sun, 27 Dec 2015 20:01:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Jmr5A/7PO86KyCboOyP5WLXe9FCJIhWVbZm1wGwaWIc=; b=YFAvjYXekfiVPT/Q+9gPnD0XAViJufkpdJ2pwTdU85fXXne95jTTW6Q+MakUYvoOZi aH8o6WL8HZwbimMFvlOUvHsT5FV2TjP/BjFEK6yAOO/NX1BduSOBkD0ynaDbsiW1Ktfu 019HjqOMcB263xMQc+vIKILhDOEwpwh3shv5+Jei7aqAOXZ1LLC/c7Wl/Ls7eBaxzrRh Yk+pgBLZjPCxMtzK2zPY0R9xsfh33yVt64KxyqnWP85g9ydhq4YZDWs72LG9eTlC2AAh 5SByWpPAc8KsCo0xRbA5NMxqxGO9Ln6G/P2TZv9TfYwa+Q3LtnXHfFzQqDFtee84Wv2n OiXQ==
MIME-Version: 1.0
X-Received: by with SMTP id s24mr67682088qki.72.1451275272031; Sun, 27 Dec 2015 20:01:12 -0800 (PST)
Received: by with HTTP; Sun, 27 Dec 2015 20:01:11 -0800 (PST)
In-Reply-To: <>
References: <20151228032023.48153.qmail@ary.lan> <>
Date: Sun, 27 Dec 2015 23:01:11 -0500
Message-ID: <>
From: Shumon Huque <>
To: Paul Wouters <>
Content-Type: multipart/alternative; boundary="001a1147a26a0f94060527ed5b6f"
Archived-At: <>
Cc: dnsop <>
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 04:01:14 -0000

On Sun, Dec 27, 2015 at 10:31 PM, Paul Wouters <> wrote:

> On Sun, 28 Dec 2015, John Levine wrote:
> 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.
> Note that I said "unconditionally refusing all NS queries". Conditionally
> refusing queries based on query source behaviour is off-topic.
> The section in question of the draft under discussion talks about the
> specific case where a load balancer is returning REFUSED because it
> did not implement NS queries, and that such behaviour is a violation
> of the RFC. Not implementing NS queries on an authoritative nameserver
> results in a DNS implementation that indeed violates the RFC. The question
> was, which part of which RFC is the best reference to point to.

I certainly agree that unconditionally refusing NS queries is a bad idea.
Whether or not it is explicitly forbidden by current DNS protocol specs,
I'm not so certain about. I'd love to be corrected if anyone can point to
explicit text.

The statement Paul excerpts from RFC 1035 does not to my mind preclude
REFUSED responses to explicit NS queries; it merely states what is expected
of the named host in terms of the zone that it serves. Resolvers normally
obtain NS records not by explicit queries, but indirectly as part of data
included in referral responses. Even with DNSSEC, I think a validating
resolver could function properly without ever needing to issue explicit NS
queries (with the exception of priming queries which are directed at only
the root servers).

Query-name minimization (with query type hiding) obviously changes this

Shumon Huque