DNSSEC

Domain Name Security Extensions (DNSSEC) are extensions to the Domain Name System (DNS) that provide:

Authentication of the origin of DNS data
Integrity of data
Authentication of denial of existence

What is the DNS and why do we need to secure it?

The DNS is a hierarchical distributed naming system that translates easy to remember names (that are meaningful to people) into the IP numbers required for devices to network across the Internet. Likewise, it also provides the opposite (numbers to names) lookup, called Reverse DNS.

Each DNS lookup — the process of looking for web addresses using a domain name — occurs over several stages, and each stage is vulnerable to hijacking as the DNS does not include security in its native form.

DNSSEC tries to prevent someone from injecting false information into this DNS lookup by providing a set of extensions that digitally sign data so end users can be assured it is valid. Essentially, DNSSEC attests to the validity of the web address you want to visit.

How does it work?

When the DNS looks up particular information (DNS lookup), the answers are digitally signed allowing the DNS client (resolver) to check if the information is identical to the information on the authoritative name server. It provides a validation path for records and follows a chain of trust up to the root. It’s important that DNSSEC is deployed across all domains to complete the chain of trust. This ensures that outgoing Internet traffic is always sent to the correct servers. New record types were created to facilitate this:

RRSIG – Resource Record Signature
DNSKEY – DNS Public Key
DS – Delegation Signer
NSEC – Next Secure

Updating domain objects in MyAPNIC

Using the Whois template to update a single domain object

Add an optional attribute field ‘ds-rdata’ to your domain object and enter your DS resource records.

Using the Bulk update form to update multiple domain objects

Attach your plain text zone file containing your Name Server and/or DS resource records:

Example:


113.0.203.in-addr.arpa. 86400 IN NS ns1.example.com.
113.0.203.in-addr.arpa. 86400 IN NS ns2.example.com.
113.0.203.in-addr.arpa. 86400 IN DS 33736 13 2
	B1E76175EC4F7AEF17EC5DBD3BA24EA19728C96FAC
	8713C008030EBB FD7A28FC

APNIC operational settings

The following values are the operational parameters used by APNIC for its DNSSEC:

Key Algorithm	KSK is ECDSAP256SHA256 ZSK is ECDSAP256SHA256
Key sizes	KSK is 256-bit ZSK is 256-bit
Roll-over frequency	KSK – mid-May after 02:00 (UTC +10) ZSK – monthly on the 1st of the month after 02:00 (UTC +10)
Zone re-sign frequency	Daily at 00:00 (UTC +10)
Signature validity	RRSIGs are valid for 30 days

KSK rollover

DNS Root Zone KSK Rollover

ICANN rolled, or changed, the ‘top’ pair of cryptographic keys used in the DNSSEC protocol, commonly known as the Root Zone KSK (Key Signing Key) on 11 October 2018.

This was the first time the KSK has been changed since it was initially generated in 2010. It is an important security step, in much the same way that regularly changing passwords is considered good practice by any Internet user.

Changing the key involved generating a new cryptographic key pair and distributing the new public component to all DNSSEC-validating resolvers globally.

This was a significant change as every Internet query using DNSSEC depends on the root zone KSK to validate the destination.

Once the new keys were generated, network operators performing DNSSEC validation had to update their systems with the new key so that when a user attempts to visit a website, it validated it against the new KSK.

Maintaining an up-to-date KSK is essential to ensuring DNSSEC-validating DNS resolvers continue to function following the rollover.

Failure to have the current root zone KSK will mean that DNSSEC-validating DNS resolvers will be unable to resolve any DNS queries.

Key dates

The KSK rollover occurred over several months, with the key milestones noted below:

11 July 2017	New KSK published in DNS
19 September 2017	Size increase for DNSKEY response from root name servers
1 February 2018	Public comment period for plan to resume the KSK rollover began; ended 2 April 2018
23 April 2018	Staff report on the Draft Plan Comments published
13 May 2018	ICANN Board requested RSSAC, SSAC and RZERC advice on draft plan
11 October 2018	KSK rollover

Resources

Blog articles

RSS Feed

Analyzing the KSK roll

It’s time to look at the data to see what we can learn from the first roll of the root zone’s KSK.

DNS-OARC 29: KSK roll and two days of DNS internals

The 29th DNS-OARC workshop was a remarkably effective DNS meeting, with a wealth of operational experience and engagement.

Measuring the KSK Roll

APNIC Labs has been assisting with measuring how ready the Internet is for the DNS Root Zone KSK rollover.

The uncertainty of measuring the DNS

While there are a number of approaches to DNS measurement, all have their own forms of potential bias and uncertainty.

Measuring the Root Zone KSK Trust

APNIC Labs attempts to validate the proportion of resolvers reporting trust in KSK-2017 ahead of the restart of the Root Zone DNS key roll process.

Peak DNSSEC?

Since 2016, APNIC Labs has observed a drop in global DNSSEC adoption. Have we passed the point of peak use of DNSSEC?

Update on the Root KSK Rollover Project

Guest Post: ICANN has announced that it will not roll the root zone KSK in the first quarter of 2018. Read why.

Thoughts on DNS-OARC 27

Some of the highlights from DNS-OARC 27 held in San Jose from 29 September to 3 October 2017.

Not rolling the KSK

Why has the DNS Root Zone KSK roll been postponed? Geoff Huston digs into the data to explain.

IETF 99, Prague: Thoughts from the IEPG meeting

Automating DNSSEC key management and validating issues with the KSK roll where two of the many novel discussions had during the recent IEPG meeting in Prague.