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

[Juliusz Chroboczek <[e-mail]>]

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

These are two completely different problems, with different default
behaviours and different failure modes.

The default behaviour for the local zone is that devices should be
discoverable.  The default behaviour for the public DNS is that a device
should not be published unless it takes explicit action.

It makes a lot of sense to have two different protocols, rather than
essentially leaking a local zone into the ISP's DNS servers.

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

> Doing this transaction over HTTP means another service that the ISP has
> to operate,

Not the ISP, a third-party DNS provider.  That's the whole point.

> and another service that the HNR has to connect to.

Not the HNR, the end host.  That's the whole point.

And it's literally four lines of shell:

    while true; do
        wget --post-data 'name=gameserver.myhome.net&password=topsecret' \
             https://dyndns.example.com
        sleep $((24 * 3600))
    done

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

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

With delegation through an ISP-controlled hidden master, the ISP gets
a database of all the names published by all of its users.

With an encrypted connection to a DNS provider, the ISP needs to troll all
of the DNS providers in order to build such a database.

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

Uh-huh.

-- Juliusz