Re: [DNSOP] [homenet] Fwd: WGLC on "redact" and "homenet-dot"

[Juliusz Chroboczek <[e-mail]>]

> This brings us to one of the knottiest parts of special use names, which
> is that they're all handled differently.  For .onion, it's generally
> handled in a SOCKS proxy in the application, for .local it's handled by
> mDNS, and for .localhost it's special cased in the stub client library.

Let's please not bring .onion into this discussion.  .onion is a hack with
far-reaching consequences, and one that the IETF should never have
standardised.  The less we mention .onion, the better.

.onion encodes the protocol into the hostname.  Instead of .onion, tor
should have used http+tor:// and https+tor://, which would have required
no special-casing, since an application that doesn't understand the new
scheme will return an error straight away rather than leaking .onion names
into the DNS.  (I understand why .onion was used -- it was an expedient
way to avoid the need for special-case code in the browser --, but the
tradeoff that was chosen requires special-case code in every single
freaking DNS-speaking application.  Yeah, I'm still pissed off.)

Not so with .local and .homenet.  Neither of these requires any special
code in the application.  From the point of view of the application,
.local and .homenet are just ordinary domain names that are passed to the
stub resolver, which yields a perfectly normal IP(v6) address that is then
used with ICMP, TCP, UDP, DCCP (remember that?) or whatever your favourite
transport-layer protocol happens to be.  Completely unlike .onion.

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.

Sorry for the rant.

-- Juliusz