The introduction of new gTLDs posed no risk to human life.
That’s the conclusion of JAS Advisors, the consulting company that has been working with ICANN on the issue of DNS name collisions.
It is final report “Mitigating the Risk of DNS Namespace Collisions”, published last night, JAS described the response to the “controlled interruption” mechanism it designed as “annoyed but understanding and generally positive”.
New text added since the July first draft says: “ICANN has received fewer than 30 reports of disruptive collisions since the first delegation in October of 2013. None of these reports have reached the threshold of presenting a danger to human life.”
That’s a reference to Verisign’s June 2013 claim that name collisions could disrupt “life-supporting” systems such as those used by emergency response services.
Names collisions, you will recall, are scenarios in which a newly delegated TLD matches a string that it is already used widely on internal networks.
Such scenarios could (and have) led to problems such as system failure and DNS queries leaking on to the internet.
The applied-for gTLDs .corp and .home have been effectively banned, due to the vast numbers of organizations already using them.
All other gTLDs were obliged, following JAS recommendations, to redirect all non-existent domains to 127.0.53.53, an IP address chosen to put network administrators in mind of port 53, which is used by the DNS protocol.
As we reported a little over a year ago, many administrators responded swearily to some of the first collisions.
JAS says in its final report:
Over the past year, JAS has monitored technical support/discussion fora in search of posts related to controlled interruption and DNS namespace collisions. As expected, controlled interruption caused some instances of limited operational issues as collision circumstances were encountered with new gTLD delegations. While some system administrators expressed frustration at the difficulties, overall it appears that controlled interruption in many cases is having the hoped-for outcome. Additionally, in private communication with a number of firms impacted by controlled interruption, JAS would characterize the overall response as “annoyed but understanding and generally positive” – some even expressed appreciation as issues unknown to them were brought to their attention.
There are a number of other substantial additions to the report, largely focusing on types of use cases JAS believes are responsible for most name collision traffic.
Oftentimes, such as the random 10-character domains Google’s Chrome browser uses for configuration purposes, the collision has no ill effect. In other cases, the local system administrators were forced to remedy their software to avoid the collision.
The report also reveals that the domain name corp.com, which is owned by long-time ICANN volunteer Mikey O’Connor, receives a “staggering” 30 DNS queries every second.
That works out to almost a billion (946,728,000) queries per year, coming when a misconfigured system or inexperienced user attempts to visit a .corp domain name.
Verisign has launched a free recursive DNS service aimed at the consumer market.
Public DNS, as the service is called, is being positioned as a way to avoid having your browsing history collated and sold for marketing purposes by your ISP.
There’s no charge, and the company is promising not to sell your data. It also does not plan to monetize NXDOMAIN traffic.
So what’s in it for Verisign? According to a FAQ:
One of Verisign’s core operating principles is to be a good steward of the Internet. Providing the Verisign Public DNS service supports the overall ecosystem of DNS and solidifies end-user trust in the critical navigation that they have come to depend upon for their everyday interactions.
Verisign also offers paid-for recursive DNS services to enterprises, so there may be an up-sell opportunity here.
The market for free public DNS currently has big players including Cisco’s OpenDNS and Google.
If you want to use the Verisign service, the IP addresses to switch to are 18.104.22.168 and 22.214.171.124.
Some networks in Iran appear to be systematically blocking Uniregistry’s .sexy gTLD.
That’s one of the conclusions of a slightly odd experiment commissioned by ICANN.
The newly published An Analysis of New gTLD Universal Acceptance was conducted by APNIC Labs. The idea was to figure out whether there are any issues with new gTLDs on the internet’s DNS infrastructure.
It concluded that there is not — new gTLDs work just fine on the internet’s plumbing.
However, the survey — which comprised over 100 million DNS resolution attempts — showed “One country, Iran, shows some evidence of a piecemeal block of Web names within the .sexy gTLD.”
The sample size for Iranian attempts to access .sexy was just 30 attempts. In most cases, users were able to resolve the names with DNS, but HTTP responses appeared to be blocked.
The survey did not test .porn or .adult names, but it might be safe to assume similar behavior in those gTLDs.
APNIC also concluded that Israel’s .il ccTLD, included in the report as a known example of TLD blocking at the national level, is indeed blocked in Iran and Syria.
The study also found that there may be issues with Adobe’s Flash software, when used in Internet Explorer, when it comes to resolving internationalized domain names.
That conclusion seems to have been reached largely because the test’s methodology saw a Flash advertisement discretely fetching URLs in the background of web pages using Google Ads.
When the experimenters used HTML 5 to run their scripts instead, there was no problem resolving the names.
The study did not look at some of the perhaps more pressing UA issues, such as the ability for registrants and others to use new gTLD domain names in web applications.
Security vendor Blue Coat apparently doesn’t check whether domains are actually domains before it advises customers to block them.
Unrepentant, Blue Coat continued to insist that businesses should consider blocking .zip domains, while acknowledging there aren’t any.
It said that its censorware treats anything entered into a browser’s address bar as a URL, so it has been treating file names that end in .zip — the common format for compressed archive files — as if they are .zip domain names. The blog states:
when one of those URLs shows up out on the public Internet, as a real Web request, we in turn treat it as a URL. Funny-looking URLs that don’t resolve tend to get treated as Suspicious — after all, we don’t see any counter-balancing legitimate traffic there.
Further, if a legal domain name gets enough shady-looking traffic — with no counter-evidence of legitimate Web traffic — it’s possible for one of our AI systems to conclude that the behavior isn’t changing, and that it deserves a Suspicious rating in the database. So it gets one.
In other words, Blue Coat has been categorizing Zip file names that somehow find their way into a browser address bar as .zip domain names.
That may sound like a software bug that Blue Coat needs to fix, but it’s still telling people to block Google’s gTLD anyway, writing:
In conclusion, none of the .zip “domains” we see in our traffic logs are requests to registered sites. Nevertheless, we recommend that people block these requests, until valid .zip domains start showing up.
That’s a slight change of position from its original “Businesses should consider blocking traffic that leads to the riskiest TLDs”, but it still strikes me as irresponsible.
The company has still not disclosed the real numbers behind any of the percentages in its report, so we still have no idea whether it was fair to label, for example, Famous Four’s .review as “100% shady”.
The Trademark Clearinghouse is investigating the causes and impact of an outage that is believed to have hit its primary database for 10 hours last Friday.
Some in the intellectual property community are concerned that the downtime may have allowed people to register domain names without receiving Trademark Claims notices.
The downtime was confirmed as unscheduled by the TMCH on a mailing list, but requests for more information sent its way today were deflected to ICANN.
An ICANN spokesperson said that the outage is being analyzed right now, which will take a couple of days.
The problem affected the IBM-administered Trademark Database, which registrars query to determine whether they need to serve up a Claims notice when a customer tries to register a domain that matches a trademark.
I gather that registries are supposed to reject registration attempts if they cannot get a definitive answer from the TMDB, but some are concerned that that may not have been the case during the downtime.
Over 145,000 Claims notices have been sent to trademark owners since the TMCH came online over a year ago.
(UPDATE: This story was edited May 21 to clarify that it is the TMCH conducting the investigation, rather than ICANN.)