ComputerSurge/bind9
3
0
Fork 0
Code Pull Requests 1 Activity

Update FAQ in the DNSSEC Guide

Browse Source 
Mention DoT/DoH, update stats, remove mentions of early stages of
deployment.
This commit is contained in:
Petr Špaček
2022-06-13 18:05:27 +02:00
parent 635885afe6
commit fd3a2c7854
1 changed files with 45 additions and 42 deletions
Download Patch File Download Diff File Expand all files Collapse all files

87
doc/dnssec-guide/commonly-asked-questions.rst
View File

@@ -14,8 +14,8 @@
Commonly Asked Questions
------------------------
No questions are too stupid to ask. Below are some common
questions you may have and (hopefully) some answers that help.
Below are some common questions and (hopefully) some answers that
help.
Do I need IPv6 to have DNSSEC?
No. DNSSEC can be deployed without IPv6.
@@ -26,64 +26,67 @@ Does DNSSEC encrypt my DNS traffic, so others cannot eavesdrop on my DNS queries
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.
For protection against eavesdropping, the preferred protocol is DNS-over-TLS.
DNS-over-HTTPS can also do the job, but it is more complex.
If I deploy DNS-over-TLS/HTTPS, can I skip deploying DNSSEC?
No. DNS-over-encrypted-transport stops eavesdroppers on a network, but it does
not protect against cache poisoning and answer manipulation in other parts
of the DNS resolution chain. In other words, these technologies offer protection
only for records when they are in transit between two machines; any
compromised server can still redirect traffic elsewhere (or simply eavesdrop).
However, DNSSEC provides integrity and authenticity for DNS
*records*, even when these records are stored in caches and on disks.
Does DNSSEC protect the communication between my laptop and my name server?
Unfortunately, not at the moment. DNSSEC is designed to protect the
communication between end clients (laptop) and name servers;
however, there are few applications or stub resolver libraries as of
mid-2020 that take advantage of this capability. While enabling DNSSEC today
does little to enhance the security of communications between a recursive
server and its clients (commonly called the "last mile"), we hope that
will change in the near future as more applications become DNSSEC-aware.
mid-2020 that take advantage of this capability.
Does DNSSEC secure zone transfers?
No. You should consider using TSIG to secure zone transfers among your
name servers.
Does DNSSEC protect my network from malicious websites?
The answer in the early stages of DNSSEC deployment is, unfortunately,
no. DNSSEC is designed to provide
confidence that when you receive a DNS response for www.company.com over
port 53, it really came from Company's name servers and the
answers are authentic. But that does not mean the web server a user visits
over port 80 or port 443 is necessarily safe. Furthermore, 98.5% of
domain name operators (as of this writing in mid-2020) have not yet signed
their zones, so DNSSEC cannot even validate their answers.
The answer for sometime in
the future is that, as more zones are signed and more
recursive servers validate, DNSSEC will make it much more
difficult for attackers to spoof DNS responses or perform cache
poisoning. It will still not protect against users who visit a malicious
website that an attacker owns and operates, or prevent users from
DNSSEC makes it much more difficult for attackers to spoof DNS responses
or perform cache poisoning. It cannot protect against users who
visit a malicious website that an attacker owns and operates, or prevent users from
mistyping a domain name; it will just become less likely that an attacker can
hijack other domain names.
In other words, DNSSEC is designed to provide confidence that when
a DNS response is received for www.company.com over port 53, it really came from
Company's name servers and the answers are authentic. But that does not mean
the web server a user visits over port 80 or port 443 is necessarily safe.
If I enable DNSSEC validation, will it break DNS lookup, since most domain names do not yet use DNSSEC?
No, DNSSEC is backwards-compatible to "standard"
DNS. As of this writing (in mid-2020), although 98.5% of the .com domains have yet to
be signed, a DNSSEC-enabled validating resolver can still look up all of
these domain names as it always has under standard DNS.
No, DNSSEC is backwards-compatible to "standard" DNS. A DNSSEC-enabled
validating resolver can still look up all of these domain names as it always
has under standard DNS.
There are four (4) categories of responses (see :rfc:`4035`):
*Secure*:
Domains that have DNSSEC deployed correctly.
*Insecure*:
Domains that have yet to deploy DNSSEC.
*Bogus*:
Domains that have deployed DNSSEC but have done it incorrectly.
*Indeterminate*:
Domains for which it is not possible to determine whether these domains use DNSSEC.
.. glossary::
A DNSSEC-enabled validating resolver still resolves #1 and #2; only #3
and #4 result in a SERVFAIL. You may already be using DNSSEC
validation without realizing it, since some ISPs have begun enabling
DNSSEC validation on their recursive name servers. Google public DNS
(8.8.8.8) also has enabled DNSSEC validation.
Secure
Domains that have DNSSEC deployed correctly.
Insecure
Domains that have yet to deploy DNSSEC.
Bogus
Domains that have deployed DNSSEC but have done it incorrectly.
Indeterminate
Domains for which it is not possible to determine whether these domains use DNSSEC.
A DNSSEC-enabled validating resolver still resolves :term:`Secure` and
:term:`Insecure`; only :term:`Bogus` and :term:`Indeterminate` result in a
SERVFAIL.
As of mid-2022, roughly one-third of users worldwide are using DNSSEC validation
on their recursive name servers. Google public DNS (8.8.8.8) also has
enabled DNSSEC validation.
Do I need to have special client software to use DNSSEC?
No. DNSSEC only changes the communication