Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

[Jacques Latour <[e-mail]>]

The provisioning process for front end naming delegation we’re thinking of includes the provisioning of the domain name itself at the registry, and the setup on the home gateway itself and registration with an external secondary anycast for global name resolution. The gateway would have an internal and external view, where the external view would sync with the outsourced DNS service, could be using standard IXFR/AXFR methods.  We would sign both internal/external views with DNSSEC and publish a CDS that the registry can take to bootstrap the delegation. We need to add a Dyn like process to sync external dynamic addresses to the external zone file.

We’re not planning to use home.arpa because it will not have a secure chain of trust and if we have a domain name for external reachability (example.ca) then might as well use it internally.

As a side note, I don’t think we should even think of building a solution to make home.arpa a secure delegation, it’s a good domain name for internal use and avoid name collisions, not good for DNSSEC.

From: homenet <[e-mail]> On Behalf Of Ted Lemon
Sent: Thursday, July 19, 2018 9:31 AM
To: Stephen Farrell <[e-mail]>
Cc: Homenet <[e-mail]>; Daniel Migault <[e-mail]>; Juliusz Chroboczek <[e-mail]>
Subject: Re: [homenet] draft-ietf-homenet-front-end-naming-delegation vs. DynDNS

One way to automate this would be using mud.

On Thu, Jul 19, 2018 at 9:28 AM, Stephen Farrell <[e-mail]<mailto:[e-mail]>> wrote:

(with no hats...)

On 19/07/18 10:42, Juliusz Chroboczek wrote:

>> Also, think of the privacy implications if all of the services on the
>> homenet had to be discovered from a shared zone like dyndns.org<http://dyndns.org>.

> Quite the opposite.  In the trivial update protocol, the update is
> end-to-end, encrypted, and only the host and the DNS provider see the
> data.  Every Homenet, every host, heck, even every application can use
> a different DNS provider, and each DNS provider only sees the data that
> was explicitly sent to it.

I'm also a bit puzzled by how the subset of records to be
globally published relates to the set of records that are
to be internally visible. I guess this is not something
that we'd fully standardise, but there are privacy issues
here if too much gets published globally, so there may be
some protocol (change/tweak) required to make it possible
for implementers to distinguish which information ought be
globally visible, and which not.

Cheers,
S.