Domain Name Authentication with DNSSEC and DANE - The Internet Protocol Journal, Volume 15, No. 1

Richard L. Barnes, BBN Technologies

Authentication of domain names is a fundamental function for Internet security. In order for applications to protect information from unauthorized disclosure, they need to make sure that the entity on the far end of a secure connection actually represents the domain that the user intended to connect to. For many years, authentication of domain names has been accomplished by having third-party Certification Authorities attest to which entities could represent a domain name. This system of external authorities, however, has recently come under heavy attack, and there have been several high-profile compromises [0]. The Domain Name System Security Extensions (DNSSEC) offer an alternative channel for distributing secure information about domain names, through the Domain Name System (DNS) itself. The DNS-based Authentication of Named Entities (DANE) working group in the Internet Engineering Task Force (IETF) has developed a new type of DNS record that allows a domain itself to sign statements about which entities are authorized to represent it. End users' applications can use these records either to augment the existing system of Certification Authorities or to create a new chain of trust, rooted in the DNS.


Without authentication, other security services are moot. There is little point in Alice's encrypting information en route to Bob if she has not first verified that she is talking to Bob and not an attacker Eve. In the context of Internet applications, authentication is about ensuring that users know whom they are talking to, and in most cases, that "whom," is represented by a domain name. For example, in the Hypertext Transfer Protocol (HTTP), the "authority" section of a Uniform Resource Identifier (URI) indicates the domain name of the server that will fulfill requests for that URI. So when an HTTP user agent starts a TCP connection to a remote server, it needs to verify that the server is actually authorized to represent that domain name [1].

The most common security protocol used by Internet applications is the Transport Layer Security (TLS) protocol [2]. TLS provides a layer above TCP that facilitates authentication of the remote side of the connection as well as encryption and integrity protection for data. TLS underlies Secure HTTP (HTTPS) and secure e-mail[1, 3, 4], and provides hop-by-hop security in real-time multimedia and instant-messaging protocols[5, 6]. In all of these applications, the server that the user ultimately wants to connect to is identified by a DNS domain name[7, 8]. A user might enter into a web browser or send an e-mail to

One of the main purposes of using TLS in these cases is thus to assure the user that the entity on the other end of the connection actually represents; in other words, to authenticate the server as a legitimate representative of the domain name. Note that these comments apply to Datagram Transport Layer Security (DTLS) as well, because it provides the same functions as TLS for User Datagram Protocol (UDP) packet flows [9].

Today, a server asserts its right to represent a domain by presenting a Public Key Infrastructure (PKIX) digital certificate containing that domain [8, 10]. A certificate is an attestation by a Certification Authority of a binding between a public key and a name—the entity holding the corresponding private key is authorized to represent that name. TLS ensures that only the holder of a given private key can read the encrypted data; the certificate ensures that the holder of the key represents the desired name.

Current TLS-based applications maintain a list of Certification Authorities whose certificates they will accept. Unfortunately, over time, these lists have grown very long, with major web browsers trusting nearly 200 Certification Authorities, representing a diverse range of organizations. Because any of these Certification Authorities can vouch for any domain name, a long list creates many points of vulnerability; a compromise at any point allows the attacker to issue certificates for any domain. Several recent attacks have taken advantage of this fact by targeting smaller Certification Authorities as a way to obtain certificates for major domains. For example, an attack through DigiNotar against Google is discussed in this issue [0].

DNSSEC offers an alternative to Certification Authorities. In the DNSSEC system, each domain holder can act as an authority for subordinate domains. The IETF DANE working group has developed a DNS record format for "certificate associations," so that domain holders can sign statements about which certificates can be used to authenticate as that domain. In effect, this scenario allows a domain to speak for itself, instead of through a third-party Certification Authority. DANE associations can be used either as a check on the current model (for example, to limit which Certification Authorities may vouch for a domain) or as an alternative trust path, rooting trust in a DNSSEC authority instead of a Certification Authority. Work on the protocol document is drawing to a close, and several prototype implementations are already in progress.

Background: PKIX and DNSSEC

At one level, the choice of which authentication technology to use is a choice of authorities and scoping. As mentioned previously, authentication is fundamental for security, but it is also very hard to accomplish scalably. For example, a web browser needs to be able to authenticate any website the user chooses to visit. It would clearly not work for each browser vendor to send a human representative to meet every website owner in order to find out what public key should be used for that website.

