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

["John Levine" <[e-mail]>]

>Here's the reasoning:   Either your home router understands .homenet or 
>it doesn't.  If it doesn't, then your homenet shouldn't be using 
>.homenet and any .homenet lookups to the real world should fail.  If it 
>does, then it should trap .homenet queries and do with it what it will.

But it's worse than that -- if your client software does DNSSEC
validation it needs to understand that homenet is a special case and
it's OK not to validate.  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.  (There are of course other
ways one could do it, e.g., a .onion proxy on a LAN could intercept
AAAA lookups, and return link-local addresses it serves.)

One model is that DNSSEC is so complex that applications depend on the
cache and if it sets the AD bit, you trust the result.  Another is
that memory is cheap and you put a complete DNSSEC verifier in the
application libraries, so they need to get all of the DNSSEC goop and
decide for themselves whether they believe it.

In the former model, you're right, the cache can tell virtuous lies
about .homenet addresses and there's no need to put anything in the
root.  In the latter case, you're pretty much schrod.  Since there's
no way to do a DNSSEC chain from the root to a zillion random homenet
setups, an unsigned root delegation says that an unsigned result isn't
necessarily wrong, but of course it doesn't say that it's right,
either.

This is a situation that DNSSEC wasn't set up to solve, unless you're
going to wave your hands and invent some sort of DHCP extension where
the router can hand out local trust anchors.  I realize we have RFC
3318, but I don't get the impression that this is a scenario it can
handle without implausible amounts of manual preconfiguration just
to get your mobile phone on your home wifi.

So having said all this, I agree with Steve that an unsigned delegation
is a bad idea, not because all unsigned delegations are necessarily
bad, but because this one wouldn't solve enough problems to be worth
the ugly and ambiguous precedent it'd set.

R's,
John