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_guide_introduction: 13 14Introduction 15------------ 16 17.. _who_should_read: 18 19Who Should Read this Guide? 20~~~~~~~~~~~~~~~~~~~~~~~~~~~ 21 22This guide is intended as an introduction to DNSSEC for the DNS 23administrator who is already comfortable working with the existing BIND and DNS 24infrastructure. He or she might be curious about DNSSEC, but may not have had the 25time to investigate DNSSEC, to learn whether DNSSEC should 26be a part of his or her environment, and understand what it means to deploy it in the 27field. 28 29This guide provides basic information on how to configure DNSSEC using 30BIND 9.16.9 or later. Most of the information and examples in this guide also 31apply to versions of BIND later than 9.9.0, but some of the key features described here 32were only introduced in version 9.16.9. Readers are assumed to have basic 33working knowledge of the Domain Name System (DNS) and related network 34infrastructure, such as concepts of TCP/IP. In-depth knowledge of DNS and 35TCP/IP is not required. The guide assumes no prior knowledge of DNSSEC or 36related technology such as public key cryptography. 37 38.. _who_should_not_read: 39 40Who May Not Want to Read this Guide? 41~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 42 43If you are already operating a DNSSEC-signed zone, you may not learn 44much from the first half of this document, and you may want to start with 45:ref:`dnssec_advanced_discussions`. If you want to 46learn about details of the protocol extension, such as data fields and flags, 47or the new record types, this document can help you get started but it 48does not include all the technical details. 49 50If you are experienced in DNSSEC, you 51may find some of the concepts in this document to be overly simplified for 52your taste, and some details are intentionally omitted at times for ease of 53illustration. 54 55If you administer a large or complex BIND environment, this 56guide may not provide enough information for you, as it is intended to provide 57only basic, generic working examples. 58 59If you are a top-level domain (TLD) operator, or 60administer zones under signed TLDs, this guide can 61help you get started, but it does not provide enough details to serve all of your 62needs. 63 64If your DNS environment uses DNS products other than (or in addition to) 65BIND, this document may provide some background or overlapping information, but you 66should check each product's vendor documentation for specifics. 67 68Finally, deploying 69DNSSEC on internal or private networks is not covered in this document, with the 70exception of a brief discussion in :ref:`dnssec_on_private_networks`. 71 72.. _what_is_dnssec: 73 74What is DNSSEC? 75~~~~~~~~~~~~~~~ 76 77The Domain Name System (DNS) was designed in a day and age when the 78Internet was a friendly and trusting place. The protocol itself provides 79little protection against malicious or forged answers. DNS Security 80Extensions (DNSSEC) addresses this need, by adding digital signatures 81into DNS data so that each DNS response can be verified for integrity 82(the answer did not change during transit) and authenticity (the data 83came from the true source, not an impostor). In the ideal world, when 84DNSSEC is fully deployed, every single DNS answer can be validated and 85trusted. 86 87DNSSEC does not provide a secure tunnel; it does not encrypt or hide DNS 88data. It operates independently of an existing Public Key Infrastructure 89(PKI). It does not need SSL certificates or shared secrets. It was 90designed with backwards compatibility in mind, and can be deployed 91without impacting "old" unsecured domain names. 92 93DNSSEC is deployed on the three major components of the DNS 94infrastructure: 95 96- *Recursive Servers*: People use recursive servers to lookup external 97 domain names such as ``www.example.com``. Operators of recursive servers 98 need to enable DNSSEC validation. With validation enabled, recursive 99 servers carry out additional tasks on each DNS response they 100 receive to ensure its authenticity. 101 102- *Authoritative Servers*: People who publish DNS data on their name 103 servers need to sign that data. This entails creating additional 104 resource records, and publishing them to parent domains where 105 necessary. With DNSSEC enabled, authoritative servers respond to 106 queries with additional DNS data, such as digital signatures and 107 keys, in addition to the standard answers. 108 109- *Applications*: This component lives on every client machine, from web 110 servers to smart phones. This includes resolver libraries on different 111 operating systems, and applications such as web browsers. 112 113In this guide, we focus on the first two components, Recursive 114Servers and Authoritative Servers, and only lightly touch on the third 115component. We look at how DNSSEC works, how to configure a 116validating resolver, how to sign DNS zone data, and other operational 117tasks and considerations. 118 119.. _what_does_dnssec_add_to_dns: 120 121What Does DNSSEC Add to DNS? 122~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 123 124.. note:: 125 126 Public Key Cryptography works on the concept of a pair of keys: one 127 made available to the world publicly, and one kept in secrecy 128 privately. Not surprisingly, they are known as a public key and a private 129 key. If you are not familiar with the concept, think of it as a 130 cleverly designed lock, where one key locks and one key unlocks. In 131 DNSSEC, we give out the unlocking public key to the rest of the 132 world, while keeping the locking key private. To learn how this is 133 used to secure DNS messages, see :ref:`how_are_answers_verified`. 134 135DNSSEC introduces eight new resource record types: 136 137- RRSIG (digital resource record signature) 138 139- DNSKEY (public key) 140 141- DS (parent-child) 142 143- NSEC (proof of nonexistence) 144 145- NSEC3 (proof of nonexistence) 146 147- NSEC3PARAM (proof of nonexistence) 148 149- CDS (child-parent signaling) 150 151- CDNSKEY (child-parent signaling) 152 153This guide does not go deep into the anatomy of each resource record 154type; the details are left for the reader to research and explore. 155Below is a short introduction on each of the new record types: 156 157- *RRSIG*: With DNSSEC enabled, just about every DNS answer (A, PTR, 158 MX, SOA, DNSKEY, etc.) comes with at least one resource 159 record signature, or RRSIG. These signatures are used by recursive name 160 servers, also known as validating resolvers, to verify the answers 161 received. To learn how digital signatures are generated and used, see 162 :ref:`how_are_answers_verified`. 163 164- *DNSKEY*: DNSSEC relies on public-key cryptography for data 165 authenticity and integrity. There are several keys used in DNSSEC, 166 some private, some public. The public keys are published to the world 167 as part of the zone data, and they are stored in the DNSKEY record 168 type. 169 170 In general, keys in DNSSEC are used for one or both of the following 171 roles: as a Zone Signing Key (ZSK), used to protect all zone data; or 172 as a Key Signing Key (KSK), used to protect the zone's keys. A key 173 that is used for both roles is referred to as a Combined Signing Key 174 (CSK). We talk about keys in more detail in 175 :ref:`advanced_discussions_key_generation`. 176 177- *DS*: One of the critical components of DNSSEC is that the parent 178 zone can "vouch" for its child zone. The DS record is verifiable 179 information (generated from one of the child's public keys) that a 180 parent zone publishes about its child as part of the chain of trust. 181 To learn more about the Chain of Trust, see 182 :ref:`chain_of_trust`. 183 184- *NSEC, NSEC3, NSEC3PARAM*: These resource records all deal with a 185 very interesting problem: proving that something does not exist. We 186 look at these record types in more detail in 187 :ref:`advanced_discussions_proof_of_nonexistence`. 188 189- *CDS, CDNSKEY*: The CDS and CDNSKEY resource records apply to 190 operational matters and are a way to signal to the parent zone that 191 the DS records it holds for the child zone should be updated. This is 192 covered in more detail in :ref:`cds_cdnskey`. 193 194.. _how_does_dnssec_change_dns_lookup: 195 196How Does DNSSEC Change DNS Lookup? 197~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 198 199Traditional (insecure) DNS lookup is simple: a recursive name server 200receives a query from a client to lookup a name like ``www.isc.org``. The 201recursive name server tracks down the authoritative name server(s) 202responsible, sends the query to one of the authoritative name servers, 203and waits for it to respond with the answer. 204 205With DNSSEC validation enabled, a validating recursive name server 206(a.k.a. a *validating resolver*) asks for additional resource 207records in its query, hoping the remote authoritative name servers 208respond with more than just the answer to the query, but some proof to 209go along with the answer as well. If DNSSEC responses are received, the 210validating resolver performs cryptographic computation to verify the 211authenticity (the origin of the data) and integrity (that the data was not altered 212during transit) of the answers, and even asks the parent zone as part of 213the verification. It repeats this process of get-key, validate, 214ask-parent, and its parent, and its parent, all the way until 215the validating resolver reaches a key that it trusts. In the ideal, 216fully deployed world of DNSSEC, all validating resolvers only need to 217trust one key: the root key. 218 219.. _dnssec_12_steps: 220 221The 12-Step DNSSEC Validation Process (Simplified) 222~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 223 224The following example shows the 12 steps of the DNSSEC validating process 225at a very high level, looking up the name ``www.isc.org`` : 226 227.. figure:: ../dnssec-guide/img/dnssec-12-steps.png 228 :alt: DNSSEC Validation 12 Steps 229 2301. Upon receiving a DNS query from a client to resolve ``www.isc.org``, 231 the validating resolver follows standard DNS protocol to track down 232 the name server for ``isc.org``, and sends it a DNS query to ask for the 233 A record of ``www.isc.org``. But since this is a DNSSEC-enabled 234 resolver, the outgoing query has a bit set indicating it wants 235 DNSSEC answers, hoping the name server that receives it is DNSSEC-enabled 236 and can honor this secure request. 237 2382. The ``isc.org`` name server is DNSSEC-enabled, so it responds with both 239 the answer (in this case, an A record) and a digital signature for 240 verification purposes. 241 2423. The validating resolver requires cryptographic keys to be able to verify the 243 digital signature, so it asks the ``isc.org`` name server for those keys. 244 2454. The ``isc.org`` name server responds with the cryptographic keys 246 (and digital signatures of the keys) used to generate the digital 247 signature that was sent in #2. At this point, the validating 248 resolver can use this information to verify the answers received in 249 #2. 250 251 Let's take a quick break here and look at what we've got so far... 252 how can our server trust this answer? If a clever attacker had taken over 253 the ``isc.org`` name server(s), of course she would send matching 254 keys and signatures. We need to ask someone else to have confidence 255 that we are really talking to the real ``isc.org`` name server. This 256 is a critical part of DNSSEC: at some point, the DNS administrators 257 at ``isc.org`` uploaded some cryptographic information to its 258 parent, ``.org``, maybe through a secure web form, maybe 259 through an email exchange, or perhaps in person. In 260 any event, at some point some verifiable information about the 261 child (``isc.org``) was sent to the parent (``.org``) for 262 safekeeping. 263 2645. The validating resolver asks the parent (``.org``) for the 265 verifiable information it keeps on its child, ``isc.org``. 266 2676. Verifiable information is sent from the ``.org`` server. At this 268 point, the validating resolver compares this to the answer it received 269 in #4; if the two of them match, it proves the authenticity of 270 ``isc.org``. 271 272 Let's examine this process. You might be thinking to yourself, 273 what if the clever attacker that took over ``isc.org`` also 274 compromised the ``.org`` servers? Of course all this information 275 would match! That's why we turn our attention now to the 276 ``.org`` server, interrogate it for its cryptographic keys, and 277 move one level up to ``.org``'s parent, root. 278 2797. The validating resolver asks the ``.org`` authoritative name server for 280 its cryptographic keys, to verify the answers received in #6. 281 2828. The ``.org`` name server responds with the answer (in this case, 283 keys and signatures). At this point, the validating resolver can 284 verify the answers received in #6. 285 2869. The validating resolver asks root (``.org``'s parent) for the verifiable 287 information it keeps on its child, ``.org``. 288 28910. The root name server sends back the verifiable information it keeps 290 on ``.org``. The validating resolver uses this information 291 to verify the answers received in #8. 292 293 So at this point, both ``isc.org`` and ``.org`` check out. But 294 what about root? What if this attacker is really clever and somehow 295 tricked us into thinking she's the root name server? Of course she 296 would send us all matching information! So we repeat the 297 interrogation process and ask for the keys from the root name 298 server. 299 30011. The validating resolver asks the root name server for its cryptographic 301 keys to verify the answer(s) received in #10. 302 30312. The root name server sends its keys; at this point, the validating 304 resolver can verify the answer(s) received in #10. 305 306.. _chain_of_trust: 307 308Chain of Trust 309~~~~~~~~~~~~~~ 310 311But what about the root server itself? Who do we go to verify root's 312keys? There's no parent zone for root. In security, you have to trust 313someone, and in the perfectly protected world of DNSSEC (we talk later 314about the current imperfect state and ways to work around it), 315each validating resolver would only have to trust one entity, that is, 316the root name server. The validating resolver already has the root key 317on file (we discuss later how we got the root key file). So 318after the answer in #12 is received, the validating resolver compares it 319to the key it already has on file. Providing one of the keys in the 320answer matches the one on file, we can trust the answer from root. Thus 321we can trust ``.org``, and thus we can trust ``isc.org``. This is known 322as the "chain of trust" in DNSSEC. 323 324We revisit this 12-step process again later in 325:ref:`how_does_dnssec_change_dns_lookup_revisited` with more 326technical details. 327 328.. _why_is_dnssec_important: 329 330Why is DNSSEC Important? (Why Should I Care?) 331~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 332 333You might be thinking to yourself: all this DNSSEC stuff sounds 334wonderful, but why should I care? Below are some reasons why you may 335want to consider deploying DNSSEC: 336 3371. *Being a good netizen*: By enabling DNSSEC validation (as described in 338 :ref:`dnssec_validation`) on your DNS servers, you're protecting 339 your users and yourself a little more by checking answers returned to 340 you; by signing your zones (as described in 341 :ref:`dnssec_signing`), you are making it possible for other 342 people to verify your zone data. As more people adopt DNSSEC, the 343 Internet as a whole becomes more secure for everyone. 344 3452. *Compliance*: You may not even get a say in 346 implementing DNSSEC, if your organization is subject to compliance 347 standards that mandate it. For example, the US government set a 348 deadline in 2008 to have all ``.gov`` subdomains signed by 349 December 2009 [#]_. So if you operate a subdomain in ``.gov``, you 350 must implement DNSSEC to be compliant. ICANN also requires 351 that all new top-level domains support DNSSEC. 352 3533. *Enhanced Security*: Okay, so the big lofty goal of "let's be good" 354 doesn't appeal to you, and you don't have any compliance standards to 355 worry about. Here is a more practical reason why you should consider 356 DNSSEC: in the event of a DNS-based security breach, such as cache 357 poisoning or domain hijacking, after all the financial and brand 358 damage done to your domain name, you might be placed under scrutiny 359 for any preventive measure that could have been put in place. Think 360 of this like having your website only available via HTTP but not 361 HTTPS. 362 3634. *New Features*: DNSSEC brings not only enhanced security, but also 364 a whole new suite of features. Once DNS 365 can be trusted completely, it becomes possible to publish SSL 366 certificates in DNS, or PGP keys for fully automatic cross-platform 367 email encryption, or SSH fingerprints.... New features are still 368 being developed, but they all rely on a trustworthy DNS 369 infrastructure. To take a peek at these next-generation DNS features, 370 check out :ref:`introduction_to_dane`. 371 372.. [#] 373 The Office of Management and Budget (OMB) for the US government 374 published `a memo in 375 2008 <https://georgewbush-whitehouse.archives.gov/omb/memoranda/fy2008/m08-23.pdf>`__, 376 requesting all ``.gov`` subdomains to be DNSSEC-signed by December 377 2009. This explains why ``.gov`` is the most-deployed DNSSEC domain 378 currently, with `around 90% of subdomains 379 signed. <https://fedv6-deployment.antd.nist.gov/cgi-bin/generate-gov>`__ 380 381.. _how_does_dnssec_change_my_job: 382 383How Does DNSSEC Change My Job as a DNS Administrator? 384~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 385 386With this protocol extension, some of the things you were used to in DNS 387have changed. As the DNS administrator, you have new maintenance 388tasks to perform on a regular basis (as described in 389:ref:`signing_maintenance_tasks`); when there is a DNS resolution 390problem, you have new troubleshooting techniques and tools to use (as 391described in :ref:`dnssec_troubleshooting`). BIND 9 tries its best to 392make these things as transparent and seamless as possible. In this 393guide, we try to use configuration examples that result in the least 394amount of work for BIND 9 DNS administrators. 395