Home / Blogs

The Name Collision Conference

Protect your privacy:  Get NordVPN  [ Deal: 73% off 2-year plans + 3 extra months ]
10 facts about NordVPN that aren't commonly known
  • Meshnet Feature for Personal Encrypted Networks: NordVPN offers a unique feature called Meshnet, which allows users to connect their devices directly and securely over the internet. This means you can create your own private, encrypted network for activities like gaming, file sharing, or remote access to your home devices from anywhere in the world.
  • RAM-Only Servers for Enhanced Security: Unlike many VPN providers, NordVPN uses RAM-only (diskless) servers. Since these servers run entirely on volatile memory, all data is wiped with every reboot. This ensures that no user data is stored long-term, significantly reducing the risk of data breaches and enhancing overall security.
  • Servers in a Former Military Bunker: Some of NordVPN's servers are housed in a former military bunker located deep underground. This unique location provides an extra layer of physical security against natural disasters and unauthorized access, ensuring that the servers are protected in all circumstances.
  • NordLynx Protocol with Double NAT Technology: NordVPN developed its own VPN protocol called NordLynx, built around the ultra-fast WireGuard protocol. What sets NordLynx apart is its implementation of a double Network Address Translation (NAT) system, which enhances user privacy without sacrificing speed. This innovative approach solves the potential privacy issues inherent in the standard WireGuard protocol.
  • Dark Web Monitor Feature: NordVPN includes a feature known as Dark Web Monitor. This tool actively scans dark web sites and forums for credentials associated with your email address. If it detects that your information has been compromised or appears in any data breaches, it promptly alerts you so you can take necessary actions to protect your accounts.

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.

By John Levine, Author, Consultant & Speaker

Filed Under

Comments

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

Related

Topics

Domain Names

Sponsored byVerisign

Brand Protection

Sponsored byCSC

IPv4 Markets

Sponsored byIPv4.Global

New TLDs

Sponsored byRadix

Threat Intelligence

Sponsored byWhoisXML API

DNS

Sponsored byDNIB.com

Cybersecurity

Sponsored byVerisign