In message <20161214220428.1688.qm...@ary.lan>, "John Levine" writes: > >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.
But it isn't. Go read the library code. There isn't magic for localhost in there. The code looks in /etc/hosts before looking in the DNS (normally) if there is a gethostbyname/getaddrinfo etc. call. This allows the administrator to override the DNS for specific names on this machine for those calls. This makes "telnet localhost" work. It doesn't make lots of other stuff that should work succeed. .localhost needs the same treatment as .homenet. It doesn't get it today but it should for the same reason .homenet needs a insecure delegation. > (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 > > _______________________________________________ > homenet mailing list > home...@ietf.org > https://www.ietf.org/mailman/listinfo/homenet -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
