DI Leaders Roundtable #2 — Should we kill off “Whois”?

Should we stop using the word “Whois” to describe registration data lookup services?
That’s the question I posed for the second DI Leaders Roundtable.
I’m sure you’re all very well aware that the Registration Data Access Protocol (RDAP) is the imminent replacement for the Whois protocol, as the technical method by which domain registrant contact information is stored, transmitted and displayed.
ICANN also regularly refers to Registration Data Directory Services (RDDS) as a protocol-independent blanket term covering the concept of looking up Whois or RDAP data.
You may also recall that ICANN, which is ostensibly a technical body, appears to bedeprecating the word “Whois” in favor of “Lookup” on its own web-based query service.
ICANN has a track record of introducing new acronyms to describe already well-understood functions. The IANA has technically been called “Public Technical Identifiers” for years, but does anyone actually call it “PTI”? No, everyone still talks about “IANA”.
So I wanted to know:

Should we continue to call it “Whois” after the technical transition to RDAP is complete? Will you continue to refer to “Whois”? Should we change to a different word or acronym? Should the industry standardardize its language one way or the other?

There seems to be a general consensus that “Whois” ain’t going anywhere.
The responses, in no particular order.
Jothan Frakes, Executive Director, Domain Name Association

The term WHOIS won’t quickly leave the zeitgeist due to the decades of its use as a description of the lookup process. Lookup is somewhat confusing, as there is DNS Query lookup that works across the resolution system, and WHOIS Lookup that works to find registrant info via the registration system. As far as the term “Lookup” as the label for the new normal that is poised to replace WHOIS? It is better than the acronym “RDDS”. The general public probably would not assume that RDDS is a way to find out about a domain owner or registration information, because it sounds like it involves dentistry (DDS) if one is not following the ICANN world as close as insiders. Despite the evolutionary path the basic function seems to be on, it is likely that WHOIS continues to be what the nickname for the lookup process called, regardless of the support technology layers below it not literally being WHOIS.

Frank Schilling, CEO, Uniregistry

WHOIS IS DEAD, LONG LIVE WHOIS.
The echo of “Whois” will live long after Whois is dead and gone. The very nature of its replacement word “Lookup” ensures that the information hungry public will expect more fulsome data than ICANN intends the word to provide. There will continue to be services who try to engineer a Whois hack and provide accurate underlying data for paying customers. Whois is going to outlive all of us. Even those who diet, exercise, and eat organic food.

Dave Piscitello, Partner, Interisle Consulting Group

Just as most of the world isn’t familiar with new TLDs, most have no appreciation for the differences between Whois and RDAP. The term “Whois” is convenient, memorable, and embedded. It also represents a service to most users, not a protocol, so if we do “standardize” we should use “RDS”. While we sort out the disastrous effects of ICANN’s Temp Spec policy on both investigators and victims of DNS abuse, most parties involved with educating policy makers and legislators should continue to use Whois for consistency’s sake.

Christa Taylor, CMO, MMX

As the old adage goes, “Don’t fix what’s not broken.” While “Whois” may have lost some of its luster due to GDPR I prefer to retain the term — it’s simple, representative of the information it provides and avoids adding any confusion especially for people outside of ICANN. Employing standardized language is, of course, logical and after twenty years of using “Whois” it is the accepted term both inside and outside the industry.

Sandeep Ramchamdani, CEO, Radix Registry

First up, the transition to the RDAP system is much needed given the fundamental flaws of Whois.
It would help in placing some guardrails around customers’ privacy while still providing agencies such as law enforcement authenticated access that they need to do their work.
Whois is a major cause of spam and in the age where privacy is top currency, public, unauthenticated availability of personal data is unacceptable.
It should also smooth out inter-registrar transfers and lower customer frustration while moving out to a different service provider.
When it comes to its name, calling it “RDAP” or “Lookup” would be a branding error. It would cause some confusion and for those not intimately involved in the industry, who may find it hard to discover the new system.
In my mind, keeping the original nomenclature “Whois”, while making it clear that it’s a newer avatar of the same solution would be the way to go.
Can’t think of a better term than “Whois 2.0”.
Very easy to understand that it’s a newer, more advanced iteration of the same product.

Michele Neylon, CEO, Blacknight

