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

[Ted Lemon <[e-mail]>]

On Thu, Jul 19, 2018 at 5:42 AM, Juliusz Chroboczek <[e-mail]> wrote:

> > 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.
>
> I am not speaking about discovery within the Homenet.  I am speaking about
> exporting names into the global DNS, which is what Daniel's draft is about.
>

Yes, but the problem is that you are treating this as if these are two
separate problems, but they are not.   If we need devices to know how to do
one thing, that's enough.   We shouldn't demand that they know how to do
two things that accomplish the same thing.   So if we need service
registration, we shouldn't also have a second method of publishing names,
because that's additional work for the device manufacturer.


> > The reverse mapping zone has to be delegated by the ISP, so we might as
> > well do it in a prefix delegation transaction.
>
> I'm not following your reasoning here -- why does the zone being tied to
> the ISP imply that we must use a more complex protocol?
>

Again, we are already doing DHCP PD to get the prefix from the ISP.   The
transaction is already happening.   Sending our ZSK to the root along with
the IP address of our public or hidden primary for the reverse zone isn't a
lot of additional work.   Doing this transaction over HTTP means another
service that the ISP has to operate, and another service that the HNR has
to connect to.   So it's not a simplication—it's a complexification, even
though the protocol itself is simple.


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

You've published a record in a public zone.   It doesn't matter that the
protocol you used to publish it is  privacy-protecting, because the
publication of the name immediately negated that.

In Daniel's protocol, the data goes from host to hidden primary to DNS
> provider.  The hidden primary is probably controlled by the ISP, which is
> convenient if you happen to be a privacy-violating ISP.


The hidden primary would be on an HNR, so unless the HNR is controlled by
the ISP, the hidden primary isn't either.   In principle, at least, the
hidden primary should only be exposing names to the ISP that are intended
to be exposed.

The reason I was hassling  Daniel about implementations at the mic is that
I actually share your concern that what he's got written down right now is
more complicated than it needs to be, and this is partly because it was
originally motivated by his work at an ISP.   Now that he isn't doing that,
we have an opportunity to do a rethink about what is good and bad about the
proposal, and I think we should take advantage of this opportunity.

That said, DNS delegation and IXFR are well-understood technologies that
are well-suited to the purpose we have here, so I think we should be
careful when trying to simplify this to make sure that what is being
proposed actually has that effect!