Domain Name System Security Extensions (DNSSEC)

The Domain Name System (DNS) is like the white pages for the Internet – mapping the Internet Protocol (IP) addresses to domain names that are easy to read.

For example the domain name for this website is www.dnc.org.nz, and the website is located on a computer server that has the IP address 202.78.240.52.  It is the DNS that translates that domain name into the IP address, so that your browser can find the location of the server to request the website you want to view.

The DNS was designed early in the history of the Internet and was not designed with security in mind.  Vulnerabilities exist in the DNS that can be exploited allowing attackers to intercept, re-direct, or modify your Internet traffic. 

DNSSEC was developed in response to these vulnerabilities.

A DNS Operator could be the Registrar for your domain, a Registrar who does not manage your domain, a hosting provider, an ISP, or some other third party that offers DNS management services.

Registrants can elect to operate their own domain name system or they can delegate this responsibility to a third party called a ‘DNS Operator’. A DNS Operator could be the Registrar for the domain, a Registrar who does not manage the domain, a hosting provider, an ISP, or some other third party that offers DNS management services.

It is important for the implementation of DNSSEC that there is a mechanism to encourage the cooperation and participation of DNS Operators, given the lack of a legal relationship between DNCL and non-Registrar DNS Operators. 

DNCL has established a contact repository of DNS Operators who offer DNSSEC services. The contact details of DNS Operators who provide them to DNCL will be made available to Registrars and other DNS Operators upon request. DNS Operators can email DNCL ([email protected]) with their details to be included in the contact repository. 

The Domain Name System Security Extensions (DNSSEC) have been developed to improve the security of the Domain Name System (DNS) and provide increased protection for activities such as browsing the Internet and email.  DNSSEC is in the process of being rolled out internationally.

DNSSEC ensures that the website displayed on your computer really is the genuine website that you intended to visit.  It works, in simple terms, by using encoded “keys”, similar to passwords, that your web browser looks up in the DNS to verify that you are viewing the genuine website.

The Internet’s root zone was signed in 2010, and increasing numbers of Country Code Top Level Domains (ccTLDs) and Generic Top Level Domains (gTLDs) are now being signed.

.nz, a ccTLD, has signed .nz and all of the second level domains such as .co.nz, .govt.nz and .org.nz.

Registrants can now decide whether they wish to deploy DNSSEC for their domain names to provide these assurances to visitors to their site.

DNSSEC uses public key cryptography to digitally sign DNS data. DNSSEC-capable resolvers are able to verify whether the data contained in a DNS response comes from an authoritative DNS server and whether it has been altered.

DNSSEC has been developed to provide authentication and integrity to the DNS to mitigate threats (listed below) , while ensuring that backwards compatibility is maintained.  

Origin Authentication and Data Integrity

DNSSEC-capable resolvers are able to digitally verify that the DNS data they receive is identical to the information on the authoritative DNSSEC-capable name server.  This is done by authenticating the origin and integrity of DNS data as it transits the Internet.

Authenticated denial of existence

DNSSEC-capable resolvers are able to determine whether or not a resource, such as a name server, actually exists.

One example of the benefits that DNSSEC provides is that owners of websites and email servers that have implemented DNSSEC, will have a higher degree of certainty that visitors to their website and emails destined for their email servers, will not be redirected elsewhere.

While every website could benefit from implementing DNSSEC the priority should be for those websites that are concerned about the integrity of their domain name, such as those that process financial and personally identifiable information, and sites that are at a higher risk for malicious activity.

When you deploy DNSSEC on a domain name it is referred to as “signing” the domain name. You can contact your .nz Registrar to see if they offer DNSSEC services, or you could contact a third party DNS Operator who may offer DNSSEC services. You should be aware that the Domain Name Commission does not have any formal relationships with DNS Operators who are not .nz Authorised Registrars. Therefore the DNC cannot mandate their cooperation and participation in the management of DNSSEC signed domain names.

DNSSEC does not provide confidentiality for data that is transmitted. 

The short answer is yes, as DNSSEC and Secure Socket Layer (SSL) provide different types of protection.  SSL aims to provide data confidentiality by encrypting the connection between websites and the web browsers of its visitors.  DNSSEC provides Origin Authentication of DNS data, Data Integrity, and Authenticated Denial of Existence.

