Login
The data privacy company Onerep.com bills itself as a Virginia-based service for helping people remove their personal information from almost 200 people-search websites. However, an investigation into the history of onerep.com finds this company is operating out of Belarus and Cyprus, and that its founder has launched dozens of people-search services over the years.
Onerep’s “Protect” service starts at $8.33 per month for individuals and $15/mo for families, and promises to remove your personal information from nearly 200 people-search sites. Onerep also markets its service to companies seeking to offer their employees the ability to have their data continuously removed from people-search sites.
A testimonial on onerep.com.
Customer case studies published on onerep.com state that it struck a deal to offer the service to employees of Permanente Medicine, which represents the doctors within the health insurance giant Kaiser Permanente. Onerep also says it has made inroads among police departments in the United States.
But a review of Onerep’s domain registration records and that of its founder reveal a different side to this company. Onerep.com says its founder and CEO is Dimitri Shelest from Minsk, Belarus, as does Shelest’s profile on LinkedIn. Historic registration records indexed by DomainTools.com say Mr. Shelest was a registrant of onerep.com who used the email address dmitrcox2@gmail.com.
A search in the data breach tracking service Constella Intelligence for the name Dimitri Shelest brings up the email address dimitri.shelest@onerep.com. Constella also finds that Dimitri Shelest from Belarus used the email address d.sh@nuwber.com, and the Belarus phone number +375-292-702786.
Nuwber.com is a people search service whose employees all appear to be from Belarus, and it is one of dozens of people-search companies that Onerep claims to target with its data-removal service. Onerep.com’s website disavows any relationship to Nuwber.com, stating quite clearly, “Please note that OneRep is not associated with Nuwber.com.”
However, there is an abundance of evidence suggesting Mr. Shelest is in fact the founder of Nuwber. Constella found that Minsk telephone number (375-292-702786) has been used multiple times in connection with the email address dmitrcox@gmail.com. Recall that Onerep.com’s domain registration records in 2018 list the email address dmitrcox2@gmail.com.
It appears Mr. Shelest sought to reinvent his online identity in 2015 by adding a “2” to his email address. The Belarus phone number tied to Nuwber.com shows up in the domain records for comversus.com, and DomainTools says this domain is tied to both dmitrcox@gmail.com and dmitrcox2@gmail.com. Other domains that mention both email addresses in their WHOIS records include careon.me, docvsdoc.com, dotcomsvdot.com, namevname.com, okanyway.com and tapanyapp.com.
Onerep.com CEO and founder Dimitri Shelest, as pictured on the “about” page of onerep.com.
A search in DomainTools for the email address dmitrcox@gmail.com shows it is associated with the registration of at least 179 domain names, including dozens of mostly now-defunct people-search companies targeting citizens of Argentina, Brazil, Canada, Denmark, France, Germany, Hong Kong, Israel, Italy, Japan, Latvia and Mexico, among others.
Those include nuwber.fr, a site registered in 2016 which was identical to the homepage of Nuwber.com at the time. DomainTools shows the same email and Belarus phone number are in historic registration records for nuwber.at, nuwber.ch, and nuwber.dk (all domains linked here are to their cached copies at archive.org, where available).
Nuwber.com, circa 2015. Image: Archive.org.
Update, March 21, 11:15 a.m. ET: Mr. Shelest has provided a lengthy response to the findings in this story. In summary, Shelest acknowledged maintaining an ownership stake in Nuwber, but said there was “zero cross-over or information-sharing with OneRep.” Mr. Shelest said any other old domains that may be found and associated with his name are no longer being operated by him.
“I get it,” Shelest wrote. “My affiliation with a people search business may look odd from the outside. In truth, if I hadn’t taken that initial path with a deep dive into how people search sites work, Onerep wouldn’t have the best tech and team in the space. Still, I now appreciate that we did not make this more clear in the past and I’m aiming to do better in the future.” The full statement is available here (PDF).
Original story:
Historic WHOIS records for onerep.com show it was registered for many years to a resident of Sioux Falls, SD for a completely unrelated site. But around Sept. 2015 the domain switched from the registrar GoDaddy.com to eNom, and the registration records were hidden behind privacy protection services. DomainTools indicates around this time onerep.com started using domain name servers from DNS provider constellix.com. Likewise, Nuwber.com first appeared in late 2015, was also registered through eNom, and also started using constellix.com for DNS at nearly the same time.
Listed on LinkedIn as a former product manager at OneRep.com between 2015 and 2018 is Dimitri Bukuyazau, who says their hometown is Warsaw, Poland. While this LinkedIn profile (linkedin.com/in/dzmitrybukuyazau) does not mention Nuwber, a search on this name in Google turns up a 2017 blog post from privacyduck.com, which laid out a number of reasons to support a conclusion that OneRep and Nuwber.com were the same company.
“Any people search profiles containing your Personally Identifiable Information that were on Nuwber.com were also mirrored identically on OneRep.com, down to the relatives’ names and address histories,” Privacyduck.com wrote. The post continued:
“Both sites offered the same immediate opt-out process. Both sites had the same generic contact and support structure. They were – and remain – the same company (even PissedConsumer.com advocates this fact: https://nuwber.pissedconsumer.com/nuwber-and-onerep-20160707878520.html).”
“Things changed in early 2016 when OneRep.com began offering privacy removal services right alongside their own open displays of your personal information. At this point when you found yourself on Nuwber.com OR OneRep.com, you would be provided with the option of opting-out your data on their site for free – but also be highly encouraged to pay them to remove it from a slew of other sites (and part of that payment was removing you from their own site, Nuwber.com, as a benefit of their service).”
Reached via LinkedIn, Mr. Bukuyazau declined to answer questions, such as whether he ever worked at Nuwber.com. However, Constella Intelligence finds two interesting email addresses for employees at nuwber.com: d.bu@nuwber.com, and d.bu+figure-eight.com@nuwber.com, which was registered under the name “Dzmitry.”
PrivacyDuck’s claims about how onerep.com appeared and behaved in the early days are not readily verifiable because the domain onerep.com has been completely excluded from the Wayback Machine at archive.org. The Wayback Machine will honor such requests if they come directly from the owner of the domain in question.
Still, Mr. Shelest’s name, phone number and email also appear in the domain registration records for a truly dizzying number of country-specific people-search services, including pplcrwlr.in, pplcrwlr.fr, pplcrwlr.dk, pplcrwlr.jp, peeepl.br.com, peeepl.in, peeepl.it and peeepl.co.uk.
The same details appear in the WHOIS registration records for the now-defunct people-search sites waatpp.de, waatp1.fr, azersab.com, and ahavoila.com, a people-search service for French citizens.
The German people-search site waatp.de.
A search on the email address dmitrcox@gmail.com suggests Mr. Shelest was previously involved in rather aggressive email marketing campaigns. In 2010, an anonymous source leaked to KrebsOnSecurity the financial and organizational records of Spamit, which at the time was easily the largest Russian-language pharmacy spam affiliate program in the world.
Spamit paid spammers a hefty commission every time someone bought male enhancement drugs from any of their spam-advertised websites. Mr. Shelest’s email address stood out because immediately after the Spamit database was leaked, KrebsOnSecurity searched all of the Spamit affiliate email addresses to determine if any of them corresponded to social media accounts at Facebook.com (at the time, Facebook allowed users to search profiles by email address).
That mapping, which was done mainly by generous graduate students at my alma mater George Mason University, revealed that dmitrcox@gmail.com was used by a Spamit affiliate, albeit not a very profitable one. That same Facebook profile for Mr. Shelest is still active, and it says he is married and living in Minsk [Update, Mar. 16: Mr. Shelest’s Facebook account is no longer active].
The Italian people-search website peeepl.it.
Scrolling down Mr. Shelest’s Facebook page to posts made more than ten years ago show him liking the Facebook profile pages for a large number of other people-search sites, including findita.com, findmedo.com, folkscan.com, huntize.com, ifindy.com, jupery.com, look2man.com, lookerun.com, manyp.com, peepull.com, perserch.com, persuer.com, pervent.com, piplenter.com, piplfind.com, piplscan.com, popopke.com, pplsorce.com, qimeo.com, scoutu2.com, search64.com, searchay.com, seekmi.com, selfabc.com, socsee.com, srching.com, toolooks.com, upearch.com, webmeek.com, and many country-code variations of viadin.ca (e.g. viadin.hk, viadin.com and viadin.de).
The people-search website popopke.com.
Domaintools.com finds that all of the domains mentioned in the last paragraph were registered to the email address dmitrcox@gmail.com.
Mr. Shelest has not responded to multiple requests for comment. KrebsOnSecurity also sought comment from onerep.com, which likewise has not responded to inquiries about its founder’s many apparent conflicts of interest. In any event, these practices would seem to contradict the goal Onerep has stated on its site: “We believe that no one should compromise personal online security and get a profit from it.”
The people-search website findmedo.com.
Max Anderson is chief growth officer at 360 Privacy, a legitimate privacy company that works to keep its clients’ data off of more than 400 data broker and people-search sites. Anderson said it is concerning to see a direct link between between a data removal service and data broker websites.
“I would consider it unethical to run a company that sells people’s information, and then charge those same people to have their information removed,” Anderson said.
Last week, KrebsOnSecurity published an analysis of the people-search data broker giant Radaris, whose consumer profiles are deep enough to rival those of far more guarded data broker resources available to U.S. police departments and other law enforcement personnel.
That story revealed that the co-founders of Radaris are two native Russian brothers who operate multiple Russian-language dating services and affiliate programs. It also appears many of the Radaris founders’ businesses have ties to a California marketing firm that works with a Russian state-run media conglomerate currently sanctioned by the U.S. government.
KrebsOnSecurity will continue investigating the history of various consumer data brokers and people-search providers. If any readers have inside knowledge of this industry or key players within it, please consider reaching out to krebsonsecurity at gmail.com.
Update, March 15, 11:35 a.m. ET: Many readers have pointed out something that was somehow overlooked amid all this research: The Mozilla Foundation, the company that runs the Firefox Web browser, has launched a data removal service called Mozilla Monitor that bundles OneRep. That notice says Mozilla Monitor is offered as a free or paid subscription service.
“The free data breach notification service is a partnership with Have I Been Pwned (“HIBP”),” the Mozilla Foundation explains. “The automated data deletion service is a partnership with OneRep to remove personal information published on publicly available online directories and other aggregators of information about individuals (“Data Broker Sites”).”
In a statement shared with KrebsOnSecurity.com, Mozilla said they did assess OneRep’s data removal service to confirm it acts according to privacy principles advocated at Mozilla.
“We were aware of the past affiliations with the entities named in the article and were assured they had ended prior to our work together,” the statement reads. “We’re now looking into this further. We will always put the privacy and security of our customers first and will provide updates as needed.”
Related tags
Today, the latest issue of The Domain Name Industry Brief Quarterly Report was released by DNIB.com, showing the fourth quarter of 2023 closed with 359.8 million domain name registrations across all top-level domains (TLDs), an increase of 0.6 million domain name registrations, or 0.2%, compared to the third quarter of 2023. Domain name registrations also increased by 8.9 million, or 2.5%, year over year.
Check out the latest issue of The Domain Name Industry Brief Quarterly Report to see domain name stats from the fourth quarter of 2023, including:
DNIB.com and The Domain Name Industry Brief Quarterly Report are sponsored by Verisign. To see past issues of the quarterly report, interactive dashboards and learn about DNIB.com’s statistical methodology, please visit DNIB.com.
The post Domain Name Industry Brief Quarterly Report: DNIB.com Announces 359.8 Million Domain Name Registrations in the Fourth Quarter of 2023 appeared first on Verisign Blog.
In 2020, the United States brought charges against four men accused of building a bulletproof hosting empire that once dominated the Russian cybercrime industry and supported multiple organized cybercrime groups. All four pleaded guilty to conspiracy and racketeering charges. But there is a fascinating and untold backstory behind the two Russian men involved, who co-ran the world’s top spam forum and worked closely with Russia’s most dangerous cybercriminals.
From January 2005 to April 2013, there were two primary administrators of the cybercrime forum Spamdot (a.k.a Spamit), an invite-only community for Russian-speaking people in the businesses of sending spam and building botnets of infected computers to relay said spam. The Spamdot admins went by the nicknames Icamis (a.k.a. Ika), and Salomon (a.k.a. Sal).
Spamdot forum administrator “Ika” a.k.a. “Icamis” responds to a message from “Tarelka,” the botmaster behind the Rustock botnet. Dmsell said: “I’m actually very glad that I switched to legal spam mailing,” prompting Tarelka and Ika to scoff.
As detailed in my 2014 book, Spam Nation, Spamdot was home to crooks controlling some of the world’s nastiest botnets, global malware contagions that went by exotic names like Rustock, Cutwail, Mega-D, Festi, Waledac, and Grum.
Icamis and Sal were in daily communications with these botmasters, via the Spamdot forum and private messages. Collectively in control over millions of spam-spewing zombies, those botmasters also continuously harvested passwords and other data from infected machines.
As we’ll see in a moment, Salomon is now behind bars, in part because he helped to rob dozens of small businesses in the United States using some of those same harvested passwords. He is currently housed in a federal prison in Michigan, serving the final stretch of a 60-month sentence.
But the identity and whereabouts of Icamis have remained a mystery to this author until recently. For years, security experts — and indeed, many top cybercriminals in the Spamit affiliate program — have expressed the belief that Sal and Icamis were likely the same person using two different identities. And there were many good reasons to support this conclusion.
For example, in 2010 Spamdot and its spam affiliate program Spamit were hacked, and its user database shows Sal and Icamis often accessed the forum from the same Internet address — usually from Cherepovets, an industrial town situated approximately 230 miles north of Moscow. Also, it was common for Icamis to reply when Spamdot members communicated a request or complaint to Sal, and vice versa.
Image: maps.google.com
Still, other clues suggested Icamis and Sal were two separate individuals. For starters, they frequently changed the status on their instant messenger clients at different times. Also, they each privately discussed with others having attended different universities.
KrebsOnSecurity began researching Icamis’s real-life identity in 2012, but failed to revisit any of that research until recently. In December 2023, KrebsOnSecurity published new details about the identity of “Rescator,” a Russian cybercriminal who is thought to be closely connected to the 2013 data breach at Target.
That story mentioned Rescator’s real-life identity was exposed by Icamis in April 2013, as part of a lengthy farewell letter Ika wrote to Spamdot members wherein Ika said he was closing the forum and quitting the cybercrime business entirely.
To no one’s shock, Icamis didn’t quit the business: He simply became more quiet and circumspect about his work, which increasingly was focused on helping crime groups siphon funds from U.S. bank accounts. But the Rescator story was a reminder that 10 years worth of research on who Ika/Icamis is in real life had been completely set aside. This post is an attempt to remedy that omission.
The farewell post from Ika (aka Icamis), the administrator of both the BlackSEO forum and Pustota, the successor forum to Spamit/Spamdot.
Icamis and Sal offered a comprehensive package of goods and services that any aspiring or accomplished spammer would need on a day-to-day basis: Virtually unlimited bulletproof domain registration and hosting services, as well as services that helped botmasters evade spam block lists generated by anti-spam groups like Spamhaus.org. Here’s snippet of Icamis’s ad on Spamdot from Aug. 2008, wherein he addresses forum members with the salutation, “Hello Gentlemen Scammers.”
We are glad to present you our services!
Many are already aware (and are our clients), but publicity is never superfluous.Domains.
– all major gtlds (com, net, org, info, biz)
– many interesting and uninteresting cctlds
– options for any topic
– processing of any quantities
– guarantees
– exceptionally low prices for domains for white and gray schemes (including any SEO and affiliate spam )
– control panel with balances and auto-registration
– all services under the Ikamis brand, proven over the years;)Servers.
– long-term partnerships with several [data centers] in several parts of the world for any topic
– your own data center (no longer in Russia ;)) for gray and white topics
– any configuration and any hardware
– your own IP networks (PI, not PA) and full legal support
– realtime backups to neutral sites
– guarantees and full responsibility for the services provided
– non-standard equipment on request
– our own admins to resolve any technical issues (services are free for clients)
– hosting (shared and vps) is also possibleNon-standard and related services.
– ssl certificates signed by geotrust and thawte
– old domains (any year, any quantity)
– beautiful domains (keyword, short, etc.)
– domains with indicators (any, for SEO, etc.)
– making unstable gtld domains stable
– interception and hijacking of custom domains (expensive)
– full domain posting via web.archive.org with restoration of native content (preliminary applications)
– any updates to our panels to suit your needs upon request (our own coders)All orders for the “Domains” sections and “Servers” are carried out during the day (depending on our workload).
For non-standard and related services, a preliminary application is required 30 days in advance (except for ssl certificates – within 24 hours).
Icamis and Sal frequently claimed that their service kept Spamhaus and other anti-spam groups several steps behind their operations. But it’s clear that those anti-spam operations had a real and painful impact on spam revenues, and Salomon was obsessed with striking back at anti-spam groups, particularly Spamhaus.
In 2007, Salomon collected more than $3,000 from botmasters affiliated with competing spam affiliate programs that wanted to see Spamhaus suffer, and the money was used to fund a week-long distributed denial-of-service (DDoS) attack against Spamhaus and its online infrastructure. But rather than divert their spam botnets from their normal activity and thereby decrease sales, the botmasters voted to create a new DDoS botnet by purchasing installations of DDoS malware on thousands of already-hacked PCs (at a rate of $25 per 1,000 installs).
As an affiliate of Spamdot, Salomon used the email address ad1@safe-mail.net, and the password 19871987gr. The breach tracking service Constella Intelligence found the password 19871987gr was used by the email address grichishkin@gmail.com. Multiple accounts are registered to that email address under the name Alexander Valerievich Grichishkin, from Cherepovets.
In 2020, Grichishkin was arrested outside of Russia on a warrant for providing bulletproof hosting services to cybercriminal gangs. The U.S. government said Grichishkin and three others set up the infrastructure used by cybercriminals between 2009 to 2015 to distribute malware and attack financial institutions and victims throughout the United States.
Those clients included crooks using malware like Zeus, SpyEye, Citadel and the Blackhole exploit kit to build botnets and steal banking credentials.
“The Organization and its members helped their clients to access computers without authorization, steal financial information (including banking credentials), and initiate unauthorized wire transfers from victims’ financial accounts,” the government’s complaint stated.
Grichishkin pleaded guilty to conspiracy charges and was sentenced to four years in prison. He is 36 years old, has a wife and kids in Thailand, and is slated for release on February 8, 2024.
The identity of Icamis came into view when KrebsOnSecurity began focusing on clues that might connect Icamis to Cherepovets (Ika’s apparent hometown based on the Internet addresses he regularly used to access Spamdot).
Historic domain ownership records from DomainTools.com reveal that many of the email addresses and domains connected to Icamis invoke the name “Andrew Artz,” including icamis[.]ws, icamis[.]ru, and icamis[.]biz. Icamis promoted his services in 2003 — such as bulk-domains[.]info — using the email address icamis@4host.info. From one of his ads in 2005:
Domains For Projects Advertised By Spam
I can register bulletproof domains for sites and projects advertised by spam(of course they must be legal). I can not provide DNS for u, only domains. The price will be:
65$ for domain[if u will buy less than 5 domains]
50$ for domain[more than 5 domains]
45$ for domain[more than 10 domains]
These prices are for domains in the .net & .com zones.
If u want to order domains write me to: icamis@4host.info
In 2009, an “Andrew Artz” registered at the hosting service FirstVDS.com using the email address icamis@4host.info, with a notation saying the company name attached to the account was “WMPay.” Likewise, the bulletproof domain service icamis[.]ws was registered to an Andrew Artz.
The domain wmpay.ru is registered to the phonetically similar name “Andrew Hertz,” at andrew@wmpay.ru. A search on “icamis.ru” in Google brings up a 2003 post by him on a discussion forum designed by and for students of Amtek, a secondary school in Cherepovets (Icamis was commenting from an Internet address in Cherepovets).
The website amtek-foreva-narod.ru is still online, and it links to several yearbooks for Amtek graduates. It states that the yearbook for the Amtek class of 2004 is hosted at 41.wmpay[.]com.
The yearbook photos for the Amtek class of 2004 are not indexed in the Wayback Machine at archive.org, but the names and nicknames of 16 students remain. However, it appears that the entry for one student — the Wmpay[.]com site administrator — was removed at some point.
In 2004, the administrator of the Amtek discussion forum — a 2003 graduate who used the handle “Grand” — observed that there were three people named Andrey who graduated from Amtek in 2004, but one of them was conspicuously absent from the yearbook at wmpay[.]ru: Andrey Skvortsov.
To bring this full circle, Icamis was Andrey Skvortsov, the other Russian man charged alongside Grichiskin (the two others who pleaded guilty to conspiracy charges were from Estonia and Lithuania). All of the defendants in that case pleaded guilty to conspiracy to engage in a Racketeer Influenced Corrupt Organization (RICO).
[Author’s note: No doubt government prosecutors had their own reasons for omitting the nicknames of the defendants in their press releases, but that information sure would have saved me a lot of time and effort].
Skvortsov was sentenced to time served, and presumably deported. His current whereabouts are unknown and he was not reachable for comment via his known contact addresses.
The government says Ika and Sal’s bulletproof hosting empire provided extensive support for a highly damaging cybercrime group known as the JabberZeus Crew, which worked closely with the author of the Zeus Trojan — Evgeniy Mikhailovich Bogachev — to develop a then-advanced strain of the Zeus malware that was designed to defeat one-time codes for authentication. Bogachev is a top Russian cybercriminal with a standing $3 million bounty on his head from the FBI.
The JabberZeus Crew stole money by constantly recruiting money mules, people in the United States and in Europe who could be enticed or tricked into forwarding money stolen from cybercrime victims. Interestingly, Icamis’s various email addresses are connected to websites for a vast network of phony technology companies that claimed they needed people with bank accounts to help pay their overseas employees.
Icamis used the email address tech@safe-mail.net on Spamdot, and this email address is tied to the registration records for multiple phony technology companies that were set up to recruit money mules.
One such site — sun-technology[.]net — advertised itself as a Hong Kong-based electronics firm that was looking for “honest, responsible and motivated people in UK, USA, AU and NZ to be Sales Representatives in your particular region and receive payments from our clients. Agent commission is 5 percent of total amount received to the personal bank account. You may use your existing bank account or open a new one for these purposes.”
In January 2010, KrebsOnSecurity broke the news that the JabberZeus crew had just used money mules to steal $500,000 from tiny Duanesburg Central School District in upstate New York. As part of his sentence, Skvortsov was ordered to pay $497,200 in restitution to the Duanesburg Central School District.
The JabberZeus Crew operated mainly out of the eastern Ukraine city of Donetsk, which was always pro-Russia and is now occupied by Russian forces. But when Russia invaded Ukraine in February 2022, the alleged leader of the notorious cybercrime gang — Vyacheslav Igoravich Andreev (a.ka. Penchukov) — fled his mandatory military service orders and was arrested in Geneva, Switzerland. He is currently in federal custody awaiting trial, and is slated to be arraigned in U.S. federal court tomorrow (Jan. 9, 2024). A copy of the indictment against Andreev is here (PDF).
Andreev, aka “Tank,” seen here performing as a DJ in Ukraine in an undated photo from social media.
More than five years after domain name registrars started redacting personal data from all public domain registration records, the non-profit organization overseeing the domain industry has introduced a centralized online service designed to make it easier for researchers, law enforcement and others to request the information directly from registrars.
In May 2018, the Internet Corporation for Assigned Names and Numbers (ICANN) — the nonprofit entity that manages the global domain name system — instructed all registrars to redact the customer’s name, address, phone number and email from WHOIS, the system for querying databases that store the registered users of domain names and blocks of Internet address ranges.
ICANN made the policy change in response to the General Data Protection Regulation (GDPR), a law enacted by the European Parliament that requires companies to gain affirmative consent for any personal information they collect on people within the European Union. In the meantime, registrars were to continue collecting the data but not publish it, and ICANN promised it would develop a system that facilitates access to this information.
At the end of November 2023, ICANN launched the Registration Data Request Service (RDRS), which is designed as a one-stop shop to submit registration data requests to participating registrars. This video from ICANN walks through how the system works.
Accredited registrars don’t have to participate, but ICANN is asking all registrars to join and says participants can opt out or stop using it at any time. ICANN contends that the use of a standardized request form makes it easier for the correct information and supporting documents to be provided to evaluate a request.
ICANN says the RDRS doesn’t guarantee access to requested registration data, and that all communication and data disclosure between the registrars and requestors takes place outside of the system. The service can’t be used to request WHOIS data tied to country-code top level domains (CCTLDs), such as those ending in .de (Germany) or .nz (New Zealand), for example.
The RDRS portal.
As Catalin Cimpanu writes for Risky Business News, currently investigators can file legal requests or abuse reports with each individual registrar, but the idea behind the RDRS is to create a place where requests from “verified” parties can be honored faster and with a higher degree of trust.
The registrar community generally views public WHOIS data as a nuisance issue for their domain customers and an unwelcome cost-center. Privacy advocates maintain that cybercriminals don’t provide their real information in registration records anyway, and that requiring WHOIS data to be public simply causes domain registrants to be pestered by spammers, scammers and stalkers.
Meanwhile, security experts argue that even in cases where online abusers provide intentionally misleading or false information in WHOIS records, that information is still extremely useful in mapping the extent of their malware, phishing and scamming operations. What’s more, the overwhelming majority of phishing is performed with the help of compromised domains, and the primary method for cleaning up those compromises is using WHOIS data to contact the victim and/or their hosting provider.
Anyone looking for copious examples of both need only to search this Web site for the term “WHOIS,” which yields dozens of stories and investigations that simply would not have been possible without the data available in the global WHOIS records.
KrebsOnSecurity remains doubtful that participating registrars will be any more likely to share WHOIS data with researchers just because the request comes through ICANN. But I look forward to being wrong on this one, and will certainly mention it in my reporting if the RDRS proves useful.
Regardless of whether the RDRS succeeds or fails, there is another European law that takes effect in 2024 which is likely to place additional pressure on registrars to respond to legitimate WHOIS data requests. The new Network and Information Security Directive (NIS2), which EU member states have until October 2024 to implement, requires registrars to keep much more accurate WHOIS records, and to respond within as little as 24 hours to WHOIS data requests tied everything from phishing, malware and spam to copyright and brand enforcement.
Today, the latest issue of The Domain Name Industry Brief Quarterly Report was released by DNIB.com, showing the third quarter of 2023 closed with 359.3 million domain name registrations across all top-level domains (TLDs), an increase of 2.7 million domain name registrations, or 0.8%, compared to the second quarter of 2023. Domain name registrations also increased by 8.5 million, or 2.4%, year over year.
Check out the latest issue of The Domain Name Industry Brief Quarterly Report to see domain name stats from the third quarter of 2023, including:
DNIB.com and The Domain Name Industry Brief Quarterly Report are sponsored by Verisign. To see past issues of the quarterly report, interactive dashboards, and learn about DNIB.com’s statistical methodology, please visit DNIB.com.
The post Domain Name Industry Brief Quarterly Report: DNIB.com Announces 359.3 Million Domain Name Registrations in the Third Quarter of 2023 appeared first on Verisign Blog.
The top-level domain for the United States — .US — is home to thousands of newly-registered domains tied to a malicious link shortening service that facilitates malware and phishing scams, new research suggests. The findings come close on the heels of a report that identified .US domains as among the most prevalent in phishing attacks over the past year.
Researchers at Infoblox say they’ve been tracking what appears to be a three-year-old link shortening service that is catering to phishers and malware purveyors. Infoblox found the domains involved are typically three to seven characters long, and hosted on bulletproof hosting providers that charge a premium to ignore any abuse or legal complaints. The short domains don’t host any content themselves, but are used to obfuscate the real address of landing pages that try to phish users or install malware.
A graphic describing the operations of a malicious link shortening service that Infoblox has dubbed “Prolific Puma.”
Infoblox says it’s unclear how the phishing and malware landing pages tied to this service are being initially promoted, although they suspect it is mainly through scams targeting people on their phones via SMS. A new report says the company mapped the contours of this link shortening service thanks in part to pseudo-random patterns in the short domains, which all appear on the surface to be a meaningless jumble of letters and numbers.
“This came to our attention because we have systems that detect registrations that use domain name generation algorithms,” said Renee Burton, head of threat intelligence at Infoblox. “We have not found any legitimate content served through their shorteners.”
Infoblox determined that until May 2023, domains ending in .info accounted for the bulk of new registrations tied to the malicious link shortening service, which Infoblox has dubbed “Prolific Puma.” Since then, they found that whoever is responsible for running the service has used .US for approximately 55 percent of the total domains created, with several dozen new malicious .US domains registered daily.
.US is overseen by the National Telecommunications and Information Administration (NTIA), an executive branch agency of the U.S. Department of Commerce. But Uncle Sam has long outsourced the management of .US to various private companies, which have gradually allowed the United States’s top-level domain to devolve into a cesspool of phishing activity.
Or so concludes The Interisle Consulting Group, which gathers phishing data from multiple industry sources and publishes an annual report on the latest trends. As far back as 2018, Interisle found .US domains were the worst in the world for spam, botnet (attack infrastructure for DDOS etc.) and illicit or harmful content.
Interisle’s newest study examined six million phishing reports between May 1, 2022 and April 30, 2023, and identified approximately 30,000 .US phishing domains. Interisle found significant numbers of .US domains were registered to attack some of the United States’ most prominent companies, including Bank of America, Amazon, Apple, AT&T, Citi, Comcast, Microsoft, Meta, and Target. Others were used to impersonate or attack U.S. government agencies.
Under NTIA regulations, domain registrars processing .US domain registrations must take certain steps (PDF) to verify that those customers actually reside in the United States, or else own organizations based in the U.S. However, if one registers a .US domain through GoDaddy — the largest domain registrar and the current administrator of the .US contract — the way one “proves” their U.S. nexus is simply by choosing from one of three pre-selected affirmative responses.
In an age when most domain registrars are automatically redacting customer information from publicly accessible registration records to avoid running afoul of European privacy laws, .US has remained something of an outlier because its charter specifies that all registration records be made public. However, Infoblox said it found more than 2,000 malicious link shortener domains ending in .US registered since October 2023 through NameSilo that have somehow subverted the transparency requirements for the usTLD and converted to private registrations.
“Through our own experience with NameSilo, it is not possible to select private registration for domains in the usTLD through their interface,” Infoblox wrote. “And yet, it was done. Of the total domains with private records, over 99% were registered with NameSilo. At this time, we are not able to explain this behavior.”
NameSilo CEO Kristaps Ronka said the company actively responds to reports about abusive domains, but that it hasn’t seen any abuse reports related to Infoblox’s findings.
“We take down hundreds to thousands of domains, lots of them proactively to combat abuse,” Ronka said. “Our current abuse rate on abuseIQ for example is currently at 0%. AbuseIQ receives reports from countless sources and we are yet to see these ‘Puma’ abuse reports.”
Experts who track domains associated with malware and phishing say even phony information supplied at registration is useful in identifying potentially malicious or phishous domains before they can be used for abuse.
For example, when it was registered through NameSilo in July 2023, the domain 1ox[.]us — like thousands of others — listed its registrant as “Leila Puma” at a street address in Poland, and the email address blackpumaoct33@ukr.net. But according to DomainTools.com, on Oct. 1, 2023 those records were redacted and hidden by NameSilo.
Infoblox notes that the username portion of the email address appears to be a reference to the song October 33 by the Black Pumas, an Austin, Texas based psychedelic soul band. The Black Pumas aren’t exactly a household name, but they did recently have a popular Youtube video that featured a cover of the Kinks song “Strangers,” which included an emotional visual narrative about Ukrainians seeking refuge from the Russian invasion, titled “Ukraine Strangers.” Also, Leila Puma’s email address is at a Ukrainian email provider.
DomainTools shows that hundreds of other malicious domains tied to Prolific Puma previously were registered through NameCheap to a “Josef Bakhovsky” at a different street address in Poland. According to ancestry.com, the anglicized version of this surname — Bakovski — is the traditional name for someone from Bakowce, which is now known as Bakivtsi and is in Ukraine.
This possible Polish and/or Ukrainian connection may or may not tell us something about the “who” behind this link shortening service, but those details are useful for identifying and grouping these malicious short domains. However, even this meager visibility into .US registration data is now under threat.
The NTIA recently published a proposal that would allow registrars to redact all registrant data from WHOIS registration records for .US domains. A broad array of industry groups have filed comments opposing the proposed changes, saying they threaten to remove the last vestiges of accountability for a top-level domain that is already overrun with cybercrime activity.
Infoblox’s Burton says Prolific Puma is remarkable because they’ve been able to facilitate malicious activities for years while going largely unnoticed by the security industry.
“This exposes how persistent the criminal economy can be at a supply chain level,” Burton said. “We’re always looking at the end malware or phishing page, but what we’re finding here is that there’s this middle layer of DNS threat actors persisting for years without notice.”
Infoblox’s full report on Prolific Puma is here.
This article originally appeared Aug. 21, 2020 on the APNIC blog.
Chromium is an open-source software project that forms the foundation for Google’s Chrome web browser, as well as a number of other browser products, including Microsoft Edge, Opera, Amazon Silk, and Brave. Since Chrome’s introduction in 2008, Chromium-based browsers have steadily risen in popularity and today comprise approximately 70% of the market share.1
Chromium has, since its early days, included a feature known as the omnibox. This is where users may enter either a web site name, URL, or search terms. But the omnibox has an interface challenge. The user might enter a word like “marketing” that could refer to both an (intranet) web site and a search term. Which should the browser choose to display? Chromium treats it as a search term, but also displays an infobar that says something like “did you mean http://marketing/?” if a background DNS lookup for the name results in an IP address.
At this point, a new issue arises. Some networks (e.g., ISPs) utilize products or services designed to intercept and capture traffic from mistyped domain names. This is sometimes known as “NXDomain hijacking.” Users on such networks might be shown the “did you mean” infobar on every single-term search. To work around this, Chromium needs to know if it can trust the network to provide non-intercepted DNS responses.
Inside the Chromium source code there is a file named intranet_redirect_detector.c. The functions in this file attempt to load three URLs whose hostnames consist of a randomly generated single-label domain name, as shown in Figure 1 below.
This code results in three URL fetches, such as http://rociwefoie/, http://uawfkfrefre/, and http://awoimveroi/, and these in turn result in three DNS lookups for the random host names. As can be deduced from the source code, these random names are 7-15 characters in length (line 151) and consist of only the letters a-z (line 153). In versions of the code prior to February 2014, the random names were always 10 characters in length.
The intranet redirect detector functions are executed each time the browser starts up, each time the system/device’s IP address changes, and each time the system/device’s DNS configuration changes. If any two of these fetches resolve to the same address, that address is stored as the browser’s redirect origin.
Nearly any cursory glance at root name server traffic will exhibit queries for names that look like those used in Chromium’s probe queries. For example, here are 20 sequential queries received at an a.root-servers.net instance:
In this brief snippet of data, we can see six queries (yellow highlight) for random, single-label names, and another four (green highlight) with random first labels followed by an apparent domain search suffix. These match the pattern from the Chromium source code, being 7-15 characters in length and consisting of only the letters a-z.
To characterize the amount of Chromium probe traffic in larger amounts of data (i.e., covering a 24-hour period), we tabulate queries based on the following attributes:
Figure 2 shows a classification of data from a.root-servers.net on May 13, 2020. Here we can see that 51% of all queried names were observed fewer than four times in the 24-hour period. Of those, nearly all were for non-existent TLDs, although a very small amount come from the existing TLDs (labeled “YXD” on the left). This small sliver represents either false positives or Chromium probe queries that have been subject to domain suffix search appending by stub resolvers or end user applications.
Of the 51% observed fewer than four times, all but 2.86% of those have a first label between 7 and 15 characters in length (inclusive). Furthermore, most of those match the pattern consisting of only a-z characters (case insensitive), leaving us with 45.80% of total traffic on this day that appears to be from Chromium probes.
From there we break down the queries by number of labels and length of the first label. Note that label lengths, on the far right of the graph, have a very even distribution, except for 7 and 10 characters. Labels with 10 characters are more popular because older versions of Chromium generated only 10-character names. We believe that 7 is less popular due to the increased probability of collisions in only 7 characters, which can increase the query count to above our threshold of three.
Next, we turn our attention to an analysis of how the total root traffic percentage of Chromium-like queries has changed over time. We use two data sets in this analysis: data from DNS-OARC’s “Day In The Life” (DITL) collections, and Verisign’s data for a.root-servers.net and j.root-servers.net.
Figure 3 shows the results of the long-term analysis. We were able to analyze the annual DITL data from 2006-2014, and from 2017-2018, labeled “DITL Full” in the figure. The 2015-2016 data was unavailable on the DNS-OARC systems. The 2019 dataset could not be analyzed in full due to its size, so we settled for a sampled analysis instead, labeled “DITL Sampled” in Figure 3. The 2020 data was not ready for analysis by the time our research was done.
In every DITL dataset, we analyzed each root server identity (“letter”) separately. This produces a range of values for each year. The solid line shows the average of all the identities, while the shaded area shows the range of values.
To fill in some of the DITL gaps we used Verisign’s own data for a.root-servers.net and j.root-servers.net. Here we selected a 24-hour period for each month. Again, the solid line shows the average and the shaded area represents the range.
The figure also includes a line labeled “Chrome market share” (note: Chrome, not Chromium-based browsers) and a marker indicating when the feature was first added to the source code. Note, there are some false positive Chromium-like queries observed in the DITL data prior to introduction of the feature, comprising about 1% of the total traffic, but in the 10+ years since the feature was added, we now find that half of the DNS root server traffic is very likely due to Chromium’s probes. That equates to about 60 billion queries to the root server system on a typical day.
The root server system is, out of necessity, designed to handle very large amounts of traffic. As we have shown here, under normal operating conditions, half of the traffic originates with a single library function, on a single browser platform, whose sole purpose is to detect DNS interception. Such interception is certainly the exception rather than the norm. In almost any other scenario, this traffic would be indistinguishable from a distributed denial of service (DDoS) attack.
Could Chromium achieve its goal while only sending one or two queries instead of three? Are other approaches feasible? For example, Firefox’s captive portal test uses delegated namespace probe queries, directing them away from the root servers towards the browser’s own infrastructure. While technical solutions such as Aggressive NSEC Caching (RFC 8198), Qname Minimization (RFC 7816), and NXDomain Cut (RFC 8020) could also significantly reduce probe queries to the root server system, these solutions require action by recursive resolver operators, who have limited incentive to deploy and support these technologies.
This piece was co-authored by Matt Thomas, Distinguished Engineer in Verisign’s CSO Applied Research division.
1https://www.w3counter.com/trends
The post Chromium’s Impact on Root DNS Traffic appeared first on Verisign Blog.
Today, the latest issue of The Domain Name Industry Brief Quarterly Report was released by DNIB.com, showing the second quarter of 2023 closed with 356.6 million domain name registrations across all top-level domains (TLDs), an increase of 1.7 million domain name registrations, or 0.5%, compared to the first quarter of 2023. Domain name registrations also increased by 4.3 million, or 1.2%, year over year.
Check out the latest issue of The Domain Name Industry Brief Quarterly Report to see domain name stats from the second quarter of 2023, including:
With the launch of the DNIB.com dashboards, 16 additional TLDs have been included in applicable calculations. The applicable current and historical data presented in this edition of the quarterly report have been adjusted accordingly, and applicable quarterly and year-over-year trends have been calculated using those adjusted figures. More information is available at DNIB.com.
DNIB.com and the Domain Name Industry Brief Quarterly Report are sponsored by Verisign. To see past issues of the quarterly report, interactive dashboards, and learn about DNIB.com’s statistical methodology, please visit DNIB.com.
The post Domain Name Industry Brief Quarterly Report: DNIB.com announces 356.6 Million Domain Name Registrations in the Second Quarter of 2023 appeared first on Verisign Blog.
Verisign today announced the launch of DNIB.com, the new Domain Name Industry Brief (DNIB) website.
Sponsored by Verisign, DNIB.com is a source for insights and analysis from subject-matter experts on key topics relevant to the global Domain Name System (DNS). DNIB.com will offer insight on policy, governance, technology, security, and business trends relevant to analysts, entrepreneurs, policymakers, and anyone with an interest in the DNS. The website features a collection of new, searchable, and interactive dashboards tracking relevant DNS data and trends, that is designed to be a valuable day-to-day resource for industry stakeholders, and anyone interested in learning more about global domain name operations.
DNIB.com is also the new home of the DNIB quarterly report, which Verisign has published for more than a decade, providing a trusted and valued resource for stakeholders across the globe seeking to understand the dynamism and trends of the domain name industry.
The report will be published each quarter at DNIB.com, summarizing the state of the domain name industry through a variety of statistical and analytical research. The new and expanded DNIB.com dashboards take that statistical data to the next level, enabling exploration of trend data across the industry, providing additional history and depth, and offering expert insights and commentary.
The post Announcing the Launch of DNIB.com, a New Source for DNS News, Information, Research, and Analysis appeared first on Verisign Blog.
Today, we released the latest issue of The Domain Name Industry Brief, which shows that the first quarter of 2023 closed with 354.0 million domain name registrations across all top-level domains (TLDs), an increase of 3.5 million domain name registrations, or 1.0%, compared to the fourth quarter of 2022.1,2 Domain name registrations also increased by 3.5 million, or 1.0%, year over year.1,2
Check out the latest issue of The Domain Name Industry Brief to see domain name stats from the first quarter of 2023, including:
This issue of the Domain Name Industry Brief includes a correction to the March 2023 issue, which incorrectly reported the number of domain name registrations in the .eu ccTLD.2 This was the result of a one-time error in the .eu domain name registration data, provided by ZookNIC, which has since been resolved.
To see past issues of The Domain Name Industry Brief, please visit https://verisign.com/dnibarchives.
The post Verisign Domain Name Industry Brief: 354.0 Million Domain Name Registrations in the First Quarter of 2023 appeared first on Verisign Blog.
The number of phishing websites tied to domain name registrar Freenom dropped precipitously in the months surrounding a recent lawsuit from social networking giant Meta, which alleged the free domain name provider has a long history of ignoring abuse complaints about phishing websites while monetizing traffic to those abusive domains.
The volume of phishing websites registered through Freenom dropped considerably since the registrar was sued by Meta. Image: Interisle Consulting.
Freenom is the domain name registry service provider for five so-called “country code top level domains” (ccTLDs), including .cf for the Central African Republic; .ga for Gabon; .gq for Equatorial Guinea; .ml for Mali; and .tk for Tokelau.
Freenom has always waived the registration fees for domains in these country-code domains, but the registrar also reserves the right to take back free domains at any time, and to divert traffic to other sites — including adult websites. And there are countless reports from Freenom users who’ve seen free domains removed from their control and forwarded to other websites.
By the time Meta initially filed its lawsuit in December 2022, Freenom was the source of well more than half of all new phishing domains coming from country-code top-level domains. Meta initially asked a court to seal its case against Freenom, but that request was denied. Meta withdrew its December 2022 lawsuit and re-filed it in March 2023.
“The five ccTLDs to which Freenom provides its services are the TLDs of choice for cybercriminals because Freenom provides free domain name registration services and shields its customers’ identity, even after being presented with evidence that the domain names are being used for illegal purposes,” Meta’s complaint charged. “Even after receiving notices of infringement or phishing by its customers, Freenom continues to license new infringing domain names to those same customers.”
Meta pointed to research from Interisle Consulting Group, which discovered in 2021 and again last year that the five ccTLDs operated by Freenom made up half of the Top Ten TLDs most abused by phishers.
Interisle partner Dave Piscitello said something remarkable has happened in the months since the Meta lawsuit.
“We’ve observed a significant decline in phishing domains reported in the Freenom commercialized ccTLDs in months surrounding the lawsuit,” Piscitello wrote on Mastodon. “Responsible for over 60% of phishing domains reported in November 2022, Freenom’s percentage has dropped to under 15%.”
Interisle collects data from 12 major blocklists for spam, malware, and phishing, and it receives phishing-specific data from Spamhaus, Phishtank, OpenPhish and the APWG Ecrime Exchange. The company publishes historical data sets quarterly, both on malware and phishing.
Piscitello said it’s too soon to tell the full impact of the Freenom lawsuit, noting that Interisle’s sources of spam and phishing data all have different policies about when domains are removed from their block lists.
“One of the things we don’t have visibility into is how each of the blocklists determine to remove a URL from their lists,” he said. “Some of them time out [listed domains] after 14 days, some do it after 30, and some keep them forever.”
Freenom did not respond to requests for comment.
This is the second time in as many years that a lawsuit by Meta against a domain registrar has disrupted the phishing industry. In March 2020, Meta sued domain registrar giant Namecheap, alleging cybersquatting and trademark infringement.
The two parties settled the matter in April 2022. While the terms of that settlement have not been disclosed, new phishing domains registered through Namecheap declined more than 50 percent the following quarter, Interisle found.
Phishing attacks using websites registered through Namecheap, before and after the registrar settled a lawsuit with Meta. Image: Interisle Consulting.
Unfortunately, the lawsuits have had little effect on the overall number of phishing attacks and phishing-related domains, which have steadily increased in volume over the years. Piscitello said the phishers tend to gravitate toward registrars that offer the least resistance and lowest price per domain. And with new top-level domains constantly being introduced, there is rarely a shortage of super low-priced domains.
“The abuse of a new top-level domain is largely the result of one registrar’s portfolio,” Piscitello told KrebsOnSecurity. “Alibaba or Namecheap or another registrar will run a promotion for a cheap domain, and then we’ll see flocking and migration of the phishers to that TLD. It’s like strip mining, where they’ll buy hundreds or thousands of domains, use those in a campaign, exhaust that TLD and then move on to another provider.”
Piscitello said despite the steep drop in phishing domains coming out of Freenom, the alternatives available to phishers are many. After all, there are more than 2,000 accredited domain registrars, not to mention dozens of services that let anyone set up a website for free without even owning a domain.
“There is no evidence that the trend line is even going to level off,” he said. “I think what the Meta lawsuit tells us is that litigation is like giving someone a standing eight count. It temporarily disrupts a process. And in that sense, litigation appears to be working.”
The launch of .web top-level domain is once again at risk of being delayed by baseless procedural maneuvering.
On May 2, the Internet Corporation for Assigned Names and Numbers (ICANN) Board of Directors posted a decision on the .web matter from its April 30 meeting, which found “that NDC (Nu Dotco LLC) did not violate the Guidebook or the Auction Rules” and directed ICANN “to continue processing NDC’s .web application,” clearing the way for the delegation of .web. ICANN later posted a preliminary report from this meeting showing that the Board vote on the .web decision was without objection.
Less than 24 hours later, however, Altanovo (formerly Afilias) – a losing bidder whose repeatedly rejected claims already have delayed the delegation of .web for more than six years – dusted off its playbook from 2018 by filing yet another ICANN Cooperative Engagement Process (CEP), beginning the cycle of another independent review of the Board’s decision, which last time cost millions of dollars and resulted in years of delay.
Under ICANN rules, a CEP is intended to be a non-binding process designed to efficiently resolve or narrow disputes before the initiation of an Independent Review Process (IRP). ICANN places further actions on hold while a CEP is pending. It’s an important and worthwhile aspect of the multistakeholder process…when used in good faith.
But that does not appear to be what is happening here. Altanovo and its backers initiated this repeat CEP despite the fact that it lost a fair, ICANN-sponsored auction; lost, in every important respect, the IRP; lost its application for reconsideration of the IRP (which it was sanctioned for filing, and which was determined to be frivolous by the IRP panel); and has now lost before the ICANN Board.
The Board’s decision expressly found that these disputes “have delayed the delegation of .web for more than six years” and already cost each of the parties, including ICANN, “millions of dollars in legal fees.”
Further delay appears to be the only goal of this second CEP – and any follow-on IRP – because no one could conclude in good faith that an IRP panel would find that the thorough process and decision on .web established in the Board’s resolutions and preliminary report violated ICANN’s bylaws. At the end of the day, all that will be accomplished by this second CEP and a second IRP is continued delay, and delay for delay’s sake amounts to an abuse of process that threatens to undermine the multistakeholder processes and the rights of NDC and Verisign.
ICANN will, no doubt, follow its processes for resolving the CEP and any further procedural maneuvers attempted by Altanovo. But, given Altanovo’s track record of losses, delays, and frivolous maneuvering since the 2016 .web auction, a point has been reached when equity demands that this abuse of process not be allowed to thwart NDC’s right, as determined by the Board, to move ahead on its .web application.
The post Will Altanovo’s Maneuvering Continue to Delay .web? appeared first on Verisign Blog.
Over the past several years, domain name queries – a critical element of internet communication – have quietly become more secure, thanks, in large part, to a little-known set of technologies that are having a global impact. Verisign CTO Dr. Burt Kaliski covered these in a recent Internet Protocol Journal article, and I’m excited to share more about the role Verisign has performed in advancing this work and making one particular technology freely available worldwide.
The Domain Name System (DNS) has long followed a traditional approach of answering queries, where resolvers send a query with the same fully qualified domain name to each name server in a chain of referrals. Then, they generally apply the final answer they receive only to the domain name that was queried for in the original request.
But recently, DNS operators have begun to deploy various “minimization techniques” – techniques aimed at reducing both the quantity and sensitivity of information exchanged between DNS ecosystem components as a means of improving DNS security. Why the shift? As we discussed in a previous blog, it’s all in the interest of bringing the process closer to the “need-to-know” security principle, which emphasizes the importance of sharing only the minimum amount of information required to complete a task or carry out a function. This effort is part of a general, larger movement to reduce the disclosure of sensitive information in our digital world.
As part of Verisign’s commitment to security, stability, and resiliency of the global DNS, the company has worked both to develop qname minimization techniques and to encourage the adoption of DNS minimization techniques in general. We believe strongly in this work since these techniques can reduce the sensitivity of DNS data exchanged between resolvers and both root and TLD servers without adding operational risk to authoritative name server operations.
To help advance this area of technology, in 2015, Verisign announced a royalty-free license to its qname minimization patents in connection with certain Internet Engineering Task Force (IETF) standardization efforts. There’s been a steady increase in support and deployment since that time; as of this writing, roughly 67% of probes were utilizing qname-minimizing resolvers, according to statistics hosted by NLnet Labs. That’s up from just 0.7% in May 2017 – a strong indicator of minimization techniques’ usefulness to the community. At Verisign, we are seeing similar trends with approximately 65% of probes utilizing qname-minimizing resolvers in queries with two labels at .com and .net authoritative name servers, as shown in Figure 1 below.
Kaliski’s article, titled “Minimized DNS Resolution: Into the Penumbra,” explores several specific minimization techniques documented by the IETF, reports on their implementation status, and discusses the effects of their adoption on DNS measurement research. An expanded version of the article can be found on the Verisign website.
This piece is just one of the latest to demonstrate Verisign’s continued investment in research and standards development in the DNS ecosystem. As a company, we’re committed to helping shape the DNS of today and tomorrow, and we recognize this is only possible through ongoing contributions by dedicated members of the internet infrastructure community – including the team here at Verisign.
Read more about Verisign’s contributions to this area:
Minimum Disclosure: What Information Does a Name Server Need to Do Its Job? (blog)
Maximizing Qname Minimization: A New Chapter in DNS Protocol Evolution (blog)
Information Protection for the Domain Name System: Encryption and Minimization (blog)
The post Minimized DNS Resolution: Into the Penumbra appeared first on Verisign Blog.
Today, we released the latest issue of The Domain Name Industry Brief, which shows that the fourth quarter of 2022 closed with 350.4 million domain name registrations across all top-level domains (TLDs), an increase of 0.5 million domain name registrations, or 0.1%, compared to the third quarter of 2022.1,2 Domain name registrations have increased by 8.7 million, or 2.6%, year over year.1,2
Check out the latest issue of The Domain Name Industry Brief to see domain name stats from the fourth quarter of 2022, including:
• Top 10 Largest TLDs by Number of Reported Domain Names
• Top 10 Largest ccTLDs by Number of Reported Domain Names
• ngTLDs as Percentage of Total TLDs
• Geographical ngTLDs as Percentage of Total Corresponding Geographical TLDs
To see past issues of The Domain Name Industry Brief, please visit https://verisign.com/dnibarchives.
The post Verisign Domain Name Industry Brief: 350.4 Million Domain Name Registrations in the Fourth Quarter of 2022 appeared first on Verisign Blog.
Imagine this: Your CEO sends you an email asking for your help transferring $5,000 to a new vendor for an urgent project. You make the transfer, only to find out later that the email was actually from an imposter, and that money is now in the hands of cybercriminals. Oops, right? crickets
Business Email Compromise (BEC) is a type of cybercrime that involves compromising or imitating legitimate business email accounts to carry out fraudulent transactions or steal sensitive information. The goal of a BEC attack is typically to trick the victim into transferring money, clicking on a malicious link, or disclosing sensitive information such as login credentials. BEC attacks can have a devastating impact on organizations of all sizes and in all industries, making it essential for businesses to be aware of the threat, understand the business risk, and take the necessary steps to protect themselves.
According to the latest FBI IC3 report, BEC is “one of the most financially damaging online crimes” and in 2021 was accountable for $2.4 Billion in adjusted losses for businesses and consumers.
One of the most common types of BEC attacks is called impersonating or email spoofing. By pretending to be a trusted colleague or business partner to gain the victim’s trust, the attacker uses social engineering techniques to trick the victim into clicking on a link or attachment in an email that contains malware, takes the victim to a malicious website, and has them transfer funds or change payment information.
BEC attacks can be very sophisticated and are difficult to detect. Many times, what the end-user sees on their email client does not represent the true email address of that sender, or it shows one that has been spoofed.
Typically, the attacker tries to impersonate someone in the organization with enough authority to not be questioned about what he/she is asking to be done.
As with everything in security, to be able to succeed in stopping BEC attacks, additional security layers & techniques should be implemented. There are several options to mitigate or reduce the number of successful BEC attacks. Creating a list of the people who will be likely to be impersonated will provide the best results. Usually, with names from the CxO level, this is known as a High Impact Personnel list. It will be used along with other security analysis engines to make sure any impersonated/spoof emails, along with other threats, get stopped and will not reach the end user.
The Cisco Secure Email Threat Defense solution leverages hundreds of detection engines that utilize state-of-the-art artificial intelligence/machine learning and natural language processing to convict messages from the most creative attackers! On top of this, our customers can define their High Impact Personnel list, and together with the other detection engines, will be able to not only block malicious messages but also understand the reasons and categories of why a message is being convicted as malicious.
In summary, Business Email Compromise (BEC) is a serious threat to organizations of all sizes and in all industries. To protect against BEC attacks, businesses should implement multiple techniques including identifying their High Impact Personnel for their organization, educating employees about the threat, and relying on reporting to understand who is being targeted most frequently so their security policies can be adjusted.
See how Secure Email Threat Defense identifies specific business risk factors to protect your organization.
We’d love to hear what you think. Ask a Question, Comment Below, and Stay Connected with Cisco Secure on social!
Cisco Secure Social Channels
Today, we released the latest issue of The Domain Name Industry Brief, which shows that the third quarter of 2022 closed with 349.9 million domain name registrations across all top-level domains, a decrease of 1.6 million domain name registrations, or 0.4%, compared to the second quarter of 2022.1,2 Domain name registrations have increased by 11.5 million, or 3.4%, year over year.1,2
Check out the latest issue of The Domain Name Industry Brief to see domain name stats from the third quarter of 2022, including:
• Top 10 Largest TLDs by Number of Reported Domain Names
• Top 10 Largest ccTLDs by Number of Reported Domain Names
• ngTLDs as Percentage of Total TLDs
• Geographical ngTLDs as Percentage of Total Corresponding Geographical TLDs
To see past issues of The Domain Name Industry Brief, please visit verisign.com/dnibarchives.
The post Verisign Domain Name Industry Brief: 349.9 Million Domain Name Registrations in the Third Quarter of 2022 appeared first on Verisign Blog.
In 1987, CompuServe introduced GIF images, Steve Wozniak left Apple and IBM introduced the PS/2 personal computer with improved graphics and a 3.5-inch diskette drive. Behind the scenes, one more critical piece of internet infrastructure was quietly taking form to help establish the internet we know today.
November of 1987 saw the establishment of the Domain Name System protocol suite as internet standards. This was a development that not only would begin to open the internet to individuals and businesses globally, but also would arguably redefine communications, commerce and access to information for future generations.
Today, the DNS continues to be critical to the operation of the internet as a whole. It has a long and strong track record thanks to the work of the internet’s pioneers and the collaboration of different groups to create volunteer standards.
Let’s take a look back at the journey of the DNS over the years.
Prior to 1987, the internet was primarily used by government agencies and members of academia. Back then, the Network Information Center, managed by SRI International, manually maintained a directory of hosts and networks. While the early internet was transformative and forward-thinking, not everyone had access to it.
During that same time period, the U.S. Advanced Research Projects Agency Network, the forerunner to the internet we know now, was evolving into a growing network environment, and new naming and addressing schemes were being proposed. Seeing that there were thousands of interested institutions and companies wanting to explore the possibilities of networked computing, a group of ARPA networking researchers realized that a more modern, automated approach was needed to organize the network’s naming system for anticipated rapid growth.
Two Request for Comments documents, numbered RFC 1034 and RFC 1035, were published in 1987 by the informal Network Working Group, which soon after evolved into the Internet Engineering Task Force. Those RFCs, authored by computer scientist Paul V. Mockapetris, became the standards upon which DNS implementations have been built. It was Mockapetris, inducted into the Internet Hall of Fame in 2012, who specifically suggested a name space where database administration was distributed but could also evolve as needed.
In addition to allowing organizations to maintain their own databases, the DNS simplified the process of connecting a name that users could remember with a unique set of numbers – the Internet Protocol address – that web browsers needed to navigate to a website using a domain name. By not having to remember a seemingly random string of numbers, users could easily get to their intended destination, and more people could access the web. This has worked in a logical way for all internet users – from businesses large and small to everyday people – all around the globe.
With these two aspects of the DNS working together – wide distribution and name-to-address mapping – the DNS quickly took shape and developed into the system we know today.
Thirty-five years of DNS development and progress is attributable to the collaboration of multiple stakeholders and interest groups – academia, technical community, governments, law enforcement and civil society, plus commercial and intellectual property interests – who continue even today to bring crucial perspectives to the table as it relates to the evolution of the DNS and the internet. These perspectives have lent themselves to critical security developments in the DNS, from assuring protection of intellectual property rights to the more recent stakeholder collaborative efforts to address DNS abuse.
Other major collaborative achievements involve the IETF, which has no formal membership roster or requirements, and is responsible for the technical standards that comprise the internet protocol suite, and the Internet Corporation for Assigned Names and Numbers, which plays a central coordination role in the bottom-up multistakeholder system governing the global DNS. Without constructive and productive voluntary collaboration, the internet as we know it simply isn’t possible.
Indeed, these cooperative efforts marshaled a brand of collaboration known today as “rough consensus.” That term, originally “rough consensus and running code,” gave rise to a more dynamic collaboration process than the “100% consensus from everyone” model. In fact, the term was adopted by the IETF in the early days of establishing the DNS to describe the formation of the dominant view of the working group and the need to quickly implement new technologies, which doesn’t always allow for lengthy discussions and debates. This approach is still in use today, proving its usefulness and longevity.
As we look back on how the DNS came to be and the processes that have kept it reliably running, it’s important to recognize the work done by the organizations and individuals that make up this community. We must also remember that the efforts continue to be powered by voluntary collaborations.
Commemorating anniversaries such as 35 years of the DNS protocol allows the multiple stakeholders and communities to pause and reflect on the enormity of the work and responsibility before us. Thanks to the pioneering minds who conceived and built the early infrastructure of the internet, and in particular to Paul Mockapetris’s fundamental contribution of the DNS protocol suite, the world has been able to establish a robust global economy that few could ever have imagined so many years ago.
The 35th anniversary of the publication of RFCs 1034 and 1035 reminds us of the contributions that the DNS has made to the growth and scale of what we know today as “the internet.” That’s a moment worth celebrating.
The post Celebrating 35 Years of the DNS Protocol appeared first on Verisign Blog.
Today, we released the latest issue of The Domain Name Industry Brief, which shows that the second quarter of 2022 closed with 351.5 million domain name registrations across all top-level domains, an increase of 1.0 million domain name registrations, or 0.3%, compared to the first quarter of 2022.1,2 Domain name registrations have increased by 10.4 million, or 3.0%, year over year.1,2
Check out the latest issue of The Domain Name Industry Brief to see domain name stats from the second quarter of 2022, including:
• Top 10 Largest TLDs by Number of Reported Domain Names
• Top 10 Largest ccTLDs by Number of Reported Domain Names
• ngTLDs as Percentage of Total TLDs
• Geographical ngTLDs as Percentage of Total Corresponding Geographical TLDs
To see past issues of The Domain Name Industry Brief, please visit verisign.com/dnibarchives.
The post Verisign Q2 2022 Domain Name Industry Brief: 351.5 Million Domain Name Registrations in the Second Quarter of 2022 appeared first on Verisign Blog.
Today, we released the latest issue of The Domain Name Industry Brief, which shows that the first quarter of 2022 closed with 350.5 million domain name registrations across all top-level domains, an increase of 8.8 million domain name registrations, or 2.6%, compared to the fourth quarter of 2021.1,2 Domain name registrations have increased by 13.2 million, or 3.9%, year over year.1,2
Check out the latest issue of The Domain Name Industry Brief to see domain name stats from the first quarter of 2022, including:
• Top 10 Largest TLDs by Number of Reported Domain Names
• Top 10 Largest ccTLDs by Number of Reported Domain Names
• ngTLDs as Percentage of Total TLDs
• Geographical ngTLDs as Percentage of Total Corresponding Geographical TLDs
To see past issues of The Domain Name Industry Brief, please visit verisign.com/dnibarchives.
The post Verisign Q1 2022 Domain Name Industry Brief: 350.5 Million Domain Name Registrations in the First Quarter of 2022 appeared first on Verisign Blog.
Today, we released the latest issue of The Domain Name Industry Brief, which shows that the fourth quarter of 2021 closed with 341.7 million domain name registrations across all top-level domains, an increase of 3.3 million domain name registrations, or 1.0%, compared to the third quarter of 2021.1,2 Domain name registrations have increased by 1.6 million, or 0.5%, year over year.1,2
Check out the latest issue of The Domain Name Industry Brief to see domain name stats from the fourth quarter of 2021, including:
• Top 10 Largest TLDs by Number of Reported Domain Names
• Top 10 Largest ccTLDs by Number of Reported Domain Names
• ngTLDs as Percentage of Total TLDs
• Geographical ngTLDs as Percentage of Total Corresponding Geographical TLDs
To see past issues of The Domain Name Industry Brief, please visit verisign.com/dnibarchives.
The post Verisign Q4 2021 The Domain Name Industry Brief: 341.7 Million Domain Name Registrations in the Fourth Quarter of 2021 appeared first on Verisign Blog.
The .web Independent Review Process (IRP) Panel issued a Final Decision six months ago, in May 2021. Immediately thereafter, the claimant, Afilias Domains No. 3 Limited (now a shell entity known as AltaNovo Domains Limited), filed an application seeking reconsideration of the Final Decision under Rule 33 of the arbitration rules. Rule 33 allows for the clarification of an ambiguous ruling and allows the Panel the opportunity to supplement its decision if it inadvertently failed to consider a claim or defense, but specifically does not permit wholesale reconsideration of a final decision. The problem for Afilias’ application, as we said at the time, was that it sought exactly that.
The Panel ruled on Afilias’ application on Dec. 21, 2021. In this latest ruling, the Panel not only rejected Afilias’ application in its entirety, but went further and sanctioned Afilias for having filed it in the first place. Quoting from the ruling:
In the opinion of the Panel, under the guise of seeking an additional decision, the Application is seeking reconsideration of core elements of the Final Decision. Likewise, under the guise of seeking interpretation, the Application is requesting additional declarations and advisory opinions on a number of questions, some of which had not been discussed in the proceedings leading to the Final Decision.
In such circumstances, the Panel cannot escape the conclusion that the Application is “frivolous” in the sense of it “having no sound basis (as in fact or law).” This finding suffices to entitle [ICANN] to the cost shifting decision it is seeking…the Panel hereby unanimously…Grants [ICANN’s] request that the Panel shift liability for the legal fees incurred by [ICANN] in connection with the Application, fixes at US $236,884.39 the amount of the legal fees to be reimbursed to [ICANN] by [Afilias]…and orders [Afilias] to pay this amount to [ICANN] within thirty (30) days….
In light of the Panel’s finding that Afililas’ Rule 33 application was so improper and frivolous as to be sanctionable, a serious question arises about the motives in filing it. Reading the history of the .web proceedings, one possible motivation is becoming more clear. The community will recall that, five years ago, Donuts (through its wholly-owned subsidiary Ruby Glen) failed in its bid to enjoin the .web auction when a federal court rejected false allegations that Nu Dot Co (NDC) had failed to disclose an ownership change. After the auction was conducted, Afilias then picked up the litigation baton from Donuts. Afilias’ IRP complaint demanded that the arbitration Panel nullify the auction results, and award .web to itself, thereby bypassing ICANN completely. In the May 2021 Final Decision the IRP Panel gave an unsurprising but firm “no” to Afilias’ request to supplant ICANN’s role, and instead directed ICANN’s Board to review the complaints about the conduct of the .web contention set members and then make a determination on delegation.
A result of this five-year battle has been to prevent ICANN from passing judgment on the .web situation. These proceedings have unsuccessfully sought to have courts and arbitrators stand in the shoes of ICANN, rather than letting ICANN discharge its mandated duty to determine what, if anything, should be done in response to the allegations regarding the pre-auction conduct of the contention set. This conduct includes Afilias’ own wrongdoing in violating the pre-auction communications blackout imposed in the Auction Rules. That misconduct is set forth in a July 23, 2021 letter by NDC to ICANN, since published by ICANN, containing written proof of Afilias’ violation of the auction rules. In its Dec. 21 ruling, the Panel made it unmistakably clear that it is ICANN – not a judge or a panel of arbitrators – who must first review all allegations of misconduct by the contention set, including the powerful evidence indicating that it is Afilias’ .web application, not NDC’s, that should be disqualified.
If Afilias’ motivation has been to avoid ICANN’s scrutiny of its own pre-auction misconduct, especially after exiting the registry business when it appears that its only significant asset is the .web application itself, then what we should expect to see next is for Afilias/AltaNovo to manufacture another delaying attack on the Final Decision. Perhaps this is why its litigation counsel has already written ICANN threatening to continue litigation “in all available fora whether within or outside of the United States of America.…”
It is long past time to put an end to this five-year campaign, which has interfered with ICANN’s duty to decide on the delegation of .web, harming the interests of the broader internet community. The new ruling obliges ICANN to take a decisive step in that direction.
The post IRP Panel Sanctions Afilias, Clears the Way for ICANN to Decide .web Disputes appeared first on Verisign Blog.
Today, we released the latest issue of The Domain Name Industry Brief, which shows that the third quarter of 2021 closed with 364.6 million domain name registrations across all top-level domains, a decrease of 2.7 million domain name registrations, or 0.7%, compared to the second quarter of 2021.1,2 Domain name registrations have decreased by 6.1 million, or 1.6%, year over year.1,2
Check out the latest issue of The Domain Name Industry Brief to see domain name stats from the third quarter of 2021, including:
The Domain Name Industry Brief this quarter also includes an overview of the ongoing community work to mitigate DNS security threats.
To see past issues of The Domain Name Industry Brief, please visit verisign.com/dnibarchives.
The post Verisign Q3 2021 The Domain Name Industry Brief: 364.6 Million Domain Name Registrations in the Third Quarter of 2021 appeared first on Verisign Blog.
For over a decade, the Internet Corporation for Assigned Names and Numbers (ICANN) and its multi-stakeholder community have engaged in an extended dialogue on the topic of DNS abuse, and the need to define, measure and mitigate DNS-related security threats. With increasing global reliance on the internet and DNS for communication, connectivity and commerce, the members of this community have important parts to play in identifying, reporting and mitigating illegal or harmful behavior, within their respective roles and capabilities.
As we consider the path forward on necessary and appropriate steps to improve mitigation of DNS abuse, it’s helpful to reflect briefly on the origins of this issue within ICANN, and to recognize the various and relevant community inputs to our ongoing work.
As a starting point, it’s important to understand ICANN’s central role in preserving the security, stability, resiliency and global interoperability of the internet’s unique identifier system, and also the limitations established within ICANN’s bylaws. ICANN’s primary mission is to ensure the stable and secure operation of the internet’s unique identifier systems, but as expressly stated in its bylaws, ICANN “shall not regulate (i.e., impose rules and restrictions on) services that use the internet’s unique identifiers or the content that such services carry or provide, outside the express scope of Section 1.1(a).” As such, ICANN’s role is important, but limited, when considering the full range of possible definitions of “DNS Abuse,” and developing a comprehensive understanding of security threat categories and the roles and responsibilities of various players in the internet infrastructure ecosystem is required.
In support of this important work, ICANN’s generic top-level domain (gTLD) contracted parties (registries and registrars) continue to engage with ICANN, and with other stakeholders and community interest groups, to address key factors related to effective and appropriate DNS security threat mitigation, including:
To better understand the various roles, responsibilities and processes, it’s important to first define illegal and abusive online activity. While perspectives may vary across our wide range of interest groups, the emerging consensus on definitions and terminology is that these activities can be categorized as DNS Security Threats, Infrastructure Abuse, Illegal Content, or Abusive Content, with ICANN’s remit generally limited to the first two categories.
Behavior within each of these categories constitutes abuse, and it is incumbent on members of the community to actively work to combat and mitigate these behaviors where they have the capability, expertise and responsibility to do so. We recognize the benefit of coordination with other entities, including ICANN within its bylaw-mandated remit, across their respective areas of responsibility.
The ICANN Organization has been actively involved in advancing work on DNS abuse, including the 2017 initiation of the Domain Abuse Activity Reporting (DAAR) system by the Office of the Chief Technology Officer. DAAR is a system for studying and reporting on domain name registration and security threats across top-level domain (TLD) registries, with an overarching purpose to develop a robust, reliable, and reproducible methodology for analyzing security threat activity, which the ICANN community may use to make informed policy decisions. The first DAAR reports were issued in January 2018 and they are updated monthly. Also in 2017, ICANN published its “Framework for Registry Operators to Address Security Threats,” which provides helpful guidance to registries seeking to improve their own DNS security posture.
The ICANN Organization also plays an important role in enforcing gTLD contract compliance and implementing policies developed by the community via its bottom-up, multi-stakeholder processes. For example, over the last several years, it has conducted registry and registrar audits of the anti-abuse provisions in the relevant agreements.
The ICANN Organization has also been a catalyst for increased community attention and action on DNS abuse, including initiating the DNS Security Facilitation Initiative Technical Study Group, which was formed to investigate mechanisms to strengthen collaboration and communication on security and stability issues related to the DNS. Over the last two years, there have also been multiple ICANN cross-community meeting sessions dedicated to the topic, including the most recent session hosted by the ICANN Board during its Annual General Meeting in October 2021. Also, in 2021, ICANN formalized its work on DNS abuse into a dedicated program within the ICANN Organization. These enforcement and compliance responsibilities are very important to ensure that all of ICANN’s contracted parties are living up to their obligations, and that any so-called “bad actors” are identified and remediated or de-accredited and removed from serving the gTLD registry or registrar markets.
The ICANN Organization continues to develop new initiatives to help mitigate DNS security threats, including: (1) expanding DAAR to integrate some country code TLDs, and to eventually include registrar-level reporting; (2) work on COVID domain names; (3) contributions to the development of a Domain Generating Algorithms Framework and facilitating waivers to allow registries and registrars to act on imminent security threats, including botnets at scale; and (4) plans for the ICANN Board to establish a DNS abuse caucus.
As early as 2009, the ICANN community began to identify the need for additional safeguards to help address DNS abuse and security threats, and those community inputs increased over time and have reached a crescendo over the last two years. In the early stages of this community dialogue, the ICANN Governmental Advisory Committee, via its Public Safety Working Group, identified the need for additional mechanisms to address “criminal activity in the registration of domain names.” In the context of renegotiation of the Registrar Accreditation Agreement between ICANN and accredited registrars, and the development of the New gTLD Base Registry Agreement, the GAC played an important and influential role in highlighting this need, providing formal advice to the ICANN Board, which resulted in new requirements for gTLD registry and registrar operators, and new contractual compliance requirements for ICANN.
Following the launch of the 2012 round of new gTLDs, and the finalization of the 2013 amendments to the RAA, several ICANN bylaw-mandated review teams engaged further on the issue of DNS Abuse. These included the Competition, Consumer Trust and Consumer Choice Review Team (CCT-RT), and the second Security, Stability and Resiliency Review Team (SSR2-RT). Both final reports identified and reinforced the need for additional tools to help measure and combat DNS abuse. Also, during this timeframe, the GAC, along with the At-Large Advisory Committee and the Security and Stability Advisory Committee, issued their own respective communiques and formal advice to the ICANN Board reiterating or reinforcing past statements, and providing support for recommendations in the various Review Team reports. Most recently, the SSAC issued SAC 115 titled “SSAC Report on an Interoperable Approach to Addressing Abuse Handling in the DNS.” These ICANN community group inputs have been instrumental in bringing additional focus and/or clarity to the topic of DNS abuse, and have encouraged ICANN and its gTLD registries and registrars to look for improved mechanisms to address the types of abuse within our respective remits.
During 2020 and 2021, ICANN’s gTLD contracted parties have been constructively engaged with other parts of the ICANN community, and with ICANN Org, to advance improved understanding on the topic of DNS security threats, and to identify new and improved mechanisms to enhance the security, stability and resiliency of the domain name registration and resolution systems. Collectively, the registries and registrars have engaged with nearly all groups represented in the ICANN community, and we have produced important documents related to DNS abuse definitions, registry actions, registrar abuse reporting, domain generating algorithms, and trusted notifiers. These all represent significant steps forward in framing the context of the roles, responsibilities and capabilities of ICANN’s gTLD contracted parties, and, consistent with our Letter of Intent commitments, Verisign has been an important contributor, along with our partners, in these Contracted Party House initiatives.
In addition, the gTLD contracted parties and ICANN Organization continue to engage constructively on a number of fronts, including upcoming work on standardized registry reporting, which will help result in better data on abuse mitigation practices that will help to inform community work, future reviews, and provide better visibility into the DNS security landscape.
It is important to note that groups outside of ICANN’s immediate multi-stakeholder community have contributed significantly to the topic of DNS abuse mitigation:
Internet & Jurisdiction Policy Network
The Internet & Jurisdiction Policy Network is a multi-stakeholder organization addressing the tension between the cross-border internet and national jurisdictions. Its secretariat facilitates a global policy process engaging over 400 key entities from governments, the world’s largest internet companies, technical operators, civil society groups, academia and international organizations from over 70 countries. The I&JP has been instrumental in developing multi-stakeholder inputs on issues such as trusted notifier, and Verisign has been a long-time contributor to that work since the I&JP’s founding in 2012.
DNS Abuse Institute
The DNS Abuse Institute was formed in 2021 to develop “outcomes-based initiatives that will create recommended practices, foster collaboration and develop industry-shared solutions to combat the five areas of DNS Abuse: malware, botnets, phishing, pharming, and related spam.” The Institute was created by Public Interest Registry, the registry operator for the .org TLD.
Global Cyber Alliance
The Global Cyber Alliance is a nonprofit organization dedicated to making the internet a safer place by reducing cyber risk. The GCA builds programs, tools and partnerships to sustain a trustworthy internet to enable social and economic progress for all.
ECO “topDNS” DNS Abuse Initiative
Eco is the largest association of the internet industry in Europe. Eco is a long-standing advocate of an “Internet with Responsibility” and of self-regulatory approaches, such as the DNS Abuse Framework. The eco “topDNS” initiative will help bring together stakeholders with an interest in combating and mitigating DNS security threats, and Verisign is a supporter of this new effort.
Other Community Groups
Verisign contributes to the anti-abuse, technical and policy communities: We continuously engage with ICANN and an array of other industry partners to help ensure the continued safe and secure operation of the DNS. For example, Verisign is actively engaged in anti-abuse, technical and policy communities such as the Anti-Phishing and Messaging, Malware and Mobile Anti-Abuse Working Groups, FIRST and the Internet Engineering Task Force.
As a leader in the domain name industry and DNS ecosystem, Verisign supports and has contributed to the cross-community efforts enumerated above. In addition, Verisign also engages directly by:
An important concept and approach for mitigating illegal and abusive activity online is the ability to engage with and rely upon third-party “trusted notifiers” to identify and report such incidents at the appropriate level in the DNS ecosystem. Verisign has supported and been engaged in the good work of the Internet & Jurisdiction Policy Network since its inception, and we’re encouraged by its recent progress on trusted notifier framing. As mentioned earlier, there are some key questions to be addressed as we consider the viability of engaging trusted notifiers or building trusting notifier entities, to help mitigate illegal and abusive online activity.
Verisign’s recent experience with the U.S. government (NTIA and FDA) in combating illegal online opioid sales has been very helpful in illuminating a possible approach for third-party trusted notifier engagement. As noted, we have also benefited from direct engagement with the Internet Watch Foundation and law enforcement in combating CSAM. These recent examples of third-party engagement have underscored the value of a well-formed and executed notification regime, supported by clear expectations, due diligence and due process.
Discussions around trusted notifiers and an appropriate framework for engagement are under way, and Verisign recently engaged with other registries and registrars to lead the development of such a framework for further discussion within the ICANN community. We have significant expertise and experience as an infrastructure provider within our areas of technical, legal and contractual responsibility, and we are aggressive in protecting our operations from bad actors. But in matters related to illegal or abusive content, we need and value contributions from third parties to appropriately identify such behavior when supported by necessary evidence and due diligence. Precisely how such third-party notifications can be formalized and supported at scale is an open question, but one that requires further exploration and work. Verisign is committed to continuing to contribute to these ongoing discussions as we work to mitigate illegal and abusive threats to the security, stability and resiliency of the internet.
Over the last several years, DNS abuse and DNS-related security threat mitigation has been a very important topic of discussion in and around the ICANN community. In cooperation with ICANN, contracted parties, and other groups within the ICANN community, the DNS ecosystem including Verisign has been constructively engaged in developing a common understanding and practical work to advance these efforts, with a goal of meaningfully reducing the level and impact of malicious activity in the DNS. In addition to its contractual compliance functions, ICANN’s contributions have been important in helping to advance this important work and it continues to have a critical coordination and facilitation function that brings the ICANN community together on this important topic. The ICANN community’s recent focus on DNS abuse has been helpful, significant progress has been made, and more work is needed to ensure continued progress in mitigating DNS security threats. As we look ahead to 2022, we are committed to collaborating constructively with ICANN and the ICANN community to deliver on these important goals.
The post Ongoing Community Work to Mitigate Domain Name System Security Threats appeared first on Verisign Blog.
Can thieves steal identities with only a name and address?
In short, the answer is “no.” Which is a good thing, as your name and address are in fact part of the public record. Anyone can get a hold of them. However, because they are public information, they are still tools that identity thieves can use.
If you think of your identity as a jigsaw puzzle, your name and address are the first two pieces that they can use to build a bigger picture and ultimately put your identity at risk.
With that, let’s look at some other key pieces of your identity that are associated with your name and address—and what you can do to protect them.
For starters, this information is so general that it is of little value in of itself to an identity thief. Yet a determined identity thief can do a bit of legwork and take a few extra steps to use them as a springboard for other scams.
For example, with your name and address a thief could:
There are volumes of public information that are readily available should someone want to add some more pieces to your identity jigsaw puzzle, such as:
In the U.S., the availability of such information will vary from state-to-state and different levels of government may have different regulations about what information gets filed—in addition to whether and how those reports are made public. Globally, different nations and regions will collect varying amounts of public information and have their own regulations in place as well. More broadly, though, many of these public databases are now online. Consequently, accessing them is easier than the days when getting a hold of that information required an in-person visit a library or public office.
Thieves can gain additional information about you from other online sources, such as data brokers. And data brokerage is a big business, a global economy estimated at $200 billion U.S. dollars a year. What fuels it? Personal information, representing thousands of data points on billions of people scraped from public records, social media, smartphone apps, shopper loyalty cards, third-party sources, and sometimes other data broker sites as well.
The above-the-board legal intent of data broker sites is to sell that information to advertisers so that they can create highly targeted campaigns based on people’s behaviors, travels, interests, and even political leanings. Others such as law enforcement officials, journalists, and others who are conducting background checks will use them too.
On the dark side, hackers, scammers, and thieves will buy this information as well, which they can use to commit identity theft and fraud. The thing is, data brokers will sell to anyone. They don’t discriminate.
Phishing attacks aren’t just for email, texts, and direct messages. In fact, thieves are turning to old tricks via old-fashioned physical mail. That includes sending phony offers or by impersonating officials of government institutions, all designed to trick you into giving up your personally identifiable information (PII).
What might that look like in your mailbox? They can take the form of bogus lottery prizes that request bank information for routing (non-existent) winnings. Another favorite of scammers are bogus tax notifications that demand immediate payment. In all, many can look quite convincing at first blush, yet there are ready ways you can spot them. In fact, many of the tips for avoiding these physical mail phishing attacks are the same for avoiding phishing attacks online, which we outline in detail here.
Recently, I’ve seen a few news stories like this where thieves reportedly abuse the change-of-address system with the U.S. Postal Service. Thieves will simply forward your mail to an address of their choosing, which can drop sensitive information like bank and credit card statements in their mailbox. From there, they could potentially have new checks sent to them or perhaps an additional credit card—both of which they can use to drain your accounts and run up your bills.
The Postal Service has mechanisms in place to prevent this, however. Among which, the Postal Service will send you a physical piece of mail to confirm the forwarding. So, if you ever receive mail from the Postal Service, open it and give it a close look. If you get such a notice and didn’t order the forwarding, visit your local post office to get things straightened out. Likewise, if it seems like you’re missing bills in the mail, that’s another good reason to follow up with your post office and the business in question to see if there have been any changes made in your mail forwarding.
So while your name and address are out there for practically all to see, they’re largely of little value to an identity thief on their own. But as mentioned above, they are key puzzle pieces to your overall identity. With enough of those other pieces in hand, that’s where an identity thief can cause trouble.
Other crucial pieces of your identity include:
Let’s start with the biggest one. This is the master key to your identity, as it is one of the most unique identifiers you have. As I covered in my earlier blog on Social Security fraud, a thief can unlock everything from credit history and credit line to tax refunds and medical care with your Social Security or tax ID number. In extreme cases, they can use it to impersonate you for employment, healthcare, and even in the event of an arrest.
You can protect your Social Security Number by keeping it locked in a safe place (rather than in your wallet) and by providing your number only when absolutely necessary. For more tips on keeping your number safe, drop by that blog on Social Security fraud I mentioned.
Thieves have figured out ways of getting around the fact that IDs like these include a photo. They may be able to modify or emulate these documents “well enough” to pull off certain types of fraud, particularly if the people requesting their bogus documents don’t review them with a critical eye.
Protecting yourself in this case means knowing where these documents are at any time. (With passports, you may want to store those securely like your Social Security or tax ID number.) Also be careful when you share this information, as the identifiers on these documents are highly unique. If you’re uncomfortable with sharing this information, you can ask if other forms of ID might work—or if this information is really needed at all. Also, take a moment to make copies of these documents and store them in a secure place. This can help you provide important info to the proper authorities if they’re lost or stolen.
With data breaches large and small making the news (and many more that do not), keeping a sharp eye on your accounts is a major part of identity theft prevention. We talk about this topic quite often, and it’s worth another mention because protecting these means protecting yourself from thieves who’re after direct access to your finances and more.
Secure your digital accounts for banking, credit cards, financials, and shopping by using strong, unique passwords for each of your accounts that you change every 60 days. Sound like a lot of work? Let a password manager do it for you, which you can find in comprehensive online protection software. By changing your strong passwords and keeping them unique can help prevent you from becoming a victim if your account information is part of a breach—by the time a crook attempts to use it, you may have changed it and made it out of date.
In addition to protecting the core forms of identity mentioned above, a few other good habits go a long way toward keeping your identity secure.
By protecting your devices, you protect what’s on them, like your personal information. Comprehensive online protection software can protect your identity in several ways, like creating and managing the strong, unique passwords we talked about and providing further services that monitor and protect your identity—in addition to digital shredders that can permanently remove sensitive documents (simply deleting them won’t do that alone.) Further, it can monitor your identity and monitor your credit, further protecting you from theft and fraud.
Identity theft where thieves dig through trash or go “dumpster diving” for literal scraps of personal info in bills and statements, has been an issue for some time. You can prevent it by shredding up any paper medical bills, tax documents, and checks once you’re through with them. Paper shredders are inexpensive, and let’s face it, kind of fun too. Also, if you’re traveling, have a trusted someone collects your mail or have the post office put a temporary hold on your mail. Thieves still poach mail from mailboxes too.
Getting statements online cuts the paper out of the equation and thus removes another thing that a thief can physically steal and possibly use against you. Whether you use electronic statements through your bank, credit card company, medical provider, or insurance company, use a secure password and a secure connection provided by a VPN. Both will make theft of your personal info far tougher on identity thieves.
A VPN is a Virtual Private Network, a service that protects your data and privacy online. It creates an encrypted tunnel to keep you more anonymous online by masking your IP address, device information, and the data you’re passing along that connection. In this way, it makes if far more difficult for advertisers, data brokers, and bad actors to skim your private information—in addition to shielding your information from crooks and snoops while you’re banking, shopping, or handling any kind of sensitive information online.
Give your statements a close look each time they come around. While many companies and institutions have fraud detection mechanisms in place, they don’t always catch every instance of fraud. Look out for strange purchases or charges and follow up with your bank or credit card company if you suspect fraud. Even the smallest charge could be a sign that something shady is afoot.
This is a powerful tool for spotting identity theft. And in many cases, it’s free to do so. In the U.S., the Fair Credit Reporting Act (FCRA) requires the major credit agencies to provide you with a free credit check at least once every 12 months. Canada provides this service, and the UK has options to receive free reports as well, along with several other nations. It’s a great idea to check your credit report, even if you don’t suspect a problem.
If the thought of your personal info being bought and sold puts you off, there’s something you can do about it. Our Personal Data Cleanup service can scan some of the riskiest data broker sites and show you which ones are selling your personal info. It also provides guidance on how you can remove your data from those sites, and with select products, it can even manage the removal for you.
While thieves need more than just your name and address to commit the overwhelming majority of fraud, your name and address are centerpieces of the larger jigsaw puzzle that is your overall identity.
And the interesting thing is your puzzle gets larger and larger as time goes on. With each new account you create and service that you sign into, that’s one more piece added to the puzzle. Thieves love getting their hands on any pieces they can because with enough of them in place they can try and pull a fast one in your name. By looking after each piece and knowing what your larger jigsaw puzzle looks like, you can help keep identity thieves out of your business and your life.
The post Can Thieves Steal Identities With Only a Name and Address? appeared first on McAfee Blog.
This article originally appeared in The Domain Name Industry Brief (Volume 18, Issue 3)
Earlier this year, the Internet Engineering Task Force’s (IETF’s) Internet Engineering Steering Group (IESG) announced that several Proposed Standards related to the Registration Data Access Protocol (RDAP), including three that I co-authored, were being promoted to the prestigious designation of Internet Standard. Initially accepted as proposed standards six years ago, RFC 7480, RFC 7481, RFC 9082 and RFC 9083 now comprise the new Standard 95. RDAP allows users to access domain registration data and could one day replace its predecessor the WHOIS protocol. RDAP is designed to address some widely recognized deficiencies in the WHOIS protocol and can help improve the registration data chain of custody.
In the discussion that follows, I’ll look back at the registry data model, given the evolution from WHOIS to the RDAP protocol, and examine how the RDAP protocol can help improve upon the more traditional, WHOIS-based registry models.
In 1998, Network Solutions was responsible for providing both consumer-facing registrar and back-end registry functions for the legacy .com, .net and .org generic top-level domains (gTLDs). Network Solutions collected information from domain name registrants, used that information to process domain name registration requests, and published both collected data and data derived from processing registration requests (such as expiration dates and status values) in a public-facing directory service known as WHOIS.
From Network Solution’s perspective as the registry, the chain of custody for domain name registration data involved only two parties: the registrant (or their agent) and Network Solutions. With the introduction of a Shared Registration System (SRS) in 1999, multiple registrars began to compete for domain name registration business by using the registry services operated by Network Solutions. The introduction of additional registrars and the separation of registry and registrar functions added parties to the chain of custody of domain name registration data. Information flowed from the registrant, to the registrar, and then to the registry, typically crossing multiple networks and jurisdictions, as depicted in Figure 1.
Over time, new gTLDs and new registries came into existence, new WHOIS services (with different output formats) were launched, and countries adopted new laws and regulations focused on protecting the personal information associated with domain name registration data. As time progressed, it became clear that WHOIS lacked several needed features, such as:
The IETF made multiple attempts to add features to WHOIS to address some of these issues, but none of them were widely adopted. A possible replacement protocol known as the Internet Registry Information Service (IRIS) was standardized in 2005, but it was not widely adopted. Something else was needed, and the IETF went back to work to produce what became known as RDAP.
RDAP was specified in a series of five IETF Proposed Standard RFC documents, including the following, all of which were published in March 2015:
Only when RDAP was standardized did we start to see broad deployment of a possible WHOIS successor by domain name registries, domain name registrars and address registries.
The broad deployment of RDAP led to RFCs 7480 and 7481 becoming Internet Standard RFCs (part of Internet Standard 95) without modification in March 2021. As operators of registration data directory services implemented and deployed RDAP, they found places in the other specifications where minor corrections and clarifications were needed without changing the protocol itself. RFC 7482 was updated to become Internet Standard RFC 9082, which was published in June 2021. RFC 7483 was updated to become Internet Standard RFC 9083, which was also published in June 2021. All were added to Standard 95. As of the writing of this article, RFC 7484 is in the process of being reviewed and updated for elevation to Internet Standard status.
Operators of registration data directory services who implemented RDAP can take advantage of key features not available in the WHOIS protocol. I’ve highlighted some of these important features in the table below.
| RDAP Feature | Benefit |
| Standard, well-understood, and widely available HTTP transport | Relatively easy to implement, deploy and operate using common web service tools, infrastructure and applications. |
| Securable via HTTPS | Helps provide confidentiality for RDAP queries and responses, reducing the amount of information that is disclosed to monitors. |
| Structured output in JavaScript Object Notation (JSON) | JSON is well-understood and tool friendly, which makes it easier for clients to parse and format responses from all servers without the need for software that’s customized for different service providers. |
| Easily extensible | Designed to support the addition of new features without breaking existing implementations. This makes it easier to address future function needs with less risk of implementation incompatibility. |
| Internationalized output, with full support for Unicode character sets | Allows implementations to provide human-readable inputs and outputs that are represented in a language appropriate to the local operating environment. |
| Referral capability, leveraging HTTP constructs | Provides information to software clients that allow the client to retrieve additional information from other RDAP servers. This can be used to hide complexity from human users. |
| Support of standardized authentication | RDAP can take full advantage of all of the client identification, authentication and authorization methods that are available to web services. This means that RDAP can be used to provide the basic framework for differentiated access to registration data based on attributes associated with the user and the user’s query. |
Verisign’s RDAP service, which was originally launched as an experimental implementation several years before gaining widespread adoption, allows users to look up records in the registry database for all registered .com, .net, .name, .cc and .tv domain names. It also supports Internationalized Domain Names (IDNs).
We at Verisign were pleased not only to see the IETF recognize the importance of RDAP by elevating it to an Internet Standard, but also that the protocol became a requirement for ICANN-accredited registrars and registries as of August 2019. Widespread implementation of the RDAP protocol makes registration data more secure, stable and resilient, and we are hopeful that the community will evolve the prescribed implementation of RDAP such that the full power of this rich protocol will be deployed.
You can learn more in the RDAP Help section of the Verisign website, and access helpful documents such as the RDAP technical implementation guide and the RDAP response profile.
The post Industry Insights: RDAP Becomes Internet Standard appeared first on Verisign Blog.
As I noted on May 26, the final decision issued on May 20 in the Independent Review Process (IRP) brought by Afilias against the Internet Corporation for Assigned Names and Numbers (ICANN) rejected Afilias’ petition to nullify the results of the public auction for .WEB, and it further rejected Afilias’ demand to have it be awarded .WEB (at a price substantially lower than the winning bid). Instead, as we urged, the IRP Panel determined that the ICANN Board should move forward with reviewing the objections made about .WEB, and to make a decision on delegation thereafter.
Afilias and its counsel both issued press releases claiming victory in an attempt to put a positive spin on the decision. In contrast to this public position, Afilias then quickly filed a 68-page application asking the Panel to reverse its decision. This application is, however, not permitted by the arbitration rules – which expressly prohibit such requests for “do overs.”
In addition to Afilias’ facially improper application, there is an even more serious instance of rule-breaking now described in a July 23 letter from Nu Dot Co (NDC) to ICANN. This letter sets out in considerable detail how Afilias engaged in prohibited conduct during the blackout period immediately before the .WEB auction in 2016, in violation of the auction rules. The letter shows how this rule violation is more than just a technicality; it was part of a broader scheme to rig the auction. The attachments to the letter shed light on how, during the blackout period, Afilias offered NDC money to stop ICANN’s public auction in favor of a private process – which would in turn deny the broader internet community the benefit of the proceeds of a public auction.
Afilias’ latest application to reverse the Panel’s decision, like its pre-auction misconduct 5 years ago, has only led to unnecessary delay of the delegation of .WEB. It is long past time for this multi-year campaign to come to an end. The Panel’s unanimous ruling makes clear that it strongly agrees.
The post Afilias’ Rule Violations Continue to Delay .WEB appeared first on Verisign Blog.
Today, we released the latest issue of The Domain Name Industry Brief, which shows that the second quarter of 2021 closed with 367.3 million domain name registrations across all top-level domains (TLDs), an increase of 3.8 million domain name registrations, or 1.0%, compared to the first quarter of 2021.1,2 Domain name registrations have decreased by 2.8 million, or 0.7%, year over year.1,2
Check out the latest issue of The Domain Name Industry Brief to see domain name stats from the second quarter of 2021, including:
This quarter’s The Domain Name Industry Brief also includes an overview of how Registration Data Access Protocol (RDAP) improves upon the legacy WHOIS protocol.
To see past issues of The Domain Name Industry Brief, please visit verisign.com/dnibarchives.
1. The figure(s) includes domain names in the .tk ccTLD. .tk is a ccTLD that provides free domain names to individuals and businesses. Revenue is generated by monetizing expired domain names. Domain names no longer in use by the registrant or expired are taken back by the registry and the residual traffic is sold to advertising networks. As such, there are no deleted .tk domain names. https://www.businesswire.com/news/home/20131216006048/en/Freenom-Closes-3M-Series-Funding#.UxeUGNJDv9s.
2. The generic top-level domain (gTLD), new gTLD (ngTLD) and ccTLD data cited in the brief: (i) includes ccTLD Internationalized Domain Names (IDNs), (ii) is an estimate as of the time this brief was developed and (iii) is subject to change as more complete data is received. Some numbers in the brief may reflect standard rounding.
The post Verisign Q2 2021 The Domain Name Industry Brief: 367.3 Million Domain Name Registrations in the Second Quarter of 2021 appeared first on Verisign Blog.
The global internet, from the perspective of its billions of users, has often been envisioned as a cloud — a shapeless structure that connects users to applications and to one another, with the internal details left up to the infrastructure operators inside.
From the perspective of the infrastructure operators, however, the global internet is a network of networks. It’s a complex set of connections among network operators, application platforms, content providers and other parties.
And just as the total amount of global internet traffic continues to grow, so too does the shape and structure of the internet — the internal details of the cloud — continue to evolve.
At the Association for Computing Machinery’s Special Interest Group on Data Communications (ACM SIGCOMM) conference in 2010, researchers at Arbor Networks and the University of Michigan, including Danny McPherson, now executive vice president and chief security officer at Verisign, published one of the first papers to analyze the internal structure of the internet in detail.
The study, entitled “Internet Inter-Domain Traffic,” drew from two years of measurements involving more than 200 exabytes of data.
One of the paper’s key observations was the emergence of a “global internet core” of a relatively small number of large application and content providers that had become responsible for the majority of the traffic between different parts of the internet — in contrast to the previous topology where large network operators were the primary source.
The authors’ conclusion: “we expect the trend towards internet inter-domain traffic consolidation to continue and even accelerate.”
The paper’s predictions of internet traffic and topology trends proved out over the past decade, as confirmed by one of the paper’s authors, Craig Labovitz, in a 2019 presentation that reiterated the paper’s main findings: the internet is “getting bigger by traffic volume” while also “rapidly getting smaller by concentration of content sources.”
This week, the ACM SIGCOMM 2021 conference series recognized the enduring value of the research with the prestigious Test of Time Paper Award, given to a paper that “deemed to be an outstanding paper whose contents are still a vibrant and useful contribution today.”
Internet measurement research is particularly relevant to Domain Name System (DNS) operators such as Verisign. To optimize the deployment of their services, DNS operators need to know where DNS query traffic is most likely to be exchanged in the coming years. Insights into the internal structure of the internet can help DNS operators ensure the ongoing security, stability and resiliency of their services, for the benefit both of other infrastructure operators who depend on DNS, and the billions of users who connect online every day.
Congratulations to Danny and co-authors Craig Labovitz, Scott Iekel-Johnson, Jon Oberheide and Farnam Jahanian on receiving this award, and thanks to ACM SIGCOMM for its recognition of the research. If you’re curious about what evolutionary developments Danny and others at Verisign are envisioning today about the internet of the future, subscribe to the Verisign blog, and follow us on Twitter and LinkedIn.
The post The Test of Time at Internet Scale: Verisign’s Danny McPherson Recognized with ACM SIGCOMM Award appeared first on Verisign Blog.
Note: This article originally appeared in Verisign’s Q1 2021 Domain Name Industry Brief.
This article expands on observations of a botnet traffic group at various levels of the Domain Name System (DNS) hierarchy, presented at DNS-OARC 35.
Addressing DNS abuse and maintaining a healthy DNS ecosystem are important components of Verisign’s commitment to being a responsible steward of the internet. We continuously engage with the Internet Corporation for Assigned Names and Numbers (ICANN) and other industry partners to help ensure the secure, stable and resilient operation of the DNS.
Based on recent telemetry data from Verisign’s authoritative top-level domain (TLD) name servers, Verisign observed a widespread botnet responsible for a disproportionate amount of total global DNS queries – and, in coordination with several registrars, registries and ICANN, acted expeditiously to remediate it.
Just prior to Verisign taking action to remediate the botnet, upwards of 27.5 billion queries per day were being sent to Verisign’s authoritative TLD name servers, accounting for roughly 10% of Verisign’s total DNS traffic. That amount of query volume in most DNS environments would be considered a sustained distributed denial-of-service (DDoS) attack.
These queries were associated with a particular piece of malware that emerged in 2018, spreading throughout the internet to create a global botnet infrastructure. Botnets provide a substrate for malicious actors to theoretically perform all manner of malicious activity – executing DDoS attacks, exfiltrating data, sending spam, conducting phishing campaigns or even installing ransomware. This is the result of the malware’s ability to download and execute any other type of payload the malicious actor desires.
Malware authors often apply various forms of evasion techniques to protect their botnets from being detected and remediated. A Domain Generation Algorithm (DGA) is an example of such an evasion technique.
DGAs are seen in various families of malware that periodically generate a number of domain names, which can be used as rendezvous points for botnet command-and-control servers. By using a DGA to build the list of domain names, the malicious actor makes it more difficult for security practitioners to identify what domain names will be used and when. Only by exhaustively reverse-engineering a piece of malware can the definitive set of domain names be ascertained.
The choices made by miscreants to tailor malware DGAs directly influences the DGAs’ ability to evade detection. For instance, electing to use more TLDs and a large number of domain names in a given time period makes the malware’s operation more difficult to disrupt; however, this approach also increases the amount of network noise, making it easier to identify anomalous traffic patterns by security and network teams. Likewise, a DGA that uses a limited number of TLDs and domain names will generate significantly less network noise but is more fragile and susceptible to remediation.
Botnets that implement DGA algorithms or utilize domain names clearly represent an “abuse of the DNS,” opposed to other types of abuse that are executed “via the DNS,” such as phishing. This is an important distinction the DNS community should consider as it continues to refine the scope of DNS abuse and how remediation of the various abuses can be effectuated.
The remediation of domain names used by botnets as rendezvous points poses numerous operational challenges and insights. The set of domain names needs to be identified and investigated to determine their current registration status. Risk assessments must be evaluated on registered domain names to determine if additional actions should be performed, such as sending registrar notifications, issuing requests to transfer domain names, adding Extensible Provisioning Protocol (EPP) hold statuses, altering delegation records, etc. There are also timing and coordination elements that must be balanced with external entities, such as ICANN, law enforcement, Computer Emergency Readiness Teams (CERTs) and contracted parties, including registrars and registries. Other technical decisions also need to be considered, designed and deployed to achieve the desired remediation goal.
After coordinating with ICANN, and several registrars and registries, Verisign registered the remaining available botnet domain names and began a three-phase plan to sinkhole those domain names. Ultimately, this remediation effort would reduce the traffic sent to Verisign authoritative name servers and effectively eliminate the botnet’s ability to use command-and-control domain names within Verisign-operated TLDs.
Figure 1 below shows the amount of botnet traffic Verisign authoritative name servers received prior to intervention, and throughout the process of registering, delegating and sinkholing the botnet domain names.
Phase one was executed on Dec. 21, 2020, in which 100 .cc domain names were configured to resolve to Verisign-operated sinkhole servers. Subsequently, traffic at Verisign authoritative name servers quickly decreased. The second group of domain names contained 500 .com and .net domain names, which were sinkholed on Jan. 7, 2021. Again, traffic volume at Verisign authoritative name servers quickly decreased. The final group of 879 .com and .net domain names were sinkholed on Jan. 13, 2021. By the end of phase three, the cumulative DNS traffic reduction surpassed 25 billion queries per day. Verisign reserved approximately 10 percent of the botnet domain names to remain on serverHold as a placebo/control-group to better understand sinkholing effects as they relate to query volume at the child and parent zones. Verisign believes that sinkholing the remaining domain names would further reduce authoritative name server traffic by an additional one billion queries.
This botnet highlights the remarkable Pareto-like distribution of DNS query traffic, in which a few thousand domain names that span namespaces containing more than 165 million domain names, demand a vastly disproportionate amount of DNS resources.
What causes the amplification of DNS traffic volume for non-existent domain names to occur at the upper levels of the DNS hierarchy? Verisign is conducting a variety of measurements on the sinkholed botnet domain names to better understand the caching behavior of the resolver population. We are observing some interesting traffic changes at the TLD and root name servers when time to live (TTL) and response codes are altered at the sinkhole servers. Stay tuned.
In addition to remediating this botnet in late 2020 and into early 2021, Verisign extended its already four-year endeavor to combat the Avalanche botnet family. Since 2016, the Avalanche botnet had been significantly impacted due to actions taken by Verisign and an international consortium of law enforcement, academic and private organizations. However, many of the underlying Avalanche-compromised machines are still not remediated, and the threat from Avalanche could increase again if additional actions are not taken. To prevent this from happening, Verisign, in coordination with ICANN and other industry partners, is using a variety of tools to ensure Avalanche command-and-control domain names cannot be used in Verisign-operated TLDs.
Botnets are a persistent issue. And as long as they exist as a threat to the security, stability and resiliency of the DNS, cross-industry coordination and collaboration will continue to lie at the core of combating them.
This piece was co-authored by Matt Thomas and Duane Wessels, distinguished engineers at Verisign.
The post Industry Insights: Verisign, ICANN and Industry Partners Collaborate to Combat Botnets appeared first on Verisign Blog.
Today, we released the latest issue of the Domain Name Industry Brief, which shows that the first quarter of 2021 closed with 363.5 million domain name registrations across all top-level domains (TLDs), a decrease of 2.8 million domain name registrations, or 0.8%, compared to the fourth quarter of 2020.1,2 Domain name registrations have decreased by 3.3 million, or 0.9%, year over year.1,2
Check out the latest issue of the Domain Name Industry Brief to see domain name stats from the first quarter of 2021, including:
This quarter’s Domain Name Industry Brief also includes a look at a recent collaboration between Verisign, ICANN and industry partners to combat botnets.
To see past issues of the Domain Name Industry Brief, please visit verisign.com/dnibarchives.
1. The figure(s) includes domain names in the .tk ccTLD. .tk is a ccTLD that provides free domain names to individuals and businesses. Revenue is generated by monetizing expired domain names. Domain names no longer in use by the registrant or expired are taken back by the registry and the residual traffic is sold to advertising networks. As such, there are no deleted .tk domain names. https://www.businesswire.com/news/home/20131216006048/en/Freenom-Closes-3M-Series-Funding#.UxeUGNJDv9s.
2. The generic top-level domain (gTLD), new gTLD (ngTLD) and ccTLD data cited in the brief: (i) includes ccTLD Internationalized Domain Names (IDNs), (ii) is an estimate as of the time this brief was developed and (iii) is subject to change as more complete data is received. Some numbers in the brief may reflect standard rounding.
The post Verisign Q1 2021 Domain Name Industry Brief: 363.5 Million Domain Name Registrations in the First Quarter of 2021 appeared first on Verisign Blog.
On Thursday, May 20, a final decision was issued in the Independent Review Process (IRP) brought by Afilias against the Internet Corporation for Assigned Names and Numbers (ICANN), rejecting Afilias’ petition to nullify the results of the July 27, 2016 public auction for the .WEB new generic top level domain (gTLD) and to award .WEB to Afilias at a substantially lower, non-competitive price. Nu Dotco, LLC (NDC) submitted the highest bid at the auction and was declared the winner, over Afilias’ lower, losing bid. Despite Afilias’ repeated objections to participation by NDC or Verisign in the IRP, the Panel ordered that NDC and Verisign could participate in the IRP in a limited way each as amicus curiae.
Consistent with NDC, Verisign and ICANN’s position in the IRP, the Order dismisses “the Claimant’s [Afilias’] request that Respondent [ICANN] be ordered by the Panel to disqualify NDC’s bid for .WEB, proceed with contracting the Registry Agreement for .WEB with the Claimant in accordance with the New gTLD Program Rules, and specify the bid price to be paid by the Claimant.” Contrary to Afilias’ position, all objections to the auction are referred to ICANN for determination. This includes Afilias’ objections as well as objections by NDC that Afilias violated the auction rules by engaging in secret discussions during the Blackout Period under the Program Rules.
Afilias’ claims for relief were based on its allegation that NDC violated the New gTLD Program Rules by entering into an agreement with Verisign, under which Verisign provided funds for NDC’s participation in the .WEB auction in exchange for NDC’s commitment, if it prevailed at the auction and entered into a registry agreement with ICANN, to assign its .WEB registry agreement to Verisign upon ICANN’s consent to the assignment. As the Panel determined, the relief requested by Afilias far exceeded the scope of proper IRP relief provided for in ICANN’s Bylaws, which limit an IRP to a determination whether or not ICANN has exceeded its mission or otherwise failed to comply with its Articles of Incorporation and Bylaws.
Issued two and a half years after Afilias initiated its IRP, the Panel’s decision unequivocally rejects Afilias’ attempt to misuse the IRP to rule on claims of NDC or Verisign misconduct or obtain the .WEB gTLD for itself despite its losing bid. The Panel held that it is for ICANN, which has the requisite knowledge, expertise, and experience, to determine whether NDC’s contract with Verisign violated ICANN’s Program Rules. The Panel further determined that it would be improper for the Panel to dictate what should be the consequences of an alleged violation of the rules contained in the gTLD Applicant Guidebook, if any took place. The Panel therefore denied Afilias’ requests for a binding declaration that ICANN must disqualify NDC’s bid for violating the Guidebook rules and award .WEB to Afilias.
Despite pursuing its claims in the IRP for over two years — at a cost of millions of dollars — Afilias failed to offer any evidence to support its allegations that NDC improperly failed to update its application and/or assigned its application to Verisign. Instead, the evidence was to the contrary. Indeed, Afilias failed to offer testimony from a single Afilias witness during the hearing on the merits, including witnesses with direct knowledge of relevant events and industry practices. It is apparent that Afilias failed to call as witnesses any of its own officers or employees because, testifying under penalty of perjury, they would have been forced to contradict the false allegations advanced by Afilias during the IRP. By contrast, ICANN, NDC and Verisign each supported their respective positions appropriately by calling witnesses to testify and be subject to cross-examination by the three-arbitrator panel and Afilias, under oath, with respect to the facts refuting Afilias’ claims.
Afilias also argued in the IRP that ICANN is a competition regulator and that ICANN’s commitment, contained in its Bylaws, to promote competition required ICANN to disqualify NDC’s bid for the .WEB gTLD because NDC’s contract with Verisign may lead to Verisign’s operation of .WEB. The Panel rejected Afilias’ claim, agreeing with ICANN and Verisign that “ICANN does not have the power, authority, or expertise to act as a competition regulator by challenging or policing anticompetitive transactions or conduct.” The Panel found ICANN’s evidence “compelling” that it fulfills its mission to promote competition through the expansion of the domain name space and facilitation of innovative approaches to the delivery of domain name registry services, not by acting as an antitrust regulator. The Panel quoted Afilias’ own statements to this effect, which were made outside of the IRP proceedings when Afilias had different interests.
Although the Panel rejected Afilias’ Guidebook and competition claims, it did find that the manner in which ICANN addressed complaints about the .WEB matter did not meet all of the commitments in its Bylaws. But even so, Afilias was awarded only a small portion of the legal fees it hoped to recover from ICANN.
It is now up to ICANN to move forward expeditiously to determine, consistent with its Bylaws, the validity of any objections under the New gTLD Program Rules in connection with the .WEB auction, including NDC and Verisign’s position that Afilias should be disqualified from making any further objections to NDC’s application.
As Verisign and NDC pointed out in 2016, the evidence during the IRP establishes that collusive conduct by Afilias in connection with the auction violated the Guidebook. The Guidebook and Auction Rules both prohibit applicants within a contention set from discussing “bidding strategies” or “settlement” during a designated Blackout Period in advance of an auction. Violation of the Blackout Period is a “serious violation” of ICANN’s rules and may result in forfeiture of an applicant’s application. The evidence adduced in the IRP proves that Afilias committed such violations and should be disqualified. On July 22, just four days before the public ICANN auction for .WEB, Afilias contacted NDC, following Afilias’ discussions with other applicants, to try to negotiate a private auction if ICANN would delay the public auction. Afilias knew the Blackout Period was in effect, but nonetheless violated it in an attempt to persuade NDC to participate in a private auction. Under the settlement Afilias proposed, Afilias would make millions of dollars even if it lost the auction, rather than auction proceeds being used for the internet community through the investment of such proceeds by ICANN as determined by the community.
All of the issues raised during the IRP were the subject of extensive briefing, evidentiary submissions and live testimony during the hearing on the merits, providing ICANN with a substantial record on which to render a determination with respect to .WEB and proceed forward with delegation of the new gTLD. Verisign stands ready to assist ICANN in any way we can to quickly resolve this matter so that domain names within the .WEB gTLD can finally be made available to businesses and consumers.
As a final observation: Afilias no longer operates a registry business, and has neither the platform, organization, nor necessary consents from ICANN, to support one. Inconsistent with Afilias’ claims in the IRP, Afilias transferred its entire registry business to Donuts during the pendency of the IRP. Although long in the works, the sale was not disclosed by Afilias either before or during the IRP hearings, nor, remarkably, did Afilias produce any company witness for examination who might have disclosed the sale to the panel of arbitrators or others. Based on a necessary public disclosure of the Donuts sale after the hearings and before entry of the Panel’s Order, the Panel included in its final Order a determination that it is for ICANN to determine whether the Afilias’ sale is itself a basis for a denial of Afilias’ claims with respect to .WEB.
The post IRP Panel Dismisses Afilias’ Claims to Reverse .WEB Auction and Award .WEB to Afilias appeared first on Verisign Blog.
At Verisign we have a commitment to making a positive and lasting impact on the global internet community, and on the communities in which we live and work.
This commitment guided our initial efforts to help these communities respond to and recover from the effects of the COVID-19 pandemic, over a year ago. And at the end of 2020, our sense of partnership with our local communities helped shape our efforts to alleviate COVID-related food insecurity in the areas where we have our most substantial footprint. This same sense of community is reflected in our partnership with Virginia Ready, which aims to help individuals in our home State of Virginia access training and certification to pivot to new careers in the technology sector.
We also believe that our team is one of our most important assets. We particularly value the diverse origins of our people; we have colleagues from all over the world who, in turn, are closely connected to their own communities both in the United States and elsewhere. A significant proportion of our staff are of either Asian American and Pacific Islander (AAPI) or South Asian origin, and today we are pleased to announce two charitable contributions, via our Verisign Cares program, directly related to these two communities.
First, Verisign is pleased to associate ourselves with the Stand with Asian Americans initiative, launched by AAPI business leaders in response to recent and upsetting episodes of aggression toward their community. Verisign supports this initiative and the pledge for which it stands, and has made a substantial contribution to the initiative’s partner, the Asian Pacific Fund, to help uplift the AAPI community.
Second, and after consultation with our staff, we have directed significant charitable contributions to organizations helping to fight the worsening wave of COVID-19 in India. Through Direct Relief we will be helping to provide oxygen and other medical equipment to hospitals, while through GiveIndia we will be supporting families in India impacted by COVID-19.
The ‘extended Verisign family’ of our employees, and their families and their communities, means a tremendous amount to us – it is only thanks to our talented and dedicated people that we are able to continue to fulfill our mission of enabling the world to connect online with reliability and confidence, anytime, anywhere.
The post Verisign Support for AAPI Communities and COVID Relief in India appeared first on Verisign Blog.
Today, we released the latest issue of the Domain Name Industry Brief, which shows that the fourth quarter of 2020 closed with 366.3 million domain name registrations across all top-level domains (TLDs), a decrease of 4.4 million domain name registrations, or 1.2 percent, compared to the third quarter of 2020.1,2 Domain name registrations have grown by 4.0 million, or 1.1 percent, year over year.1,2
Check out the latest issue of the Domain Name Industry Brief to see domain name stats from the fourth quarter of 2020, including:
This quarter’s Domain Name Industry Brief also includes a closer look at encryption and what new DNS capabilities may be possible with a “minimize at the root and top-level domain, encrypt when needed elsewhere” approach to DNS encryption.
To see past issues of the Domain Name Industry Brief, please visit Verisign.com/DNIBArchives.
1. The figure(s) includes domain names in the .tk ccTLD. .tk is a ccTLD that provides free domain names to individuals and businesses. Revenue is generated by monetizing expired domain names. Domain names no longer in use by the registrant or expired are taken back by the registry and the residual traffic is sold to advertising networks. As such, there are no deleted .tk domain names. https://www.businesswire.com/news/home/20131216006048/en/Freenom-Closes-3M-Series-Funding#.UxeUGNJDv9s.
2. The generic top-level domain (gTLD), new gTLD (ngTLD) and ccTLD data cited in the brief: (i) includes ccTLD Internationalized Domain Names (IDNs), (ii) is an estimate as of the time this brief was developed and (iii) is subject to change as more complete data is received. Some numbers in the brief may reflect standard rounding.
The post Verisign Q4 2020 Domain Name Industry Brief: 366.3 Million Domain Name Registrations in the Fourth Quarter of 2020 appeared first on Verisign Blog.
This is the final in a multi-part series on cryptography and the Domain Name System (DNS).
In previous posts in this series, I’ve discussed a number of applications of cryptography to the DNS, many of them related to the Domain Name System Security Extensions (DNSSEC).
In this final blog post, I’ll turn attention to another application that may appear at first to be the most natural, though as it turns out, may not always be the most necessary: DNS encryption. (I’ve also written about DNS encryption as well as minimization in a separate post on DNS information protection.)
In 2014, the Internet Engineering Task Force (IETF) chartered the DNS PRIVate Exchange (dprive) working group to start work on encrypting DNS queries and responses exchanged between clients and resolvers.
That work resulted in RFC 7858, published in 2016, which describes how to run the DNS protocol over the Transport Layer Security (TLS) protocol, also known as DNS over TLS, or DoT.
DNS encryption between clients and resolvers has since gained further momentum, with multiple browsers and resolvers supporting DNS over Hypertext Transport Protocol Security (HTTPS), or DoH, with the formation of the Encrypted DNS Deployment Initiative, and with further enhancements such as oblivious DoH.
The dprive working group turned its attention to the resolver-to-authoritative exchange during its rechartering in 2018. And in October of last year, ICANN’s Office of the CTO published its strategy recommendations for the ICANN-managed Root Server (IMRS, i.e., the L-Root Server), an effort motivated in part by concern about potential “confidentiality attacks” on the resolver-to-root connection.
From a cryptographer’s perspective the prospect of adding encryption to the DNS protocol is naturally quite interesting. But this perspective isn’t the only one that matters, as I’ve observed numerous times in previous posts.
A common theme in this series on cryptography and the DNS has been the question of whether the benefits of a technology are sufficient to justify its cost and complexity.
This question came up not only in my review of two newer cryptographic advances, but also in my remarks on the motivation for two established tools for providing evidence that a domain name doesn’t exist.
Recall that the two tools — the Next Secure (NSEC) and Next Secure 3 (NSEC3) records — were developed because a simpler approach didn’t have an acceptable risk / benefit tradeoff. In the simpler approach, to provide a relying party assurance that a domain name doesn’t exist, a name server would return a response, signed with its private key, “<name> doesn’t exist.”
From a cryptographic perspective, the simpler approach would meet its goal: a relying party could then validate the response with the corresponding public key. However, the approach would introduce new operational risks, because the name server would now have to perform online cryptographic operations.
The name server would not only have to protect its private key from compromise, but would also have to protect the cryptographic operations from overuse by attackers. That could open another avenue for denial-of-service attacks that could prevent the name server from responding to legitimate requests.
The designers of DNSSEC mitigated these operational risks by developing NSEC and NSEC3, which gave the option of moving the private key and the cryptographic operations offline, into the name server’s provisioning system. Cryptography and operations were balanced by this better solution. The theme is now returning to view through the recent efforts around DNS encryption.
Like the simpler initial approach for authentication, DNS encryption may meet its goal from a cryptographic perspective. But the operational perspective is important as well. As designers again consider where and how to deploy private keys and cryptographic operations across the DNS ecosystem, alternatives with a better balance are a desirable goal.
In addition to encryption, there has been research into other, possibly lower-risk alternatives that can be used in place of or in addition to encryption at various levels of the DNS.
We call these techniques collectively minimization techniques.
In “textbook” DNS resolution, a resolver sends the same full domain name to a root server, a top-level domain (TLD) server, a second-level domain (SLD) server, and any other server in the chain of referrals, until it ultimately receives an authoritative answer to a DNS query.
This is the way that DNS resolution has been practiced for decades, and it’s also one of the reasons for the recent interest in protecting information on the resolver-to-authoritative exchange: The full domain name is more information than all but the last name server needs to know.
One such minimization technique, known as qname minimization, was identified by Verisign researchers in 2011 and documented in RFC 7816 in 2016. (In 2015, Verisign announced a royalty-free license to its qname minimization patents.)
With qname minimization, instead of sending the full domain name to each name server, the resolver sends only as much as the name server needs either to answer the query or to refer the resolver to a name server at the next level. This follows the principle of minimum disclosure: the resolver sends only as much information as the name server needs to “do its job.” As Matt Thomas described in his recent blog post on the topic, nearly half of all .com and .net queries received by Verisign’s .com TLD servers were in a minimized form as of August 2020.
Other techniques that are part of this new chapter in DNS protocol evolution include NXDOMAIN cut processing [RFC 8020] and aggressive DNSSEC caching [RFC 8198]. Both leverage information present in the DNS to reduce the amount and sensitivity of DNS information exchanged with authoritative name servers. In aggressive DNSSEC caching, for example, the resolver analyzes NSEC and NSEC3 range proofs obtained in response to previous queries to determine on its own whether a domain name doesn’t exist. This means that the resolver doesn’t always have to ask the authoritative server system about a domain name it hasn’t seen before.
All of these techniques, as well as additional minimization alternatives I haven’t mentioned, have one important common characteristic: they only change how the resolver operates during the resolver-authoritative exchange. They have no impact on the authoritative name server or on other parties during the exchange itself. They thereby mitigate disclosure risk while also minimizing operational risk.
The resolver’s exchanges with authoritative name servers, prior to minimization, were already relatively less sensitive because they represented aggregate interests of the resolver’s many clients1. Minimization techniques lower the sensitivity even further at the root and TLD levels: the resolver sends only its aggregate interests in TLDs to root servers, and only its interests in SLDs to TLD servers. The resolver still sends the aggregate interests in full domain names at the SLD level and below2, and may also include certain client-related information at these levels, such as the client-subnet extension. The lower levels therefore may have different protection objectives than the upper levels.
Minimization techniques and encryption together give DNS designers additional tools for protecting DNS information — tools that when deployed carefully can balance between cryptographic and operational perspectives.
These tools complement those I’ve described in previous posts in this series. Some have already been deployed at scale, such as a DNSSEC with its NSEC and NSEC3 non-existence proofs. Others are at various earlier stages, like NSEC5 and tokenized queries, and still others contemplate “post-quantum” scenarios and how to address them. (And there are yet other tools that I haven’t covered in this series, such as authenticated resolution and adaptive resolution.)
Modern cryptography is just about as old as the DNS. Both have matured since their introduction in the late 1970s and early 1980s respectively. Both bring fundamental capabilities to our connected world. Both continue to evolve to support new applications and to meet new security objectives. While they’ve often moved forward separately, as this blog series has shown, there are also opportunities for them to advance together. I look forward to sharing more insights from Verisign’s research in future blog posts.
Read the complete six blog series:
1. This argument obviously holds more weight for large resolvers than for small ones — and doesn’t apply for the less common case of individual clients running their own resolvers. However, small resolvers and individual clients seeking additional protection retain the option of sending sensitive queries through a large, trusted resolver, or through a privacy-enhancing proxy. The focus in our discussion is primarily on large resolvers.
2. In namespaces where domain names are registered at the SLD level, i.e., under an effective TLD, the statements in this note about “root and TLD” and “SLD level and below” should be “root through effective TLD” and “below effective TLD level.” For simplicity, I’ve placed the “zone cut” between TLD and SLD in this note.
The post Information Protection for the Domain Name System: Encryption and Minimization appeared first on Verisign Blog.
A name collision occurs when a user attempts to resolve a domain in one namespace, but it unexpectedly resolves in a different namespace. Name collision issues in the public global Domain Name System (DNS) cause billions of unnecessary and potentially unsafe DNS queries every day. A targeted outreach program that Verisign started in March 2020 has remediated one billion queries per day to the A and J root name servers, via 46 collision strings. After contacting several national internet service providers (ISPs), the outreach effort grew to include large search engines, social media companies, networking equipment manufacturers, national CERTs, security trust groups, commercial DNS providers, and financial institutions.
While this unilateral outreach effort resulted in significant and successful name collision remediation, it is broader DNS community engagement, education, and participation that offers the potential to address many of the remaining name collision problems. Verisign hopes its successes will encourage participation by other organizations in similar positions in the DNS community.
Verisign is proud to be the operator for two of the world’s 13 authoritative root servers. Being a root server operator carries with it many operational responsibilities. Ensuring the security, stability and resiliency of the DNS requires proactive efforts so that attacks against the root name servers do not disrupt DNS resolution, as well as the monitoring of DNS resolution patterns for misconfigurations, signaling telemetry, and unexpected or unintended uses that, without closer collaboration, could have unforeseen consequences (e.g. Chromium’s impact on root DNS traffic).
Monitoring may require various forms of responsible disclosure or notification to the underlying parties. Further, monitoring the root server system poses logistical challenges because any outreach and remediation programs must work at internet scale, and because root operators have no direct relationship with many of the involved entities.
Despite these challenges, Verisign has conducted several successful internet-scale outreach efforts to address various issues we have observed in the DNS.
In response to the Internet Corporation for Assigned Names and Number (ICANN) proposal to mitigate name collision risks in 2013, Verisign conducted a focused study on the collision string .CBA. Our measurement study revealed evidence of a substantial internet-connected infrastructure in Japan that relied on the non-resolution of names that end in .CBA. Verisign informed the network operator, who subsequently reconfigured some of its internal systems, resulting in an immediate decline of queries for .CBA observed at A and J root servers.
Prior to the 2018 KSK rollover, several operators of DNSSEC-validating name servers appeared to be sending out-of-date RFC 8145 signals to root name servers. To ensure the KSK rollover did not disrupt internet name resolution functions for billions of end users, Verisign augmented ICANN’s outreach effort and conducted a multi-faceted technical outreach program by contacting and working with The United States Computer Emergency Readiness Team (US-CERT) and other national CERTs, industry partners, various DNS operator groups and performing direct outreach to out-of-date signalers. The ultimate success of the KSK rollover was due in large part to outreach efforts by ICANN and Verisign.
In response to the ICANN Board’s request in resolutions 2017.11.02.29 – 2017.11.02.31, the ICANN Security and Stability Advisory Committee (SSAC) was asked to conduct studies, and to present data and points of view on collision strings, including specific advice on three higher risk strings: .CORP, .HOME and .MAIL. While Verisign is actively engaged in this Name Collision Analysis Project (NCAP) developed by SSAC, we are also reviving and expanding our 2012 name collision outreach efforts.
Verisign’s name collision outreach program is based on the guidance we provided in several recent peer-reviewed name collision publications, which highlighted various name collision vulnerabilities and examined the root causes of leaked queries and made remediation recommendations. Verisign’s program uses A and J root name server traffic data to identify high-affinity strings related to particular networks, as well as high query volume strings that are contextually associated with device manufacturers, software, or platforms. We then attempt to contact the underlying parties and assist with remediation as appropriate.
While we partially rely on direct communication channel contact information, the key enabler of our outreach efforts has been Verisign’s relationships with the broader collective DNS community. Verisign’s active participation in various industry organizations within the ICANN and DNS communities, such as M3AAWG, FIRST, DNS-OARC, APWG, NANOG, RIPE NCC, APNIC, and IETF1, enables us to identify and communicate with a broad and diverse set of constituents. In many cases, participants operate infrastructure involved in name collisions. In others, they are able to put us in direct contact with the appropriate parties.
Through a combination of DNS traffic analysis and publicly accessible data, as well as the rolodexes of various industry partnerships, across 2020 we were able to achieve effective outreach to the anonymized entities listed in Table 1.
| Organization | Queries per Day to A & J | Status | Number of Collision Strings (TLDs) | Notes / Root Cause Analysis |
| Search Engine | 650M | Fixed | 1 string | Application not using FQDNs |
| Telecommunications Provider | 250M | Fixed | N/A | Prefetching bug |
| eCommerce Provider | 150M | Fixed | 25 strings | Application not using FQDNs |
| Networking Manufacturer | 70M | Pending | 3 strings | Suffix search list |
| Cloud Provider | 64M | Fixed | 15 strings | Suffix search list |
| Telecommunications Provider | 60M | Fixed | 2 strings | Remediated through device vendor |
| Networking Manufacturer | 45M | Pending | 2 strings | Suffix search list problem in router/modem device |
| Financial Corporation | 35M | Fixed | 2 strings | Typo / misconfiguration |
| Social Media Company | 30M | Pending | 9 strings | Application not using FQDNs |
| ISP | 20M | Fixed | 1 string | Suffix search list problem in router/modem device |
| Software Provider | 20M | Pending | 50+ strings | Acknowledged but still investigating |
| ISP | 5M | Pending | 1 string | At time of writing, still investigating but confirmed it is a router/modem device |
Many of the name collision problems encountered are the result of misconfigurations and not using fully qualified domain names. After operators deploy patches to their environments, as shown in Figure 1 below, Verisign often observes an immediate and dramatic traffic decrease at A and J root name servers. Although several networking equipment vendors and ISPs acknowledge their name collision problems, the development and deployment of firmware to a large userbase will take time.
Cumulatively, the operators who have deployed patches constitute a reduction of one billion queries per day to A and J root servers (roughly 3% of total traffic). Although root traffic is not evenly distributed among the 13 authoritative servers, we expect a similar impact at the other 11, resulting in a system-wide reduction of approximately 6.5 billion queries per day.
As the ICANN community prepares for Subsequent Procedures (the introduction of additional new TLDs) and the SSAC NCAP continues to work to answer the ICANN Board’s questions, we encourage the community to participate in our efforts to address name collisions through active outreach efforts. We believe our efforts show how outreach can have significant impact to both parties and the broader community. Verisign is committed to addressing name collision problems and will continue executing the outreach program to help minimize the attack surface exposed by name collisions and to be a responsible and hygienic root operator.
For additional information about name collisions and how to properly manage private-use TLDs, please see visit ICANN’s Name Collision Resource & Information website.
1. The Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG), Forum of Incident Response and Security Teams (FIRST), DNS Operations, Analysis, and Research Center (DNS-OARC), Anti-Phishing Working Group (APWG), North American Network Operators’ Group (NANOG), Réseaux IP Européens Network Coordination Centre (RIPE NCC), Asia Pacific Network Information Centre (APNIC), Internet Engineering Task Force (IETF)
The post Verisign Outreach Program Remediates Billions of Name Collision Queries appeared first on Verisign Blog.
As we begin a new year, it is important to look back and reflect on our accomplishments and how we can continue to improve. A significant positive the DNS community could appreciate from 2020 is the receptiveness and responsiveness of the Chromium team to address the large amount of DNS queries being sent to the root server system.
In a previous blog post, we quantified that upwards of 45.80% of total DNS traffic to the root servers was, at the time, the result of Chromium intranet redirection detection tests. Since then, the Chromium team has redesigned its code to disable the redirection test on Android systems and introduced a multi-state DNS interception policy that supports disabling the redirection test for desktop browsers. This functionality was released mid-November of 2020 for Android systems in Chromium 87 and, quickly thereafter, the root servers experienced a rapid decline of DNS queries.
The figure below highlights the significant decline of query volume to the root server system immediately after the Chromium 87 release. Prior to the software release, the root server system saw peaks of ~143 billion queries per day. Traffic volumes have since decreased to ~84 billion queries a day. This represents more than a 41% reduction of total query volume.
This type of broad root system measurement is facilitated by ICANN’s Root Server System Advisory Committee standards document RSSAC002, which establishes a set of baseline metrics for the root server system. These root server metrics are readily available to the public for analysis, monitoring, and research. These metrics represent another milestone the DNS community could appreciate and continue to support and refine going forward.
Rightly noted in ICANN’s Root Name Service Strategy and Implementation publication, the root server system currently “faces growing volumes of traffic” from legitimate users but also from misconfigurations, misuse, and malicious actors and that “the costs incurred by the operators of the root server system continue to climb to mitigate these attacks using the traditional approach”.
As we reflect on how Chromium’s large impact to root server traffic was identified and then resolved, we as a DNS community could consider how outreach and engagement should be incorporated into a traditional approach of addressing DNS security, stability, and resiliency. All too often, technologists solve problems by introducing additional layers of technology abstractions and disregarding simpler solutions, such as outreach and engagement.
We believe our efforts show how such outreach and community engagement can have significant impact both to the parties directly involved, and to the broader community. Chromium’s actions will directly aide and ease the operational costs to mitigate attacks at the root. Reducing the root server system load by 41%, with potential further reduction depending on future Chromium deployment decisions, will lighten operational costs incurred to mitigate attacks by relinquishing their computing and network resources.
In pursuit of maintaining a responsible and common-sense root hygiene regimen, Verisign will continue to analyze root telemetry data and engage with entities such as Chromium to highlight operational concerns, just as Verisign has done in the past to address name collisions problems. We’ll be sharing more information on this shortly.
This piece was co-authored by Matt Thomas and Duane Wessels, Distinguished Engineers at Verisign.
The post Chromium’s Reduction of Root DNS Traffic appeared first on Verisign Blog.
The COVID-19 pandemic, when it struck earlier this year, ushered in an immediate period of adjustment for all of us. And just as the challenges posed by COVID-19 in 2020 have been truly unprecedented, Verisign’s mission – enabling the world to connect online with reliability and confidence, anytime, anywhere – has never been more relevant. We are grateful for the continued dedication of our workforce, which enables us to provide the building blocks people need for remote working and learning, and simply for keeping in contact with each other.
At Verisign we took early action to adopt a COVID-19 work posture to protect our people, their families, and our operations. This involved the majority of our employees working from home, and implementing new cleaning and health safety protocols to protect those employees and contractors for whom on-site presence was essential to maintain key functions.
Our steps to address the pandemic did not stop there. On March 25 we announced a series of measures to help the communities where we live and work, and the broader DNS community in which we operate. This included, under our Verisign Cares program, making contributions to organizations supporting key workers, first responders and medical personnel, and doubling the company’s matching program for employee giving so that employee donations to support the COVID-19 response could have a greater impact.
Today, while vaccines may offer signs of long term hope, the pandemic has plunged many families into economic hardship and has had a dramatic effect on food insecurity in the U.S., with an estimated 50 million people affected. With this hardship in mind, we have this week made contributions totaling $275,000 to food banks in the areas where we have our most substantial footprint: the Washington DC-Maryland-Virginia region; Delaware; and the canton of Fribourg, in Switzerland. This will help local families put food on their tables during what will be a difficult winter for many.
The pandemic has also had a disproportionate, and potentially permanent, impact on certain sectors of the economy. So today Verisign is embarking on a partnership with Virginia Ready, which helps people affected by COVID-19 access training and certification for in-demand jobs in sectors such as technology. We are making an initial contribution of $250,000 to Virginia Ready, and will look to establish further partnerships of this kind across the country in 2021.
The post Meeting the Evolving Challenges of COVID-19 appeared first on Verisign Blog.
Over the past several years, questions about how to protect information exchanged in the Domain Name System (DNS) have come to the forefront.
One of these questions was posed first to DNS resolver operators in the middle of the last decade, and is now being brought to authoritative name server operators: “to encrypt or not to encrypt?” It’s a question that Verisign has been considering for some time as part of our commitment to security, stability and resiliency of our DNS operations and the surrounding DNS ecosystem.
Because authoritative name servers operate at different levels of the DNS hierarchy, the answer is not a simple “yes” or “no.” As I will discuss in the sections that follow, different information protection techniques fit the different levels, based on a balance between cryptographic and operational considerations.
Rather than asking whether to deploy encryption for a particular exchange, we believe it is more important to ask how best to address the information protection objectives for that exchange — whether by encryption, alternative techniques or some combination thereof.
Information protection must balance three objectives:
The importance of balancing these objectives is well-illustrated in the case of encryption. Encryption can improve confidentiality and integrity by making it harder for an adversary to view or change data, but encryption can also impair availability, by making it easier for an adversary to cause other participants to expend unnecessary resources. This is especially the case in DNS encryption protocols where the resource burden for setting up an encrypted session rests primarily on the server, not the client.
The Internet-Draft “Authoritative DNS-Over-TLS Operational Considerations,” co-authored by Verisign, expands on this point:
Initial deployments of [Authoritative DNS over TLS] may offer an immediate expansion of the attack surface (additional port, transport protocol, and computationally expensive crypto operations for an attacker to exploit) while, in some cases, providing limited protection to end users.
Complexity is also a concern because DNS encryption requires changes on both sides of an exchange. The long-installed base of DNS implementations, as Bert Hubert has parabolically observed, can only sustain so many more changes before one becomes the “straw that breaks the back” of the DNS camel.
The flowchart in Figure 1 describes a two-stage process for factoring in operational risk when determining how to mitigate the risk of disclosure of sensitive information in a DNS exchange. The process involves two questions.
This process can readily be applied to develop guidance for each exchange in the DNS resolution ecosystem.
Three main exchanges in the DNS resolution ecosystem are considered here, as shown in Figure 2: resolver-to-authoritative at the root and TLD level; resolver-to-authoritative below these levels; and client-to-resolver.
The resolver-to-authoritative exchange at the root level enables DNS resolution for all underlying domain names; the exchange at the TLD level does the same for all names under a TLD. These exchanges provide global navigation for all names, benefiting all resolvers and therefore all clients, and making the availability objective paramount.
As a resolver generally services many clients, information exchanged at these levels represents aggregate interests in domain names, not the direct interests of specific clients. The sensitivity of this aggregated information is therefore relatively low to start with, as it does not contain client-specific details beyond the queried names and record types. However, the full domain name of interest to a client has conventionally been sent to servers at the root and TLD levels, even though this is more information than they need to know to refer the resolver to authoritative name servers at lower levels of the DNS hierarchy. The additional detail in the full domain name may be considered sensitive in some cases. Therefore, this data exchange merits consideration for protection.
The decision flow (as generally described in Figure 1) for this exchange is as follows:
Interestingly, while minimization itself is sufficient to address the disclosure risk at the root and TLD levels, encryption alone isn’t. Encryption protects against disclosure to outside observers but not against disclosure to (or by) the name server itself. Even though the sensitivity of the information is relatively low for reasons noted above, without minimization, it’s still more than the name server needs to know.
Summary: Resolvers should apply minimization techniques at the root and TLD levels. Resolvers and root and TLD servers should not be required to implement DNS encryption on these exchanges.
Note that at this time, Verisign has no plans to implement DNS encryption at the root or TLD servers that the company operates. Given the availability of qname minimization, which we are encouraging resolver operators to implement, and other minimization techniques, we do not currently see DNS encryption at these levels as offering an appropriate risk / benefit tradeoff.
The resolver-to-authoritative exchanges at the SLD level and below enable DNS resolution within specific namespaces. These exchanges provide local optimization, benefiting all resolvers and all clients interacting with the included namespaces.
The information exchanged at these levels also represents the resolver’s aggregate interests, but in some cases, it may also include client-related information such as the client’s subnet. The full domain names and the client-related information, if any, are the most sensitive parts.
The decision flow for this exchange is as follows:
Summary: Resolvers and SLD servers (and below) should implement DNS encryption on their exchanges if they are sending sensitive full domain names or client-specific information. Otherwise, they should not be required to implement DNS encryption.
The client-to-resolver exchange enables navigation to all domain names for all clients of the resolver.
The information exchanged here represents the interests of each specific client. The sensitivity of this information is therefore relatively high, making confidentiality vital.
The decision process in this case traverses the first and second steps:
Summary: Clients and resolvers should implement DNS encryption on this exchange, unless the exchange is otherwise adequately protected, for instance as part of the network connection provided by an enterprise or internet service provider.
The following table summarizes the guidance for how to protect the various exchanges in the DNS resolution ecosystem.
In short, the guidance is “minimize at root and TLD, encrypt when needed elsewhere.”
| DNS Exchange | Purpose | Guidance |
|---|---|---|
| Resolver-to-Root and TLD | Global navigational availability | • Resolvers should apply minimization techniques • Resolvers and root and TLD servers should not be required to implement DNS encryption on these exchanges |
| Resolver-to-SLD and Below | Local performance optimization | • Resolvers and SLD servers (and below) should implement DNS encryption on their exchanges if they are sending sensitive full domain names, or client-specific information • Resolvers and SLD servers (and below) should not be required to implement DNS encryption otherwise |
| Client-to-Resolver | General DNS resolution | • Clients and resolvers should implement DNS encryption on this exchange, unless adequate protection is otherwise provided, e.g., as part of a network connection |
If the guidance suggested here were followed, we could expect to see more deployment of minimization techniques on resolver-to-authoritative exchanges at the root and TLD levels; more deployment of DNS encryption, when needed, at the SLD levels and lower; and more deployment of DNS encryption on client-to-resolver exchanges.
In all these deployments, the DNS will serve the same purpose as it already does in today’s unencrypted exchanges: enabling general-purpose navigation to information and resources on the internet.
DNS encryption also brings two new capabilities that make it possible for the DNS to serve two new purposes. Both are based on concepts developed in Verisign’s research program.
You can read more about these two applications in my recent blog post on this topic, Authenticated Resolution and Adaptive Resolution: Security and Navigational Enhancements to the Domain Name System.
The post A Balanced DNS Information Protection Strategy: Minimize at Root and TLD, Encrypt When Needed Elsewhere appeared first on Verisign Blog.
FreshRSS