So instead of relying on having preestablished relationships with every entity we want to authenticate, we rely on centralized authorities to do identity checking. The authorities then create credentials that anyone else can check, so that if the credential is valid and you believe the authority is trustworthy, then the entity holding the credential has the indicated identity.

In a technical sense, an entity holds a credential if it holds the private key corresponding to the public key in the credential. The credential encodes a binding between the public key and the identity, asserted by the authority.

Authority is of course not a purely digital concept. If we want to know a person's name in real life we do not just ask them directly, because the person could lie. Instead we look to a credential issued by an authority, such as a driver’s license or birth certificate. So the technology question here is how to manage authorities, and how to encode these credentials.

The IETF has defined two major cryptographic authority systems: PKIX, based on digital certificates [10]; and DNSSEC, based on the DNS [11]. Both of these systems allow authorities to associate public keys with identities, and both arrange these authorities hierarchically.

The hierarchy is important because it allows a relying party (someone who is verifying identities) to choose whom to trust. In these hierarchical systems, an authority's identity can itself be attested by a credential issued by another authority. When a relying party wants to verify a credential issued by an authority A, he then has to verify that A's credential is valid (under an authority B), and so on until he reaches an authority that he trusts. This sequence of credentials constitutes a logical path through the hierarchy, known as a "certification path" in PKIX terminology (Figure 1).

Figure 1: PKIX and DNSSEC Trust Hierarchies

In order to be useful as a given relying party to authenticate someone, a certification path has to end in a trust anchor, that is, an authority that the relying party trusts to make assertions. In the DNSSEC context, relying parties can in principle have only one trust anchor, namely the DNS root, although alternatives to the root have been proposed [12]. The PKIX system, on the other hand, does not represent a single globally consistent hierarchy, so in order to be able to validate many certificates, relying parties often have to choose many trust anchors.

Crossing the Streams

Current TLS-based applications rely on PKIX for authentication of domain names, which has facilitated fairly broad deployment, but also created some vulnerabilities. PKIX is based on a very general digital certificate system called X.509, and because of this generality, it has no inherent binding to the DNS. This situation creates two problems when it comes to authenticating domain names.

First, unlike the DNS, which has a single global root, there is no single authority under which all PKIX certificates can be verified. Indeed, there is an open marketplace of authorities, where each entity can choose which authority will sign its certificate, leaving relying parties with a choice: Either they must trust every authority that has signed a certificate for an entity it wants to authenticate, or they will be unable to validate the identities of some entities. In general, current software has preferred the former approach of trusting many authorities, to the extent that modern browsers and operating systems will trust up to 200 authorities by default. Users can add to this list, for example, using the "Accept this certificate?" dialogs in their browsers, but it can be very difficult to remove trust anchors from the default list [13].

Second, PKIX authorities today are not constrained in the scope, so they can issue credentials for any name—even those for whom they have no real information (in contrast to the DNS—where each zone can vouch only for sub-domains; only the root can act with impunity). Conversely, there is no real way for a relying party to know what authority should be vouching for a site, so if a rogue authority were to issue a certificate to an unauthorized party, relying parties would have no way to detect it.

Given these vulnerabilities, any of the many authorities trusted within the PKIX system can attack any domain by issuing a false certificate from that domain. This false certificate can then be used to masquerade as the victim domain, for example, to perform a man-in-the-middle attack. Note that the authority itself is not necessarily the bad actor in this attack—it could be an external attacker that can obtain illicit access to the systems that issue certificates. The risks of having broadly trusted Certificatation Authorities have recently become clear, because attackers were able to break into two small Certification Authorities and create fraudulent certificates for Google and Facebook, among others [14, 15].

The goal of DANE is to address some of the vulnerabilities of the current PKIX ecosystem by allowing DNSSEC—to "cross the streams" to allow domains to publish information secured with DNSSEC that can add additional security to PKIX certificates used for TLS. For example, a domain might use DANE to inform relying parties of which authorities can be trusted, as illustrated in Figure 2.

Figure 2: Using a DANE TLS Associations (TLSA) Record to Indicate Which PKIX Authority Should Be Trusted

DANE Records