Whois was originally a simple little protocol that allowed network operators to contact each other to address technical issues. It predates the usage of domain names or the “web”.
When domains were introduced the same concept was simply transposed over to the new identifiers.
However over the past 20 plus years the way that people viewed Whois has morphed dramatically. The first time I spoke at an ICANN meeting 12 years ago was on the subject of Whois!
Now the term is used both to talk about the technical protocol, which is being replaced in the gTLD space and the data that it is used to store and possibly display. We talk about “Thin Whois”, “Thick Whois” and so many other services and issues linked back to it.
Whois as a protocol is far from perfect, which is why replacing the technical side of it makes a lot of sense.
So with the world slowly moving towards a new technical method for processing domain registration data then maybe we should come up with another word for it. However I’m not sure if there’s much to be gained by doing that.
We are all used to the floppy disk icon to save a document, even if floppy disks are no longer used. With the term “Whois” being part of people’s vocabulary for the nearly a quarter of a century. it’d be pretty hard to find a simple replacement and have people adopt it widely. Sure, in the more technical conversations it makes sense to use more accurate terms like “RDAP”, but the average punter just wants to be able to use a term that they can understand.
Those of us who work with domains and internet technology in our day jobs might care about the “correct” terminology, but we’re in a minority. We all get excited when the mainstream media picks up on a story involving domain names or the DNS and even gets half of it right! If we conjure up some new term that we think is accurate it’ll take years before anyone outside our bubble is comfortable with it. So I don’t think we should.
We should simply accept that “Whois” is a term used to refer to domain registration data no matter what technology under the hood is used to handle it.

Rick Schwartz, domain investor

Hate to give the same basic answer to two questions in a row, but who cares?
Really!! Who cares? Nobody!
This is inside baseball that doesn’t affect anyone on the entire planet except for a handful of domain investors and ICANN etc.
Call it whatever you like just make sure it’s public info.

Emoji domains get a 😟 after broad study

Domain names containing emojis are a security risk and not recommended, according to a pretty comprehensive review by an ICANN study group.
The Country-Code Names Supporting Organization has delivered the results of its 12-person, 18-month Emoji Study Group, which was tasked with looking into the problems emoji domains can cause, review current policy, and talk to ccTLD registries that currently permit emoji domains.
The ESG didn’t have a lot of power, and its recommendations are basically an exercise in can-kicking, but it’s easily the most comprehensive overview of the issues surrounding emoji domains that I’ve ever come across.
It’s 30 pages long, and you can read it here (pdf).
Emojis are currently banned in gTLDs, where ICANN has to approve new Unicode tables before they can be used by registries at the second level, under its internationalized domain name policy, IDNA 2008.
But ccTLDs, which are not contracted with ICANN, have a lot more flexibility. There are 15 ccTLDs — almost all representing small islands or low-penetration African nations — that currently permit emoji domains, the ESG found.
That’s about 6% of Latin-script ccTLDs out there today. These TLDs are .az, .cf, .fm, .je, .ga, .ge, .gg, .gq, .ml, .st, .to, .tk, .uz, .vu, and .ws.
Five of them, including .tk, are run by notorious freebie registry Freenom, but perhaps the best-known is .ws, where major brands such as Budweiser and Coca-Cola have run marketing campaigns in the past.
The main problem with emojis is the potential for confusing similarity, and the ESG report does a pretty good job of enumerating the ways confusability can arise. Take its comparison of multiple applications’ version of the exact same “grinning face” emoji, for example:

If you saw a domain containing one of those in marketing on one platform, would you be able to confidently navigate to the site on another? I doubt I would.
There’s also variations in how registrars handle emojis on their storefronts, the report found. On some you can search with an emoji, on others you’ll need to type out the xn-- prefixed Punycode translation longhand.
In terms of recommendations, the ESG basically just asked ICANN to keep an eye on the situation, to come to a better definition of what an emoji actually is, and to reach out for information to the ccTLDs accepting emojis, which apparently haven’t been keen on opening up so far.
Despite the lack of closure, it’s a pretty good read if you’re interested in this kind of thing.

ICANN enters talks to kill off Whois for good

Whois’ days are numbered.
ICANN is to soon enter talks with accredited registrars and contracted gTLD registries with the aim of naming a date to finally “sunset” the aging protocol.
It wants to negotiate amendments to the Registrar Accreditation Agreement and Registry Agreement with a view to replacing obligations to publish Whois with obligations to publish Registration Data Access Protocol data.
In letters to the chairs of its registrar and registry constituencies this week, ICANN CEO Göran Marby wrote:

