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

Recursive name servers temporarily store, or cache, information learned during the name resolution process. Cache poisoning occurs when fraudulent DNS data is inserted into the cache of a recursive name server. Without DNSSEC, the server has no way to ensure the validity and accuracy of this information. When malicious information is cached on the recursive name server, the server is considered ‘poisoned’. Cache poisoning allows an attacker to redirect Internet traffic to fraudulent sites.

Malicious resolvers pose a threat because the information they host cannot be trusted nor validated. The consequence is that an attacker can redirect you to a malicious website or server.

A man-in-the-middle (MITM) attack secretly intercepts and modifies communications between two systems. The attacker can potentially modify the communication to redirect traffic to an illegitimate address or website. End users do not detect the MITM attacks and assume that they are communicating directly with their intended destination.

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 to 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 has 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.

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 an addition to the Domain Name System (DNS) protocols; it is designed to add security to the DNS to protect it from certain attacks, such as any data modification attack (e.g. cache poisoning). It is a set of extensions to DNS, which provide origin authentication of DNS data, data integrity and authenticated denial of existence.

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.

The Domain Name System Security Extensions (DNSSEC) as described in [RFC4033], [RFC4034], and [RFC4035] define new records and protocol modifications to DNS that permit security-aware resolvers to validate DNS Resource Records (RRs)

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.

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

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.

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.

DNSSEC does not provide confidentiality for data that is transmitted.

The short answer is yes, as DNSSEC and 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.

When you deploy DNSSEC on a domain name it is referred to as “signing” the domain name.  You can contact your Registrar to see if they offer DNSSEC services.

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 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 zadna.org.za is established through the keys for zadna.org.za being signed by the .org.za zone keys.  The keys for the .org.za zone are signed by the .za zone keys and the keys

for the .za 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 zadna.org.za.

A key pair contains two digital keys — a private key (held only by the organization responsible for signing data) and a public key (distributed to the public). ICANN and VeriSign each use a private / public key pair; the key pair used by VeriSign (the “zone-signing key”, or ZSK) is used to sign the zone, and the key pair used by ICANN (the “key-signing key”, or KSK) is used to provide a cryptographic chain of trust between validators and the signed root zone records. End users’ validators (or the validators at their ISPs) use the KSK public key to verify that signatures are correct and that the answers they receive in response to DNS queries are authentic.

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

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.

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.

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

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.za the DNSKEY is created, then the corresponding DS record is generated and sent to the Registry to be included in the .org.za 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 .ZA Registry Services (ZADNA) has developed a DNSSEC Practice Statement (DPS). It defines the operational procedures for the management of DNS Security Extensions (DNSSEC) in the South Africa top-level domain (.ZA) and second level domains under .ZA.

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 .ZA DPS appropriate for .ZA.

The DPS can be found here.