Ted, I am truly confused by your note. I sense I am missing something fundamental.
See specific questions below. Thanks, Steve > On Dec 15, 2016, at 12:20 PM, Ted Lemon <mel...@fugue.com> wrote: > > On Dec 15, 2016, at 11:05 AM, Jacques Latour <jacques.lat...@cira.ca > <mailto:jacques.lat...@cira.ca>> wrote: >> Where do you delegate homenet to? Advanced DNSSEC validation may check for >> proper delegation? > > I think we should ask ICANN to set up an unsecured delegation of .homenet to > the AS112 servers. 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. 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. 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. 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. 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. > 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. > 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.
_______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