The primary focus of the amendment is to incorporate contractual requirements for the Registration Data Access Protocol (RDAP) into the Registration Data Directory Services. This should include definition of the plan and provisions to sunset the obligations related to the WHOIS protocol as we transition Registration Data Services to RDAP.

For avoidance of doubt, people will still be able to look up the contact information for domain name owners after the change, but the data they see (very likely redacted for privacy reasons nowadays) will be delivered over a different protocol.
The contract amendment processes involve both registry and registrar constituencies to nominate a few people to engage in talks with ICANN negotiators, which is expected to conclude within 90 days.
When they come up with mutually acceptable language, the amendments will be open for both public comment and a vote of registries and registrars, before going to the ICANN board of directors for final approval.
The voting process is complex, designed to avoid capture by the largest registrars, and based on a balance of the number of voting registrars and the number of domains they collectively manage.
The contractual changes will come as no surprise to contracted parties, which have been on-notice for years that Whois is on its way out in favor of RDAP.
Most registrars already operate an RDAP server in parallel to their old Whois service, following an ICANN deadline in August.
We could be looking at the death of Whois within a year.

More than 1,000 new gTLDs a year? Sure!

There’s no particular reason ICANN shouldn’t be able to add more than 1,000 new gTLDs to the DNS every year, according to security experts.
The Security and Stability Advisory Committee has informed ICANN (pdf) that the cap, which was in place for the 2012 application round, “has no relevance for the security of the root zone”.
Back then, ICANN had picked the 1,000-a-year upper limit for delegations more or less out of thin air, as a straw man for SSAC, the root server operators, and those who were opposed to new gTLDs in general to shake their sticks at. It was concluded that 1,000 should present no issues.
As it turned out, it took two and a half years for ICANN to add the first 1,000 new gTLDs, largely due to the manual elements of the application process.
SSAC is now reiterating its previous advice that monitoring the rate of change at the root is more important than how many TLDs are added, and that there needs to be a way to slam the brakes on delegations if things go titsup.
The committee is also far more concerned that some of the 2012 new gTLDs are being quite badly abused by spammers and the like, and that ICANN is not doing enough to address this problem.

Paranoid ICANN opens another root server in China

ICANN has announced the creation of another root server instance in China, which definitely, DEFINITELY won’t let the Chinese government mess with the interwebs.
ICANN said this week that it’s opened an instance of the L-root that it manages in Shanghai.
It’s the third L-root in China but only the first outside of Beijing.
In a press release announcing the installation, which was carried out with technical support from CNNIC and Shanghai Telecom, ICANN decided to preemptively head off any concerns that putting an important piece of internet infrastructure in China comes with added security risk:

Contrary to common misconception, root servers do not control the Internet. The operation of an instance also does not provide any mechanism to alter content of the DNS. Any modification of root zone content will be mitigated by a part of the DNS protocol known as the DNS Security Extensions (DNSSEC) and if an instance fail to respond to a query, resolvers will ask the same question to another instance or root server.

It’s merely the latest of 168 L-root installations and 1,015 copies of the 13 logical root servers, which all use IP Anycast to more quickly serve DNS answers to their local users.
Given how big and populous China is, there are surprisingly few root server instances in the country, according to root-servers.org.
In addition to ICANN’s three boxes, Verisign’s J-root and Internet Systems Consortium’s F-root have three in Beijing and two in Hangzhou between them. The K, I and F roots each have one instance in Beijing.
That’s eight nodes in China proper, which has 800 million internet users. Cross the border into semi-autonomous Hong Kong, which has a population of under eight million people, and there are nine root instances.
The city of Bucharest, Romania (pop. 1.8 million) has the same number of root instances as China.

ICANN dumps the “Whois” in new Whois tool

Of all the jargon regularly deployed in the domain name industry and ICANN community, “Whois” is probably the one requiring the least explanation.
It’s self-explanatory, historically doing exactly what it says on the tin. But it’s on its way out, to be replaced by the far less user-friendly “RDAP”.
The latest piece of evidence of this transition: ICANN has pushed its old Whois query tool aside in favor of a new, primarily RDAP-based service that no longer uses the word “Whois”.
RDAP is the Registration Data Access Protocol, the IETF’s standardized Whois replacement to which gTLD registries and registrars are contractually obliged to migrate their registrant data.
Thankfully, ICANN isn’t branding the service on this rather opaque acronym. Rather, it’s using the word “Lookup” instead.
The longstanding whois.icann.org web site has been deprecated, replaced with lookup.icann.org. Visitors to the old page will be bounced to the new one.
The old site looked like this:

