[Collisions] Collisions, smollisions!

[Jim Reid]

On Jan 21, 2014, at 6:38 AM, Andy Gardner <ceo at andygardner.com> wrote:

> Has anyone involved in these discussions finally come to the realisation that this is not the case and that a lot of this NXDOMAIN traffic is to be expected, is not the result of a collision, and is in fact a healthy sign?

Speaking only for myself, I have not come to that conclusion and strongly disagree with it.

For one thing, IMO the focus on NXDOMAIN responses from root servers is at best misguided and may well be completely wrong.

There are other aspects of the name collision problem that are probably more important and so far these do not appear to have been examined in detail yet. The Internet doesn't have the data to know whether these problems are serious or can be ignored -- both quantitatively and qualitatively -- or what their impact (and solutions) will be.

At present nobody knows what, if anything, will break when .mail (say) goes into the root and what that may do to currently deployed mail systems or stub resolvers that have a domain name with mail as a label in their search list. [This is not to pick on .mail. It's just an example of a name collision problem that needs investigation and may well require robust risk mitigation measures before the TLD goes live. There are other TLD strings like this which will already be in use as DNS labels, particularly in corporate settings: oracle and sap to pick just two.] The issues around TLD strings that clash with resolver search lists are largely orthogonal to concerns about NXDOMAIN responses. From that perspective the risk mitigation framework thing that ICANN has commissioned is long overdue and badly needed.

The Interisle study I worked on last summer identified other potential nasties. The MX and SRV queries found in the DITL data indicate things have been deliberately configured to lookup names with TLDs that were not in the root. How those currently operational systems will behave once certain TLDs get added is anyone's guess. The lookups coming from what appear to be Active Directory leaks is another. That one should worry us all.

It's also not as simple as saying "everything will be just fine provided the DNS continues to return NXDOMAIN for certain queries just like it does today" either.

The behaviour of the DNS *as a whole* changes once .foo goes into the root. Root servers will no longer return NXDOMAIN. They'll return a referrals to the .foo name servers which then presumably return NXDOMAIN (or whatever). Those referral responses break clients that are not set up to handle them. Nobody knows what harm that causes. Now some might say stub resolvers, stupid DNS proxies/forwarders and broken CPE that don't do iterative queries shouldn't be querying the root servers. I happen to agree with that PoV. However those idiot resolvers ARE querying the root now and they WILL break once the root returns a referral instead of an NXDOMAIN. How many systems will be affected and what are the likely consequences? Nobody can say yet with any reasonable degree of certainty.

Note too that other DNS traffic goes to the root besides DNS queries: eg dynamic updates. The responses to these can change when a TLD gets added and the impact of that on the orginating hosts is also unclear.

FWIW I'm saddened and disappointed that little discussion about these issues is taking place here (or elsewhere). It's not clear about what sort of analysis is being done on them either.

Another point: while the DITL datasets are pretty much the only repository of root DNS traffic, they only cover one day each year (or theresabouts). Traffic patterns may well be different on other days. Using that singular data source as the last word on name collision traffic would be like deciding how popular/busy a stadium is all year round by looking at the attendance on the day it hosts an Elvis concert. Though in the absence of any other data, the collision problem seems to be getting reduced to something nail-shaped for the DITL hammer.

IMO a more cautious approach is advisable, perhaps something along the lines of Verisign's ephemeral delegation proposal: ie delegate the TLD and leave it empty, analyse the actual DNS traffic to the TLD's name servers for a few weeks (at least) and then go into production once it's clear all is well and/or satisfactory risk mitigation measures are in place to deal with the *known* problems.