Re: [homenet] securing zone transfer

"Ray Hunter (v6ops)" <> Thu, 13 June 2019 12:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9A47712004D for <>; Thu, 13 Jun 2019 05:32:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=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 Vc58hyRKasQp for <>; Thu, 13 Jun 2019 05:32:22 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3A38112000F for <>; Thu, 13 Jun 2019 05:32:22 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id E84204018F; Thu, 13 Jun 2019 14:32:20 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id blYFHHHqCTPX; Thu, 13 Jun 2019 14:32:17 +0200 (CEST)
Received: from MacBook-Pro-3.local ( []) (Authenticated sender: by (Postfix) with ESMTPA id C75FD4012D; Thu, 13 Jun 2019 14:32:17 +0200 (CEST)
To: Michael Richardson <>
Cc: Juliusz Chroboczek <>, homenet <>
References: <> <> <2348.1560261275@localhost> <> <27503.1560302791@localhost> <> <4109.1560349340@localhost> <> <21639.1560389132@localhost>
From: "Ray Hunter (v6ops)" <>
Message-ID: <>
Date: Thu, 13 Jun 2019 14:32:16 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 PostboxApp/6.1.18
MIME-Version: 1.0
In-Reply-To: <21639.1560389132@localhost>
Content-Type: multipart/alternative; boundary="------------BFD486A12DFA998CA8FC46B6"
Content-Language: en-US
Archived-At: <>
Subject: Re: [homenet] securing zone transfer
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF Homenet WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Jun 2019 12:32:25 -0000

Michael Richardson wrote on 13/06/2019 03:25:
> Juliusz Chroboczek <> wrote:
>      > Are you assuming here there's a central Homenet controller that presents
>      > a web interface where the "house owner" can choose which names get
>      > published?
> No, we are assuming that there are one or more homenet routers that either
> come with a delegated domain from the manufacturer (probably a very ugly
> one), or which that CPE's ISP will delegate via DHCPv6. (or both)
> Whether we should or have to do some negotiation over HNCP if there are
> multiple CPEs is a problem we can deal with later.
> We have, however, been thinking about the problem of having partial
> connectivity for the home, and how do published names get resolved.
>      > I'm probably missing something, Michael, so please explain if you agree
>      > with the analysis above, whether you're assuming a central controller,
>      > and, if so, where is the central controller located in a network that has
>      > multiple edge routers.
> If an end user wants a non-ugly domain, and they buy it, then they need to
> introduce one or more of their CPEs to the upstream provider of the
> domain.  It could be it is at this point that it makes sense to do some HNCP,
> but in essence, this is an internal problem, and the front-end-naming
> document is not about internal issues.
> --
> Michael Richardson <>ca>, Sandelman Software Works
>   -= IPv6 IoT consulting =-
> _______________________________________________
> homenet mailing list

Indeed this draft should say as little as possible about what should 
happen internally (whether there's one elected central Homenet 
controller for all ISP uplinks, or there's something running on all 
Homenet routers that updates an edge HNA per ISP uplink, or the HNA 
service runs on a host, or something else).

Probably the text isn't in that state yet.

The facts of life with using DNS are that:
- a zone delegation is built on a hierarchical name space with a single 
- a delegated zone is a proper subset of a parent zone,
- zone signing occurs with one single active zone signing key signing 
the complete set of RR's in a zone (not a key or signature per RR), and 
- zone transfer updates are performed with a master/slave arrangement 
with a limited number of known peers per zone.

If you want individual hosts to interact directly with an outsourced 
name service based on DNS (instead of via an HNA), you either have to 
delegate the zone signing to the outsourced name service (which 
introduces a different trust model), or you assign a dedicated zone per 
host (possible?), or you introduce a massive key sharing and signing 

Another use case could be small companies who want to run something like 
Active Directory on premises (AD integrated DNS).

Then they could potentially build AD forest trust relationships between 

AD of course runs on a domain controller (DC). The DC function could 
then potentially take on the role of HNA, whether that is running a 
separate server or on a CPE.