The new site looks like this:

It’s pretty much useless for most domains, if you want to find out who actually owns them.
If you query a .com or .net domain, you’ll only receive Verisign’s “thin” output. This does not included any registrant information.
That’s unlike most commercial Whois services, which also ping the relevant registrar for the full thick record.
For non-Verisign gTLDs, ICANN will return the registry’s thick record, but it will be very likely be mostly redacted, as required under ICANN’s post-GDPR privacy policy.
While contracted parties are still transitioning away from Whois to RDAP, the ICANN tool will fail over to the old Whois output if it receives no RDAP data.
Under current ICANN Whois policy, registries and registrars have until August 26 to deploy RDAP services to run alongside their existing Whois services.

ICANN’s new conferencing software has a webcam security bug

ICANN can’t catch a break when it comes to remote participation security, it seems.
Having just recently made the community-wide switch away from Adobe Connect to Zoom, partly for security reasons, now Zoom has been hit by what many consider to be a critical zero-day vulnerability.
Zoom (which, irrelevantly, uses a .us domain) pushed out an emergency patch for the vulnerability yesterday, which would have allowed malicious web sites to automatically turn on visitors’ webcams without their consent.
Only users of the installable Mac client were affected.
According to security researcher Jonathan Leitschuh, who discovered the problem, Zoom’s Mac client was installing a web server on users’ machines in order to bypass an Apple security feature that requires a confirmatory click before the webcam turns on.
This meant a web site owner could trick a user into a Zoom session, with their camera turned on by default, without their knowledge or consent.
If you’re in the habit of keeping your webcam lens uncovered, that’s potentially a big privacy problem, especially if you do most of your remote coverage of ICANN meetings from the toilet.
It appears that Leitschuh, who reported the problem to Zoom three months ago, took issue with what he saw as the company’s ambivalent attitude to fixing it in a timely fashion.
When he finally blogged about it on Monday, after giving Zoom a 90-day “responsible disclosure” period to issue a patch, the problem still hadn’t been fully resolved, he wrote.
But, following media coverage, Zoom’s new patch apparently removes the covert web server completely. This removes the vulnerability but means Apple users will have to click a confirmation button before joining Zoom meetings in future.
Zoom is used now for all of ICANN’s remote participation, from sessions of its public meetings to discussions of its policy-making working groups.
I really like it. It feels a lot less clunky than Adobe, and it’s got some nifty extra features such as the ability to skip around in recordings based on an often-hilarious machine-transcription sidebar, which makes my life much easier.
One of the reasons ICANN made the switch was due to a bug found in Adobe Connect last year that could have been used to steal confidential information from closed meetings.
ICANN actually turned off Adobe Rooms for remote participants halfway through its public meeting in Puerto Rico due to the bug.
The switch to Zoom was hoped to save ICANN $100,000 a year.

What time is it? For ICANN, even that can be a controversial question

ICANN has found itself involved in a debate about whether Russia’s 2014 annexation of Crimea should be recognized.
It’s not unusual for ICANN to find itself in geopolitical controversies — see .amazon for the most recent example — but this time, it’s not about domain names.
It’s about time zones.
One of the little-known functions ICANN provides via its IANA division is the hosting of the so-called TZ Database, which keeps track of all international time zones, daylight savings time practices, and so on.
The database is referenced by scores of operating systems, web sites, libraries and software development kits. It’s used by MacOS, many major Unix/Linux distributions, Java and PHP.
IANA took over the database in 2011, after the original administrator, David Olson, was hit with a bogus lawsuit from an astrology company.
It’s currently managed by University of California computer scientist Paul Eggert. He’s not an ICANN employee. He’s responsible for making changes to the database, which IANA hosts.
There are no complex layers of policy-making and bureaucracy, just an ICANN-hosted mailing list. it very much harks back to the pre-ICANN/Jon Postel/Just A Guy model of international database administration.
But because time zones are set by the governments of territories, and the ownership of territories is sometimes in dispute, the TZ Database often finds itself involved in political debates.
The latest of these relates to Crimea.
As you will recall, back in 2014 the Russian Federation annexed Crimea — part of Ukraine and formerly part of the Soviet Union.
The United Nations condemned the move as illegal and still refuses to recognize the region as part of Russia. The de facto capital city of Crimea is now Simferopol.
As part of the takeover, Russia switched its new territories over to Moscow Time (MSK), a time zone three hours ahead of UTC that does not observe daylight savings.
The rest of Ukraine continues to use Eastern European Time, which is UTC+2, and Eastern European Summer Time (UTC+3).
This means that in the winter months, Crimea is an hour out of whack with the rest of Ukraine.
Currently, the TZ Database’s entry for Simferpol contains the country code “RU”, instead of “UA”.
This means that if you go to Crimea and try to configure your Unix-based system to the local time, you’ll see an indication in the interface that you’re in Russia, which understandably pisses off Ukrainians and is not in line with what most governments think.
You can check this out on some time zone web sites. The services at time.is and timeanddate.com both refer to Europe/Simferopol as being in Ukraine, while WorldTimeServer says it’s in Russia.
The TZ Database mailing list has recently received a couple of complaints from Ukrainians, including the head of the local cyber police, about this issue.
Serhii Demediuk, head of the Cyberpolice Department of the National Police of Ukraine, wrote in December:

