Re: [DNSOP] .arpa

Matt Larson <> Thu, 23 March 2017 21:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C27713167B for <>; Thu, 23 Mar 2017 14:43:11 -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 KhUpliyEsCJD for <>; Thu, 23 Mar 2017 14:43:09 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 78591131678 for <>; Thu, 23 Mar 2017 14:43:09 -0700 (PDT)
Received: from [IPv6:2601:703:6:2f56:3c22:f097:d96d:1826] (unknown [IPv6:2601:703:6:2f56:3c22:f097:d96d:1826]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 5541B1F42D; Thu, 23 Mar 2017 21:43:08 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail=_56BFF812-60B5-4904-8DCC-95663423C100"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Matt Larson <>
In-Reply-To: <>
Date: Thu, 23 Mar 2017 17:43:07 -0400
Cc: Ralph Droms <>,, Ray Bellis <>
X-Mao-Original-Outgoing-Id: 511998187.037559-7561ad00a8a2300b0ad227b3d7532004
Message-Id: <>
References: <20170323042741.79108.qmail@ary.lan> <> <> <> <> <> <> <>
To: Ted Lemon <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Subject: Re: [DNSOP] .arpa
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: Thu, 23 Mar 2017 21:43:11 -0000

> On Mar 23, 2017, at 2:30 PM, Ted Lemon <> wrote:
> On Mar 23, 2017, at 2:11 PM, Ralph Droms < <>> wrote:
>> No snark intended, but if "the protocol" were really just DNS, we wouldn't be having this discussion.  Rather, it is the DNS wire protocol using a local resolution context rather than the root zone.  In any event, yes, the locally server homenet zone can function with DNSSEC.
> So do locally-served zones, by this definition, use a different protocol?

I think saying "different protocol" is not accurate and risks being a distraction.  Rather, Ralph's comment about "resolution context" is important and gets to the heart of the issue.  Before DNSSEC, a recursive name server could also be authoritative for local zones or use other mechanisms (such as stub zones and conditional forwarding) to "short circuit" resolution to handle the local context and not send traffic to the root, and everything resolved just fine.  Now, with DNSSEC validation enabled, zones in this "local resolution context" need to chain up to a trust anchor somewhere.  If there's not a chain of trust from the root, a local trust anchor is needed for validation to succeed.

Consider a corporate split DNS example.  Let's say Acme Corp maintains two versions of the zone <>, one for external consumption (delegated to from .com) and another version for internal use.  Their internal recursive name servers use some mechanism (local authoritative zones, stub zones, etc.) to ensure that internally generated queries resolve against the internal version of <>.  Let's also say that Acme Corp signs both the internal and external versions of <> and that their internal recursive servers have DNSSEC validation enabled.  The chain of trust from the root leads to the external <>, so the internal recursive servers will need a trust anchor for the internal version of <> or validation fails.

homenet uses a local resolution context without a local trust anchor, hence the request for special casing in the root.