diff --git a/explanation/crypto/bind-9-dnssec-cryptography-selection.md b/explanation/crypto/bind-9-dnssec-cryptography-selection.md index 6aeb5697..d8a78946 100644 --- a/explanation/crypto/bind-9-dnssec-cryptography-selection.md +++ b/explanation/crypto/bind-9-dnssec-cryptography-selection.md @@ -4,17 +4,9 @@ Domain Name System Security Extensions (DNSSEC), which provides a set of securit ## DNSSEC validation -Out of the box, the BIND 9 DNS server is configured to try to use DNSSEC whenever it's available, doing all the validation checks automatically. This is done via the `dnssec-validation` setting in `/etc/bind/named.conf.options`: +Out of the box, the BIND 9 DNS server is configured to try to use DNSSEC whenever it's available, doing all the validation checks automatically. This is done via the `dnssec-validation auto` setting in `/etc/bind/named.conf.options`, which became the implicit default as of version `1:9:18.34-1` in Ubuntu 24.10 and above. -```text -options { - (...) - dnssec-validation auto; - (...) -}; -``` - -This can be quickly checked with the help of `dig`. Right after you installed `bind9`, you can run `dig` and ask it about the `isc.org` domain: +DNSSEC can be quickly checked with the help of `dig`. Right after you installed `bind9`, you can run `dig` and ask it about the `isc.org` domain: ```text $ dig @127.0.0.1 isc.org +dnssec +multiline diff --git a/explanation/dnssec/dnssec.md b/explanation/dnssec/dnssec.md index f1e8fc4e..0a5b91d3 100644 --- a/explanation/dnssec/dnssec.md +++ b/explanation/dnssec/dnssec.md @@ -31,6 +31,47 @@ The public key cryptography underpinning SSL/TLS operates in a similar manner, b For a more detailed explanation of how the DNSSEC validation is performed, please refer to the [Simplified 12-step DNSSEC validation process](https://bind9.readthedocs.io/en/latest/dnssec-guide.html#the-12-step-dnssec-validation-process-simplified) guide from ISC. +## DNS daemons +Ubuntu supports multiple DNS resolvers, covering a variety of use cases. Most of them support DNSSEC validation, but it might not be activated and set up with valid trust-anchors automatically. + + +| Daemon | Type | DNSSEC support | +| --- | --- | --- | +| systemd‑resolved | Stub Resolver (local) | Yes. Enabled by default via `DNSSEC=allow-downgrade` setting. | +| dnsmasq | Stub Resolver | Yes. Disabled by default. Controlled via `dnssec` and `conf-file=../trust-anchors.conf` settings. | +| bind9 | Recursive Resolver | Yes. Enabled by default via `dnssec-validation auto;` setting. | + + +The **systemd-resolved** stub resolver is pre-installed by default and comes with DNSSEC enabled in fallback mode (as of Ubuntu 25.10). This mode configures the `DNSSEC=allow-downgrade` setting in `/usr/lib/systemd/resolved.conf.d/00-enable-dnssec.conf` (installed by the `systemd-resolved-dnssec` package) and tries to validate the DNSSEC records whenever possible, but at the same time accepts unsigned responses for backwards compatibility with unsigned zones. + +The functionality of DNSSEC in **systemd-resolved** can be confirmed, using the `dig` command on the local stub resolver at `127.0.0.53:53`, by checking for the existence of the **ad** (Authenticated Data) flag: +``` +$ dig @127.0.0.53 isc.org +dnssec +[...] +;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 +``` + +Should authenticity of DNS records be a concern to you, it's advised to override the default DNSSEC validation settings through an additional drop-in configuration in `/etc/systemd/resolved.conf.d/10-dnssec.conf`, which would reject any unsigned records, after reloading the configuration: +``` +$ cat /etc/systemd/resolved.conf.d/10-dnssec.conf +[Resolve] +DNSSEC=yes + +$ sudo systemctl reload systemd-resolved.service +``` +```{warning} +Be aware that enforcing DNSSEC can lead to errors, especially for local, unsigned domains and you would only be able to reach such services by accessing them through their IP address directly. For example this could manifest itself by errors like `DNS_PROBE_FINISHED_NXDOMAIN` in your browser, when trying to access services in the local network. + +``` + +Once DNSSEC validation is enforced, you should also be able to confirm it through higher level checks in your browser, e.g. using those 3rd party services: + * https://internet.nl/test-connection/ + * https://wander.science/projects/dns/dnssec-resolver-test/ + +```{note} +In case of issues with Domain Name resolution, make sure to remove any drop-in configs for **resolved.conf.d**, execute `systemctl reload systemd-resolved.service` and `apt remove systemd-resolved-dnssec`. This will reset any DNSSEC configuration to `DNSSEC=no` and can be confirmed by executing `resolvectl dnssec`. +``` + ## New Resource Records (RRs) DNSSEC introduces a set of new Resource Records. Here are the most important ones: @@ -112,6 +153,10 @@ This stub resolver has its own configuration for which recursive DNS servers to DNS Servers: 10.10.17.1 DNS Domain: lxd +```{note} +Starting with Ubuntu 25.10 the `systemd-resolved-dnssec` package is pre-installed enabling the fallback mode as `DNSSEC=allow-downgrade/supported` +``` + This configuration is usually provided via {term}`DHCP`, but could also be set via other means. In this particular example, the DNS server that the stub resolver (`systemd-resolved`) will use for all queries that go out on that network interface is 10.10.17.1. The output above also has `DNSSEC=no/unsupported`: we will get back to that in a moment, but it means that `systemd-resolved` is not performing the DNSSEC cryptographic validation. Given what we have: @@ -138,6 +183,10 @@ This is the case if you install the BIND9 DNS server: the default configuration ... }; +```{note} +Starting with version `1:9.18.34-1` in Ubuntu 24.10 and above, the `dnssec-validation auto` setting became the implicit default and does not need to be set explicitly in `named.conf.options` anymore. +``` + A critical aspect of this deployment model is the trust in the network segment between the stub resolver and the Validating Resolver. If this network is compromised, the security benefits of DNSSEC can be undermined. While the Validating Resolver performs DNSSEC checks and returns only verified responses, the response could still be tampered with on the final ("last mile") network segment. This is where the `trust-ad` setting from `/etc/resolv.conf` comes into play: @@ -159,7 +208,7 @@ Specifying `trust-ad` in `/etc/resolv.conf` implies in these assumptions: When using `systemd-resolved` as a stub resolver, as configured above, the network path to the local DNS resolver is inherently trusted, as it is a localhost interface. However, the actual nameserver used is not 127.0.0.53; it depends on `systemd-resolved`'s configuration. Unless local DNSSEC validation is enabled, `systemd-resolved` will strip the ad bit from queries sent to the Validating Resolver and from the received responses. -This is the default case in Ubuntu systems. +This is the default case in Ubuntu systems until Ubuntu 25.04. Another valid configuration is to not use `systemd-resolved`, but rather point at the Validating Resolver of the network directly, like in this example: @@ -176,14 +225,15 @@ As these assumptions have a higher chance of not being true, this is not the def In any case, having a Validating Resolver in the network is a valid and very useful scenario, and good enough for most cases. And it has the extra benefit that the DNSSEC validation is done only once, at the resolver, for all clients on the network. ### Local DNSSEC validation -Some stub resolvers, such as systemd-resolved, can perform DNSSEC validation locally. This eliminates the risk of network attacks between the resolver and the client, as they reside on the same system. However, local DNSSEC validation introduces additional overhead in the form of multiple DNS queries. For each DNS query, the resolver must fetch the desired record, its digital signature, and the corresponding public key. This process can significantly increase latency, and with multiple clients on the same network request the same record, that's duplicated work. +Some stub resolvers, such as systemd-resolved, can perform DNSSEC validation locally. This eliminates the risk of network attacks between the resolver and the client, as they reside on the same system. However, local DNSSEC validation introduces additional overhead in the form of multiple DNS queries. For each DNS query, the resolver must fetch the desired record, its digital signature, and the corresponding public key. This process can increase latency, and with multiple clients on the same network request the same record, that's duplicated work. -In general, local DNSSEC validation is only required in more specific secure environments. +In general, local DNSSEC validation is still the more secure approach, validating and authenticating the DNS resource records end-to-end, without the need to trust any DNS server along the way. Besides this, DNS-over-TLS (DoT) or DNS-over-HTTPS (DoH) could be used to increase privacy, by encrypting the DNS connection between your local client and the remote Recursive Resolver. As an example, let's perform the same query using `systemd-resolved` with and without local DNSSEC validation enabled. Without local DNSSEC validation. First, let's show it's disabled indeed: + $ sudo resolvectl dnssec eth0 false $ resolvectl dnssec Global: no Link 44 (eth0): no @@ -194,7 +244,7 @@ Now we perform the query: isc.org IN MX 10 mx.ams1.isc.org -- link: eth0 isc.org IN MX 5 mx.pao1.isc.org -- link: eth0 - -- Information acquired via protocol DNS in 229.5ms. + -- Information acquired via protocol DNS in 37.2ms. -- Data is authenticated: no; Data was acquired via local or encrypted transport: no -- Data from: network @@ -252,3 +302,4 @@ But even when the validation is local, simpler clients might not get the full pi * [Tool to visualize the DNSSEC chain of trust of a domain](https://dnsviz.net/) * [DANE](https://en.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities) * [RFC 4255](https://datatracker.ietf.org/doc/html/rfc4255) - Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints + * {ref}`dnssec-troubleshooting` diff --git a/how-to/networking/dnssec-troubleshooting.md b/how-to/networking/dnssec-troubleshooting.md index 6845e5c9..51dd6b13 100644 --- a/how-to/networking/dnssec-troubleshooting.md +++ b/how-to/networking/dnssec-troubleshooting.md @@ -65,37 +65,36 @@ For DNSSEC troubleshooting purposes, we are interested in the following features * `ad`: When included in a response, this flag means *authenticated data*, and tells us that the resolver who provided this answer has performed DNSSEC validation. * `@`: This parameter lets us direct the query to a specific DNS server running at the provided IP address. -For example, let's query a local DNS server for the *isc.org* type *A* record, and request DNSSEC data: +For example, let's query the local systemd-resolved DNS stub resolver (running at **127.0.0.53**) for the *isc.org* type *A* record, and request DNSSEC data: - $ dig @127.0.0.1 -t A +dnssec +multiline isc.org + $ dig @127.0.0.53 -t A +dnssec +multiline isc.org - ; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> @127.0.0.1 -t A +dnssec +multiline isc.org + ; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> @127.0.0.53 -t A +dnssec +multiline isc.org ; (1 server found) ;; global options: +cmd ;; Got answer: - ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25738 + ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13164 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: - ; EDNS: version: 0, flags: do; udp: 1232 - ; COOKIE: 8c4c8391524d28af01000000671bd625936966d67a5f7061 (good) + ; EDNS: version: 0, flags: do; udp: 65494 ;; QUESTION SECTION: - ;isc.org. IN A + ;isc.org. IN A ;; ANSWER SECTION: - isc.org. 207 IN A 151.101.2.217 - isc.org. 207 IN A 151.101.66.217 - isc.org. 207 IN A 151.101.130.217 - isc.org. 207 IN A 151.101.194.217 - isc.org. 207 IN RRSIG A 13 2 300 ( - 20241107074911 20241024070338 27566 isc.org. - BIl7hov5X11CITexzV9w7wbCOpKZrup3FopjgF+RIgOI - 5A8p8l2dJCLp/KBn/G6INj7TOHTtrGs1StTSJVNksw== ) - - ;; Query time: 0 msec - ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) - ;; WHEN: Fri Oct 25 17:32:21 UTC 2024 - ;; MSG SIZE rcvd: 231 + isc.org. 300 IN A 151.101.130.217 + isc.org. 300 IN A 151.101.66.217 + isc.org. 300 IN A 151.101.2.217 + isc.org. 300 IN A 151.101.194.217 + isc.org. 300 IN RRSIG A 13 2 300 ( + 20250830114017 20250816111944 27566 isc.org. + u6hKKZGX3DUD6JJAjHsGog+nfR9bz5qp2g1h3qibZI+A + qWH05fWJJjoSMzcnOgzIO1299zPIZd0xdMAh1wbkjw== ) + + ;; Query time: 83 msec + ;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP) + ;; WHEN: Mon Aug 25 13:28:33 CEST 2025 + ;; MSG SIZE rcvd: 203 Let's unpack this answer for the important troubleshooting parts: @@ -105,61 +104,71 @@ Let's unpack this answer for the important troubleshooting parts: If we repeat this query with a domain that we know fails DNSSEC validation, we get the following reply: - $ dig @127.0.0.1 -t A +dnssec +multiline dnssec-failed.org + $ dig @127.0.0.53 -t A +dnssec +multiline dnssec-failed.org - ; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> @127.0.0.1 -t A +dnssec +multiline dnssec-failed.org + ; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> @127.0.0.53 -t A +dnssec +multiline dnssec-failed.org ; (1 server found) ;; global options: +cmd ;; Got answer: - ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 41300 - ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 + ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 8314 + ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2 ;; OPT PSEUDOSECTION: - ; EDNS: version: 0, flags: do; udp: 1232 - ; COOKIE: b895f4fe3f3d605401000000671bd719636ef1cfc4e615f3 (good) + ; EDNS: version: 0, flags: do; udp: 65494 ;; QUESTION SECTION: - ;dnssec-failed.org. IN A + ;dnssec-failed.org. IN A - ;; Query time: 1355 msec - ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) - ;; WHEN: Fri Oct 25 17:36:25 UTC 2024 - ;; MSG SIZE rcvd: 74 + ;; ANSWER SECTION: + dnssec-failed.org. 300 IN A 96.99.227.255 + + ;; ADDITIONAL SECTION: + dnssec-failed.org. 300 IN RRSIG A 5 2 300 ( + 20250904145125 20250818144625 44973 dnssec-failed.org. + UF75l9JkH/AZ9ApNF86stA81B+L36j0F/L8ENvMknsfK + Fwll6cLEJWBalKeyhK7p3U/Lqet9L3Oti8H7RudmgZ4v + kdYMDrb9mqnXscY1R/kmSrtu3gOO1ob+khKinyAVwKLb + R0CVZnJLSb7c++BI9fRJjE2caZ+2RkHwkLATR28= ) + + ;; Query time: 138 msec + ;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP) + ;; WHEN: Mon Aug 25 13:37:11 CEST 2025 + ;; MSG SIZE rcvd: 239 This time: * There is no `ad` flag set in the answer. * The status of the query is a generic `SERVFAIL`, and zero answers were provided. -We can tell the Validating Resolver (the service running on the `@127.0.0.1` address) that we don't want it to perform DNSSEC validation. We do that by setting the `+cd` (check disabled) flag. Then things change in our answer: +We can tell the local stub resolver (systemd-resolved running at `@127.0.0.53` address) that we don't want it to perform DNSSEC validation. We do that by setting the `+cd` (check disabled) flag. Then things change in our answer: - $ dig @127.0.0.1 -t A +dnssec +cd +multiline dnssec-failed.org + $ dig @127.0.0.53 -t A +dnssec +cd +multiline dnssec-failed.org - ; <<>> DiG 9.18.28-0ubuntu0.24.04.1-Ubuntu <<>> @127.0.0.1 -t A +dnssec +cd +multiline dnssec-failed.org + ; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> @127.0.0.53 -t A +dnssec +cd +multiline dnssec-failed.org ; (1 server found) ;; global options: +cmd ;; Got answer: - ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7269 + ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55352 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: - ; EDNS: version: 0, flags: do; udp: 1232 - ; COOKIE: dd66930044348f2501000000671bd808f6852a18a0089b3f (good) + ; EDNS: version: 0, flags: do; udp: 65494 + ; EDE: 9 (DNSKEY Missing) ;; QUESTION SECTION: - ;dnssec-failed.org. IN A + ;dnssec-failed.org. IN A ;; ANSWER SECTION: - dnssec-failed.org. 297 IN A 96.99.227.255 - dnssec-failed.org. 297 IN RRSIG A 5 2 300 ( - 20241111145122 20241025144622 44973 dnssec-failed.org. - fa53BQ7HPpKFIPKyn3Md4bVLawQLeatny47hTq1QouG8 - DwyVqmsfs3d5kUTFO5FHdCy4U7o97ODYXiVuilEZS/aZ - n6odin2SCm0so4TnIuKBgZFW41zpI6oIRmIVPv6HLerI - uUxovyMEtaGyd5maNgxGldqLzgWkl18TWALYlrk= ) - - ;; Query time: 0 msec - ;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP) - ;; WHEN: Fri Oct 25 17:40:24 UTC 2024 - ;; MSG SIZE rcvd: 267 + dnssec-failed.org. 181 IN A 96.99.227.255 + dnssec-failed.org. 181 IN RRSIG A 5 2 300 ( + 20250904145125 20250818144625 44973 dnssec-failed.org. + UF75l9JkH/AZ9ApNF86stA81B+L36j0F/L8ENvMknsfK + Fwll6cLEJWBalKeyhK7p3U/Lqet9L3Oti8H7RudmgZ4v + kdYMDrb9mqnXscY1R/kmSrtu3gOO1ob+khKinyAVwKLb + R0CVZnJLSb7c++BI9fRJjE2caZ+2RkHwkLATR28= ) + + ;; Query time: 3 msec + ;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP) + ;; WHEN: Mon Aug 25 13:39:09 CEST 2025 + ;; MSG SIZE rcvd: 245 Looks like we have some sort of answer, but: @@ -167,7 +176,7 @@ Looks like we have some sort of answer, but: * The status is `NOERROR`, and we got two answers. * Note there is a `cd` flag in the answer, meaning "check disabled". No attempt at validating the answer was done by the resolver, as requested. -In none of these cases, though, did `dig` perform DNSSEC validation: it just presented the results provided by the Validating Resolver, which in some cases was no validation at all (via the `+cd` flag). To perform the validation ourselves, we have to use a different tool. +In none of these cases, though, did `dig` perform DNSSEC validation: it just presented the results provided by the resolver, which in some cases was no validation at all (via the `+cd` flag). To perform the validation ourselves, we have to use a different tool. ## Digging a bit deeper: `delv` @@ -175,12 +184,12 @@ The `delv` tool is very similar to `dig`, and can perform the same DNS queries, But to bring the responsibility of doing DNSSEC validation to the tool itself, we use the `+cd` flag in our queries, to tell the resolver to not attempt that validation. Otherwise we will just get back a generic `SERVFAIL` error: - $ delv @127.0.0.1 -t A +dnssec +multiline dnssec-failed.org + $ delv @127.0.0.53 -t A +dnssec +multiline dnssec-failed.org ;; resolution failed: SERVFAIL With the `+cd` flag present, however, `delv` itself will do the validation. It will fail again, but now with a DNSSEC-specific error: - $ delv @127.0.0.1 -t A +dnssec +cd +multiline dnssec-failed.org + $ delv @127.0.0.53 -t A +dnssec +cd +multiline dnssec-failed.org ;; validating dnssec-failed.org/DNSKEY: no valid signature found (DS) ;; no valid RRSIG resolving 'dnssec-failed.org/DNSKEY/IN': 127.0.0.1#53 ;; broken trust chain resolving 'dnssec-failed.org/A/IN': 127.0.0.1#53 @@ -188,24 +197,24 @@ With the `+cd` flag present, however, `delv` itself will do the validation. It w If needed, `delv` can be told to not perform DNSSEC validation at all, by passing the `-i` flag. Together with the `+cd` flag, which instructs the Validating Resolver to not perform validation either, we get this result: - $ delv @127.0.0.1 -i -t A +dnssec +cd +multiline dnssec-failed.org + $ delv @127.0.0.53 -i -t A +dnssec +cd +multiline dnssec-failed.org ; answer not validated dnssec-failed.org. 100 IN A 96.99.227.255 For a good DNSSEC domain, `delv` will return a validated answer: - $ delv @127.0.0.1 -t A +multiline +cd isc.org + $ delv @127.0.0.53 -t A +multiline +cd isc.org ; fully validated - isc.org. 300 IN A 151.101.2.217 - isc.org. 300 IN A 151.101.66.217 - isc.org. 300 IN A 151.101.130.217 - isc.org. 300 IN A 151.101.194.217 - isc.org. 300 IN RRSIG A 13 2 300 ( - 20241107074911 20241024070338 27566 isc.org. - BIl7hov5X11CITexzV9w7wbCOpKZrup3FopjgF+RIgOI - 5A8p8l2dJCLp/KBn/G6INj7TOHTtrGs1StTSJVNksw== ) + isc.org. 299 IN A 151.101.2.217 + isc.org. 299 IN A 151.101.66.217 + isc.org. 299 IN A 151.101.130.217 + isc.org. 299 IN A 151.101.194.217 + isc.org. 299 IN RRSIG A 13 2 300 ( + 20250908112301 20250825104017 27566 isc.org. + 9oclTno0Ub2NmUEXdyLv0zqwPBbbUVmT3RX4aP4BQQ+h + 4g839JXuCKHufXSPkWh/GJe/MveP83dDvJkrMmEIzg== ) -Given that above we used the `+cd` flag, this means that the validation was done by `delv` itself. We will get the same result without that flag if the Validating Resolver also succeeds in the DNSSEC validation, and provides an answer. +Given that above we used the `+cd` flag, this means that the validation was done by `delv` itself. We will get the same result without that flag if the resolver also succeeds in the DNSSEC validation, and provides an answer. ## Incorrect time @@ -237,7 +246,7 @@ If the DNSSEC validator has an incorrect clock, outside of the validity range, t Any other Validating Resolver will fail in a similar way, and should indicate this error in its logs. -BIND9 itself will complain loudly if it's running on a system with an incorrect clock, as the root zones will fail validation: +BIND9 will complain loudly if it's running on a system with an incorrect clock, as the root zones will fail validation: named[3593]: managed-keys-zone: DNSKEY set for zone '.' could not be verified with current keys named[3593]: validating ./DNSKEY: verify failed due to bad signature (keyid=20326): RRSIG validity period has not begun @@ -249,11 +258,12 @@ BIND9 itself will complain loudly if it's running on a system with an incorrect There are some public third-party web-based tools that will check the status of DNSSEC of a public domain. Here are some: - * https://dnsviz.net/: Returns a graphical diagram showing the chain of trust and where it breaks down, if that's the case. - * https://dnssec-debugger.verisignlabs.com/: A DNSSEC debugger which also shows the chain of trust and where it breaks down, in a table format. + * : Returns a graphical diagram showing the chain of trust and where it breaks down, if that's the case. + * : A DNSSEC debugger which also shows the chain of trust and where it breaks down, in a table format. ## Further reading * [bind9's guide to DNSSEC troubleshooting](https://bind9.readthedocs.io/en/latest/dnssec-guide.html#basic-dnssec-troubleshooting) + * [How to validate DNSSEC using the command line](https://www.cyberciti.biz/faq/unix-linux-test-and-validate-dnssec-using-dig-command-line/) * {manpage}`delv(1)` manpage * {manpage}`dig(1)` manpage diff --git a/how-to/networking/install-dns.md b/how-to/networking/install-dns.md index c30866e1..dcf96e0c 100644 --- a/how-to/networking/install-dns.md +++ b/how-to/networking/install-dns.md @@ -488,6 +488,8 @@ This section covers some of the most common DNS record types. ## Further reading +- {ref}`install-dnssec` + - [Upstream BIND9 Documentation](https://bind9.readthedocs.io/en/latest/) - [DNS and BIND](http://shop.oreilly.com/product/9780596100575.do) is a popular book now in its fifth edition. There is now also a [DNS and BIND on IPv6](http://shop.oreilly.com/product/0636920020158.do) book. diff --git a/how-to/networking/install-dnssec.md b/how-to/networking/install-dnssec.md index 70a70453..c5379f65 100644 --- a/how-to/networking/install-dnssec.md +++ b/how-to/networking/install-dnssec.md @@ -3,7 +3,7 @@ DNSSEC is a set of security extensions to {term}`DNS` which allow DNS data to be verified for authenticity and integrity. -This guide will show you how to enable DNSSEC for an existing zone in your BIND9 DNS server deployment. +This guide will show you how to enable DNSSEC for an existing zone in your BIND9 DNS server deployment, by serving additional records like `DS`, `DNSKEY` or `RRSIG` for signed zones. ## Starting point The starting point for this how-to is an existing BIND9 DNS server deployed with an authoritative zone. For details on how to deploy BIND9 in this fashion, please see the {ref}`DNS How-To `. One key difference from that guide, however, is that we need the zone file to be in a directory where the server can write to, like `/var/lib/bind`, instead of `/etc/bind`.