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

The trivial update protocol isn't a standard protocol, and doesn't do what
we need it to do.   In order for services to be discoverable on the
homenet, they have to publish their contact info on the homenet.   The
protocol that everyone uses for this is DNSSD.   This is how you find your
printer when you want to print to it.   Nobody uses the ad-hoc DynDNS
protocol for this.

What the DynDNS protocol does is to allow you to track the IP address of
your home gateway using a single A record in someone else's zone (e.g.,
dyndns.org).   It doesn't let you populate your own zone, and you can't do
service discovery on the resultant DNS entry, because service discovery is
a bit more complicated than that.

It's certainly true that we could use an HTTPS-based protocol for setting
up delegations for the forward mapping zone.   This makes a great deal of
sense, since the forward mapping zone shouldn't have to be tied to the
ISP.   The reverse mapping zone has to be delegated by the ISP, so we might
as well do it in a prefix delegation transaction.

So if you are advocating this second thing, that makes sense, and we should
definitely talk about whether it makes sense to do it this way.   If you
are talking about the first thing, then maintaining a zone in the homenet
is definitely a requirement.  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.

On Wed, Jul 18, 2018 at 9:35 PM, Juliusz Chroboczek <jch@irif.fr> wrote:

> > All of this can be done in the DNS without resorting to any other
> protocol.
>
> Excellent.
>
> So what technical reasons are there to prefer the complexity of
> draft...front-end-naming-delegation over a trivial update protocol,
> whether encapsulated in HTTPS or DNS?
>
> -- Juliusz
>
> _______________________________________________
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
>