1 .. Copyright (C) Internet Systems Consortium, Inc. ("ISC") 2 .. 3 .. SPDX-License-Identifier: MPL-2.0 4 .. 5 .. This Source Code Form is subject to the terms of the Mozilla Public 6 .. License, v. 2.0. If a copy of the MPL was not distributed with this 7 .. file, you can obtain one at https://mozilla.org/MPL/2.0/. 8 .. 9 .. See the COPYRIGHT file distributed with this work for additional 10 .. information regarding copyright ownership. 11 12 .. _dnssec_commonly_asked_questions: 13 14 Commonly Asked Questions 15 ------------------------ 16 17 Below are some common questions and (hopefully) some answers that 18 help. 19 20 Do I need IPv6 to have DNSSEC? 21 No. DNSSEC can be deployed without IPv6. 22 23 Does DNSSEC encrypt my DNS traffic, so others cannot eavesdrop on my DNS queries? 24 No. Although cryptographic keys and digital signatures 25 are used in DNSSEC, they only provide authenticity and integrity, not 26 privacy. Someone who sniffs network traffic can still see all the DNS 27 queries and answers in plain text; DNSSEC just makes it very difficult 28 for the eavesdropper to alter or spoof the DNS responses. 29 For protection against eavesdropping, the preferred protocol is DNS-over-TLS. 30 DNS-over-HTTPS can also do the job, but it is more complex. 31 32 If I deploy DNS-over-TLS/HTTPS, can I skip deploying DNSSEC? 33 No. DNS-over-encrypted-transport stops eavesdroppers on a network, but it does 34 not protect against cache poisoning and answer manipulation in other parts 35 of the DNS resolution chain. In other words, these technologies offer protection 36 only for records when they are in transit between two machines; any 37 compromised server can still redirect traffic elsewhere (or simply eavesdrop). 38 However, DNSSEC provides integrity and authenticity for DNS 39 *records*, even when these records are stored in caches and on disks. 40 41 Does DNSSEC protect the communication between my laptop and my name server? 42 Unfortunately, not at the moment. DNSSEC is designed to protect the 43 communication between end clients (laptop) and name servers; 44 however, there are few applications or stub resolver libraries as of 45 mid-2020 that take advantage of this capability. 46 47 Does DNSSEC secure zone transfers? 48 No. You should consider using TSIG to secure zone transfers among your 49 name servers. 50 51 Does DNSSEC protect my network from malicious websites? 52 DNSSEC makes it much more difficult for attackers to spoof DNS responses 53 or perform cache poisoning. It cannot protect against users who 54 visit a malicious website that an attacker owns and operates, or prevent users from 55 mistyping a domain name; it will just become less likely that an attacker can 56 hijack other domain names. 57 58 In other words, DNSSEC is designed to provide confidence that when 59 a DNS response is received for www.company.com over port 53, it really came from 60 Company's name servers and the answers are authentic. But that does not mean 61 the web server a user visits over port 80 or port 443 is necessarily safe. 62 63 If I enable DNSSEC validation, will it break DNS lookup, since most domain names do not yet use DNSSEC? 64 No, DNSSEC is backwards-compatible to "standard" DNS. A DNSSEC-enabled 65 validating resolver can still look up all of these domain names as it always 66 has under standard DNS. 67 68 There are four (4) categories of responses (see :rfc:`4035`): 69 70 .. glossary:: 71 72 Secure 73 Domains that have DNSSEC deployed correctly. 74 75 Insecure 76 Domains that have yet to deploy DNSSEC. 77 78 Bogus 79 Domains that have deployed DNSSEC but have done it incorrectly. 80 81 Indeterminate 82 Domains for which it is not possible to determine whether these domains use DNSSEC. 83 84 A DNSSEC-enabled validating resolver still resolves :term:`Secure` and 85 :term:`Insecure`; only :term:`Bogus` and :term:`Indeterminate` result in a 86 SERVFAIL. 87 As of mid-2022, roughly one-third of users worldwide are using DNSSEC validation 88 on their recursive name servers. Google public DNS (8.8.8.8) also has 89 enabled DNSSEC validation. 90 91 Do I need to have special client software to use DNSSEC? 92 No. DNSSEC only changes the communication 93 behavior among DNS servers, not between a DNS server (validating resolver) and 94 a client (stub resolver). With DNSSEC validation enabled on your recursive 95 server, if a domain name does not pass the checks, an error message 96 (typically SERVFAIL) is returned to clients; to most client 97 software today, it appears that the DNS query has failed or that the domain 98 name does not exist. 99 100 Since DNSSEC uses public key cryptography, do I need Public Key Infrastructure (PKI) in order to use DNSSEC? 101 No, DNSSEC does not depend on an existing PKI. Public keys are stored within 102 the DNS hierarchy; the trustworthiness of each zone is guaranteed by 103 its parent zone, all the way back to the root zone. A copy of the trust 104 anchor for the root zone is distributed with BIND 9. 105 106 Do I need to purchase SSL certificates from a Certificate Authority (CA) to use DNSSEC? 107 No. With DNSSEC, you generate and publish your own keys, and sign your own 108 data as well. There is no need to pay someone else to do it for you. 109 110 My parent zone does not support DNSSEC; can I still sign my zone? 111 Technically, yes, but you will not get 112 the full benefit of DNSSEC, as other validating resolvers are not 113 able to validate your zone data. Without the DS record(s) in your parent 114 zone, other validating resolvers treat your zone as an insecure 115 (traditional) zone, and no actual verification is carried out. 116 To the rest of the world, your zone still appears to be 117 insecure, and it will continue to be insecure until your parent zone can 118 host the DS record(s) for you and tell the rest of the world 119 that your zone is signed. 120 121 Is DNSSEC the same thing as TSIG? 122 No. TSIG is typically used 123 between primary and secondary name servers to secure zone transfers, 124 while DNSSEC secures DNS lookup by validating answers. Even if you enable 125 DNSSEC, zone transfers are still not validated; to 126 secure the communication between your primary and secondary name 127 servers, consider setting up TSIG or similar secure channels. 128 129 How are keys copied from primary to secondary server(s)? 130 DNSSEC uses public cryptography, which results in two types of keys: public and 131 private. The public keys are part of the zone data, stored as DNSKEY 132 record types. Thus the public keys are synchronized from primary to 133 secondary server(s) as part of the zone transfer. The private keys are 134 not, and should not be, stored anywhere other than secured on the primary server. 135 See :ref:`advanced_discussions_key_storage` for 136 more information on key storage options and considerations. 137 138 Can I use the same key for multiple zones? 139 Yes and no. Good security practice 140 suggests that you should use unique key pairs for each zone, just as 141 you should have different passwords for your email account, social 142 media login, and online banking credentials. On a technical level, it 143 is completely feasible to reuse a key, but multiple zones are at risk if one key 144 pair is compromised. However, if you have hundreds or thousands 145 of zones to administer, a single key pair for all might be 146 less error-prone to manage. You may choose to use the same approach as 147 with password management: use unique passwords for your bank accounts and 148 shopping sites, but use a standard password for your not-very-important 149 logins. First, categorize your zones: high-value zones (or zones that have 150 specific key rollover requirements) get their own key pairs, while other, 151 more "generic" zones can use a single key pair for easier management. Note that 152 at present (mid-2020), fully automatic signing (using the :any:`dnssec-policy` 153 clause in your :iscman:`named` configuration file) does not support reuse of keys 154 except when the same zone appears in multiple views (see next question). 155 To use the same key for multiple zones, sign your 156 zones using semi-automatic signing. Each zone wishing to use the key 157 should point to the same key directory. 158 159 How do I sign the different instances of a zone that appears in multiple views? 160 Add a :any:`dnssec-policy` statement to each :any:`zone` definition in the 161 configuration file. To avoid problems when a single computer accesses 162 different instances of the zone while information is still in its cache 163 (e.g., a laptop moving from your office to a customer site), you 164 should sign all instances with the same key. This means setting the 165 same DNSSEC policy for all instances of the zone, and making sure that the 166 key directory is the same for all instances of the zone. 167 168 Will there be any problems if I change the DNSSEC policy for a zone? 169 If you are using fully automatic signing, no. Just change the parameters in the 170 :any:`dnssec-policy` statement and reload the configuration file. :iscman:`named` 171 makes a smooth transition to the new policy, ensuring that your zone 172 remains valid at all times. 173
Indexes created Sun May 03 00:22:47 UTC 2026