DNSSEC uses cryptographic ‘keys’ to to verify whether the data contained in a DNS response comes from an authoritative DNS server and whether it has been altered.

Registrants or DNS Operators need to store the public part of a cryptographic key in a DNS Resource Record, called a DNSKEY, in the zonefile for the domain.  To enable the DNSKEY to be authenticated, a DS (Delegation Signer) Record needs to be generated and added to the .nz Registry.  Only DNSSEC capable Registrars can add this information to the Registry.

Registrars who are able to handle and process DNSKEYs and DS Records are listed on the .nz Authorised Registrars list.

ISPs often provide caching recursive DNS services (DNS resolvers) for a large number of their customers. As a result ISPs are a crucial step in ensuring that the chains of trust created by DNSSEC are actually used. This is known as DNSSEC validation. The most important benefit of DNSSEC validation is that it protects users effectively against forged DNS responses.

The technology surrounding DNSSEC validation is mature and ISPs are encouraged to deploy DNSSEC validation on their DNS resolvers. Experiences and comments from some ISPs in NZ that have enabled DNSSEC validation can be found here /content/Firsthand_experiences_with_DNSSEC.pdf.

The process of updating of DNSSEC keys is referred to as rolling the keys, or a key rollover.

The cost of deploying DNSSEC validation is usually low to very low, DNSSEC functionality has been standard in DNS resolvers for some time. A white paper on DNSSEC deplyoment (covering BIND, Unbound and Microsoft Wndows Server 2012) is available here:
http://www.internetsociety.org/deploy360/resources/deploying-dnssec-validation-on-recursive-caching-name-servers/

DNSSEC related policy can be found in the following .nz policy:

• .nz Operations and Procedures Policy

The following is a summary of the DNSSEC elements contained within the .nz Policies. 

.nz Operations and Procedures Policy

The .nz DNSSEC policy is found in the Operations and Procedures Policy.

When registering a new domain name the registrar will supply the following data:

• Domain name
• Name server list (Optional)
• Registrant Name
• Registrant contact details
• Registrant Customer ID (Optional)
• Administrative contact details
• Technical contact details
• Billing term

and, if applicable:

• DS Record List.

Registrars will be required to maintain the details of the domain names for which they are the registrar.  They will be able to amend/update the following fields:

• Name Server List
• Registrant Name
• Registrant Contact Details
• Registrant Customer ID
• Administrative Contact Details
• Technical Contact Details
• Billing Term
• DS Record List

In relation to managing DNSSEC signed domain names, Registrants, or their DNS Operator, will be responsible for:

• generating and managing their keys;
• generating the DS Records; and
• determining how often they perform key rollovers.

When a Registrant elects to un-sign a DNSSEC signed name, the Registrar will remove the DS Records for that name as soon as it is practical to do so.

Name Server Updates

Registrants can elect to operate their own domain name system or they can delegate this responsibility to a third party called a ‘DNS Operator’.  The DNS Operator could be the Registrar for the domain, a Registrar who does not manage the domain, a hosting provider, an ISP, or some other third party that offers DNS management services.

When a change of DNS Operator for a signed domain name is required and both the current and proposed DNS Operators are Registrars, then the cooperation and participation set out in 9.3 is required.

Domain Names with DNSSEC enabled

Prior to a name server update, the losing DNS Operator must provide the zone information for the domain name when requested to do so, and accept and add the new DNSKEY to the zone for the domain name, re-sign it and continue to serve this until they are notified the change is complete.

The gaining DNS Operator then provides the new DS Record to the losing DNS Operator who provides it to the Registry.  The name servers for the domain name can then be updated with the Registry.

Following the name server update, the gaining DNS Operator must delete the old DS Record and DNSKEY provided by the losing DNS Operator.

The losing DNS Operator must remove the domain name from their name servers when requested, but must not remove it before being requested to do so.

The DNC will establish and maintain a contact repository of DNS Operators who offer DNSSEC services.

DNSSEC works in a chain, and each part of the chain must be signed for the whole signature to be valid. DNS Resolvers need to be able to fetch the public key and verify that it can be trusted. 

