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 <[email protected]> On Behalf Of Ted Lemon
Sent: Thursday, July 19, 2018 9:31 AM
To: Stephen Farrell <[email protected]>
Cc: Homenet <[email protected]>; Daniel Migault <[email protected]>; 
Juliusz Chroboczek <[email protected]>
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 
<[email protected]<mailto:[email protected]>> 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.

_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet

Reply via email to