In message <20150810191030.13804.qm...@ary.lan>, "John Levine" writes: > >> I believe that the registry we have currently defined doesn't do a great j > ob of capturing the actual needs here. > > Agreed. It seems to me that there are two somewhat separate things going on > here. > > One is the .ONION issue. It's a domain name string that has a > coordinated use that is implemented outside the RFC 1034/1035 DNS. > > The other is the .BELKIN and .CORP issue. They're domain name strings > that have no coordinated use, but there's enough uncoordinated use > that there'd be a stability risk if a live TLD started answering > queries. > > In both cases, one question is when we reserve the name, and the other equall > y > important question is when we un-reserve the name. > > For all three, I think there's adequate evidence to reserve them now. > The un-reserve criteria is different, and I expect would be different > for any other name we reserved. For .onion, it's not out of the > question that five or ten years from now we check in with the ToR > project and they say oh, the whole reserved name thing was such a hassle > that we switched to onion:// names and we don't use domain names at all. > > For .BELKIN, the problem was a lot of home routers shipped a decade > ago. Eventually most of them will die and the problem will go away. > Or if the Belkin company wanted a vanity domain, they presumably know > what the routers did and could come up with a TLD that avoided sending > unfortunate responses to the old queries.
If .BELKIN is reserved then it is not available to *anyone* including Belkin. The simplist fix for .BELKIN is for the vendor to request registration of the name through ICANN. It becomes a expensive mea-culpa. The IETF should leave this to ICANN processes. > For .CORP, I gather the main usage was for intranet TLS certificates, > but the public CAs have stopped signing them so they will probably > mostly go away, too. > > The point of these examples is not that we need to solve any of those > issues now, but that a useful reserved name registry needs to deal with > the reality that most reservations need not be forever. > > R's, > John > > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