The public key to validate a domain name’s data can be obtained from the domain name’s authoritative servers. To establish the trust on a key, you can get a copy through an offline trusted channel or use a ‘Chain of Trust’. 

A ‘Link of Trust’ is established between a child zone and its parent. The child zone provides a digest of the keys, known as a Delegation Signer (DS) Record, to the parent and the parent validates and signs it, using its own key. The step is repeated up the hierarchy creating a ‘Chain of Trust’ that can be followed.

For example the Chain of Trust for dnc.org.nz is established through the keys for dnc.org.nz being signed by the .org.nz zone keys. The keys for the .org.nz zone are signed by the .nz zone keys and the keys for the .nz zone are signed by the keys for the root '.' (dot) zone. This forms the Chain of Trust that can be ‘walked’ from the DNS root zone down to dnc.org.nz.

This status identifies those Registrars who have the capability to update the SRS with DS Records.

The status ‘Handles DS Records’ status identifies those Registrars who have the capability to update the SRS with DS Records.

Organisations that wish to apply for the ‘Handles DS Records’ status will need to confirm that their organisation:

• Accepts all IANA-accepted code points for DS’s or DNSKEY’s, and if accepting DNSKEY’s will produce valid DS records.
• Has the ability to delete, modify and add DS records (either provided directly or derived from DNSKEY).
  The application form can be found here.

DNCL will review the applications on a case-by-case basis and may ask for evidence supporting the following affirmations before making a decision.

This status identifies Registrars that meet a higher level of service, offering DNSSEC services in the .nz space.  The Domain Name Commission recommends that Registrants looking to deploy DNSSEC look for Registrars who are DNSSEC Friendly. 

The Authorised Registrars page identifies various capabilities of Registrars such as those who meet the criteria to be deemed ‘IDN Friendly’, and those who can provide IPv6 registrations. 

DNSSEC Friendly identifies Registrar’s that meet a higher level of service relative to offering DNSSEC services in the .nz space.  The Domain Name Commission recommends that Registrants looking to deploy DNSSEC look for Registrars who are DNSSEC Friendly. 

In addition to adhering to the DNSSEC related clauses in the .nz policies, Registrars who wish to apply for ‘DNSSEC Friendly’ status must also confirm the following:

A. I confirm that my organisation’s staff have been trained in DNSSEC fundamentals and their operation.

B. I confirm that my organisation has adequate information housed on our website which explains the benefits and basics of DNSSEC. 

C. I confirm that my organisation’s website will include the following information:

Key Policy

• Key length and algorithm used
• Key rollover period
• Whether a common key is used across multiple customers or a single key per customer

Key Protection

• State whether online/offline signing of keys is performed
• State how keys are backed up
• State how keys are handled (HSM, no HSM, or hardened host)

D. I confirm that Registrants will have the option to be notified when a new DS record is being introduced (as part of KSK rollover).

Organisations that wish to apply for the ‘DNSSEC Friendly’ status will need to complete the DNSSEC Status Application Form.  A DNS Security FAQ for Registrants has been prepared and a copy can be downloaded here. .nz Registrars are permitted to reuse the content in this FAQ.

DNCL will review the applications on a case-by-case basis and may ask for evidence supporting the following affirmations before making a decision.

The Domain Name Commission's website has a list of all Authorised .nz Registrars. The list shows which registrars offer DNSSEC and which are 'DNSSEC Friendly'.

This is where a DNS name server is manipulated into accepting and storing false data that is not from a trusted DNS source, and reissues that false data. 

One way this is used by attackers is to modify the IP address for a website, so that visitors to that website are unknowingly redirected to a fraudulent destination selected by the attacker.  For example, criminals may redirect users to a fake banking website. They can then harvest all of the usernames and passwords entered on the fake website, and use them on the legitimate website to withdraw funds.

A resolver is the client-side or local part of the DNS, and initiate DNS queries to lookup the IP address of a given resource, such as website.  As the DNS is a hierarchical system many DNS Servers can be involved in the lookup and DNS servers in the chain can also act as resolvers as they pass along the lookup request. 

Malicious resolvers provide fraudulent DNS responses in an attempt to redirect your Internet traffic to a fraudulent destination or website.

