Recursive DNS and FreeIPA

DNS is essential to Kerberos. Kerberos Identity for servers is based around host names, and if you don’t have a common view between client and server, you will not be able to access your remote systems. Since DNS is an essential part of FreeIPA, BIND is one of the services integrated into the IPA server.

When a user wants to visit a public website, like this one, they click a link or type that URL into their browsers navigation bar. The browser then requests the IP address for the hostname inside the URL from the operating system via a library call. On a Linux based system, the operating system makes the DNS call to the server specified in /etc/resolv.conf. But what happens if the DNS server does not know the answer? It depends on how it is configured. In the simple case, where the server is not allowed to make additional calls, it returns a response that indicates the record is not found.

Since IPA is supposed to be the one-source-of-truth for a client system, it is common practice to register the IPA server as the sole DNS resolver. As such, it cannot just short-circuit the request. Instead, it performs a recursive search to the machines it has set up as Forwarders. For example, I often will set up a sample server that points to the google resolver at 8.8.8.8. Or, now CloudFlare has DNS privacy enabled, I might use that.

This is fine inside controlled environments, but is sub-optimal if the DNS portion of the IPA server is accessible on the public internet. It turns out that forwarding requests allows a DNS server to be used to attack these DNS servers via a distributed denial of service attack. In this attack, the attackers sends the request to all DNS servers that are acting as forwarders, and these forwarders hammer on the central DNS servers.

If you have set up a FreeIPA server on the public internet, you should plan on disabling Recursive DNS queries. You do this by editing the file /etc/named.conf and setting the values:

allow-recursion {"none";};
recursion no;

And restarting the named service.

And then everything breaks. All of your IPA clients can no longer resolve anything except the entries you have in your IPA server.

The fix for that is to add the (former) DNS forward address as a nameserver entry in /etc/resolv.conf on each machine, including your IPA server. Yes, it is a pain, but it limits the query capacity to only requests local to those machines. For example, if my IPA server is on 10.10.2.1 (yes I know this is not routable, just for example) my resolve.conf would look like.

search younglogic.com
nameserver 10.10.2.1
nameserver 1.1.1.1

If you wonder if your Nameserver has this problem, use this site to test it.

2 thoughts on “Recursive DNS and FreeIPA

  1. What you really want is an authoritative DNS server for your public domain and you need a local private recursion server that can query your authoritative DNS server + the public recursive DNS systems. You then overload the libc resolver (/etc/resolv.conf) expecting it to handle querying your local authoritative server *and* upstream public recursive DNS servers e.g. cloudflare/google/opendns.

    The libc resolver is not intended to try all servers in /etc/resolv.conf. It treats those entries as recursive DNS servers that one of which will provide authoritative information on a domain. Specifically, you do not want your authoritative DNS server to return NXDOMAIN and 1.1.1.1 to return X.X.X.X for google.com. The resolver should take the first response it receives and treat that as authoritative and move on. As your authoritative server should be closer/faster to respond, you should always receive NXDOMAIN responses from it, or you’re going to have slow DNS with non-responses or other hacks from bind to allow the libc resolver to query 1.1.1.1 for the entry too. Setting up the libc resolver to query all servers simultaneously or randomly is going to have bad consequences in this use-case in the future.

    If your FreeIPA server is handling public DNS, something other than a *.local extension, you need to register the NS entries with the registrar to properly have recursive servers resolve your domain. This server should, as you indicated, not have recursion enabled to prevent the attack you describe. However, this server should be considered a domain authoritative server and should *not* be included in any DNS clients.

    The solution is to run two DNS servers. One DNS server is authoritative for your domain, registered with the domain registrar, and has recursion disabled. A second DNS server is non-authoritative, is recursive, and handles client requests and will discover your authoritative DNS server.

Leave a Reply

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