Show Table of Contents
4.5. Securing DNS Traffic with DNSSEC
4.5.1. Introduction to DNSSEC
DNSSEC is a set of Domain Name System Security Extensions (DNSSEC) that enables a
DNSclient to authenticate and check the integrity of responses from a
DNSnameserver in order to verify their origin and to determine if they have been tampered with in transit.
4.5.2. Understanding DNSSEC
For connecting over the Internet, a growing number of websites now offer the ability to connect securely using
HTTPS. However, before connecting to an
DNSlookup must be performed, unless you enter the IP address directly. These
DNSlookups are done insecurely and are subject to man-in-the-middle attacks due to lack of authentication. In other words, a
DNSclient cannot have confidence that the replies that appear to come from a given
DNSnameserver are authentic and have not been tampered with. More importantly, a recursive nameserver cannot be sure that the records it obtains from other nameservers are genuine. The
DNSprotocol did not provide a mechanism for the client to ensure it was not subject to a man-in-the-middle attack. DNSSEC was introduced to address the lack of authentication and integrity checks when resolving domain names using
DNS. It does not address the problem of confidentiality.
Publishing DNSSEC information involves digitally signing
DNSresource records as well as distributing public keys in such a way as to enable
DNSresolvers to build a hierarchical chain of trust. Digital signatures for all
DNSresource records are generated and added to the zone as digital signature resource records (RRSIG). The public key of a zone is added as a DNSKEY resource record. To build the hierarchical chain, hashes of the DNSKEY are published in the parent zone as Delegation of Signing (DS) resource records. To facilitate proof of non-existence, the NextSECure (NSEC) and NSEC3 resource records are used. In a DNSSEC signed zone, each resource record set (RRset) has a corresponding RRSIG resource record. Note that records used for delegation to a child zone (NS and glue records) are not signed; these records appear in the child zone and are signed there.
Processing DNSSEC information is done by resolvers that are configured with the root zone public key. Using this key, resolvers can verify the signatures used in the root zone. For example, the root zone has signed the DS record for
.com. The root zone also serves NS and glue records for the
.comname servers. The resolver follows this delegation and queries for the DNSKEY record of
.comusing these delegated name servers. The hash of the DNSKEY record obtained should match the DS record in the root zone. If so, the resolver will trust the obtained DNSKEY for
.com. In the
.comzone, the RRSIG records are created by the
.comDNSKEY. This process is repeated similarly for delegations within
.com, such as
redhat.com. Using this method, a validating
DNSresolver only needs to be configured with one root key while it collects many DNSKEYs from around the world during its normal operation. If a cryptographic check fails, the resolver will return SERVFAIL to the application.
DNSSEC has been designed in such a way that it will be completely invisible to applications not supporting DNSSEC. If a non-DNSSEC application queries a DNSSEC capable resolver, it will receive the answer without any of these new resource record types such as RRSIG. However, the DNSSEC capable resolver will still perform all cryptographic checks, and will still return a SERVFAIL error to the application if it detects malicious
DNSanswers. DNSSEC protects the integrity of the data between
DNSservers (authoritative and recursive), it does not provide security between the application and the resolver. Therefore, it is important that the applications are given a secure transport to their resolver. The easiest way to accomplish that is to run a DNSSEC capable resolver on
/etc/resolv.conf. Alternatively a VPN connection to a remote
DNSserver could be used.
Understanding the Hotspot Problem
Wi-Fi Hotspots or VPNs rely on “DNS lies”: Captive portals tend to hijack
DNSin order to redirect users to a page where they are required to authenticate (or pay) for the Wi-Fi service. Users connecting to a VPN often need to use an “internal only”
DNSserver in order to locate resources that do not exist outside the corporate network. This requires additional handling by software. For example, dnssec-trigger can be used to detect if a Hotspot is hijacking the
unboundcan act as a proxy nameserver to handle the DNSSEC queries.
Choosing a DNSSEC Capable Recursive Resolver
To deploy a DNSSEC capable recursive resolver, either BIND or
unboundcan be used. Both enable DNSSEC by default and are configured with the DNSSEC root key. To enable DNSSEC on a server, either will work however the use of
unboundis preferred on mobile devices, such as notebooks, as it allows the local user to dynamically reconfigure the DNSSEC overrides required for Hotspots when using dnssec-trigger, and for VPNs when using Libreswan. The
unbounddaemon further supports the deployment of DNSSEC exceptions listed in the
etc/unbound/*.d/directories which can be useful to both servers and mobile devices.
4.5.3. Understanding Dnssec-trigger
unboundis installed and configured in
DNSqueries from applications are processed by
unbound. dnssec-trigger only reconfigures the
unboundresolver when triggered to do so. This mostly applies to roaming client machines, such as laptops, that connect to different Wi-Fi networks. The process is as follows:
- NetworkManager “triggers” dnssec-trigger when a new
DNSserver is obtained through
- Dnssec-trigger then performs a number of tests against the server and decides whether or not it properly supports DNSSEC.
- If it does, then dnssec-trigger reconfigures
unboundto use that
DNSserver as a forwarder for all queries.
- If the tests fail, dnssec-trigger will ignore the new
DNSserver and try a few available fall-back methods.
- If it determines that an unrestricted port 53 (
TCP) is available, it will tell
unboundto become a full recursive
DNSserver without using any forwarder.
- If this is not possible, for example because port 53 is blocked by a firewall for everything except reaching the network's
DNSserver itself, it will try to use
DNSto port 80, or
DNSto port 443. Servers running
DNSon port 80 and 443 can be configured in
/etc/dnssec-trigger/dnssec-trigger.conf. Commented out examples should be available in the default configuration file.
- If these fall-back methods also fail, dnssec-trigger offers to either operate insecurely, which would bypass DNSSEC completely, or run in “cache only” mode where it will not attempt new
DNSqueries but will answer for everything it already has in the cache.
Wi-Fi Hotspots increasingly redirect users to a sign-on page before granting access to the Internet. During the probing sequence outlined above, if a redirection is detected, the user is prompted to ask if a login is required to gain Internet access. The
dnssec-triggerdaemon continues to probe for DNSSEC resolvers every ten seconds. See Section 4.5.8, “Using Dnssec-trigger” for information on using the dnssec-trigger graphical utility.
4.5.4. VPN Supplied Domains and Name Servers
Some types of VPN connections can convey a domain and a list of nameservers to use for that domain as part of the VPN tunnel setup. On Red Hat Enterprise Linux, this is supported by NetworkManager. This means that the combination of
unbound, dnssec-trigger, and NetworkManager can properly support domains and name servers provided by VPN software. Once the VPN tunnel comes up, the local
unboundcache is flushed for all entries of the domain name received, so that queries for names within the domain name are fetched fresh from the internal name servers reached using the VPN. When the VPN tunnel is terminated, the
unboundcache is flushed again to ensure any queries for the domain will return the public IP addresses, and not the previously obtained private IP addresses. See Section 4.5.11, “Configuring DNSSEC Validation for Connection Supplied Domains”.
4.5.5. Recommended Naming Practices
Red Hat recommends that both static and transient names match the fully-qualified domain name (FQDN) used for the machine in
DNS, such as
The Internet Corporation for Assigned Names and Numbers (ICANN) sometimes adds previously unregistered Top-Level Domains (such as
.yourcompany) to the public register. Therefore, Red Hat strongly recommends that you do not use a domain name that is not delegated to you, even on a private network, as this can result in a domain name that resolves differently depending on network configuration. As a result, network resources can become unavailable. Using domain names that are not delegated to you also makes DNSSEC more difficult to deploy and maintain, as domain name collisions require manual configuration to enable DNSSEC validation. See the ICANN FAQ on domain name collision for more information on this issue.
4.5.6. Understanding Trust Anchors
In a hierarchical cryptographic system, a trust anchor is an authoritative entity which is assumed to be trustworthy. For example, in X.509 architecture, a root certificate is a trust anchor from which a chain of trust is derived. The trust anchor must be put in the possession of the trusting party beforehand to make path validation possible.
In the context of DNSSEC, a trust anchor consists of a
DNSname and public key (or hash of the public key) associated with that name. It is expressed as a base 64 encoded key. It is similar to a certificate in that it is a means of exchanging information, including a public key, which can be used to verify and authenticate
DNSrecords. RFC 4033 defines a trust anchor as a configured DNSKEY RR or DS RR hash of a DNSKEY RR. A validating security-aware resolver uses this public key or hash as a starting point for building the authentication chain to a signed DNS response. In general, a validating resolver will have to obtain the initial values of its trust anchors through some secure or trusted means outside the DNS protocol. Presence of a trust anchor also implies that the resolver should expect the zone to which the trust anchor points to be signed.
4.5.7. Installing DNSSEC
126.96.36.199. Installing unbound
In order to validate
DNSusing DNSSEC locally on a machine, it is necessary to install the
bind). It is only necessary to install dnssec-trigger on mobile devices. For servers,
unboundshould be sufficient although a forwarding configuration for the local domain might be required depending on where the server is located (LAN or Internet). dnssec-trigger will currently only help with the global public DNS zone. NetworkManager, dhclient, and VPN applications can often gather the domain list (and nameserver list as well) automatically, but not dnssec-trigger nor unbound.
unboundenter the following command as the
yum install unbound
188.8.131.52. Checking if unbound is Running
To determine whether the
unbounddaemon is running, enter the following command:
systemctl status unboundunbound.service - Unbound recursive Domain Name Server Loaded: loaded (/usr/lib/systemd/system/unbound.service; disabled) Active: active (running) since Wed 2013-03-13 01:19:30 CET; 6h ago
systemctl statuscommand will report
Active: inactive (dead)if the
unboundservice is not running.
184.108.40.206. Starting unbound
To start the
unbounddaemon for the current session, enter the following command as the
systemctl start unbound
systemctl enablecommand to ensure that
unboundstarts up every time the system boots:
systemctl enable unbound
unbounddaemon allows configuration of local data or overrides using the following directories:
NetworkManager, as well as some VPN software, may change the configuration dynamically. These configuration directories contain commented out example entries. For further information see the
/etc/unbound/conf.ddirectory is used to add configurations for a specific domain name. This is used to redirect queries for a domain name to a specific
DNSserver. This is often used for sub-domains that only exist within a corporate WAN.
/etc/unbound/keys.ddirectory is used to add trust anchors for a specific domain name. This is required when an internal-only name is DNSSEC signed, but there is no publicly existing DS record to build a path of trust. Another use case is when an internal version of a domain is signed using a different DNSKEY than the publicly available name outside the corporate WAN.
/etc/unbound/local.ddirectory is used to add specific
DNSdata as a local override. This can be used to build blacklists or create manual overrides. This data will be returned to clients by
unbound, but it will not be marked as DNSSEC signed.
220.127.116.11. Installing Dnssec-trigger
The dnssec-trigger application runs as a daemon,
dnssec-triggerd. To install dnssec-trigger enter the following command as the
yum install dnssec-trigger
18.104.22.168. Checking if the Dnssec-trigger Daemon is Running
To determine whether
dnssec-triggerdis running, enter the following command:
systemctl status dnssec-triggerdsystemctl status dnssec-triggerd.service dnssec-triggerd.service - Reconfigure local DNS(SEC) resolver on network change Loaded: loaded (/usr/lib/systemd/system/dnssec-triggerd.service; enabled) Active: active (running) since Wed 2013-03-13 06:10:44 CET; 1h 41min ago
systemctl statuscommand will report
Active: inactive (dead)if the
dnssec-triggerddaemon is not running. To start it for the current session enter the following command as the
systemctl start dnssec-triggerd
systemctl enablecommand to ensure that
dnssec-triggerdstarts up every time the system boots:
systemctl enable dnssec-triggerd
4.5.8. Using Dnssec-trigger
The dnssec-trigger application has a GNOME panel utility for displaying DNSSEC probe results and for performing DNSSEC probe requests on demand. To start the utility, press the Super key to enter the Activities Overview, type
DNSSECand then press Enter. An icon resembling a ships anchor is added to the message tray at the bottom of the screen. Press the round blue notification icon in the bottom right of the screen to reveal it. Right click the anchor icon to display a pop-up menu.
In normal operations unbound is used locally as the name server, and
127.0.0.1. When you click on the Hotspot Sign-On panel this is changed. The
DNSservers are queried from NetworkManager and put in
resolv.conf. Now you can authenticate on the Hotspot's sign-on page. The anchor icon shows a big red exclamation mark to warn you that
DNSqueries are being made insecurely. When authenticated, dnssec-trigger should automatically detect this and switch back to secure mode, although in some cases it cannot and the user has to do this manually by selecting Reprobe.
Dnssec-trigger does not normally require any user interaction. Once started, it works in the background and if a problem is encountered it notifies the user by means of a pop-up text box. It also informs
unboundabout changes to the
4.5.9. Using dig With DNSSEC
To see whether DNSSEC is working, one can use various command line tools. The best tool to use is the dig command from the bind-utils package. Other tools that are useful are drill from the ldns package and unbound-host from the unbound package. The old
DNSutilities nslookup and host are obsolete and should not be used.
To send a query requesting DNSSEC data using dig, the option
+dnssecis added to the command, for example:
~]$In addition to the A record, an RRSIG record is returned which contains the DNSSEC signature, as well as the inception time and expiration time of the signature. The
dig +dnssec whitehouse.gov; <<>> DiG 9.9.3-rl.13207.22-P2-RedHat-9.9.3-4.P2.el7 <<>> +dnssec whitehouse.gov ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 21388 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;whitehouse.gov. IN A ;; ANSWER SECTION: whitehouse.gov. 20 IN A 22.214.171.124 whitehouse.gov. 20 IN RRSIG A 7 2 20 20130825124016 20130822114016 8399 whitehouse.gov. BB8VHWEkIaKpaLprt3hq1GkjDROvkmjYTBxiGhuki/BJn3PoIGyrftxR HH0377I0Lsybj/uZv5hL4UwWd/lw6Gn8GPikqhztAkgMxddMQ2IARP6p wbMOKbSUuV6NGUT1WWwpbi+LelFMqQcAq3Se66iyH0Jem7HtgPEUE1Zc 3oI= ;; Query time: 227 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Aug 22 22:01:52 EDT 2013 ;; MSG SIZE rcvd: 233
unboundserver indicated that the data was DNSSEC authenticated by returning the
adbit in the
flags:section at the top.
If DNSSEC validation fails, the
digcommand would return a SERVFAIL error:
dig badsign-a.test.dnssec-tools.org; <<>> DiG 9.9.3-rl.156.01-P1-RedHat-9.9.3-3.P1.el7 <<>> badsign-a.test.dnssec-tools.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 1010 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;badsign-a.test.dnssec-tools.org. IN A ;; Query time: 1284 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Aug 22 22:04:52 EDT 2013 ;; MSG SIZE rcvd: 60]
To request more information about the failure, DNSSEC checking can be disabled by specifying the
+cdoption to the
dig +cd +dnssec badsign-a.test.dnssec-tools.org; <<>> DiG 9.9.3-rl.156.01-P1-RedHat-9.9.3-3.P1.el7 <<>> +cd +dnssec badsign-a.test.dnssec-tools.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26065 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;badsign-a.test.dnssec-tools.org. IN A ;; ANSWER SECTION: badsign-a.test.dnssec-tools.org. 49 IN A 126.96.36.199 badsign-a.test.dnssec-tools.org. 49 IN RRSIG A 5 4 86400 20130919183720 20130820173720 19442 test.dnssec-tools.org. E572dLKMvYB4cgTRyAHIKKEvdOP7tockQb7hXFNZKVbfXbZJOIDREJrr zCgAfJ2hykfY0yJHAlnuQvM0s6xOnNBSvc2xLIybJdfTaN6kSR0YFdYZ n2NpPctn2kUBn5UR1BJRin3Gqy20LZlZx2KD7cZBtieMsU/IunyhCSc0 kYw= ;; Query time: 1 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Aug 22 22:06:31 EDT 2013 ;; MSG SIZE rcvd: 257
Often, DNSSEC mistakes manifest themselves by bad inception or expiration time, although in this example, the people at www.dnssec-tools.org have mangled this RRSIG signature on purpose, which we would not be able to detect by looking at this output manually. The error will show in the output of
systemctl status unboundand the
unbounddaemon logs these errors to syslog as follows:
Aug 22 22:04:52 laptop unbound: [3065:0] info: validation failure badsign-a.test.dnssec-tools.org. A IN
An example using
unbound-host -C /etc/unbound/unbound.conf -v whitehouse.govwhitehouse.gov has address 188.8.131.52 (secure) whitehouse.gov has IPv6 address 2600:1417:11:2:8800::fc4 (secure) whitehouse.gov has IPv6 address 2600:1417:11:2:8000::fc4 (secure) whitehouse.gov mail is handled by 105 mail1.eop.gov. (secure) whitehouse.gov mail is handled by 110 mail5.eop.gov. (secure) whitehouse.gov mail is handled by 105 mail4.eop.gov. (secure) whitehouse.gov mail is handled by 110 mail6.eop.gov. (secure) whitehouse.gov mail is handled by 105 mail2.eop.gov. (secure) whitehouse.gov mail is handled by 105 mail3.eop.gov. (secure)
4.5.10. Setting up Hotspot Detection Infrastructure for Dnssec-trigger
When connecting to a network, dnssec-trigger attempts to detect a Hotspot. A Hotspot is generally a device that forces user interaction with a web page before they can use the network resources. The detection is done by attempting to download a specific fixed web page with known content. If there is a Hotspot, then the content received will not be as expected.
To set up a fixed web page with known content that can be used by dnssec-trigger to detect a Hotspot, proceed as follows:
- Set up a web server on some machine that is publicly reachable on the Internet. See the Web Servers chapter in the Red Hat Enterprise Linux 7 System Administrator's Guide.
- Once you have the server running, publish a static page with known content on it. The page does not need to be a valid HTML page. For example, you could use a plain-text file named
hotspot.txtthat contains only the string
OK. Assuming your server is located at
example.comand you published your
hotspot.txtfile in the web server
document_root/static/sub-directory, then the address to your static web page would be
example.com/static/hotspot.txt. See the
DocumentRootdirective in the Web Servers chapter in the Red Hat Enterprise Linux 7 System Administrator's Guide.
- Add the following line to the
url: "http://example.com/static/hotspot.txt OK"This command adds a URL that is probed using
HTTP(port 80). The first part is the URL that will be resolved and the page that will be downloaded. The second part of the command is the text string that the downloaded webpage is expected to contain.
For more information on the configuration options see the man page
4.5.11. Configuring DNSSEC Validation for Connection Supplied Domains
By default, forward zones with proper nameservers are automatically added into
unboundby dnssec-trigger for every domain provided by any connection, except Wi-Fi connections through NetworkManager. By default, all forward zones added into
unboundare DNSSEC validated.
The default behavior for validating forward zones can be altered, so that all forward zones will not be DNSSEC validated by default. To do this, change the
validate_connection_provided_zonesvariable in the dnssec-trigger configuration file
rootuser, open and edit the line as follows:
validate_connection_provided_zones=noThe change is not done for any existing forward zones, but only for future forward zones. Therefore if you want to disable DNSSEC for the current provided domain, you need to reconnect.
184.108.40.206. Configuring DNSSEC Validation for Wi-Fi Supplied Domains
Adding forward zones for Wi-Fi provided zones can be enabled. To do this, change the
add_wifi_provided_zonesvariable in the dnssec-trigger configuration file,
rootuser, open and edit the line as follows:
add_wifi_provided_zones=yesThe change is not done for any existing forward zones, but only for future forward zones. Therefore, if you want to enable DNSSEC for the current Wi-Fi provided domain, you need to reconnect (restart) the Wi-Fi connection.
Turning on the addition of Wi-Fi provided domains as forward zones into
unboundmay have security implications such as:
- A Wi-Fi access point can intentionally provide you a domain through
DHCPfor which it does not have authority and route all your
DNSqueries to its
- If you have the DNSSEC validation of forward zones turned off, the Wi-Fi provided
DNSservers can spoof the
IPaddress for domain names from the provided domain without you knowing it.
4.5.12. Additional Resources
The following are resources which explain more about DNSSEC.
220.127.116.11. Installed Documentation
dnssec-trigger(8)man page — Describes command options for
dnssec-triggerd, dnssec-trigger-control and dnssec-trigger-panel.
dnssec-trigger.conf(8)man page — Describes the configuration options for
unbound(8)man page — Describes the command options for
unbound.conf(5)man page — Contains information on how to configure
resolv.conf(5)man page — Contains information that is read by the resolver routines.
18.104.22.168. Online Documentation
- RFC 4033 DNS Security Introduction and Requirements.
- A website with links to many DNSSEC resources.
- The DNSSEC Deployment Initiative, sponsored by the Department for Homeland Security, contains a lot of DNSSEC information and has a mailing list to discuss DNSSEC deployment issues.
- The Internet Society's “Deploy 360” initiative to stimulate and coordinate DNSSEC deployment is a good resource for finding communities and DNSSEC activities worldwide.
- This document contains general information about the
- This document contains general information about dnssec-trigger.