Using Unbound for recursive DNS lookup

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 🙂

4 thoughts on “Using Unbound for recursive DNS lookup

  1. Davide says:

    Why cache poisoning it’s easier to be done on a autoritative+recursive server, than a only recursive one?

  2. Jeremy says:

    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!!!

Leave a Reply

Your email address will not be published. Required fields are marked *