Some organizations decide to use its internal authoritative DNS servers as recursive DNS because of easiness and reverse lookup of internal RFC 1918 networks works out of the box. That should be avoided for (at least) two reasons:
- Cache poisoning can cause security nightmares
- Authoritative answers are never cached and can cause a high load on the DNS servers.
Cache poisoning is a problem that can lead to severe problems, as more and more information is stored in DNS. Examples:
- SSHFP entries for SSH fingerprint of servers
- SRV entries for LDAP and Kerberos server autodetection
If an attacker can manipulate those kind of entries it can potentially be abused for redirecting users to fake authentication services.
There are some protective measures to avoid this kind of problems:
- The usage of a separate recursive DNS infrastructure
- Setting up DNSSEC and sign your DNS zones
- The use of TLS for LDAP queries
This article is about how to set up recursive DNS servers, DNSSEC will be covered in a follow-up article.
Turning off recursion in authoritative DNS servers
In the option section of the bind DNS configuration make sure you have the following line in /etc/named.conf:
allow-recursion { none; };
If you are using a different DNS server software, check the vendor manual. After a restart, check if it is working as expected.
[luc@bond ~]$ dig www.example.com @ipa2.delouw.ch ; <<>> DiG 9.10.4-P6-RedHat-9.10.4-4.P6.fc25 <<>> www.example.com @ipa2.delouw.ch ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58272 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; WARNING: recursion requested but not available ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;www.example.com. IN A ;; Query time: 0 msec ;; SERVER: 192.168.100.106#53(192.168.100.106) ;; WHEN: Sat Apr 15 12:10:15 CEST 2017 ;; MSG SIZE rcvd: 44 [luc@bond ~]$
Using Unbound as recursive DNS
Unbound is very secure, lightweight and high performance DNS server for validating, recursion, and caching of queries. Its astonishing how easy it is to configure Unbound.
Installation on RHEL7, Fedora and probably other Linux and BSD distributions is easy:
recursor1:~# yum -y install unbound
For this example, all configuration is made in /etc/unbound/unbound.conf
First you must define on which IPs Unbound should listen. The default is localhost only.
interface: 0.0.0.0 interface: ::0
The next default that needs to be changed is the access control. Default to refuse all but localhost. In this example you will allow access from two of your RFC 1918 subnets and the RFC 3849 IPv6 range.
access-control: 0.0.0.0/0 refuse access-control: 127.0.0.0/8 allow access-control: 192.168.1.0/24 allow access-control: 192.168.2.0/24 allow access-control: ::1 allow access-control: 2001:DB8::/32 allow
Forward PTR queries to your RFC 1918 zones
Unbound has a nice default setting: It ignores any queries to RFC 1918 PTR queries to avoid sending queries to the blackhole servers.
In this example, we need to change the behavior to allow queries for our internal networks 192.168.1.0 and 192.168.2.0.
local-zone: "1.168.192.in-addr.arpa." transparent local-zone: "2.168.192.in-addr.arpa." transparent
Next up: Forward this queries to our internal DNS server infrastructure (i.e IPA or MS-DNS or simply bind)
forward-zone: name: "1.168.192.in-addr.arpa." forward-host: ipa1.example.com forward-host: ipa2.example.com forward-host: ipa3.example.com forward-zone: name: "2.168.192.in-addr.arpa." forward-host: ipa1.example.com forward-host: ipa2.example.com forward-host: ipa3.example.com
This will forward queries at random to DNS servers ipa1,ipa2 and ipa3.example.com. Add more servers as needed.
The final step is to (re)configure your clients to use the newly set up recursive DNS servers.
Have fun 🙂
Why cache poisoning it’s easier to be done on a autoritative+recursive server, than a only recursive one?
Its not easier, but the result is probably worse. Its “bad practice” to mix up the two types of DNS servers. Please also have a look at http://cr.yp.to/djbdns/separation.html
If i am using jails to separate services and assuming my firewall is set up correctly, is violating the best practice of separating the 2 dns services still an issue? The dns can only be reached by my jailed environments and it is only allowed outgoing tcp and udp on 53. What’s your opinion? Great article by the way!!!
Hi,
Jails are kind of a weak isolation, using two VMs or containers would be a better option