diff options
Diffstat (limited to 'doc/dnssec-guide/introduction.rst')
| -rw-r--r-- | doc/dnssec-guide/introduction.rst | 394 |
1 files changed, 394 insertions, 0 deletions
diff --git a/doc/dnssec-guide/introduction.rst b/doc/dnssec-guide/introduction.rst new file mode 100644 index 0000000..7f13155 --- /dev/null +++ b/doc/dnssec-guide/introduction.rst @@ -0,0 +1,394 @@ +.. Copyright (C) Internet Systems Consortium, Inc. ("ISC") +.. +.. SPDX-License-Identifier: MPL-2.0 +.. +.. This Source Code Form is subject to the terms of the Mozilla Public +.. License, v. 2.0. If a copy of the MPL was not distributed with this +.. file, you can obtain one at https://mozilla.org/MPL/2.0/. +.. +.. See the COPYRIGHT file distributed with this work for additional +.. information regarding copyright ownership. + +.. _dnssec_guide_introduction: + +Introduction +------------ + +.. _who_should_read: + +Who Should Read this Guide? +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +This guide is intended as an introduction to DNSSEC for the DNS +administrator who is already comfortable working with the existing BIND and DNS +infrastructure. He or she might be curious about DNSSEC, but may not have had the +time to investigate DNSSEC, to learn whether DNSSEC should +be a part of his or her environment, and understand what it means to deploy it in the +field. + +This guide provides basic information on how to configure DNSSEC using +BIND 9.16.9 or later. Most of the information and examples in this guide also +apply to versions of BIND later than 9.9.0, but some of the key features described here +were only introduced in version 9.16.9. Readers are assumed to have basic +working knowledge of the Domain Name System (DNS) and related network +infrastructure, such as concepts of TCP/IP. In-depth knowledge of DNS and +TCP/IP is not required. The guide assumes no prior knowledge of DNSSEC or +related technology such as public key cryptography. + +.. _who_should_not_read: + +Who May Not Want to Read this Guide? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +If you are already operating a DNSSEC-signed zone, you may not learn +much from the first half of this document, and you may want to start with +:ref:`dnssec_advanced_discussions`. If you want to +learn about details of the protocol extension, such as data fields and flags, +or the new record types, this document can help you get started but it +does not include all the technical details. + +If you are experienced in DNSSEC, you +may find some of the concepts in this document to be overly simplified for +your taste, and some details are intentionally omitted at times for ease of +illustration. + +If you administer a large or complex BIND environment, this +guide may not provide enough information for you, as it is intended to provide +only basic, generic working examples. + +If you are a top-level domain (TLD) operator, or +administer zones under signed TLDs, this guide can +help you get started, but it does not provide enough details to serve all of your +needs. + +If your DNS environment uses DNS products other than (or in addition to) +BIND, this document may provide some background or overlapping information, but you +should check each product's vendor documentation for specifics. + +Finally, deploying +DNSSEC on internal or private networks is not covered in this document, with the +exception of a brief discussion in :ref:`dnssec_on_private_networks`. + +.. _what_is_dnssec: + +What is DNSSEC? +~~~~~~~~~~~~~~~ + +The Domain Name System (DNS) was designed in a day and age when the +Internet was a friendly and trusting place. The protocol itself provides +little protection against malicious or forged answers. DNS Security +Extensions (DNSSEC) addresses this need, by adding digital signatures +into DNS data so that each DNS response can be verified for integrity +(the answer did not change during transit) and authenticity (the data +came from the true source, not an impostor). In the ideal world, when +DNSSEC is fully deployed, every single DNS answer can be validated and +trusted. + +DNSSEC does not provide a secure tunnel; it does not encrypt or hide DNS +data. It operates independently of an existing Public Key Infrastructure +(PKI). It does not need SSL certificates or shared secrets. It was +designed with backwards compatibility in mind, and can be deployed +without impacting "old" unsecured domain names. + +DNSSEC is deployed on the three major components of the DNS +infrastructure: + +- *Recursive Servers*: People use recursive servers to lookup external + domain names such as ``www.example.com``. Operators of recursive servers + need to enable DNSSEC validation. With validation enabled, recursive + servers carry out additional tasks on each DNS response they + receive to ensure its authenticity. + +- *Authoritative Servers*: People who publish DNS data on their name + servers need to sign that data. This entails creating additional + resource records, and publishing them to parent domains where + necessary. With DNSSEC enabled, authoritative servers respond to + queries with additional DNS data, such as digital signatures and + keys, in addition to the standard answers. + +- *Applications*: This component lives on every client machine, from web + servers to smart phones. This includes resolver libraries on different + operating systems, and applications such as web browsers. + +In this guide, we focus on the first two components, Recursive +Servers and Authoritative Servers, and only lightly touch on the third +component. We look at how DNSSEC works, how to configure a +validating resolver, how to sign DNS zone data, and other operational +tasks and considerations. + +.. _what_does_dnssec_add_to_dns: + +What Does DNSSEC Add to DNS? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. note:: + + Public Key Cryptography works on the concept of a pair of keys: one + made available to the world publicly, and one kept in secrecy + privately. Not surprisingly, they are known as a public key and a private + key. If you are not familiar with the concept, think of it as a + cleverly designed lock, where one key locks and one key unlocks. In + DNSSEC, we give out the unlocking public key to the rest of the + world, while keeping the locking key private. To learn how this is + used to secure DNS messages, see :ref:`how_are_answers_verified`. + +DNSSEC introduces eight new resource record types: + +- RRSIG (digital resource record signature) + +- DNSKEY (public key) + +- DS (parent-child) + +- NSEC (proof of nonexistence) + +- NSEC3 (proof of nonexistence) + +- NSEC3PARAM (proof of nonexistence) + +- CDS (child-parent signaling) + +- CDNSKEY (child-parent signaling) + +This guide does not go deep into the anatomy of each resource record +type; the details are left for the reader to research and explore. +Below is a short introduction on each of the new record types: + +- *RRSIG*: With DNSSEC enabled, just about every DNS answer (A, PTR, + MX, SOA, DNSKEY, etc.) comes with at least one resource + record signature, or RRSIG. These signatures are used by recursive name + servers, also known as validating resolvers, to verify the answers + received. To learn how digital signatures are generated and used, see + :ref:`how_are_answers_verified`. + +- *DNSKEY*: DNSSEC relies on public-key cryptography for data + authenticity and integrity. There are several keys used in DNSSEC, + some private, some public. The public keys are published to the world + as part of the zone data, and they are stored in the DNSKEY record + type. + + In general, keys in DNSSEC are used for one or both of the following + roles: as a Zone Signing Key (ZSK), used to protect all zone data; or + as a Key Signing Key (KSK), used to protect the zone's keys. A key + that is used for both roles is referred to as a Combined Signing Key + (CSK). We talk about keys in more detail in + :ref:`advanced_discussions_key_generation`. + +- *DS*: One of the critical components of DNSSEC is that the parent + zone can "vouch" for its child zone. The DS record is verifiable + information (generated from one of the child's public keys) that a + parent zone publishes about its child as part of the chain of trust. + To learn more about the Chain of Trust, see + :ref:`chain_of_trust`. + +- *NSEC, NSEC3, NSEC3PARAM*: These resource records all deal with a + very interesting problem: proving that something does not exist. We + look at these record types in more detail in + :ref:`advanced_discussions_proof_of_nonexistence`. + +- *CDS, CDNSKEY*: The CDS and CDNSKEY resource records apply to + operational matters and are a way to signal to the parent zone that + the DS records it holds for the child zone should be updated. This is + covered in more detail in :ref:`cds_cdnskey`. + +.. _how_does_dnssec_change_dns_lookup: + +How Does DNSSEC Change DNS Lookup? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Traditional (insecure) DNS lookup is simple: a recursive name server +receives a query from a client to lookup a name like ``www.isc.org``. The +recursive name server tracks down the authoritative name server(s) +responsible, sends the query to one of the authoritative name servers, +and waits for it to respond with the answer. + +With DNSSEC validation enabled, a validating recursive name server +(a.k.a. a *validating resolver*) asks for additional resource +records in its query, hoping the remote authoritative name servers +respond with more than just the answer to the query, but some proof to +go along with the answer as well. If DNSSEC responses are received, the +validating resolver performs cryptographic computation to verify the +authenticity (the origin of the data) and integrity (that the data was not altered +during transit) of the answers, and even asks the parent zone as part of +the verification. It repeats this process of get-key, validate, +ask-parent, and its parent, and its parent, all the way until +the validating resolver reaches a key that it trusts. In the ideal, +fully deployed world of DNSSEC, all validating resolvers only need to +trust one key: the root key. + +.. _dnssec_12_steps: + +The 12-Step DNSSEC Validation Process (Simplified) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The following example shows the 12 steps of the DNSSEC validating process +at a very high level, looking up the name ``www.isc.org`` : + +.. figure:: ../dnssec-guide/img/dnssec-12-steps.png + :alt: DNSSEC Validation 12 Steps + +1. Upon receiving a DNS query from a client to resolve ``www.isc.org``, + the validating resolver follows standard DNS protocol to track down + the name server for ``isc.org``, and sends it a DNS query to ask for the + A record of ``www.isc.org``. But since this is a DNSSEC-enabled + resolver, the outgoing query has a bit set indicating it wants + DNSSEC answers, hoping the name server that receives it is DNSSEC-enabled + and can honor this secure request. + +2. The ``isc.org`` name server is DNSSEC-enabled, so it responds with both + the answer (in this case, an A record) and a digital signature for + verification purposes. + +3. The validating resolver requires cryptographic keys to be able to verify the + digital signature, so it asks the ``isc.org`` name server for those keys. + +4. The ``isc.org`` name server responds with the cryptographic keys + (and digital signatures of the keys) used to generate the digital + signature that was sent in #2. At this point, the validating + resolver can use this information to verify the answers received in + #2. + + Let's take a quick break here and look at what we've got so far... + how can our server trust this answer? If a clever attacker had taken over + the ``isc.org`` name server(s), of course she would send matching + keys and signatures. We need to ask someone else to have confidence + that we are really talking to the real ``isc.org`` name server. This + is a critical part of DNSSEC: at some point, the DNS administrators + at ``isc.org`` uploaded some cryptographic information to its + parent, ``.org``, maybe through a secure web form, maybe + through an email exchange, or perhaps in person. In + any event, at some point some verifiable information about the + child (``isc.org``) was sent to the parent (``.org``) for + safekeeping. + +5. The validating resolver asks the parent (``.org``) for the + verifiable information it keeps on its child, ``isc.org``. + +6. Verifiable information is sent from the ``.org`` server. At this + point, the validating resolver compares this to the answer it received + in #4; if the two of them match, it proves the authenticity of + ``isc.org``. + + Let's examine this process. You might be thinking to yourself, + what if the clever attacker that took over ``isc.org`` also + compromised the ``.org`` servers? Of course all this information + would match! That's why we turn our attention now to the + ``.org`` server, interrogate it for its cryptographic keys, and + move one level up to ``.org``'s parent, root. + +7. The validating resolver asks the ``.org`` authoritative name server for + its cryptographic keys, to verify the answers received in #6. + +8. The ``.org`` name server responds with the answer (in this case, + keys and signatures). At this point, the validating resolver can + verify the answers received in #6. + +9. The validating resolver asks root (``.org``'s parent) for the verifiable + information it keeps on its child, ``.org``. + +10. The root name server sends back the verifiable information it keeps + on ``.org``. The validating resolver uses this information + to verify the answers received in #8. + + So at this point, both ``isc.org`` and ``.org`` check out. But + what about root? What if this attacker is really clever and somehow + tricked us into thinking she's the root name server? Of course she + would send us all matching information! So we repeat the + interrogation process and ask for the keys from the root name + server. + +11. The validating resolver asks the root name server for its cryptographic + keys to verify the answer(s) received in #10. + +12. The root name server sends its keys; at this point, the validating + resolver can verify the answer(s) received in #10. + +.. _chain_of_trust: + +Chain of Trust +~~~~~~~~~~~~~~ + +But what about the root server itself? Who do we go to verify root's +keys? There's no parent zone for root. In security, you have to trust +someone, and in the perfectly protected world of DNSSEC (we talk later +about the current imperfect state and ways to work around it), +each validating resolver would only have to trust one entity, that is, +the root name server. The validating resolver already has the root key +on file (we discuss later how we got the root key file). So +after the answer in #12 is received, the validating resolver compares it +to the key it already has on file. Providing one of the keys in the +answer matches the one on file, we can trust the answer from root. Thus +we can trust ``.org``, and thus we can trust ``isc.org``. This is known +as the "chain of trust" in DNSSEC. + +We revisit this 12-step process again later in +:ref:`how_does_dnssec_change_dns_lookup_revisited` with more +technical details. + +.. _why_is_dnssec_important: + +Why is DNSSEC Important? (Why Should I Care?) +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You might be thinking to yourself: all this DNSSEC stuff sounds +wonderful, but why should I care? Below are some reasons why you may +want to consider deploying DNSSEC: + +1. *Being a good netizen*: By enabling DNSSEC validation (as described in + :ref:`dnssec_validation`) on your DNS servers, you're protecting + your users and yourself a little more by checking answers returned to + you; by signing your zones (as described in + :ref:`dnssec_signing`), you are making it possible for other + people to verify your zone data. As more people adopt DNSSEC, the + Internet as a whole becomes more secure for everyone. + +2. *Compliance*: You may not even get a say in + implementing DNSSEC, if your organization is subject to compliance + standards that mandate it. For example, the US government set a + deadline in 2008 to have all ``.gov`` subdomains signed by + December 2009 [#]_. So if you operate a subdomain in ``.gov``, you + must implement DNSSEC to be compliant. ICANN also requires + that all new top-level domains support DNSSEC. + +3. *Enhanced Security*: Okay, so the big lofty goal of "let's be good" + doesn't appeal to you, and you don't have any compliance standards to + worry about. Here is a more practical reason why you should consider + DNSSEC: in the event of a DNS-based security breach, such as cache + poisoning or domain hijacking, after all the financial and brand + damage done to your domain name, you might be placed under scrutiny + for any preventive measure that could have been put in place. Think + of this like having your website only available via HTTP but not + HTTPS. + +4. *New Features*: DNSSEC brings not only enhanced security, but also + a whole new suite of features. Once DNS + can be trusted completely, it becomes possible to publish SSL + certificates in DNS, or PGP keys for fully automatic cross-platform + email encryption, or SSH fingerprints.... New features are still + being developed, but they all rely on a trustworthy DNS + infrastructure. To take a peek at these next-generation DNS features, + check out :ref:`introduction_to_dane`. + +.. [#] + The Office of Management and Budget (OMB) for the US government + published `a memo in + 2008 <https://www.whitehouse.gov/sites/whitehouse.gov/files/omb/memoranda/2008/m08-23.pdf>`__, + requesting all ``.gov`` subdomains to be DNSSEC-signed by December + 2009. This explains why ``.gov`` is the most-deployed DNSSEC domain + currently, with `around 90% of subdomains + signed. <https://fedv6-deployment.antd.nist.gov/cgi-bin/generate-gov>`__ + +.. _how_does_dnssec_change_my_job: + +How Does DNSSEC Change My Job as a DNS Administrator? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +With this protocol extension, some of the things you were used to in DNS +have changed. As the DNS administrator, you have new maintenance +tasks to perform on a regular basis (as described in +:ref:`signing_maintenance_tasks`); when there is a DNS resolution +problem, you have new troubleshooting techniques and tools to use (as +described in :ref:`dnssec_troubleshooting`). BIND 9 tries its best to +make these things as transparent and seamless as possible. In this +guide, we try to use configuration examples that result in the least +amount of work for BIND 9 DNS administrators. |