On Thu, Jul 19, 2018 at 5:42 AM, Juliusz Chroboczek <[email protected]> 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!
_______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
