Announcing OCI Public DNS support for DNSSEC

We’re excited to announce domain name system security extensions (DNSSEC) support for the Oracle Cloud Infrastructure (OCI) Public DNS service. The OCI Public DNS service and DNSSEC are available in all OCI commercial regions globally. DNSSEC is cryptographically designed to validate DNS responses on the public internet. DNSSEC on OCI is optional, utilizes inline signing of DNS responses for increased ease of use and decreased complexity, and is provided free of charge. 

Benefits of DNSSEC

DNSSEC is an industry standard that uses public key cryptography to validate the authenticity and integrity of DNS responses on the public internet. DNSSEC also allows an organization to cryptographically assert the nonexistence of a DNS record. All organizations with public DNS domains in DNSSEC-enabled top level domains, such as “com,” can use DNSSEC. When enabled, DNSSEC facilitates authentic DNS responses as described by the domain’s owner, and that they haven’t been modified as they transited the network. This is designed to eliminate the effects of common attacks against the DNS, including cache poisoning and alteration of DNS responses by a man in the middle.

In a DNS cache poisoning attack, as shown in the following figure, an attacker looks to place malicious entries in a DNS server’s cache. These malicious DNS entries redirect a website or applications traffic towards an attacker-controlled destination. For this attack to succeed, the attacker sends a DNS query to the targeted DNS server (step 1) with the expectation that the targeted server must perform recursion to satisfy the query. Recursion requires the targeted server to send its own DNS queries to other DNS servers (step 2). During the attack, the attacker floods the targeted server with DNS responses that provide malicious responses to the targeted server’s DNS query (step 3). If one of those fraudulent responses matches the required parameters of the DNS server’s query and arrives before the real response, the attacker has succeeded, and the targeted server places the fraudulent data in its cache (step 4). While the fraudulent DNS response is cached, the targeted server provides the attacker-supplied data in response to DNS queries from other DNS clients. 

DNSSEC mitigates this attack because the targeted server would refuse to accept the malicious DNS response from the attacker because it lacks a valid DNSSEC RRSIG record. This record prevents malicious data from entering the cache where it can affect other users. 

Introduction to DNSSEC on OCI

To validate DNSSEC-signed DNS responses, the trust presented by DNSSEC can’t be isolated to a zone and instead must extend from some mutually trusted location. In the case of DNSSEC, that mutually trusted location, known as the trust anchor, is the DNS root. Every zone above the zone you want to enable DNSSEC for must itself be DNSSEC-enabled and therefore include the ability to sign DNS responses with DNSSEC.

For example, to enable DNSSEC on my zone tim-at-oracle.com, the “com” zone and the root zone (.) must all support DNSSEC. Support for DNSSEC is present in many top-level domains at many DNS domain registrars. However, if you’re unsure that support exists for your domain, consult your DNS domain registrar to confirm support.

The public key cryptography involved in DNSSEC for a zone uses one or two pairs of public and private keys. While you can use a single key pair with DNSSEC, DNSSEC on OCI always uses two key pairs, known as the key signing key (KSK) and zone signing key (ZSK). The KSK is cryptographically signs the ZSK for a zone, and the ZSK to signs the individual resource record sets (RRSETs) within a zone. With DNSSEC in OCI, OCI creates the KSK, but the customer manages it, and the ZSK is entirely created and managed by OCI. A new DNS record type, the DS record, is used to link a parent zone to a child zone.

Visualizing the DNSSEC keys and their uses can be helpful. The following image shows the KSKs, ZSKs, and DS records from the DNS root zone through to our example zone, tim-at-oracle.com. 

DNSSEC delivers its goals by distributing the cryptographic keys, key digests, and signatures required in DNS itself in the form of new DNS record types. We added the following new DNS record types added to support DNSSEC:

• DS: These records are added at your DNS domain registrar or other parent zone and contain the cryptographic digest of your KSK. Just as the name server (NS) records added in your domain’s parent zone “glue” the DNS together, DS records help connect the chain of trust from the trust anchor at the root of the DNS into your zone.
• DNSKEY: These records store the public key from the KSK and ZSK within your zone. The KSK public key in these records is cryptographically self-signed, and the ZSK public key is signed by the KSK. 
• RRSIG: These records contain the signature for a given RRSET. An RRSET is the set of DNS records with the same type, such as records, and name, such as www.tim-at-oracle.com.
• NSEC and NSEC3: These records assert the nonexistence of a DNS record. Because these records are sent with an RRSIG, that nonexistence is cryptographically assured. 

DNSSEC benefits a client on the internet in two primary ways. First, the DNS stub resolver—essentially the DNS client—on each computer can do the heavy lifting itself. It sends the DNS queries required to gather public keys from DS and DNSKEY records and verify the related signatures in the many DNS responses. If the signatures are valid, it uses the DNS information received, such as the IP address from www.tim-at-oracle.com. If the information received doesn’t DNSSEC validate correctly, the information is rejected and not used. This option is ultimately the most option, but also the most complex because it requires you to select, install, and configure a DNSSEC validating stub resolver. 

Alternatively, DNS stub resolvers can rely on their DNS server to do the work of DNSSEC for them. In this case, clients defer DNSSEC validation to the DNS server at their internet service provider (ISP) or employer. In this model, with the help of a stub resolver client, the recursive DNS server by validates the DNSSEC information available. If a DNS response it received was altered or otherwise invalid against DNSSEC, the recursive server returns a Server Failed (SERVFAIL) error to the client. Many home internet users in the US already, transparently use this system. Most of the time, you explore this approach to gain the security benefits of DNSSEC.

Conclusion

DNSSEC is designed to authenticate the integrity of DNS data on the public internet. This features are important for all DNS zones, but they’re critical for financial applications, healthcare systems, government systems, and other systems that are desirable targets for attackers. In some cases, such as DNS zones for government systems, DNSSEC might be required for regulatory compliance. With the release of DNSSEC for OCI Public DNS you can now mitigate the threats of cache poisoning and man-in-the-middle attacks against DNS for your public zones hosted in OCI.

For more information on enabling DNSSEC in Oracle Cloud Infrastructure, visit our documentation.