On Dec 15, 2016, at 2:23 PM, Steve Crocker <st...@shinkuro.com> wrote: > I don’t understand what is meant by an “unsecured delegation.” I also don’t > understand what sort of delegation you want, irrespective of whether DNSSEC > is involved.
There would be a delegation for .homenet in the secure root, which would point at the AS112 servers, and would have no DS records. > I think there are two very big hurdles implicit in “I think we should ask > ICANN to set up …” One is the technical hurdle of whether this is a sensible > thing technically with respect to the security and stability of the Internet. > It will take a fairly long time and a lot of analysis for ICANN to get > comfortable with such a result, and I would not count on a positive outcome. Yup, understood. > That’s the first hurdle. The second hurtle may be even harder. The only > existing procedures for adding new delegations to the root are for: > > o New ccTLDs, i.e. when new countries are created and get two letter codes > from the ISO 3166 Maintenance Agency; > > o New IDN ccTLDs via the Fast Track; and > > o New gTLDs through the gTLD process. > > The first two would not apply. The window for the third was closed a while > ago and we are studying when and how to reopen the window. The process is > geared toward prospective operators of registries. A substantial fee is > required, and an even more substantial investment in registry operation is > required. It would not make sense to follow any of these processes. This is a technical allocation under the terms of the MoU, and we don’t actually know how to do those. It would, in my view, be extremely weird for ICANN to charge IETF for doing one of these, based on my reading of the MoU, but at the same time ICANN is responsible for operating the zone, so it’s entirely reasonable for ICANN to say "no, we won’t do that," and then the IETF would have to decide that that meant in terms of the MoU. I would hope that ICANN would not do this, and I think the MoU seems to indicate that they have agreed not to, but it’s uncharted territory, and I think there would have to be a fourth process for this, which is separate from the three you described above. > I suspect what’s intended here is something qualitatively different, e.g. > some sort of entry in the root that returns a fixed result, not a pointer to > name servers. No, just a delegation to AS112 with no DS record would do the job, unless I am missing something. I will admit to not being an expert on DNSSEC arcana, so that’s entirely possible. > Aside from the technical questions I mentioned above, we would also have to > sort out the policy questions, e.g. what are the rules for accepting such > requests, what happens if there are competing requests, and perhaps others > that aren’t occurring to me as I write this. Yes. It’s a big can of worms. We won’t know precisely what’s in it unless we open it. >> In order for names under .homenet to be validated by DNSSEC, it would be >> necessary for the validating resolver to have a trust anchor for any homenet >> on which it wants to do validation, and a means of differentiating between >> home nets so that it doesn’t use the wrong key to validate. > > Yes, but the way the sentence is written suggests this would difficult or > odd. In a homenet environment, if you have a local name server responding to > requests as an authority, it can sign those requests as the authority. The > requesting resolver will have to have the public key associated with the > authority. This is a configuration matter. When the requesting resolver is > told which resolver on the edge of the homenet is authoritative for the > homenet environment, it should also learn that resolver’s public key. This > seems like a DHCP issue. I don’t think DHCP is the right answer, but the bottom line is that this isn’t really the issue that we need to figure out right now. Just bear in mind that a validating stub resolver needs to not invalidate answers that are returned within .homenet. >> But that’s out of scope for this discussion: the point of this discussion >> is simply to figure out whether we want to do the hard thing or the easy >> thing: .homenet or home.arpa. > > I don’t see a difference between .homenet or home.arpa in this regard. If the working group chose to use home.arpa, we would not need to open the aforementioned can of worms. _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