If the goal of DANE is to allow domain operators to make statements about how clients should judge TLS certificates for their domains, then what sorts of statements should DANE allow them to make? The DANE use cases document [16] lays out three major types of statements (Figure 3):

  1. CA Constraints: The client should accept only certificates issued under a specific Certificatation Authority.
  2. Service Certificate Constraints: The client should accept only a specific certificate.
  3. Trust Anchor Assertion: The client should use a domain-provided trust anchor to validate certificates for that domain.

All three of these statements can be viewed as constraining the scope of trust anchors. The first two types limit the scope of existing trust anchors, whereas the third provides the client with a new trust anchor (still within a limited scope). More on these anchors in a moment.

Figure 3: DANE Use Cases

The current draft DANE protocol defines a DNS Resource Record type TLSA for describing "TLS Associations"—statements about what certificates are "associated" to a domain [17]. Each TLSA record has three basic fields:

  • Usage: Which type of statement this record is making
  • Selector/Matching: How a TLS certificate chain should be matched against this record (for example, by exact match, by public key, or by SHA-1 digest)
  • Certificate for Association: The actual data against which the TLS certificate chain should be matched

These records are stored under the target domain with a prefix that indicates the transport and port number for the TLS server. So for example, if Alice runs a secure web service at and wants to tell clients that they should accept only certificates from the Charlie’s CA, she could provision a TLSA record under with the following contents:

  • Usage: CA constraint
  • Selector/Matching: SHA-1 digest
  • Certificate for Association: SHA-1 digest of Charlie's certificate

When a client Bob wants to connect to, he can find these TLSA records and apply Alice’s constraints when he validates the server certificate.

Adding Constraints to PKIX

The major objective of the CA constraints and service certificate constraints is to guard against "mis-issue" of certificates. A certificate is "mis-issued" when a CA issues a certificate to an entity that does not actually represent the domain name in the certificate. Mis-issue can come about in many ways, including through malicious Certification Authorities, compromised Certification Authorities (as in the Comodo and DigiNotar example discussed previously), or Certification Authorities that are simply misled as to the attacker's identity through fraud or other means. Today, mis-issue can be difficult to detect, because there is no standard way for clients to figure out which Certification Authorities are supposed to be issuing certificates for a domain. When an attacker issued false certificates for the Google Gmail service under the DigiNotar Certification Authority, it was noticed only because a vigilant user posted to a Gmail help forum. [18]

By contrast, domain operators know exactly which Certification Authorities they have requested certificates from, and, of course, which specific certificates they have received. With DANE, the domain operator can convey this information to the client. For example, to guard against the DigiNotar attack, Google could have provisioned a TLSA record expressing a Certification Authority constraint with its real Certification Authority (which is not DigiNotar) or a certificate constraint with its actual certificate. Then DANE-aware clients would have been able to immediately see that the DigiNotar certificates were improperly issued and possibly indicative of a man-in-the-middle attack.

Empowering Domain Operators

According to data from the EFF SSL Observatory, which scans the whole IPv4 address space for HTTPS servers and collects their certificates, around 48 percent of all HTTPS servers present self-signed certificates [19]. An unknown number of other servers present certificates issued under Certification Authorities that are not in the major default trust anchor lists. For example, the United States Air Force web portal uses a certificate issued under a Department of Defense Certification Authority that is not trusted by Firefox [20]. In the current environment, most clients cannot authenticate these servers at all; they have to rely on users manually checking certificates, hopefully with some out-of-band information. As a result, these servers and their users are highly vulnerable to man-in-the-middle attacks against their supposedly secure sessions.

DANE Trust Anchor Assertions enable the operators of a domain to advertise a new trust anchor, under which certificates for that domain will be issued. Using these records, clients can dynamically discover what trust anchors they should accept for a given domain, instead of relying on a static list provided by a browser or operating system.

It may seem odd to talk about a domain supplying a client with trust anchors, because trust anchor provisioning is typically a very sensitive activity. If an attacker is able to install a trust anchor into a victim's trust anchor store, then the attacker can masquerade under any name he wants by issuing certificates under that name. The PKIX working group even defined a whole protocol for managing trust anchors [21].

DANE ensures that this trust anchor provisioning is secure by applying scoping and verifying that scoping using DNSSEC. DANE trust anchor assertions are scoped to a particular domain name, so even if an attacker can introduce a false trust anchor, he can use it to spoof only a single name. Furthermore, trust anchor assertions must be DNSSEC-signed, so clients can verify that the entity providing the trust anchor represents the domain in question. Ultimately, the client still has to have a list of trust anchors configured—but they are DNSSEC trust anchors instead of PKIX trust anchors.

