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
DNS
client to authenticate and check the integrity of responses from a DNS
nameserver 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 HTTPS
webserver, a DNS
lookup must be performed, unless you enter the IP address directly. These DNS
lookups are done insecurely and are subject to man-in-the-middle attacks due to lack of authentication. In other words, a DNS
client cannot have confidence that the replies that appear to come from a given DNS
nameserver 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 DNS
protocol 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
DNS
resource records as well as distributing public keys in such a way as to enable DNS
resolvers to build a hierarchical chain of trust. Digital signatures for all DNS
resource 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 .com
name servers. The resolver follows this delegation and queries for the DNSKEY record of .com
using 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 .com
zone, the RRSIG records are created by the .com
DNSKEY. This process is repeated similarly for delegations within .com
, such as redhat.com
. Using this method, a validating DNS
resolver 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
DNS
answers. DNSSEC protects the integrity of the data between DNS
servers (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 localhost
and use 127.0.0.1
in /etc/resolv.conf
. Alternatively a VPN connection to a remote DNS
server could be used.
Understanding the Hotspot Problem
Wi-Fi Hotspots or VPNs rely on “DNS lies”: Captive portals tend to hijack
DNS
in 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” DNS
server 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 DNS
queries and unbound
can 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
unbound
can 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 unbound
is 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 unbound
daemon 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
Once
unbound
is installed and configured in /etc/resolv.conf
, all DNS
queries from applications are processed by unbound
. dnssec-trigger only reconfigures the unbound
resolver 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
DNS
server is obtained throughDHCP
. - 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
unbound
to use thatDNS
server as a forwarder for all queries. - If the tests fail, dnssec-trigger will ignore the new
DNS
server and try a few available fall-back methods. - If it determines that an unrestricted port 53 (
UDP
andTCP
) is available, it will tellunbound
to become a full recursiveDNS
server 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
DNS
server itself, it will try to useDNS
to port 80, orTLS
encapsulatedDNS
to port 443. Servers runningDNS
on 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
DNS
queries 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-trigger
daemon 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 unbound
cache 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 unbound
cache 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 host.example.com
.
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
DNS
name 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 DNS
records. 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
4.5.7.1. Installing unbound
In order to validate
DNS
using DNSSEC locally on a machine, it is necessary to install the DNS
resolver unbound
(or bind
). It is only necessary to install dnssec-trigger on mobile devices. For servers, unbound
should 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.
To install
unbound
enter the following command as the root
user:
~]# yum install unbound
4.5.7.2. Checking if unbound is Running
To determine whether the
unbound
daemon is running, enter the following command:
~]$ systemctl status unbound
unbound.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
The
systemctl status
command will report unbound
as Active: inactive (dead)
if the unbound
service is not running.
4.5.7.3. Starting unbound
To start the
unbound
daemon for the current session, enter the following command as the root
user:
~]# systemctl start unbound
Run the
systemctl enable
command to ensure that unbound
starts up every time the system boots:
~]# systemctl enable unbound
The
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
unbound
daemon allows configuration of local data or overrides using the following directories:
- The
/etc/unbound/conf.d
directory is used to add configurations for a specific domain name. This is used to redirect queries for a domain name to a specificDNS
server. This is often used for sub-domains that only exist within a corporate WAN. - The
/etc/unbound/keys.d
directory 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. - The
/etc/unbound/local.d
directory is used to add specificDNS
data as a local override. This can be used to build blacklists or create manual overrides. This data will be returned to clients byunbound
, but it will not be marked as DNSSEC signed.
unbound.conf(5)
man page.
4.5.7.4. Installing Dnssec-trigger
The dnssec-trigger application runs as a daemon,
dnssec-triggerd
. To install dnssec-trigger enter the following command as the root
user:
~]# yum install dnssec-trigger
4.5.7.5. Checking if the Dnssec-trigger Daemon is Running
To determine whether
dnssec-triggerd
is running, enter the following command:
~]$ systemctl status dnssec-triggerd
systemctl 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
The
systemctl status
command will report dnssec-triggerd
as Active: inactive (dead)
if the dnssec-triggerd
daemon is not running. To start it for the current session enter the following command as the root
user:
~]# systemctl start dnssec-triggerd
Run the
systemctl enable
command to ensure that dnssec-triggerd
starts 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
DNSSEC
and 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
resolv.conf
points to 127.0.0.1
. When you click on the Hotspot Sign-On panel this is changed. The DNS
servers 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 DNS
queries 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
unbound
about changes to the resolv.conf
file.
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
DNS
utilities nslookup and host are obsolete and should not be used.
To send a query requesting DNSSEC data using dig, the option
+dnssec
is added to the command, for example:
~]$ 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 72.246.36.110
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
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 unbound
server indicated that the data was DNSSEC authenticated by returning the ad
bit in the flags:
section at the top.
If DNSSEC validation fails, the
dig
command 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
+cd
option to the dig
command:
~]$ 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 75.119.216.33
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 unbound
and the unbound
daemon 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
:
~]$ unbound-host -C /etc/unbound/unbound.conf -v whitehouse.gov
whitehouse.gov has address 184.25.196.110 (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.txt
that contains only the stringOK
. Assuming your server is located atexample.com
and you published yourhotspot.txt
file in the web serverdocument_root/static/
sub-directory, then the address to your static web page would beexample.com/static/hotspot.txt
. See theDocumentRoot
directive in the Web Servers chapter in the Red Hat Enterprise Linux 7 System Administrator's Guide. - Add the following line to the
/etc/dnssec-trigger/dnssec-trigger.conf
file:url: "http://example.com/static/hotspot.txt OK"
This command adds a URL that is probed usingHTTP
(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
dnssec-trigger.conf(8)
.
4.5.11. Configuring DNSSEC Validation for Connection Supplied Domains
By default, forward zones with proper nameservers are automatically added into
unbound
by dnssec-trigger for every domain provided by any connection, except Wi-Fi connections through NetworkManager. By default, all forward zones added into unbound
are 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_zones
variable in the dnssec-trigger configuration file /etc/dnssec.conf
. As root
user, 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.
4.5.11.1. 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_zones
variable in the dnssec-trigger configuration file, /etc/dnssec.conf
. As root
user, 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.
Warning
Turning on the addition of Wi-Fi provided domains as forward zones into
unbound
may have security implications such as:
- A Wi-Fi access point can intentionally provide you a domain through
DHCP
for which it does not have authority and route all yourDNS
queries to itsDNS
servers. - If you have the DNSSEC validation of forward zones turned off, the Wi-Fi provided
DNS
servers can spoof theIP
address 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.
4.5.12.1. Installed Documentation
dnssec-trigger(8)
man page — Describes command options fordnssec-triggerd
, dnssec-trigger-control and dnssec-trigger-panel.dnssec-trigger.conf(8)
man page — Describes the configuration options fordnssec-triggerd
.unbound(8)
man page — Describes the command options forunbound
, theDNS
validating resolver.unbound.conf(5)
man page — Contains information on how to configureunbound
.resolv.conf(5)
man page — Contains information that is read by the resolver routines.
4.5.12.2. Online Documentation
- http://tools.ietf.org/html/rfc4033
- RFC 4033 DNS Security Introduction and Requirements.
- http://www.dnssec.net/
- A website with links to many DNSSEC resources.
- http://www.dnssec-deployment.org/
- 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.
- http://www.internetsociety.org/deploy360/dnssec/community/
- The Internet Society's “Deploy 360” initiative to stimulate and coordinate DNSSEC deployment is a good resource for finding communities and DNSSEC activities worldwide.
- http://www.unbound.net/
- This document contains general information about the
unbound
DNS
service. - http://www.nlnetlabs.nl/projects/dnssec-trigger/
- This document contains general information about dnssec-trigger.