by referring Crimea with the country code “RU”, your organization actually accepts and supports the aggressive actions of the Russian Federation who’s armed forces annexed this part of Ukraine. Such recognition may be considered as a criminal offense by the Ukrainian criminal law and we will be obliged to start formal criminal proceedings

It’s the longstanding principle of the TZ Database administrators that they’re not taking political positions when they assign country-codes to time zones, they’re just trying to be practical.
If somebody shows up for a business meeting in Crimea in December, they don’t want their clock to be an hour behind their local host’s for the sake of political correctness.
But Eggert nevertheless has proposed a patch that he believes may address Ukrainian concerns. It appears to have Simferopol listed as both RU and UA.

ICANN got hacked by crypto bots

ICANN had to take down its community wiki for several hours last week after it got hacked by crypto-currency miners.
The bad guys got in via one of two “critical” vulnerabilities in Confluence, the wiki software that ICANN licences from Atlassian Systems, which ICANN had not yet patched.
ICANN’s techies noticed the wiki, which is used by many of its policy-making bodies to coordinate their work, was running slowly April 11.
They quickly discovered that Atlassian had issued a vulnerability warning on March 20, but ICANN was not on its mailing list (doh!) so hadn’t been directly notified.
They also determined that a malicious “Crypto-Miner” — software that uses spare CPU cycles to attempt to create new cryptocurrency coins — had been installed and was responsible for the poor performance.
ICANN said it took the wiki down, restored it to a recent backup, patched Confluence, and brought the system back online. It seems to have taken a matter of hours from discovery to resolution.
The organization said it has now subscribed to Atlassian’s mailing list, so it will be notified of future vulnerabilities directly.

Root servers whacked after crypto change

The DNS root servers came under accidental attack from name servers across the internet following ICANN’s recent changes to their cryptographic master keys, according to Verisign.
The company, which runs the A and J root servers, said it saw requests for DNSSEC data at the root increase from 15 million a day in October to 1.15 billion a day a week ago.
The cause was the October 11 root Key Signing Key rollover, the first change ICANN had made to the “trust anchor” of DNSSEC since it came online at the root in 2010.
The KSK rollover saw ICANN change the cryptographic keys that rest at the very top of the DNSSEC hierarchy.
The move was controversial. ICANN delayed it for a year after learning about possible disruption at internet endpoints. Its Security and Stability Advisory Committee and even its own board were not unanimous that the roll should go ahead.
But the warnings were largely about the impact on internet users, rather than on the root servers themselves, and the impact was minimal.
Verisign is now saying that requests to its roots for DNSSEC key data increased from 15 million per day to 75 million per day, a five-fold increase, almost overnight.
It was not until January, when the old KSK was marked as “revoked”, did the seriously mahooosive traffic growth begin, however. Verisign’s distinguished engineer Duane Wessels wrote:

Everyone involved expected this to be a non-event. However, we instead saw an even bigger increase in DNSKEY queries coming from a population of root server clients. As of March 21, 2019, Verisign’s root name servers receive about 1.15 billion DNSKEY queries per day, which is 75 times higher than pre-rollover levels and nearly 7 percent of our total steady state query traffic.

Worryingly, the traffic only seemed to be increasing, until March 22, when the revoked key was removed from the root entirely.
Wessels wrote that while the root operators are still investigating, “it would seem that the presence of the revoked key in the zone triggered some unexpected behavior in a population of validating resolvers.”
The root operators hope to have answers in the coming weeks, he wrote.
The next KSK rollover is not expected for years, and the root traffic is now returning to normal levels, so there’s no urgency.