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. :) > 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. 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