Of course, in principle, a client needs only one trust anchor for DNSSEC, the root zone trust anchor. Because control of the DNS root does not change very often, it makes sense for this trust anchor to be statically configured!

The ability of a domain operator to explicitly indicate a trust anchor for a domain is obviously very powerful. It may be tempting to ask whether this case is really the only use case that DANE needs, that is, whether the constraint cases mentioned previously are needed at all. The answer is that the constraint cases are useful as a way to fold in PKIX validation with external Certification Authorities in addition to domain-asserted trust anchors. Most obviously, this feature is useful in transition, when not all clients will be DANE-aware. But even in the longer term, it is possible that Certification Authorities will be able to provide added value over DANE. For example, while DANE is made to bind certificates to domain names, Certification Authorities can vouch for bindings of certificates to other things, such as the legal identity and physical location attested in Extended Validation certificates [22].

Transition Challenges

As described previously, DANE offers some valuable new security properties for TLS authentication. But as with most IETF technologies—especially security technologies—there are some challenges to be overcome and some new potential pitfalls.

The most significant constraint for DANE deployment is DNSSEC deployment. On the server side, this problem is not a significant one because DNSSEC support is spreading fairly rapidly. On the client side, it may be more difficult. Although there are DNS libraries with robust DNSSEC support, many of the major DNS Application Programming Interfaces (APIs) that applications use do not provide any information about the DNSSEC status of the results returned.

So in order to implement DANE, application developers may have to re-factor their DNS support in addition to querying for some new record types. If more sites come to rely on DANE, then this process could also draw increasing attention to the various types of intermediaries that cause DNSSEC breakage (for example, home gateways that set DNS flags improperly).

Adding DNSSEC to the TLS connection process can also add significant latency to the TLS connection process. In addition to completing the TLS handshake and certificate validation, the client has to wait for several DNS round trips and then validate the chain of DNSSEC signatures. These combined delays can add up to multiple seconds of latency in connection establishment. Especially for real-time protocols such as HTTPS, Session Initiation Protocol (SIP), or Extensible Messaging and Presence Protocol (XMPP), such delay is clearly undesirable.

One mechanism proposed to mitigate these delays is to have the server pre-fetch all of the relevant DNSSEC records, namely all of the DS, DNSKEY, and RRSIG records chaining back to the root [27]. Then the server can provide a serialized version of the DNSSEC records in the TLS handshake, saving the client the latency of the required DNS queries. The details of this mechanism, however, are still being worked out among the DANE, TLS, and PKIX working groups [23]. A prototype version is now available in the Google Chrome web browser [24].

Security Considerations

From a security perspective, the major effect of DANE is the new role that DNS operators will play in securing Internet applications. Although DNSSEC has always meant that DNS operators would have more security functions, DANE deployment will give them an explicit effect on application security, acting as arbiters of who can authenticate under a given name in TLS. Especially if services use trust anchor assertions, DNS operators will play an analogous role to the one Certification Authorities play today—a compromise in a DNS operator will allow an attacker to masquerade as a victim domain (albeit for a more limited set of domains because of DANE constraints on names). So DNS operators are likely to inherit many of the security troubles that Certification Authorities experience today and will need to strengthen their security posture accordingly.

Another more subtle risk arises from the fact that the operator of a DNS zone is not always the same as the entity that is authorized to control the contents of the zone, which we will call the "domain holder." We used the phrase "domain operator" previously because DNSSEC protects DNS information only between the operator’s name server and the client—it does not say that what is provisioned in the name server is authorized by the domain holder.

When a domain is operated by a third party, that third party is a point of vulnerability between the client and the holder of the domain. If the domain operator provides false DANE information through malice or compromise, then a client will not be able to distinguish it from genuine DANE information. To some extent, this risk is not really new; because many current Certification Authorities authenticate requests for domain certificates based on information that is under the control of the domain operator, domain operators can already influence the credentialing process. With DANE, however, the vulnerability is much easier to exploit, for example, because the DNS operator does not have to trick a third party. This vulnerability is also fundamental to protocols that rely on DNSSEC for security, and the implications for DANE are discussed in detail in the DANE use cases document [16]. The main mitigation is simply increased care on the part of domain holders to ensure that domain operators are not behaving badly.


