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 through DHCP . 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 that DNS 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 and TCP ) is available, it will tell unbound to become a full recursive DNS 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 use DNS to port 80, or TLS encapsulated DNS to port 443. Servers running DNS 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: 4.5.7.2. Checking if unbound is Running To determine whether the unbound daemon is running, enter the following command: 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: Run the systemctl enable command to ensure that unbound starts up every time the system boots: 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 specific DNS 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 specific DNS data 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. 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.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: 4.5.7.5. Checking if the Dnssec-trigger Daemon is Running To determine whether dnssec-triggerd is running, enter the following command: 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: Run the systemctl enable command to ensure that dnssec-triggerd starts up every time the system boots: 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 OK 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: 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: To request more information about the failure, DNSSEC checking can be disabled by specifying the +cd option to the dig command: 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 : 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 string OK . Assuming your server is located at example.com and you published your hotspot.txt file 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 DocumentRoot 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 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 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=no The 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=yes The 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 your DNS queries to its DNS servers. If you have the DNSSEC validation of forward zones turned off , the Wi-Fi provided DNS servers can spoof the IP 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 for dnssec-triggerd , dnssec-trigger-control and dnssec-trigger-panel . dnssec-trigger.conf(8) man page - Describes the configuration options for dnssec-triggerd . unbound(8) man page - Describes the command options for unbound , the DNS validating resolver. unbound.conf(5) man page - Contains information on how to configure unbound . 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 .

Commands:
~]# yum install unbound
~]USD 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
~]# systemctl start unbound
~]# systemctl enable unbound
~]# yum install dnssec-trigger
~]USD 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
~]# systemctl start dnssec-triggerd
~]# systemctl enable dnssec-triggerd
~]USD 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
~]USD 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]
~]USD 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
~]USD 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)