]> Forwarding DNS and DNSSEC 🌐:aligrant.com

Forwarding DNS and DNSSEC

Alastair Grant | Friday 20 February 2015

My local DNS server is, of course, DNSSEC enabled. It will validate whether a domain should be signed and is signed before allowing clients to resolve it. This provides a significant boost to security by limiting the ability DNS can be hijacked (so you can't go to your banks web-site but actually be redirected to a different server posing with the same DNS name).

This has been working well for a long time and hasn't caused me any issues. Until today. I have a requirement to forward requests for a private subdomain to another server. The domain is an internal one and so isn't registered in the public DNS system. This is fairly common and most organisations will have setup something like this. Microsoft recommend you use [companyname].local.

The snag comes when my DNS server (Bind 9.9) attempts to validate the responses. As part of DNSSEC it will check with the parent domain, which will ultimately bubble up to ".", or the root of the domain system. In the situation where you are resolving computer.company.local, the root domain will need to validate the .local part. Alas, as it's a private domain, the root has no record of it and happily confirms that there is no .local.

Thus everything under .local will fail to resolve as it's clearly a hacking attempt (or not).

Unfortunately, with the Bind server, there doesn't appear to be any sensible workaround. You could disable DNSSEC, which a lot of people do, and make everything insecure (do _not_ do this). Or, helpfully, the stock reply from the general arrogant Bind and Linux pimping Internet crowd is to simply sign the private domain.

This though, does not help. As even if you do have control over the domain (which is unlikely as you probably wouldn't be using a forward if you were), you still don't have an entry logged in the root of the domain system.

The take home is not to use private domains internally. Instead you can use a publicly registered domain and use a split-horizon if you want to keep internal systems from being resolved externally. For example, instead of using company.local, use local.company.com. Your local sub-domain can still only be visible internally but you'll avoid problems like this in the future and when we finally all move over to IPv6. Obviously that's not something that can be easily implemented retroactively so bear that in mind when you next setup a domain.

If you're stuck there is a dirty hack that will work providing the domains you're forwarding aren't top-level; the company.local example here can be fixed by creating a master zone for .local and then delegating the subdomain "company" to the forwarders using a made up glue record. e.g.

$ORIGIN company.local
@  IN NS  glue.company.local.
glue  IN A

Obviously with all the gumph that makes a zone file up. When querying anything against company.local it'll be delegated to the IP address against the made up "glue" record. You can call this whatever you like.

I raised this as a bug with ISC and they have told me they're considering permanent negative trust anchors, which will allow you to disable validation for a zone, but currently they're only planning on doing this for a maximum of a week, which would be an administrative nightmare.

Breaking from the voyeuristic norms of the Internet, any comments can be made in private by contacting me.