Hi, >> What was the motivation for removing .lan from the list? >> >> I can see where .localdomain and .domain indeed won't cause any >> problems, but I think .lan is still a pretty common one in use. > > It is a common fake TLD used by home gateways for their internal networks.
Yeah, so I've read this draft and have hesitated to comment as I'm aware there are folks who believe it inappropriate for ICANN staff to comment on anything having to do with top-level domains in the IETF. However, as I continue to believe participation in the IETF is based on the individual, not for whom the individual works, I'm going to throw in my 2 cents on this topic with an explicit "NO HAT" placed firmly on my head. My apologies if my participation in this discussion raises political hackles. While I would like to declare the proposed strings as reserved as I think it would be crazy dangerous for them ever to be delegated, I'm concerned about the lack of objective criteria. The draft states: '[SAC045] reports the results of a CAIDA measurement study [RSSAC_DNS] which found that "NXDOMAIN responses account for more than 25 percent of the total responses from root name servers observed in the study, and the top ten such strings account for 10 percent of the total query load.' While true, these values will vary over time, location of collection, and myriad other reasons, probably including phase of moon. If we're going to reserve strings from ever being delegated, I believe we need to come up with some rationale beyond "because they showed up a lot at some root servers at this point in time." If that is the only criteria, it would be relatively easy to game the stats by hiring a few botnet zombies to pump queries with names you'd like to reserve with spoofed source addresses. Perhaps some criteria would be a combination of lots of queries over a long period of time at multiple measuring points along with some rationale for those queries to be generated (e.g., I'm told long ago Microsoft recommended the use of .CORP for internal Active Directory configurations, pointers to that documentation would explain why those queries were being generated)? FWIW. Regards, -drc (Speaking only for myself. Really.)
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
