Introduction – What is DNSSEC?

The Domain Name System (DNS) is a hierarchical and decentralized naming system that identifies hosts on IP networks.  The original specification did not emphasize protecting confidentiality, integrity, and availability of DNS zone/record data.  Not once are the words security or integrity mentioned in the original RFCs (1034 and 1035).  In the early days of the Internet, this lack of security was acceptable, but fast forward to today’s post-Kaminsky Vulnerability environment and we can see that the integrity of DNS responses is crucial.  Domain Name System Security Extensions (DNSSEC) was devised to address this lack of DNS response integrity.  DNSSEC is a set of extension specifications for securing data exchanged between authoritative DNS servers and recursive DNS servers using digital signatures based on public key cryptography.  DNSSEC provides origin authentication, authenticated denial of existence, and data integrity.  DNSSEC does not provide confidentiality or availability protections.

UltraDNS fully supports RFC-compliant DNSSEC and uses a dynamic signing methodology called on-the-fly (also referred to as inline or on-demand signing).  With on-the-fly signing, RRSIG and NSEC records are created on-demand when they are needed.  This is possible due to the use of the Elliptic Curve Digital Signature Algorithm (ECDSA), an asymmetric encryption algorithm whose keys are based on the mathematical representation of elliptic curves.  ECDSA has a much lower computation cost than older algorithms and produces shorter keys that provide the same level of security.  Current estimates are that ECDSA with a key length of 256 bits (curve P-256) has an approximate equivalent strength to RSA with a key length of 3,072 bits.  The lower computational cost of ECDSA makes on-the-fly signing possible.  This on-the-fly signing method allows UltraDNS to provide DNSSEC capabilities even for complex zones that use advanced traffic management (re: dynamic) record pools.

Easing the Implementation Burden

Once you’ve decided to implement DNSSEC, the biggest criticism is usually the implementation and maintenance burden.  Traditional Linux/BIND implementations require, configuring SSL packages, manual creation of public/private key-pairs on the command-line, and configuring Hardware Security Modules (HSM).  While ongoing maintenance involves zone signing/re-signing, key rollover, and registrar updates.  With UltraDNS on-the-fly signing, all implementation details are performed with a single button click.

The UltraDNS platform handles cryptographic package management, key generation, as well as ensuring the private key is safely stored.  Maintenance is minimized as well.  Zone Signing Keys (ZSK) are automatically rolled, and zones resigned, every 30 days.  Rolling keys is a best practice that prevents attackers from collecting enough data to perform a known plaintext attack.

Zone Signing

Signing a zone on UltraDNS is as simple as clicking the Sign button for the zone in the UltraDNS portal.  Once signed, the UltraDNS portal will display the Delegation Signer (DS) records which must be copied and uploaded to the parent domain (registrar) to complete the chain-of-trust.  Once your zone is signed, you can test the chain-of-trust with tools like dig & delv and DNSViz.  You can also use the Health Check feature in the UltraDNS portal, which automatically tests a zone for DNSSEC signing, valid DS records at the parent zone, and valid DNSSEC signatures.

UltraDNS provides the following three categories of DNSSEC signed zones:

• Signed Primary – A primary zone is a zone for which UltraDNS provides authoritative responses and is authoritative for zone data (i.e., does not obtain zone data via a zone transfer). UltraDNS signs the zone and generates keys.
• Signed Secondary – A secondary zone is a zone for which UltraDNS provides authoritative responses but requires zone transfers to obtain its zone data.  An example is a hidden-primary server that zone transfers to the UltraDNS network.  In this scenario, UltraDNS name servers are primary and authoritative from the perspective of a recursive server.  But the authoritative source of the data is the hidden-primary. UltraDNS signs the zone and generates keys as the secondary DNS server.
• Secondary Zone Transfer – A secondary zone can be signed by the primary name server, and then all zone data and DNSSEC related records (DNSKEY, RRSIG, and NSEC) will be zone transferred to UltraDNS.  This approach would be preferred over Signed Secondary only in circumstances where policy or agreements require that private key material be stored on-premise.

Types of Keys and Key Rollover

There are two types of keys associated with DNSSEC: Key Signing Key (KSK) and Zone Signing Key (ZSK).  KSKs sign the DNSKEY record set, while ZSKs sign the rest of the zone.  The keys are essentially the same, with only a single flag (Secure Entry Point) distinguishing between them.  Separate keys for these purposes are not required but are recommended to simplify operations, in particular key rollover events.  UltraDNS will generate both a KSK and a ZSK when signing zones.

Key rollover is performed differently on UltraDNS for the two types of keys:

Zone Signing Key (ZSK) rollover: The ZSK is used to sign DNS record sets (create RRSIGs) and is rolled automatically – and without customer involvement – by UltraDNS every 30 days. Vercara uses the pre-publication method for rolling the ZSK.

Key Signing Key (KSK) rollover:  The KSK is used to sign the ZSK(s) in the zone and thus signs much less data which means it requires less frequent rolling – every 365 days is recommended but not required. Vercara does not notify customers that their KSK should be rolled because whether to roll the key will depend on the customer’s internal policies and will usually be managed/tracked similarly to how SSL certificates are managed (i.e., the owner of the certificate tracks certificate expiration). Vercara uses the double-KSK method for rolling the KSK.

Conclusion

It’s been 14 years since the Kaminsky Vulnerability made apparent the threat of DNS cache poisoning, and still, DNSSEC adoption is slow (for example, only 3.3% of .com domains are signed).  DNSSEC hesitancy is due in part to competing priorities – zones using complex traffic management configurations to generate dynamic responses are not a good base for a protocol that provides signatures for static sets of records.  Furthermore, DNSSEC management can be complicated when it comes to managing multiple keys and their rollover schedules.  Getting anything wrong with DNSSEC means that you break the chain-of-trust rendering your site unavailable for validating resolvers.  The UltraDNS platform aims to increase DNSSEC adoption by supporting complex zone configurations using on-the-fly signing, making zone signing as easy as clicking a button, and automating as many aspects of key management as possible.  Stay ahead of potential threats to your DNS, and ensure you protect your DNS response data (and your brand) with DNSSEC.