4.5. Securing DNS Traffic with DNSSEC
4.5.1. Introduction to DNSSEC
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
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.
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.
.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.
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
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
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.
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
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
DNS, 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
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
220.127.116.11. Installing unbound
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
18.104.22.168. Checking if unbound is Running
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.
22.214.171.124. Starting unbound
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:
/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.
126.96.36.199. Installing Dnssec-trigger
dnssec-triggerd. To install dnssec-trigger enter the following command as the
yum install dnssec-trigger
188.8.131.52. Checking if the Dnssec-trigger Daemon is Running
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
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.
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.
unboundabout changes to the
4.5.9. Using dig With DNSSEC
DNSutilities nslookup and host are obsolete and should not be used.
+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 184.108.40.206 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.
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]
+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 220.127.116.11 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
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
unbound-host -C /etc/unbound/unbound.conf -v whitehouse.govwhitehouse.gov has address 18.104.22.168 (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
- 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.
4.5.11. Configuring DNSSEC Validation for Connection Supplied Domains
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.
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.
22.214.171.124. Configuring DNSSEC Validation for Wi-Fi Supplied Domains
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.
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
126.96.36.199. 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.
188.8.131.52. 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.