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

How APNIC is participating

APNIC has signed its own zones (apnic.net), the reverse address zones under in-addr.arpa and ip6.arpa, and has introduced Member DNSSEC data. Members can activate DNSSEC protection to their reverse zones by updating the "ds-rdata' attribute of domain objects in the APNIC Whois Database. The value of the DS resource records from the zone file is used for the "ds-rdata" attribute. A successful update of the domain objects will result in updating the parent zone data that is stored in APNIC's name servers.

APNIC Labs measures the use of DNSSEC globally and provides DNSSEC-related research to the technical community.

APNIC Labs DNSSEC measurement

What you need to do

You can update domain objects in MyAPNIC by adding an optional attribute field "ds-rdata" to your domain object and enter your DS resource records. To update multiple domain objects, you can use the bulk update form. APNIC only supports updates of this information through the use of the MyAPNIC portal which is secured by Member certificates.

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:


0.168.192.in-addr.arpa. 86400 IN NS new.ns1.apnic.net.
0.168.192.in-addr.arpa. 86400 IN NS new.ns2.apnic.net.
0.168.192.in-addr.arpa. 86400 IN DS 33736 5 1
0.168.192.in-addr.arpa. 86400 IN DS 33736 5 2
	8713C008030EBB FD7A28FC

APNIC operational settings

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

Key sizes KSK is 2048-bit ZSK is 1024-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

DNS Root Zone KSK Rollover

Update 2 Feb 2018: ICANN postponed the DNS Root Zone KSK Rollover in September 2017. ICANN has released a new draft plan to complete the KSK rollover in October 2018.

A public comment period on the plan is open until 2 April 2018 at 23:59 UTC.

ICANN is planning to roll, or change, the 'top' pair of cryptographic keys used in the DNSSEC protocol, commonly known as the Root Zone KSK (Key Signing Key).

This will be 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 involves generating a new cryptographic key pair and distributing the new public component to all DNSSEC-validating resolvers globally.

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

Once the new keys have been generated, network operators performing DNSSEC validation will need to update their systems with the new key so that when a user attempts to visit a website, it can validate 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.

Who needs to take action?

Network operators using DNSSEC-validating resolvers must update their systems with the new KSK to help ensure trouble-free Internet access for users.

  • If your organization is performing DNSSEC validation, and your software supports automatic updates of DNSSEC trust anchors (RFC 5011) then the KSK will be updated automatically at the appropriate time. You may not need to take any additional action, however, some devices may require manual intervention.
  • If your organization is performing DNSSEC validation, and your software does not support automatic updates of DNSSEC trust anchors (RFC 5011) or is not configured to use it, then manual updates of the software’s trust anchor file will be required.

In either case, it is worth checking and testing systems prior to the KSK rollover to confirm what action will be required. ICANN is providing a free testbed for operators to help you determine whether your systems can handle automated updates correctly.

APNIC will be contacting all its Members to advise of the KSK rollover, and provide information and resources to assist Members in taking appropriate action.

Important dates

Please note the following dates will be revised once ICANN announces an approved plan to restart the KSK rollover.

The KSK rollover will occur over several months. Systems can be updated at any time after the new KSK is published.

11 July 2017 New KSK published in DNS
19 September 2017 Size increase for DNSKEY response from root name servers
11 October 2017 New KSK begins to sign the root zone key set (the actual rollover event)
11 January 2018 Revocation of old KSK
22 March 2018 Last day the old KSK appears in the root zone
August 2018 Old key is deleted from equipment in both ICANN Key Management Facilities

Learn more

Information packs


ICANN automated trust anchor update testbed
How to test if DNS validating resolvers are using the latest trust anchor (ICANN)
How to update DNS validating resolvers with the latest trust anchor (ICANN)
ICANN KSK Rollover website


2017 DNSSEC KSK Rollover, Ed Lewis (ICANN)
Rolling the Root, Geoff Huston

Other resources

APNIC Labs DNSSEC measurement

Blog articles

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.

IETF 99, Prague: IEPG — always a worthwhile conversation

IEPG has moved to a new day in the IETF agenda, but it's still a very useful conversation between the operations and engineering community.

Event Wrap: BhutanNOG 4

APNIC participated at the fourth Bhutan Network Operators Group (BhutanNOG 4) meeting on 5 June 2017.

DNSSEC, IPv6, quantum networking and more: RIPE 74 thoughts

Geoff recaps some highlights from the technical presentations at RIPE 74.

Do you have DNSSEC validation enabled?

Guest Post: Here's how you can ready your network for the DNSSEC Root Zone KSK rollover this October.

KSK Rollover Q&A with ISC’s Eddy Winstead

The Root Zone KSK rollover is coming. Are your systems ready?

Update on the Root Zone Key Signing Key Rollover

ICANN recently announced the operational plans to "roll" the Root Zone Key Signing Key, an essential part of DNSSEC.

Rolling the Root

After five years of operation, where are we with rolling over the Key Signing Key of the DNS Root Zone?

How to get help

If you need technical support, your DNS software provider is the best place to start. Below is support information for some of the popular providers.

Microsoft Windows Server

Nominum Vantio

NLnet Labs Unbound

Cz.NIC Knot Resolver

Secure64 DNS Signer

Ask a Question

Send an email to globalsupport@icann.org with "KSK Rollover" in the subject line to submit your questions.