Re: [homenet] securing zone transfer

Michael Richardson wrote on 13/06/2019 03:25:
> Juliusz Chroboczek <jch@irif.fr> 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 <mcr+IETF@sandelman.ca>, Sandelman Software Works
>   -= IPv6 IoT consulting =-
>
>
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

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 
root;
- 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 
where
- 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 
problem.

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 
companies.

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.

-- 
regards,
RayH
<https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>