Thanks for the quick response. > On Mar 20, 2017, at 5:14 PM, Ted Lemon <mel...@fugue.com> wrote: > > On Mar 20, 2017, at 4:57 PM, Steve Crocker <st...@shinkuro.com> wrote: >> First, neither my opinion as an individual nor my opinion as an official of >> ICANN should be considered definitive, normative or otherwise compelling >> except and unless the substance of what I say makes sense > > I was being facetious, in case it wasn’t obvious. :)
Heh. I guess it wasn’t as obvious to me as it should have been. > >> Second, speaking as an observer and with some familiarity with DNS, DNSSEC >> and with the process related to entering strings into the root zone, the >> homenet sequence seems backwards to me. I would have expected the >> coordination to happen before or during the working group. If the homenet >> spec is approved as a proposed standard but there’s no agreement to put >> .homenet into the root or there is a glitch somewhere else in the >> coordination, the IETF will be in the position of having published an >> unimplementable standard. Running code is the hallmark of the IETF and a >> primary distinguishing characteristic, so I’m surprised and puzzled if this >> is the path the IETF is taking. > > It is a bit backwards. The name '.home' got allocated in the HNCP RFC > without due process, so we wound up suddenly needing to fix that. > >> Third, having now read the homenet spec, I see what the point is, but I can >> also see a bunch of questions. It looks like the idea is to establish a >> local DNS tree that is good only within a home or similar contained >> environment. This is analogous to a 192.168.x.x environment. To make this >> work, ignoring DNSSEC for a minute, it seems to me the DNS queries have to >> go to a DNS resolver that is acting as a local authoritative server for >> .homenet. This is problematic because there are often multiple DNS stub >> resolvers operating within a single machine, and there’s no guarantee they >> will send their queries to a particular local DNS server. The only way I >> see to force the issue is to intercept all queries headed for port 53 >> outside the local environment and examine them for .homenet. > > You should bear in mind that homenet is assuming the Internet of maybe five > years from now, more so than the Internet of now, although obviously we'd > like to get done sooner than that. So you should assume that stub resolvers > never, ever do anything so foolish as to trust a recursive resolver to > validate for them. And, indeed, as you say, any resolver that doesn’t use > the host's resolver configuration to figure out which resolver to talk to > isn't going to be able to resolve queries in the .homenet domain. It is hard to predict how things are going to evolve. The idea that all stub resolvers will be validating everything they get is a nice goal, and I certainly wouldn’t want to choose a path that precludes that, but I think it’s prudent to also design for the present. Assume we’ll be somewhere along the path between here and there. If you assume the local environment is going to get complicated and that signing of the local domain will become important in order to guard against hijacking by errant devices inside the perimeter, it looks to me there will have to be a local trust anchor. For devices brought into the environment, DHCP already assigns the IP address and the DNS servers. It can “easily” be augmented to hand out the public key of the local hierarchy. Or, I suppose, since I’ve just posited that the DHCP server will tell the new device which DNS server to use, the device could then query the DNS server to find out if it has a signed .homenet domain and what its public key is. I’m typing as I’m thinking, and I may have overlooked something quite basic and embarrassing. I’ll stop typing now ;) > > We don't consider this to be a serious problem. Are you aware of some > reason to think it is? > >> Fourth, I’m not sure I understand what the issue is with DNSSEC. If the >> queries are intercepted locally and if you trust the internal environment — >> an assumption you might want to ponder carefully as internal environments >> become ever more complicated and populated by devices and software from >> many, many sources — DNSSEC doesn’t come into play. If the queries are not >> intercepted locally, you’ll get the official answer, viz NXDOMAIN. I gather >> you want something else, and perhaps I didn’t read carefully enough to >> understand what that something else is and why it would be helpful. > > The queries are being resolved by a local resolver. But they are being > validated by the stub. So if the local resolver gives an answer that > doesn't come with a secure denial of existence, it'll work. If not, the > stub will find any answer for .homenet to be invalid, because there is a > chain of trust, and the chain of trust says that .homenet doesn't exist. > >> What emerged most clearly for me in reading the homenet spec is the apparent >> desire to have a locally served domain, which seems similar in some respects >> to a classic split domain, and the real challenge, as best I can see, is >> characterizing the perimeter and internal topology. > > We are addressing a problem with locally-served zones that existing documents > do not address. > >> And returning to the first point, let’s do indeed get people together to >> understand how the parts are supposed to fit together. Over at ICANN we try >> very hard to be of service and we also take the security and stability of >> the DNS, and particularly the root, very seriously. A non-standard request >> is almost going to be the beginning of lengthy discussion. Our mind set >> will be aimed at getting it right, not arguing about who’s in charge. > > Understood and appreciated. If the document reads as suggesting something > other than this, I apologize, since I probably wrote that text. The working > group's intention matches what you have said here. > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