For many years now, Internet applications have relied on assertions by third-party PKIX Certification Authorities to ensure that a server holding a particular private key was authorized to represent a domain. The promise of DANE is a more direct interaction between clients and the domains they interact with, secured by DNSSEC. In the short run, DANE can be deployed as an adjunct to the current system of certificates and authorities, adding constraints to better protect domains. In the long run, DANE will also allow domain operators to vouch for their own names.

The transition and security problems that face DANE are largely the growing pains of DNSSEC. It is not that DANE is causing these problems itself; rather, the problems arise because DANE is the first real application of DNSSEC that is expected to be widely deployed. So although it may be difficult to mitigate some of the security problems that DANE raises, and to enable more robust DNSSEC support in applications and gateways, these changes will ultimately make it simpler for applications to use DNSSEC for other purposes.

The DANE working group is making consistent progress on its deliverables, and there are already some prototype deployment tools. Their use cases document has been published as RFC 6394 [16], and the corresponding document defining the TLSA record type is starting to mature [17]. As of this writing, it is in Working Group Last Call. On the client side, a variant of DANE has already been implemented in Google Chrome; on the server side, prototype tools are available to generate DANE records and to generate "DNSSEC-stapled" certificates based on DANE records [24, 25]. There is also an early-stage command-line tool for generating and verifying TLSA records [26].


[0] Geoff Huston, "Hacking Away at Internet Security," The Internet Protocol Journal, Volume 15, No. 1, March 2012.

[1] Eric Rescorla, "HTTP Over TLS," RFC 2818, May 2000.

[2] Tim Dierks and Eric Rescorla, Editors, "The Transport Layer Security (TLS) Protocol Version 1.2," RFC 5246, August 2008.

[3] Chris Newman, "Using TLS with IMAP, POP3 and ACAP," RFC 2595, June 1999.

[4] Paul Hoffman, "SMTP Service Extension for Secure SMTP over Transport Layer Security," RFC 3207, February 2002.

[5] Jonathan Rosenberg, Henning Schulzrinne, Gonzalo Camarillo, Alan Johnston, Jon Peterson, Robert Sparks, Mark Handley, and Eve Schooler, "SIP: Session Initiation Protocol," RFC 3261, June 2002.

[6] Peter Saint-Andre, "Extensible Messaging and Presence Protocol (XMPP): Core," RFC 6120, March 2011.

[7] Paul Mockapetris, "Domain Names – Concepts and Facilities," RFC 1034, November 1987.

[8] Peter Saint-Andre and Jeff Hodges, "Representation and Veri- fication of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)," RFC 6125, March 2011.

[9] Eric Rescorla and Nagendra Modadugu, "Datagram Transport Layer Security Version 1.2," RFC 6347, January 2012.

[10] David Cooper, Stefan Santesson, Stephen Farrell, Sharon Boeyen, Russell Housley, and Tim Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile," RFC 5280, May 2008.

[11] Roy Arends, Rob Austein, Matt Larson, Dan Massey, and Scott Rose, "DNS Security Introduction and Requirements," RFC 4033, March 2005.



[16] Richard Barnes, "Use Cases and Requirements for DNS-Based Authentication of Named Entities (DANE)," RFC 6394, October 2011.

[17] Paul Hoffman and Jakob Schlyter, “Using Secure DNS to Associate Certificates with Domain Names for TLS,” Internet Draft, work in progress, draft-ietf-dane-protocol-16, February 2012.




[21] Russ Housley, Sam Ashmore, and Carl Wallace, "Trust Anchor Management Protocol (TAMP)," RFC 5934, August 2010.

[23] Adam Langley, "Serializing DNS Records with DNSSEC Authentication," Internet Draft, work in progress, July 2011, draft-agl-dane-serializechain.




[27] Wikipedia, "List of DNS record types,"

RICHARD BARNES has been with BBN Technologies since 2005. Richard is a member of BBN's Internet standards security team. In that role, he currently leads BBN's IETF standards efforts in the areas of geolocation, presence, and emergency calling. He is chair of the IETF GEOPRIV working group and a member of the IETF Security Area Directorate (SECDIR), and he is one of the program chairs of the Emergency Services Workshop. Prior to joining BBN, he was a student at the University of Virginia (United States), from which he received a B.A. and M.S. in Mathematics, with research focused on biologically based neural networks, quantum informatics, and network security. E-mail: