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

Paul Vixie <> Fri, 07 April 2017 00:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58BB0127275 for <>; Thu, 6 Apr 2017 17:24:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2r3VPKfI9nGK for <>; Thu, 6 Apr 2017 17:24:34 -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 2E8401286CA for <>; Thu, 6 Apr 2017 17:24:25 -0700 (PDT)
Received: from linux-hs2j.localnet ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPSA id 18A4061F9C for <>; Fri, 7 Apr 2017 00:24:25 +0000 (UTC)
From: Paul Vixie <>
Date: Fri, 07 Apr 2017 00:24:24 +0000
Message-ID: <2448193.4rPzoQ60ob@linux-hs2j>
Organization: Vixie Freehold
In-Reply-To: <6ac82154-9990-4f20-9d38-090df7a3e098@Spark>
References: <> <> <6ac82154-9990-4f20-9d38-090df7a3e098@Spark>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="nextPart3708126.Sx58FjHPgR"
Content-Transfer-Encoding: 7bit
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 00:24:36 -0000

On Thursday, April 6, 2017 11:53:25 PM GMT David Conrad wrote:
> On Apr 6, 2017, 2:32 AM -1000, Paul Vixie <>, wrote:
> > if you want to run yeti-style, there are some perl scripts that will
> > fetch and verify the root zone, edit the apex NS and DNSKEY RRsets,
> > re-sign with your local key, and give you a zone you can run on several
> > servers inside your internal network, such that you can point your
> > "hints" and your dnssec anchor at servers you control, for all your
> > internal-network recursives,
> Not so sure this is something I'd go about recommending to pretty much
> anyone other than hardcore, very experienced DNS/DNSSEC protocol geeks
> since it pretty much defeats the purpose of DNSSEC (edit the apex? ugh) and
> requires all relying devices to configure a "non-default" trust anchor or
> suffer SERVFAILs.

other than one proviso and one misstatement, i agree with this.

the proviso is, RFC 7706 is also completely unsuitable for non-hardcore or non-
experienced or non-protocol-geeks; and both approaches are appropriate only for closed 
internal networks where the configuration is controlled by a single administration.

the misstatement is, dnssec's purpose is not defeated, because iana's signatures are 
checked before the zone is accepted, and new signatures are added using local keys 
before publication.

for my many-vm's laptop environment, running on a loopback isn't a solution.

see also: