Is Verisign’s .net in trouble?

The zone file for Verisign’s .net gTLD has shrunk by almost 100,000 domains in the last few months.
I’ve been tracking .com and .net’s zone numbers since mid-March, shortly after the current wave of new gTLDs started going live, and while .com seems to be still growing strong, .net is definitely trending down.
The bulk of .net’s decline seems to have happened of the last three months. Its zone file count has decreased by 95,590 domains in the last 90 days, according to my numbers.
Here’s a chart, which you can click to enlarge, to illustrate what I’m talking about:

I don’t have comparable figures from previous years, so I can’t be certain that the downturn is not related to summer seasonality.
But if there is seasonality, it doesn’t appear to have affected .com, which has added over a million names to its zone over the last 90 days.

The last formal registry transactions report we have from Verisign for .net shows a decline of a little over 7,000 names under management in May.
Are these the early signs of trouble ahead for .net?
The TLD has always been a bit of an oddity. Originally designed for network operators, it was opened up and pitched in the 1990s by Network Solutions as a catch-all that should be acquired alongside .com.
That “Oh, I may as well buy the .net while I’m here” mentality stuck in the primary market, and I’ve often encountered the “I’ll throw in the .net for free” mentality in the secondary market.
But in a world of hundreds of new gTLDs I wonder whether .net’s brand caché will shrink.
If a registrant decides they can clearly do without defensively registering the .guru, the .pics, the .horse and the .wtf, perhaps they’ll start wondering why they bother to register the .net too.
Is .net on the verge of an unprecedented drop-off in registrations?
I’ll have to reserve judgement — that last 90 days might be a blip, and it only represents 0.63% of the .net business — but it’s going to be worth keeping an eye on, I think.
With 15 million names, the .net business is worth about $93 million a year in registry fees to Verisign.

Verisign plans TLD standards group

Verisign is trying to form a new industry standards-setting association for domain name registries and registrars.
To be called the Registration Operations Association^TM (yes, according to its web site it is apparently already trademarked), Verisign wants potential members of the group to meet in October to figure out whether such an association is needed and what its remit would be.
But the Domain Name Association apparently has other ideas, suggesting in a recent blog post that the DNA would be the best place for these kinds of technical discussions to take place.
In the second of a series of three blog posts revealing the ROA plan, Verisign senior director Scott Hollenbeck said:

The primary purpose of an association would be to facilitate communication and technical coordination among implementers and operators of the EPP protocol and its current extensions to address interoperability and efficiency obstacles.

EPP is the Extensible Provisioning Protocol used by registrars to transact with all gTLD and many ccTLD registries. It’s an IETF standard written by Hollenbeck over a decade ago.
One of the problems with it is that it is “extensible” by design, so every time a registry extends it to deal with a peculiarity of a particular TLD, partner registrars have to code new connectors.
In a world of hundreds of new gTLDs, that becomes burdensome, Hollenbeck explained in his posts.
An industry association such as the formative ROA could help registries with common requirements standardize on a single EPP extension, streamlining interoperability.
That would be good for new gTLDs.
It’s no secret that many registrars are struggling to keep up with new gTLD launches while providing a good customer experience, as Andrew Allemann pointed out last week.
The need for cooperation seems plain; the question now is what is the correct forum.
While Verisign is pushing for a new group, the DNA reckons the task could be best-performed under its own umbrella.
Executive director Kurt Pritz blogged:

Given its multi-functional and global diversity, the DNA will be an effective place to coordinate discussion of these issues and to involve broader domain name industry involvement.

Verisign isn’t a DNA member. In fact, it appears to be the only significant back-end registry provider in the western world not to have purchased a membership.
But Pritz said in his post that technical discussions would not be limited to DNA members only — anyone would be able to participate without coughing up the $5,000 to $50,000 a year the group charges:

Recognizing that industry-wide issues are… well … industry wide, the DNA Board determined that this work must include those inside and outside the DNA, welcoming all domain name industry members. Scott and others from Verisign and other firms are invited regardless of whether they join the DNA.

So is the industry going to have to deal with two rival standards-setting groups?
In the many years I was a general Silicon Valley tech reporter, I must have written scores of articles about new technologies spurring the creation of competing “standards” organizations.
Usually, this involved pitting an incumbent monopolist such as Microsoft against a coalition of smaller rivals.
It makes for great headlines, but I’m not sure the domain name industry is big enough to support or require multiple groups tackling the same problems.
With resource-strapped registries and registrars already struggling to make new gTLDs work in any meaningful way, I doubt their geeks would appreciate duplicating their efforts.
I don’t know whether the DNA or ROA would be the best venue for the work, but I strongly suspect the work itself, which almost certainly needs to be done, only needs to be done once.
Verisign wants interested parties to meet in Los Angeles on October 16, just as the ICANN meeting there concludes. The meeting may also be webcast for those unable to attend in person.

Reported mass exodus from .com explained

Did Verisign suffer from a massive 2,600% increase in the number of deleted .com domain names this April?
Not quite, although the bizarre spike in deletes may have highlighted an area where the company was previously out of compliance with its ICANN Registry Agreements.
April’s .com registry report, filed with ICANN and published last week, shows 2.4 million domains were deleted, compared to just 108,000 in March and 90,000 in April 2013.

The spike looks surprising, and you may be tempted to think it is in some way related to the arrival of new gTLDs.
But look again. Could .com, a registry with over 116 million domains under management, really only see roughly 100,000 deletes every month? Clearly that number is far too low.
So what’s going on? I asked Verisign.
The company said that it has implemented “voluntary” changes to its reporting of deleted domains, based on the standard new gTLD Registry Agreement, which specifies what must be reported by new gTLD registries.
It said:

Prior to the April 2014 monthly reports, and per the ICANN gTLD registry reporting guidelines, Verisign reported on only deleted domains outside of any grace period.

There are five “grace periods” permitted by ICANN contracts: the Add Grace Period, Renew/Extend Grace Period, Auto-Renew Grace Period, Transfer Grace Period, and Redemption Grace Period.
The familiar Add Grace Period allows registrars to cancel registrations within a week of registration if the registrant made a typo, for example, and asked for a refund.
The Redemption Grace Period covers domains that have expired and do not resolve, but can still be restored for 30 days at the request of the registrant.
According to Verisign, before April, domains that were deleted outside of any of the five grace periods were reported as “deleted-domains-nograce”.
From April, the company is reporting domains only as “deleted-domains-nograce” if they delete outside of the Add Grace Period.
According to my reading of the .com contract, that’s what Verisign should have been doing all along.
The contract, which Verisign and ICANN signed in late 2012, defines “deleted-domains-nograce” only as “domains deleted outside the add grace period”. There’s no mention of other grace periods.
The same definition can be found in the 2006 contract.
It appears to me that Verisign may have been under-reporting its deletes for quite some time.
Verisign said in response that it does not believe it has a compliance issue. A spokesperson said: “[We] voluntarily updated our reporting of deleting domain names so that our reporting is aligned with ICANN’s reporting clarifications for the new gTLDs.”

Verisign: 41% of new gTLD sites are parked

As much as 41% of domains registered in new gTLDs are parked with pay-per-click advertising, according to research carried out by Verisign.
That works out to over 540,000 domains, judging by the 1.3 million total I have on record from June 29, the day Verisign carried out the survey.
Domains classified as carrying “business” web sites — defined as “a website that shows commercial activity” — accounted for just 3% of the total, according to Verisign.
There are some big caveats, of course, not least of which is .xyz, which tends to skew any surveys based on “registered” names appearing in the zone file. Verisign noted:

XYZ.COM LLC (.xyz) has a high concentration of PPC websites as a result of a campaign that reportedly automatically registered XYZ domains to domain registrants in other TLDs unless they opted out of receiving the free domain name. After registration, these free names forward to a PPC site unless reconfigured by the end user registrant.

On June 29, .xyz had 225,159 domains in its zone file. I estimate somewhat over 200,000 of those names were most likely freebies and most likely parked.
The practice of registry parking, carried out most aggressively by Uniregistry and its affiliate North Sound, also threw off Verisign’s numbers.
Whereas most new gTLD registries reserve their premium names without adding them to the zone files, Uniregistry registers them via North Sound to park and promote them.
Tens of thousands of names have been registered in this way.
Coupled with the .xyz effect, this leads me to conclude that the number of domains registered by real registrants and parked with PPC is probably close to half of Verisign’s number.
That’s still one out of every five domains in new gTLDs, however.
Judging by a chart on Verisign’s blog, .photography appears to have the highest percentage of “business” use among the top 10 new gTLDs so far.
Verisign also found that 10% of the names it scanned redirect to a different domain. It classified these as redirects, rather than according to the content of their final destination.

ICANN says Verisign should stay in charge of root zone

Verisign should stay in its key role in root zone management after the IANA transition process is complete, according to ICANN CEO Fadi Chehade.
The company currently acts as “maintainer”, alongside the US government as “administrator” and ICANN/IANA as “operator”.
This means Verisign is responsible for actually making changes — adding, deleting or amending the records for TLDs — in the root zone file.
In a blog post yesterday, Chehade said that ICANN will “establish a relationship directly with the third-party Maintainer”, adding:

As a means to help ensure stability, ICANN’s recommended implementation option is to have Verisign continue its role as the Maintainer. However, we will be working closely with all relevant parties including the Root Zone Operators to ensure there are contingency options in place to meet our absolute commitment to the stability, security and resiliency of the Domain Name System.

I wholeheartedly agree that Verisign should stay in its role, or at the very least that ICANN should not take over.
As we’ve learned over the last couple of years of software glitches in the new gTLD program, some of them security-related, ICANN would be a poor choice today to maintain this critical resource.
Chehade noted that the US National Telecommunications and Information Administration would be replaced in its “administrator” role by whatever mechanism the ICANN community comes up with during the transition process.

Verisign stock punished after US move from root control

Verisign’s share price is down around 8% in early trading today, after analysts speculated that the US government’s planned move away from control of the DNS root put .com at risk.
The analyst firm Cowan & Co cut its rating on VRSN and reportedly told investors:

With less US control and without knowledge of what entity or entities will ultimately have power, we believe there is increased risk that VRSN may not be able to renew its .com and .net contracts in their current form.

It’s complete nonsense, of course.
The US announced on Friday it’s intention to step away from the trilateral agreements that govern control of the root between itself, ICANN and Verisign. But that deal has no dollar value to anyone.
What’s not affected, as ICANN CEO Fadi Chehade laboriously explained during his press conference Friday, are the contracts under which Verisign operates .com and .net.
The .com contract, through which Verisign derives most of its revenue, is slightly different to regular gTLD contracts in that the US has the right to veto terms if they’re considered anti-competitive.
The current contract, which runs through 2018, was originally going to retain Verisign’s right to increase its prices in most years, but it was vetoed by the US, freezing Verisign’s registry fee.
So not only has the US not said it will step away from .com oversight, but if it did it would be excellent news for Verisign, which would only have to strong-arm ICANN into letting it raise prices again.
Renewal of the .com and .net contracts shouldn’t be an issue either. The main rationale for putting .com up for rebid was to improve competition, but the new gTLD program is supposed to be doing that.
If new gTLDs, as a whole, are considered successful, I can’t see Verisign ever losing .com.
Verisign issued a statement before the markets opened today, saying:

The announcement by NTIA on Friday, March 14, 2014, does not affect Verisign’s operation of the .com and .net registries. The announcement does not impact Verisign’s .com or .net domain name business nor impact its .com or .net revenue or those agreements, which have presumptive rights of renewal.

ICANN reveals gTLD objections appeals process

Two new gTLD applicants would get the opportunity to formally appeal String Confusion Objection decisions that went against them, under plans laid out by ICANN today.
DERCars and United TLD (Rightside), which lost SCOs for their .cars and .cam applications respectively, would be the only parties able to appeal “inconsistent” objection rulings.
DERCars was told that its .cars was too similar to Google’s .car, forcing the two bids into a contention set. But Google lost similar SCO cases against two other .cars applicants.
Likewise, Rightside’s .cam application was killed off by a Verisign SCO that stated .cam and .com were too similar, despite two other .cam applicants prevailing in virtually identical cases.
Now ICANN plans to give both losing applicants the right to appeal these decisions to a three-person panel of “Last Resort” operated by the International Centre for Dispute Resolution.
ICDR was the body overseeing the original SCO process too.
Notably, ICANN’s new plan would not give Verisign and Google the right to appeal the two .cars/.cam cases they lost.

Only the applicant for the application that was objected to in the underlying SCO and lost (“Losing Applicant”) would have the option of whether to have the Expert Determination from that SCO reviewed.

There seems to be a presumption by ICANN already that what you might call the “minority” decision — ie, the one decision that disagreed with the other two — was the inconsistent one.
I wonder if that’s fair on Verisign.
Verisign lost two .cam SCO cases but won one, and only the one it won is open for appeal. But the two cases it lost were both decided by the same ICDR panelist, Murray Lorne Smith, on the same grounds. The decisions on .cam were really more 50-50 than they look.
According to the ICANN plan, there are two ways an appeal could go: the panel could decide that the original ruling should be reversed, or not. The standard of the review is:

Could the Expert Panel have reasonably come to the decision reached on the underlying SCO through an appropriate application of the standard of review as set forth in the Applicant Guidebook and procedural rules?

The appeals panelists would basically be asked to decide whether the original panelists are competent or not.
If the rulings were not reversed, the inconsistency would remain in place, making the contention sets for .car, .cars and .cam stay rather confusing.
ICANN said it would pay the appeals panel’s costs.
The plan (pdf) is now open for public comment.

MarkMonitor infiltrated by Syrian hackers targeting Facebook

The corporate brand protection registrar MarkMonitor was reportedly hacked yesterday by the group calling itself the Syrian Electronic Army, in an unsuccessful attempt to take out Facebook.
While MarkMonitor refused to confirm or deny the claims, the SEA, which has been conducting a campaign against high-profile western web sites for the last couple of years, tweeted several revealing screenshots.
One was a screen capture of a DomainTools Whois lookup for facebook.com, which does not appear to have been cached by DomainTools.

Happy Birthday Mark! http://t.co/yWBwvXPGRZ owned by #SEA http://t.co/gk8nGxATLt pic.twitter.com/eAeGp1TvBF

— SyrianElectronicArmy (@Official_SEA16) February 5, 2014

Another purported to be a cap of Facebook’s control panel at the registrar.

MarkMonitor Administration Panel. #SEA pic.twitter.com/7zDbUxHbYJ

— SyrianElectronicArmy (@Official_SEA16) February 6, 2014

The SEA tweeted more caps purporting to show it had access to domains belonging to Amazon and Yahoo!.
In response to an inquiry, MarkMonitor rather amusingly told DI “we do not comment on our clients — including neither confirming nor denying whether or not a company is a client.”
This despite the fact that the company publishes a searchable database of its clients on its web site.
The attackers were unable to take down Facebook itself because the company has rather wisely chosen to set its domain to use Verisign’s Registry Lock anti-hijacking service.
Registry Lock prevents domains’ DNS settings being changed automatically via registrar control panels. Instead, registrants need to provide a security pass phrase over the phone.

It’s official: Verisign has balls of steel

Verisign has spent the last six months telling anyone who will listen that new gTLDs will kill Japanese people and cause electricity grids to fail, so you’d expect the company to be a little coy about its own activities that (applying Verisign logic) endanger life and the global economy.
But apparently not.
Verisign today decided to use the same blog it has been using to play up the risks indicated by NXDOMAIN traffic in new gTLDs to plug its own service that actively encourages people to register error-traffic domains.
The company has launched DomainScope, which combines several older “domain discovery” tools — DomainFinder, DomainScore and DomainCountdown — under one roof.
According to an unsigned corporate blog post, with my emphasis:

DomainScope enables users to discover domain name registration opportunities through learning about the recent history of a domain name, understanding a domain name’s DNS traffic patterns, and knowing which domains are available that are receiving traffic.

That’s right, Verisign is giving malicious hackers the ability, for free, to find out which .com, .net and .tv domains currently receive NXDOMAIN traffic, so that the hackers can pay Verisign to register them and cause mayhem.
I used the service today see what mischief might be possible, and hit paydirt on my first query.
Typing in “mail” as the search query, ordering the results by “Traffic Score” — a 1 to 10 measure of how much error traffic a domain already gets — I got these results:

You’ll notice (click to enlarge if you don’t) that the third result, with a 9.9 out of 10 score, is netsoolmail.net.
That caught my attention for obvious reasons, and a little Googling seems to confirm that it’s a typo of netsolmail.net, a domain Network Solutions uses for its mail servers (or possibly a spam filter).
Network Solutions is of course a top-ten registrar with millions of mostly high-end customers.
So what?
Well, if Verisign’s arguments are to be believed, this poses a huge risk of information leakage — something that should be avoided at all costs in new gTLDs but which is apparently just fine in .com and .net.
Emails set to go to netsoolmail.net will fail today due to an NXDOMAIN response. But what happens when somebody registers that domain (which is likely to happen about 10 minutes after this post is published)?
Do they suddenly start receiving thousands of sensitive emails intended for NetSol’s customers?
Could NetSol’s spam filters all start to fail, causing SOMEBODY TO DIE! from a dodgy Viagra?
I don’t know. No clue. Probably not.
But there’s a risk, right? Even if it’s a very small risk (as Verisign argues), shouldn’t ICANN be preventing Verisign from promoting these domains, maybe using some kind of massive block-list?
Data leakage is important enough to Versign that it was the headline risk it posed in a recent report aimed at getting new gTLDs delayed.
In an August “technical report” entitled “New gTLD Security, Stability, Resiliency Update: Exploratory Consumer Impact Analysis”, somebody from Verisign wrote (pdf):

once delegated, the registrants under new gTLDs have the ability to register specific domains for targeted collisions
…
This form of information leakage can violate privacy of users, provide a competitive advantage between business rivals, expose details of corporate network infrastructures, or even be used to infer details about geographical locations of network assets or users

What the report fails to mention is that registrants today have this ability, and that Verisign is actively encouraging the practice.
In Yiddish they call what Verisign has done today chutzpah.
In British English, we call it taking the piss.

Verisign targets bank claims in name collisions fight

Verisign has rubbished the Commonwealth Bank of Australia’s claim that its dot-brand gTLD, .cba, is safe.
In a lengthy letter to ICANN today, Verisign senior vice president Pat Kane said that, contrary to CBA’s claims, the bank is only responsible for about 6% of the traffic .cba sees at the root.
It’s the latest volley in the ongoing fight about the security risks of name collisions — the scenario where an applied-for gTLD string is already in broad use on internal networks.
CBA’s application for .cba has been categorized as “uncalculated risk” by ICANN, meaning it faces more reviews and three to six months of delay while its risk profile is assessed.
But in a letter to ICANN last month, CBA said “the cause of the name collision is primarily from CBA internal systems” and “it is within the CBA realm of control to detect and remediate said systems”.
The bank was basically claiming that its own computers use DNS requests for .cba already, and that leakage of those requests onto the internet was responsible for its relatively high risk profile.
At the time we doubted that CBA had access to the data needed to draw this conclusion and Verisign said today that a new study of its own “shows without a doubt that CBA’s initial conclusions are incorrect”.
Since the publication of Interisle Consulting’s independent review into root server error traffic — which led to all applied-for strings being split into risk categories — Verisign has evidently been carrying out its own study.
While Interisle used data collected from almost all of the DNS root servers, Verisign’s seven-week study only looked at data gathered from the A-root and J-root, which it manages.
According to Verisign, .cba gets roughly 10,000 root server queries per day — 504,000 in total over the study window — and hardly any of them come from the bank itself.
Most appear to be from residential apartment complexes in Chiba, Japan, where network admins seem to have borrowed the local airport code — also CBA — to address local devices.
About 80% of the requests seen come from devices using DNS Service Discovery services such as Bonjour, Verisign said.
Bonjour is an Apple-created technology that allows computers to use DNS to automatically discover other LAN-connected devices such as printers and cameras, making home networking a bit simpler.
Another source of the .cba traffic is McAfee’s antivirus software, made by Intel, which Verisign said uses DNS to check whether code is virus-free before executing it.
While error traffic for .cba was seen from 170 countries, Verisign said that Japan — notable for not being Australia — was the biggest source, with almost 400,000 queries (79% of the total). It said:

Our measurement study reveals evidence of a substantial Internet-connected infrastructure in Japan that lies beneath the surface of the public-facing internet, which appears to rely on the non-resolution of the string .CBA.
This infrastructure appear hierarchical and seems to include municipal and private administrative and service networks associated with electronic resource management for office and residential building facilities, as well as consumer devices.

One apartment block in Chiba is is responsible for almost 5% of the daily .cba queries — about 500 per day on average — according to Verisign’s letter, though there were 63 notable sources in total.
ICANN’s proposal for reducing the risk of these name collisions causing problems would require CBA, as the registry, to hunt down and warn organizations of .cba’s impending delegation.
Verisign reiterates the point made by RIPE NCC last month: this would be quite difficult to carry out.
But it does seem that Verisign has done a pretty good job tracking down the organizations that would be affected by .cba being delegated.
The question that Verisign’s letter and presentation does not address is: what would happen to these networks if .cba was delegated?
If .cba is delegated, what will McAfee’s antivirus software do? Will it crash the user’s computer? Will it allow unsafe code to run? Will it cause false positives, blocking users from legitimate content?
Or will it simply fail gracefully, causing no security problems whatsoever?
Likewise, what happens when Bonjour expects .cba to not exist and it suddenly does? Do Apple computers start leaking data about the devices on their local network to unintended third parties?
Or does it, again, cause no security problems whatsoever?
Without satisfactory answers to those questions, maybe name collisions could be introduced by ICANN with little to no effect, meaning the “risk” isn’t really a risk at all.
Answering those questions will of course take time, which means delay, which is not something most applicants want to hear right now.
Verisign’s study targeted CBA because CBA singled itself out by claiming to be responsible for the .cba error traffic, not because CBA is a client of rival registry Afilias.
The bank can probably thank Verisign for its study, which may turn out to be quite handy.
Still, it would be interesting to see Verisign conduct a similar study on, say, .windows (Microsoft), .cloud (Symantec) or .bank (Financial Services Roundtable), which are among the 35 gTLDs with “uncalculated” risk profiles that Verisign promised to provide back-end registry services for before it decided that new gTLDs were dangerous.
You can read Verisign’s letter and presentation here. I’ve rotated the PDF to make the presentation more readable here.