>Now, granted, .local and .homenet require special casing in shared parts
>of the protocol stack (.local in the stub resolver, .homenet in the
>Homenet router's resolver), but this needs to be done just once in the
>protocol stack, not in every single application.  Completely unlike .onion.

I think you're making unwarranted assumptions about software design
here.  On the computers I know, the stub resolver is in one shared
library and the SOCKS proxy is in another.  What's the difference?

I agree that ToR users typically use specially configured browsers
to minimize side channel leakage, but that's unrelated to the way
the the sockets work.  You can run POP3 over ToR if you want to.

The somewhat relevance to the topic at hand is that we seem to have
different mental models of the way the clients work.  If we expect the
client libraries to know that .homenet is special, it doesn't matter
what's in the root.  If we expect they don't, and all the magic is in
the router, I still don't see any solutions that aren't really ugly.
If we do the unsigned delegation that Mark wants, the validating client
can tell that the .homenet answers it's getting aren't necessarily
bogus, but it can't tell that they're authentic either.

R's,
John

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to