|
|
|
Click the comments link on any story to see comments or add your own. Subscribe to this blog |
15 Mar 2014
Earlier this week Verisign sponsored a two day conference on name collisions in the DNS. Despite the very short time frame in which it was organized, only a month from announcement to meeting, there were some very good presentations. I'll just hit some highlights here; all of the papers and slides are on their web site at namecollisions.net. Sunday morning started with a keynote by Bruce Schneier, who is not a DNS expert (and doesn't claim to be) but had some interesting observations on names in general. Unique names basically don't exist anywhere, and real names are invariably qualified by context, starting with "Mom". As an example, he noted that the first Ethiopian restaurant in any city is invariably named the Red Sea, so if he does a Google search for "red sea restaurant", it will try and guess which one you mean based on where it thinks you are. Often that's right, but if you're in Washington about to leave for San Francisco and want to plan dinner when you get there, it's not. This sort of guess and iterate is quite typical. On the web, you can usually tell, since you go to a web page and it's not the one you were expecting. I noted in the comments afterward that the web gives immediate feedback, but other media like e-mail don't; my gmail address is my name, a remarkable number of other people wrongly think that my address is their address, and they and their correspondents would have no way to know if I didn't reply and tell them. (Often the correspondents argue and insist that, e.g. I must be the person in a city where I do not live who wants to buy their car, which is just bizarre.) Geoff Huston of APNIC talked about the way they're using Google search to do network surveys, by embedding test URLs in Flash animation in Google ads. Flash is fairly inflexible, but it can probe URLs to see what if anything is returned, then send call home via a URL constructed to report what the probes found. He bids very very low for the ads, and has some amusing graphs showing how Google adjusts the rate at which they're displayed to be sure to show enough ads to spend the entire daily spending cap before the day runs out. The original purpose was primarily to probe for IPv6 connectivity, but it would also be possible to do some limited collision testing of names already in the DNS by probing names and seeing if the wrong thing came back. Verisign employees presented several more technical papers, all of which are on the web site. One of them compared the name collision data from the Day In The Life snapshots (invariably called DITL and pronounced dittle) dataset with a five month series from the A and J root servers and unsurprisingly came to the conclusion that the DITL data is totally inadequate to predict what collisions were likely. This agrees with my informal observations of the "alternate path to delegation" which makes a list of names from DITL data to block from registration in new TLDs. (Most of them are useless random garbage names, which apparently are generated on the fly by the Chrome browser to check and see if domains are being wildcarded, and are unlikely ever to be seen again.) The last talk was by Jeff Schmidt of JAS Global Advisors, on his recent collision framework work. He ran through a lot of background, noting that in general when a technical identifiers change, e.g., area code splits or zip code changes, there's a publicity campaign to tell the people affected, then a transition period from the old to new identifiers. He said that a few TLDs, .CORP, .HOME, and .MAIL are so heavily (mis)used that they should never be delegated, but for other ones he suggests a publicity campaign. His idea is a 120 day "controlled interruption" transition period, during which a wildcard record in a TLD returns 127.0.53.53 to all requests. All 127/8 addresses are assigned to the loopback interface within a computer, so even if a computer attempts to contact that address, nothing will go out on the wire (he checked a lot of popular operating systems to be sure), but the address is different enough from the usual 127.0.0.1 to make it easy for anyone who's looking to notice. For people using BIND as a DNS cache, it's also possible to configure BIND to rewrite the 127.0.53.53 DNS result and replace it with an IP address on their own network where they can collect the traffic and see what's trying to talk to them. The CORP.COM domain gets vast amounts of DNS traffic, almost all appearing to be from hosts that are looking for .CORP but have helpful software that appends .COM if the first lookup fails. (There was a paper on that, too.) They're currently trying the 127.0.53.53 trick in *.CORP.COM, presumably to see who notices. Schmidt made the controlled interruption proposal in a paper commissioned by ICANN, who haven't yet decided what to do about it. From what I see, it's far better than the alternate path, and probably the best of a bad lot.
|
TopicsMy other sitesOther blogsCAUCE A keen grasp of the obvious Related sitesCoalition Against Unsolicited Commercial E-mail |
||||||||||||||||||
© 2005-2020 John R. Levine.
CAN SPAM address harvesting notice: the operator of this website will
not give, sell, or otherwise transfer addresses maintained by this
website to any other party for the purposes of initiating, or enabling
others to initiate, electronic mail messages.
