Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706

Tony Finch <> Fri, 07 April 2017 17:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 082AF1296D6 for <>; Fri, 7 Apr 2017 10:57:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SNyAHu5CGM-d for <>; Fri, 7 Apr 2017 10:57:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 44C751296D3 for <>; Fri, 7 Apr 2017 10:57:00 -0700 (PDT)
X-Cam-AntiVirus: no malware found
Received: from ([]:42766) by ( []:25) with esmtps (TLSv1:ECDHE-RSA-AES256-SHA:256) id 1cwY81-000QaU-1l (Exim 4.89) (return-path <>); Fri, 07 Apr 2017 18:56:57 +0100
Date: Fri, 07 Apr 2017 18:56:57 +0100
From: Tony Finch <>
To: Bjørn Mork <>
In-Reply-To: <>
Message-ID: <>
References: <> <2448193.4rPzoQ60ob@linux-hs2j> <f321b974-2149-478d-9b63-a19d10ed013e@Spark> <1560750.L0Fn6CvLxk@linux-hs2j> <> <> <>
User-Agent: Alpine 2.11 (DEB 23 2013-08-11)
MIME-Version: 1.0
Content-Type: MULTIPART/MIXED; BOUNDARY="1870870841-2061162964-1491587817=:13590"
Archived-At: <>
Subject: Re: [DNSOP] Unexpected REFUSED from BIND when using example config from RFC7706
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 07 Apr 2017 17:57:06 -0000

Bjørn Mork <> wrote:
> The reason I ask here first, is because RFC 7706 includes a BIND
> specific configuration example (as well as examples for other recursive
> server software).  So before considering changing config or code, I
> wanted to know the background of that example. Was there a real reason
> for the obscure(?)  "static-stub" zone type, or was that just an
> arbitrary choice?

The choice between "forward" and "static-stub" depends on whether the
target server offers recursive service or not. If it doesn't, then a BIND
resolver that is forwarding to the server can produce the wrong results,
because it is expecting a fully-resolved answer but doesn't get one.

It's a lot simpler to have a local copy of the root zone without any of
the view trickery, but then the resolver trusts the zone contents without
verifying them.

I think that if you are doing this on a production server, it would be
better to have external scripting to fetch and verify the root zone so you
can be sure you don't have an outage because the transfer got corrupted.

f.anthony.n.finch  <>  -  I xn--zr8h punycode
Rockall, Malin, Hebrides: West or southwest 5 or 6, occasionally 7 except in
Malin. Moderate or rough, occasionally very rough in north Hebrides.
Occasional rain or drizzle. Good, occasionally moderate.