>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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
