DNSSEC Guide : Chapter 8. Commonly Asked Questions

A:

No. DNSSEC can be deployed independent of IPv6.

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.

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.

A:

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

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.

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):

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.

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.

A:

No.

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.

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.

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.

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.