Login
The Domain Name System (DNS) root zone will soon be getting a new record type, called ZONEMD, to further ensure the security, stability, and resiliency of the global DNS in the face of emerging new approaches to DNS operation. While this change will be unnoticeable for the vast majority of DNS operators (such as registrars, internet service providers, and organizations), it provides a valuable additional layer of cryptographic security to ensure the reliability of root zone data.
In this blog, we’ll discuss these new proposals, as well as ZONEMD. We’ll share deployment plans, how they may affect certain users, and what DNS operators need to be aware of beforehand to ensure little-to-no disruptions.
The DNS root zone is the starting point for most domain name lookups on the internet. The root zone contains delegations to nearly 1,500 top-level domains, such as .com, .net, .org, and many others. Since its inception in 1984, various organizations known collectively as the Root Server Operators have provided the service for what we now call the Root Server System (RSS). In this system, a myriad of servers respond to approximately 80 billion root zone queries each day.
While the RSS continues to perform this function with a high degree of dependability, there are recent proposals to use the root zone in a slightly different way. These proposals create some efficiencies for DNS operators, but they also introduce new challenges.
In 2020, the Internet Engineering Task Force (IETF) published RFC 8806, titled “Running a Root Server Local to a Resolver.” Along the same lines, in 2021 the Internet Corporation for Assigned Names and Numbers (ICANN) Office of the Chief Technology Officer published OCTO-027, titled “Hyperlocal Root Zone Technical Analysis.” Both proposals share the idea that recursive name servers can receive and load the entire root zone locally and respond to root zone queries directly.
But in a scenario where the entire root zone is made available to millions of recursive name servers, a new question arises: how can consumers of zone data verify that zone content has not been modified before reaching their systems?
One might imagine that DNS Security Extensions (DNSSEC) could help. However, while the root zone is indeed signed with DNSSEC, most of the records in the zone are considered non-authoritative (i.e., all the NS and glue records) and therefore do not have signatures. What about something like a Pretty Good Privacy (PGP) signature on the root zone file? That comes with its own challenge: in PGP, the detached signature is easily separated from the data. For example, there is no way to include a PGP signature over DNS zone transfer, and there is no easy way to know which version of the zone goes with the signature.
A solution to this problem comes from RFC 8976. Led by Verisign and titled “Message Digest for DNS Zones” (known colloquially as ZONEMD), this protocol calls for a cryptographic digest of the zone data to be embedded into the zone itself. This ZONEMD record can then be signed and verified by consumers of the zone data. Here’s how it works:
Each time a zone is updated, the publisher calculates the ZONEMD record by sorting and canonicalizing all the records in the zone and providing them as input to a message digest function. Sorting and canonicalization are the same as for DNSSEC. In fact, the ZONEMD calculation can be performed at the same time the zone is signed. Digest calculation necessarily excludes the ZONEMD record itself, so the final step is to update the ZONEMD record and its signatures.
A recipient of a zone that includes a ZONEMD record repeats the same calculation and compares its calculated digest value with the published digest. If the zone is signed, then the recipient can also validate the correctness of the published digest. In this way, recipients can verify the authenticity of zone data before using it.
A number of open-source DNS software products now, or soon will, include support for ZONEMD verification. These include Unbound (version 1.13.2), NSD (version 4.3.4), Knot DNS (version 3.1.0), PowerDNS Recursor (version 4.7.0) and BIND (version 9.19).
Verisign, ICANN, and the Root Server Operators are taking steps to ensure that the addition of the ZONEMD record in no way impacts the ability of the root server system to receive zone updates and to respond to queries. As a result, most internet users are not affected by this change.
Anyone using RFC 8806, or a similar technique to load root zone data into their local resolver, is unlikely to be affected as well. Software products that implement those features should be able to fully process a zone that includes the new record type, especially for reasons described below. Once the record has been added, users can take advantage of ZONEMD verification to ensure root zone data is authentic.
Users most likely to be affected are those that receive root zone data from the internic.net servers (or some other source) and use custom software to parse the zone file. Depending on how such custom software is designed, there is a possibility that it will treat the new ZONEMD record as unexpected and lead to an error condition. Key objectives of this blog post are to raise awareness of this change, provide ample time to address software issues, and minimize the likelihood of disruptions for such users.
In 2020, Verisign asked the Root Zone Evolution Review Committee (RZERC) to consider a proposal for adding data protections to the root zone using ZONEMD. In 2021, the RZERC published its recommendations in RZERC003. One of those recommendations was for Verisign and ICANN to develop a deployment plan and make the community aware of the plan’s details. That plan is summarized in the remainder of this blog post.
One attribute of a ZONEMD record is the choice of a hash algorithm used to create the digest. RFC 8976 defines two standard hash algorithms – SHA-384 and SHA-512 – and a range of “private-use” algorithms.
Initially, the root zone’s ZONEMD record will have a private-use hash algorithm. This allows us to first include the record in the zone without anyone worrying about the validity of the digest values. Since the hash algorithm is from the private-use range, a consumer of the zone data will not know how to calculate the digest value. A similar technique, known as the “Deliberately Unvalidatable Root Zone,” was utilized when DNSSEC was added to the root zone in 2010.
After a period of more than two months, the ZONEMD record will transition to a standard hash algorithm.
SHA-384 has been selected for the initial implementation for compatibility reasons.
The developers of BIND implemented the ZONEMD protocol based on an early Internet-Draft, some time before it was published as an RFC. Unfortunately, the initial BIND implementation only accepts ZONEMD records with a digest length of 48 bytes (i.e., the SHA-384 length). Since the versions of BIND with this behavior are in widespread use today, use of the SHA-512 hash algorithm would likely lead to problems for many BIND installations, possibly including some Root Server Operators.
Distribution of the zone between the Root Zone Maintainer and Root Server Operators primarily takes place via the DNS zone transfer protocol. In this protocol, zone data is transmitted in “wire format.”
The root zone is also stored and served as a file on the internic.net FTP and web servers. Here, the zone data is in “presentation format.” The ZONEMD record will appear in these files using its native presentation format. For example:
FreshRSS . 86400 IN ZONEMD 2021101902 1 1 ( 7d016e7badfd8b9edbfb515deebe7a866bf972104fa06fec
e85402cc4ce9b69bd0cbd652cec4956a0f206998bfb34483 )Some users of zone data received from the FTP and web servers might currently be using software that does not recognize the ZONEMD presentation format. These users might experience some problems when the ZONEMD record first appears. We did consider using a generic record format; however, in consultation with ICANN, we believe that the native format is a better long-term solution.
Currently, we are targeting the initial deployment of ZONEMD in the root zone for September 13, 2023. As previously stated, the ZONEMD record will be published first with a private-use hash algorithm number. We are targeting December 6, 2023, as the date to begin using the SHA-384 hash algorithm, at which point the root zone ZONEMD record will become verifiable.
Deploying ZONEMD in the root zone helps to increase the security, stability, and resiliency of the DNS. Soon, recursive name servers that choose to serve root zone data locally will have stronger assurances as to the zone’s validity.
If you’re interested in following the ZONEMD deployment progress, please look for our announcements on the DNS Operations mailing list.
The post Adding ZONEMD Protections to the Root Zone 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.
Every few months, an important ceremony takes place. It’s not splashed all over the news, and it’s not attended by global dignitaries. It goes unnoticed by many, but its effects are felt across the globe. This ceremony helps make the internet more secure for billions of people.
This unique ceremony began in 2010 when Verisign, the Internet Corporation for Assigned Names and Numbers (ICANN), and the U.S. Department of Commerce’s National Telecommunications and Information Administration collaborated – with input from the global internet community – to deploy a technology called Domain Name System Security Extensions (DNSSEC) to the Domain Name System (DNS) root zone in a special ceremony. This wasn’t a one-off occurrence in the history of the DNS, though. Instead, these organizations developed a set of processes, procedures, and schedules that would be repeated for years to come. Today, these recurring ceremonies help ensure that the root zone is properly signed, and as a result, the DNS remains secure, stable, and resilient.
In this blog, we take the opportunity to explain these ceremonies in greater detail and describe the critical role that Verisign is honored to perform.
DNSSEC is a series of technical specifications that allow operators to build greater security into the DNS. Because the DNS was not initially designed as a secure system, DNSSEC represented an essential leap forward in securing DNS communications. Deploying DNSSEC allows operators to better protect their users, and it helps to prevent common threats such as “man-in-the-middle” attacks. DNSSEC works by using public key cryptography, which allows zone operators to cryptographically sign their zones. This allows anyone communicating with and validating a signed zone to know that their exchanges are genuine.
The root zone, like most signed zones, uses separate keys for zone signing and for key signing. The Key Signing Key (KSK) is separate from the Zone Signing Key (ZSK). However, unlike most zones, the root zone’s KSK and ZSK are operated by different organizations; ICANN serves as the KSK operator and Verisign as the ZSK operator. These separate roles for DNSSEC align naturally with ICANN as the Root Zone Manager and Verisign as the Root Zone Maintainer.
In practice, the KSK/ZSK split means that the KSK only signs the DNSSEC keys, and the ZSK signs all the other records in the zone. Signing with the KSK happens infrequently – only when the keys change. However, signing with the ZSK happens much more frequently – whenever any of the zone’s other data changes.
Something to keep in mind before we go further: remember that DNSSEC utilizes public key cryptography, in which keys have both a private and public component. The private component is used to generate signatures and must be guarded closely. The public component is used to verify signatures and can be shared openly. Good cryptographic hygiene says that these keys should be changed (or “rolled”) periodically.
In DNSSEC, changing a KSK is generally difficult, whereas changing a ZSK is relatively easy. This is especially true for the root zone where a KSK rollover requires all validating recursive name servers to update their copy of the trust anchor. Whereas the first and only KSK rollover to date happened after a period of eight years, ZSK rollovers take place every three months. Not coincidentally, this is also how often root zone key signing ceremonies take place.
The notion of holding a “ceremony” for such an esoteric technical function may seem strange, but this ceremony is very different from what most people are used to. Our common understanding of the word “ceremony” brings to mind an event with speeches and formal attire. But in this case, the meaning refers simply to the formality and ritual aspects of the event.
There are two main reasons for holding key signing ceremonies. One is to bring participants together so that everyone may transparently witness the process. Ceremony participants include ICANN staff, Verisign staff, Trusted Community Representatives (TCRs), and external auditors, plus guests on occasion.
The other important reason, of course, is to generate DNSSEC signatures. Occasionally other activities take place as well, such as generating new keys, retiring equipment, and changing TCRs. In this post, we’ll focus only on the signature generation procedures.
A month or two before each ceremony, Verisign generates a file called the Key Signing Request (KSR). This is an XML document which includes the set of public key records (both KSK and ZSK) to be signed and then used during the next calendar quarter. The KSR is securely transmitted from Verisign to the Internet Assigned Numbers Authority (IANA), which is a function of ICANN that performs root zone management. IANA securely stores the KSR until it is needed for the upcoming key signing ceremony.
Each quarter is divided into nine 10-day “slots” (for some quarters, the last slot is extended by a day or two) and the XML file contains nine key “bundles” to be signed. Each bundle, or slot, has a signature inception and expiration timestamp, such that they overlap by at least five days. The first and last slots in each quarter are used to perform ZSK rollovers. During these slots we publish two ZSKs and one KSK in the root zone.
The root zone KSK private component is held inside secure Hardware Security Modules (HSMs). These HSMs are stored inside locked safes, which in turn are kept inside locked rooms. At a key signing ceremony, the HSMs are taken out of their safes and activated for use. This all occurs according to a pre-defined script with many detailed steps, as shown in the figure below.
Also stored inside the safe is a laptop computer, its operating system on non-writable media (i.e., DVD), and a set of credentials for the TCRs, stored on smart cards and locked inside individual safe deposit boxes. Once all the necessary items are removed from the safes, the equipment can be turned on and activated.
The laptop computer is booted from its operating system DVD and the HSM is connected via Ethernet for data transfer and serial port for console logging. The TCR credentials are used to activate the HSM. Once activated, a USB thumb drive containing the KSR file is connected to the laptop and the signing program is started.
The signing program reads the KSR, validates it, and then displays information about the keys about to be signed. This includes the signature inception and expiration timestamps, and the ZSK key tag values.
Validate and Process KSR /media/KSR/KSK46/ksr-root-2022-q4-0.xml...
# Inception Expiration ZSK Tags KSK Tag(CKA_LABEL)
1 2022-10-01T00:00:00 2022-10-22T00:00:00 18733,20826
2 2022-10-11T00:00:00 2022-11-01T00:00:00 18733
3 2022-10-21T00:00:00 2022-11-11T00:00:00 18733
4 2022-10-31T00:00:00 2022-11-21T00:00:00 18733
5 2022-11-10T00:00:00 2022-12-01T00:00:00 18733
6 2022-11-20T00:00:00 2022-12-11T00:00:00 18733
7 2022-11-30T00:00:00 2022-12-21T00:00:00 18733
8 2022-12-10T00:00:00 2022-12-31T00:00:00 18733
9 2022-12-20T00:00:00 2023-01-10T00:00:00 00951,18733
...PASSED.
It also displays an SHA256 hash of the KSR file and a corresponding “PGP (Pretty Good Privacy) Word List.” The PGP Word List is a convenient and efficient way of verbally expressing hexadecimal values:
SHA256 hash of KSR:
ADCE9749F3DE4057AB680F2719B24A32B077DACA0F213AD2FB8223D5E8E7CDEC
>> ringbolt sardonic preshrunk dinosaur upset telephone crackdown Eskimo rhythm gravity artist celebrate bedlamp pioneer dogsled component ruffled inception surmount revenue artist Camelot cleanup sensation watchword Istanbul blowtorch specialist trauma truncated spindle unicorn <<
At this point, a Verisign representative comes forward to verify the KSR. The following actions then take place:
The signing program outputs a new XML document, called the Signed Key Response (SKR). This document contains signatures over the DNSKEY resource record sets in each of the nine slots. The SKR is saved to a USB thumb drive and given to a member of the Root Zone KSK Operations Security team. Usually sometime the next day, IANA securely transmits the SKR back to Verisign. Following several automatic and manual verification steps, the signature data is imported into Verisign’s root zone management system for use at the appropriate times in the next calendar quarter.
Keeping the internet’s DNS secure, stable, and resilient is a crucial aspect of Verisign’s role as the Root Zone Maintainer. We are honored to participate in the key signing ceremonies with ICANN and the TCRs and do our part to help the DNS operate as it should.
For more information on root key signing ceremonies, visit the IANA website. Visitors can watch video recordings of previous ceremonies and even sign up to witness the next ceremony live. It’s a great resource, and a unique opportunity to take part in a process that helps keep the internet safe for all.
The post Verisign’s Role in Securing the DNS Through Key Signing Ceremonies appeared first on Verisign Blog.
This blog was also published by APNIC.
With so much traffic on the global internet day after day, it’s not always easy to spot the occasional irregularity. After all, there are numerous layers of complexity that go into the serving of webpages, with multiple companies, agencies and organizations each playing a role.
That’s why when something does catch our attention, it’s important that the various entities work together to explore the cause and, more importantly, try to identify whether it’s a malicious actor at work, a glitch in the process or maybe even something entirely intentional.
That’s what occurred last year when Internet Corporation for Assigned Names and Numbers staff and contractors were analyzing names in Domain Name System queries seen at the ICANN Managed Root Server, and the analysis program ran out of memory for one of their data files. After some investigating, they found the cause to be a very large number of mysterious queries for unique names such as f863zvv1xy2qf.surgery, bp639i-3nirf.hiphop, qo35jjk419gfm.net and yyif0aijr21gn.com.
While these were queries for names in existing top-level domains, the first label consisted of 12 or 13 random-looking characters. After ICANN shared their discovery with the other root server operators, Verisign took a closer look to help understand the situation.
One of the first things we noticed was that all of these mysterious queries were of type NS and came from one autonomous system network, AS 15169, assigned to Google LLC. Additionally, we confirmed that it was occurring consistently for numerous TLDs. (See Fig. 1)
Although this phenomenon was newly uncovered, analysis of historical data showed these traffic patterns actually began in late 2019. (See Fig. 2)
Perhaps the most interesting discovery, however, was that these specific query names were not also seen at the .com and .net name servers operated by Verisign. The data in Figure 3 shows the fraction of queried names that appear at A-root and J-root and also appear on the .com and .net name servers. For second-level labels of 12 and 13 characters, this fraction is essentially zero. The graphs also show that there appears to be queries for names with second-level label lengths of 10 and 11 characters, which are also absent from the TLD data.
The final mysterious aspect to this traffic is that it deviated from our normal expectation of caching. Remember that these are queries to a root name server, which returns a referral to the delegated name servers for a TLD. For example, when a root name server receives a query for yyif0aijr21gn.com, the response is a list of the name servers that are authoritative for the .com zone. The records in this response have a time to live of two days, meaning that the recursive name server can cache and reuse this data for that amount of time.
However, in this traffic we see queries for .com domain names from AS 15169 at the rate of about 30 million per day. (See Fig. 4) It is well known that Google Public DNS has thousands of backend servers and limits TTLs to a maximum of six hours. Assuming 4,000 backend servers each cached a .com referral for six hours, we might expect about 16,000 queries over a 24-hour period. The observed count is about 2,000 times higher by this back-of-the-envelope calculation.
From our initial analysis, it was unclear if these queries represented legitimate end-user activity, though we were confident that source IP address spoofing was not involved. However, since the query names shared some similarities to those used by botnets, we could not rule out malicious activity.
These findings were presented last year at the DNS-OARC 35a virtual meeting. In the conference chat room after the talk, the missing piece of this puzzle was mentioned by a conference participant. There is a Google webpage describing its public DNS service that talks about prepending nonce (i.e., random) labels for cache misses to increase entropy. In what came to be known as “the Kaminsky Attack,” an attacker can cause a recursive name server to emit queries for names chosen by the attacker. Prepending a nonce label adds unpredictability to the queries, making it very difficult to spoof a response. Note, however, that nonce prepending only works for queries where the reply is a referral.
In addition, Google DNS has implemented a form of query name minimization (see RFC 7816 and RFC 9156). As such, if a user requests the IP address of www.example.com and Google DNS decides this warrants a query to a root name server, it takes the name, strips all labels except for the TLD and then prepends a nonce string, resulting in something like u5vmt7xanb6rf.com. A root server’s response to that query is identical to one using the original query name.
Now, we are able to explain nearly all of the mysterious aspects of this query traffic from Google. We see random second-level labels because of the nonce strings that are designed to prevent spoofing. The 12- and 13-character-long labels are most likely the result of converting a 64-bit random value into an unpadded ASCII label with encoding similar to Base32. We don’t observe the same queries at TLD name servers because of both the nonce prepending and query name minimization. The query type is always NS because of query name minimization.
With that said, there’s still one aspect that eludes explanation: the high query rate (2000x for .com) and apparent lack of caching. And so, this aspect of the mystery continues.
Even though we haven’t fully closed the books on this case, one thing is certain: without the community’s teamwork to put the pieces of the puzzle together, explanations for this strange traffic may have remained unknown today. The case of the mysterious DNS root query traffic is a perfect example of the collaboration that’s required to navigate today’s ever-changing cyber environment. We’re grateful and humbled to be part of such a dedicated community that is intent on ensuring the security, stability and resiliency of the internet, and we look forward to more productive teamwork in the future.
The post More Mysterious DNS Root Query Traffic from a Large Cloud/DNS Operator appeared first on Verisign 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.
Businesses today have many options for interacting with customers online. The findings of our independent survey of online consumers suggest that websites and branded email continue to be critical components of many businesses’ online presence, essential to supporting consumer confidence and enabling effective interaction with customers.
The quantitative study, commissioned by Verisign and conducted in December 2019 and January 2020 by 451 Research, now a part of S&P Global Market Intelligence, surveyed 5,450 online consumers across key markets in North America, Latin America, Europe and Asia to help understand their sentiments on interacting with businesses online.
The survey was designed to arm service providers and registrars with an understanding of how the resources they provide to businesses can help create trust and deliver value to their customers.
Among those surveyed, approximately two-thirds (66%) agreed that a business with its own website is more credible than one without. Likewise, a majority indicated that they would expect it to be more difficult to verify the identity of (56%), find online (55%) and contact (54%) a business that does not have its own website.
Certainly, this doesn’t suggest that businesses should abandon other online channels, such as social media and search engine efforts, to focus on a website-only approach. Instead, 64% of respondents said that a business with many points of online presence is more credible than a business with few.
Still, the study suggests that other online resources should complement, rather than replace, a small business’s own website. Respondents identified a business’s own website as being one of the most popular online methods for learning about (69%) and conducting transactions with (57%) businesses. Further, 71% of respondents reported being more likely to recommend a business with a professional website.
Taken together, these findings suggest that a website can help add credibility and drive new business.
Trust is central to the relationship between a business and customers. This may be particularly true for online transactions (95% of survey respondents said they actively make purchases online), which require consumers to trust not only that the business will deliver the product or service for which they have paid, but also that it will not misuse payment or personal information.
A branded email address may be able to help, as an overwhelming number of respondents (85%) agreed that a business with a branded email address is more credible than one that uses a free email account. Respondents were more likely to have used a business’s branded email address (67%), than the telephone (56%) or social media (40%), to communicate with a business during the prior 12 months.
For a small business, failing to be perceived as credible online could mean lost business not just today, but also in the future. A website and branded email address can help businesses add credibility and more effectively engage with consumers online.
Service providers offer a variety of website-building tools, email hosting solutions, and domain name registration services that can help businesses – whether just starting or well-established – to have a website and use a branded email.
Detailed survey results are available in 451 Research’s Black & White Paper Websites, Branded Email Remain Key to SMB Internet Services.
Verisign is a global wholesale provider of some of the world’s most recognized top-level domains, including .com and .net. For website building tools and email hosting solutions, contact a registrar. You can find a registrar here.
The post Websites, Branded Email Remain Key to SMB Internet Services 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.
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.
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.
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.
