DNS Tech Support Training Courses DNSSEC Consulting DNS Monitoring System Audit Customer Portal
The DNS Institute
Documentation Implementations Research DNS History Free DNS Tools

DNSSEC Guide : Chapter 8. Commonly Asked Questions

No questions are too stupid to ask, below is a collection of such questions and answers.

Q: Do I need IPv6 to have DNSSEC?
Q: Does DNSSEC encrypt my DNS traffic, so others cannot eavesdrop on my DNS queries?
Q: Does DNSSEC protect the communication between my laptop and my name server?
Q: Does DNSSEC secure zone transfers?
Q: Is DNSSEC going to protect me from malicious web sites?
Q: If I enable DNSSEC validation, will it break DNS lookup for majority of the domain names, since most domains names don't have DNSSEC yet?
Q: Do I need to have special client software to use DNSSEC?
Q: Since DNSSEC uses public key cryptography, do I need Public Key Infrastructure (PKI) in order to use DNSSEC?
Q: Do I need to purchase SSL certificates from a Certificate Authority (CA) to use DNSSEC?
Q: My parent zone does not support DNSSEC, can I still sign my zone?
Q: Is DNSSEC the same thing as TSIG that I have between my master and slave servers?
Q: How are keys copied from master to slave server(s)?

Q:

Do I need IPv6 to have DNSSEC?

A:

No. DNSSEC can be deployed independent of IPv6.

Q:

Does DNSSEC encrypt my DNS traffic, so others cannot eavesdrop on my DNS queries?

A:

No. Although cryptographic keys and digital signatures are used in DNSSEC, they only provide authenticity and integrity, not privacy. Someone who sniffs network traffic can still see all the DNS queries and answers in plain text, DNSSEC just makes it very difficult for the eavesdropper to alter or spoof the DNS responses.

Q:

Does DNSSEC protect the communication between my laptop and my name server?

A:

Unfortunately, currently, no. DNSSEC is designed to protect the communication between the end clients (laptop) and the name servers, however, there are few applications or stub resolver libraries as of late 2016 that take advantage of this capability. This communication between the recursive server to the clients are commonly called the "last mile", while enabling DNSSEC today does little to enhance the security for the last mile, we hope that will change in the near future as more and more applications become DNSSEC-aware.

Q:

Does DNSSEC secure zone transfers?

A:

No. You should consider using TSIG to secure zone transfers among your name servers.

Q:

Is DNSSEC going to protect me from malicious web sites?

A:

The answer for now is, unfortunately for early stages of DNSSEC deployment, no. DNSSEC is designed so you can have confidence that when you received the DNS response for www.isc.org over port 53, you know it really came from the ISC name servers, and the answers are authentic. But that does not mean the web server you visit over port 80 or port 443 is necessarily safe. Further more, 99% of the domain names (as of this writing) have not signed their zones yet, so DNSSEC cannot even validate their answers.

The answer for sometime in the future is, as more and more zones are signed and more and more recursive servers are validating, DNSSEC will make it much more difficult for attackers to spoof DNS responses or perform cache poisoning. It still does not protect users from visiting a malicious web site that the attacker owns and operates, or prevent users from mis-typing a domain name, it just becomes unlikely that the attacker can hijack other domain names.

Q:

If I enable DNSSEC validation, will it break DNS lookup for majority of the domain names, since most domains names don't have DNSSEC yet?

A:

No, DNSSEC is backwards compatible to "standard" DNS. As of this writing, although 99.5% of the .com domains have yet to be signed, a DNSSEC-enabled validating resolver can still lookup all of these domain names following the "old fashioned way". There are four (4) categories of responses (RFC 4035 Sec 4.3):

  1. Secure: Domains that have DNSSEC deployed correctly
  2. Insecure: Domains that have yet to deploy DNSSEC
  3. Bogus: Domains that deployed DNSSEC but did it incorrectly
  4. Indeterminate: Unable to determine whether or not to use DNSSEC

A validating resolver will still resolve #1 and #2, only #3 and #4 will result in a SERVFAIL.You may already be using DNSSEC validation without realizing it, since some ISP's have begun enabling DNSSEC validation on their recursive name servers. Google public DNS (8.8.8.8) also has enabled DNSSEC validation.

Q:

Do I need to have special client software to use DNSSEC?

A:

The short answer is no, DNSSEC only changes the communication behavior among DNS servers, not DNS server (validating resolver) and client (stub resolver). With DNSSEC validation enabled on your recursive server, if a domain name doesn't pass the checks, an error message (typically SERVFAIL) is returned to the clients, and to most client software today, it looks as if the DNS query has failed, or the domain name does not exist.

The longer answer is although you don't have to, you may want to. There are more and more client softwares that take advantage of the new DNSSEC features and give user better feedback about the domain name they are visiting. CZ.NIC Labs has created a plugin for several popular web browsers, and Mozilla has created a new web browser Bloodhound that performs DNSSEC validation.

As DNSSEC deployment becomes more common place, we are sure to see more and more software libraries and applications be updated to support its features.

Q:

Since DNSSEC uses public key cryptography, do I need Public Key Infrastructure (PKI) in order to use DNSSEC?

A:

No.

Q:

Do I need to purchase SSL certificates from a Certificate Authority (CA) to use DNSSEC?

A:

No. With DNSSEC, you generate and publish your own keys, and sign your own data as well. There is no need to pay someone else to do it for you.

Q:

My parent zone does not support DNSSEC, can I still sign my zone?

A:

Technically, yes, you can sign your zone, but you wouldn't be getting the full benefit of DNSSEC, as other validating resolvers would not be able to validate your zone data. Without the DS record(s) in your parent zone, other validating resolvers will treat your zone as an insecure (traditional) zone, thus no actual verification is carried out. The end result is, to the rest of the world, your zone still appears to be insecure, and it will continue to be insecure until your parent zone can host DS record(s) for you, effectively telling the rest of the world that your zone is signed.

An interim solution is to take advantage of DLV (DNSSEC Look-aside Validation), by submitting your key to a DLV registry such as https://dlv.isc.org/, you can still get the benefits of DNSSEC even if your parent zone is not yet supporting it.

Q:

Is DNSSEC the same thing as TSIG that I have between my master and slave servers?

A:

No. TSIG is typically used between master and slave name servers to secure zone transfers, DNSSEC secures DNS lookup by validating answers. Even if you enabled DNSSEC, zone transfers are still not validated, and if you wish to secure the communication between your master and slave name servers, you should consider setting up TSIG or similar secure channels.

Q:

How are keys copied from master to slave server(s)?

A:

DNSSEC uses public cryptography, which results in two types of keys: public and private. The public keys are part of the zone data, stored as DNSKEY record types. Thus the public keys are synchronized from master to slave server(s) as part of the zone transfer. The private keys do not, and should not be stored anywhere else but the master server in a secured fashion. See the section called “Key Storage” for more information on key storage options and considerations.


Contact Us | About | Site Map |  Gab |  Twitter