This is where an attacker is able to redirect, intercept, and modify network traffic.  Because DNS does not provide any data integrity checks an attacker can intercept, and modify, legitimate DNS requests or responses.  This can also result in an attacker redirecting you to a fraudulent destination of their choosing.

Even a single compromised DNS name server can have a large scale impact because one DNS server can serve many thousands of DNS requests.

The following scenario illustrates how vulnerabilities in the DNS are being exploited by miscreants and how DNSSEC mitigates those threats.

The goal of the attacker is to redirect the customers of a banking website to a fraudulent website, under the attacker’s control, to harvest customer’s credentials.  In the following scenario neither the target bank nor ISP have implemented DNSSEC.

• The attacker sets up a fake banking website that looks identical to a legitimate bank’s website.
• The attacker then inserts fraudulent data into an ISP’s DNS servers, with the IP address for their fake website. 
• When any customers of the targeted ISP enter the website address for the targeted bank into their browser, the ISP’s DNS server provides the customer with the fraudulent IP address, redirecting their customers to the attacker’s website.
• When the customers log into the fraudulent website their usernames and passwords are captured and recorded by the attacker.
• The attacker then uses those credentials to log into the targeted bank’s website, masquerading as a legitimate user, and transfers funds to an account they control.

In this scenario if either the bank or the ISP had implemented DNSSEC then the ISP’s customers may not have ended up being redirected to the attacker’s fraudulent website.

• If the bank had implemented DNSSEC, the customer’s computer may have detected the fraudulent IP address when it attempted to validate the response from the ISP’s DNS server. 
• If the ISP had implemented DNSSEC then the ISP’s caching server would have rejected the attempt to poison its cache. 

Two real world examples similar to the example above can be found here:

• Brazilian Bank Bandesco
• Irish ISP Eircom

NZRS has also provided this information regarding the requirements for DS records:

/content/DNSSEC_Requirements_for_DS Records.pdf

DNSSEC introduces the following new DNS records: DNSKEY, DS, RRSIG, NSEC and NSEC3. 

The DNSKEY record contains the public part of a cryptographic key used to sign records in a zone.  It usually lives within the zone for a domain name. 

The DS record contains a cryptographic digest, a unique digital representation or ‘fingerprint’, of a zone’s DNSKEY and is included in the parent zone.  In the case of a domain under .org.nz the DNSKEY is created, then the corresponding DS record is generated and sent to the Registry to be included in the .org.nz zone.

The RRSIG records contain the cryptographic signatures for the DNS data. The NSEC and NSEC3 records are used to provide Authenticated Denial of Existence.

DNSSEC Practice Statement

The .nz Registry Services (NZRS) has developed a DNSSEC Practice Statement (DPS). It defines the operational procedures for the management of DNS Security Extensions (DNSSEC) in the New Zealand top-level domain (.nz) and second level domains under .nz.

It draws on the Internet Engineering Task Force (IETF) I-D for DNSSEC Practices Statement construction, but has a number of significant differences to keep the .nz DPS appropriate for .nz. 

The DPS can be found here.

DNSSEC Related Specifications

The following is a list of RFCs that define the current version of DNSSEC, and are provided for further reading:

• RFC 4033 - DNS Security Introduction and Requirements
• RFC 4034 - Resource Records for the DNS Security Extensions
• RFC 4035 - Protocol Modifications for the DNS Security Extensions
• RFC 4641 - DNSSEC Operational Practices
• RFC 5155 - DNS Security (DNSSEC) Hashed Authenticated Denial of Existence

External Resources

There are many DNSSEC guides, how to documents, and websites on the Internet. The following is a list of some Key Management resources that are suggested for further reading:

• DNSSEC Key Maintenance
• DNSSEC Key Management and Rollover 
• Running OpenDNSSEC with 50000 zones

NZRS has also provided this information regarding the requirements for DS records here.

Vulnerabilities in the DNS are being actively exploited by attackers. These attacks are often undetectable to users. The attacks, which DNSSEC addresses, can be categorised into the following:

• DNS Spoofing (malicious cache poisoning)
• Malicious Resolvers
• Man in the Middle (MITM) Attacks

The Internet Society (ISOC) have produced this factsheet and basics page for more information.

ISOC have also produced more technical advice for Registrants.