Ted, et al, I’ve been watching this dialog and staying silent, but since I’m referenced and quoted directly, let me offer some points.
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. (Well, I guess when I speak officially as chair of ICANN’s board, it’s been coordinated and approved in advance and carries the weight of the organization, but I haven’t spoken in that capacity on this subject and I expect that if and when ICANN does speak officially on this subject, it’s likely to come from others.) 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. 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. 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. 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. 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. Steve > On Mar 20, 2017, at 4:15 PM, Ted Lemon <mel...@fugue.com> wrote: > > On Mar 20, 2017, at 3:44 PM, Russ Housley <hous...@vigilsec.com > <mailto:hous...@vigilsec.com>> wrote: >> This document does not describe a collaborative approach. > > The document specifies what the working group needs to have happen in order > for the specification to work. How the collaboration happens is out of > scope for the homenet working group. The working group understands that a > process needs to be invented, and I believe that the document says so. > >> Steve Crocker has already stated that he does not believe that entries that >> cannot be DNSSEC signed belong in the DNS root zone. I know that others >> share this view. For this reason, I do not think that the IETF should >> approve a document that specifies this processing until the root zone >> publication process is successful. > > > Yes, I understand that Steve Crocker has said this. And perhaps Steve > Crocker's opinion should be considered normative. However, like you, Steve > didn't give a technical reason why this policy must be applied universally, > even in the case of technical uses. > > We have a legitimate question to answer here. It seems reasonable to say > that under the MoU, the IETF can designate a name for the use that homenet is > trying to designate. Maybe the IETF consensus will be that the IETF should > not designate this particular use. But it doesn't make sense to me that the > IETF should decide not to try to do what the working group thinks is the > right thing technically, because the process for doing this thing is not yet > known. If the IETF doesn't try to do this, the process will never be known. > So I don't see how this can be a valid technical objection to going forward > with the proposal. > >> Further, the intent is that .homenet will be used with the DNS protocol. >> Section 3 of the document makes it very clear that users, applications, >> resolution APIs, and most resolvers will not to treat that domain name in a >> special in any way. For this reason, I do not think it meets the definition >> of a special-use domain name in RFC 6761, which says: >> >> ... if a domain name has special properties that affect the >> way hardware and software implementations handle the name, that apply >> universally regardless of what network the implementation may be >> connected to, then that domain name may be a candidate for having the >> IETF declare it to be a Special-Use Domain Name and specify what >> special treatment implementations should give to that name. >> >> So, I think that the desired outcome requires the use of the existing >> process to get it registered in the root zone and some standards-track RFC >> to describe the environment where: >> >> … Only a DNS server that is authoritative for the root ('.') or is >> configured to be authoritative for '.homenet' or a subdomain of >> '.homenet' will ever answer a query about '.homenet.’ > > I don't think this is a correct reading of RFC 6761. If it were, we could > drop most of the considerations in section 5 of the document. > > As for the process, it may be that in the end, ICANN pushes back and says no, > absolutely not, we won't do this. But when they say that, they will give a > reason. It is their decision to make, not ours, as long as they don't > violate the MoU. Our decision is whether or not to ask them to make this > decision. > > Maybe there is a good reason not to ask them. If so, you haven't yet stated > that reason. > _______________________________________________ > 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
