Bug 536 - [PATCH] add ACLs for local-zone-only service
[PATCH] add ACLs for local-zone-only service
Status: RESOLVED FIXED
Product: unbound
Classification: Unclassified
Component: server
unspecified
Other Linux
: P5 normal
Assigned To: unbound team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-05 10:51 CET by Travis Snoozy
Modified: 2013-11-12 11:10 CET (History)
1 user (show)

See Also:


Attachments
add ACLs deny_non_local and refuse_non_local (4.84 KB, patch)
2013-11-05 10:51 CET, Travis Snoozy
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Travis Snoozy 2013-11-05 10:51:19 CET
Created attachment 242 [details]
add ACLs deny_non_local and refuse_non_local

To use Unbound to serve a (sub)domain to the Internet, either the "allow" or "allow_snoop" ACLs have to be used, both of which allow a full recursive lookup. This runs contrary to best practice in the context of DNS amplification attacks (http://www.us-cert.gov/ncas/alerts/TA13-088A). It would be preferable if the Internet at large could only perform recursive queries to Unbound for the DNS records it is acting as the authoritative server for.

I have created the attached patch which adds two new ACL levels: "deny_non_local" and "reject_non_local." These allow Unbound to serve its authoritative data to public Internet addresses, while restricting access (using either the "deny" or "reject" behavior) to arbitrary recursive requests.

I have verified that with this patch, IPv6 addresses on my local network can make full recursive requests as before, but that IPv6 addresses outside of my local network can only make requests for zones defined directly in Unbound's config (with both deny_non_local and refuse_non_local). I have not tested this patch with IPv4, but it shouldn't matter. Famous last words. ;)

The patch applies to the current trunk.
Comment 1 Wouter Wijngaards 2013-11-11 15:07:16 CET
Hi Travis,

Your patch is of excellent quality and I would like to include it, but for some (annoying) questions.

What makes you run unbound as an authority server to the wider internet?  What sort of content does it serve?  Shouldn't you have a separate authority server (like NSD) on another IP address, that unbound queries as a stub-zone and the wider-population has full access to?

There is some guidance on DNS operations to not mix recursive and authority servers.  (e.g. RFC and from RIPE I believe).  Hence, these questions.

But I also understand that unbound needs to have a little authority server capacity to be able to fulfill it's role in your organisation, and I would like to find out if this feature is necessary for that.

Best regards,
   Wouter
Comment 2 Travis Snoozy 2013-11-11 21:36:26 CET
"What sort of content does it serve?"

It currently contains local zone data for one delegated subdomain. That local zone data (aside from SOA and NS glue entries) contains AAAA and ptr entries.

It also contains one private-domain that serves A records for important servers on the local (192.168.0.0) network, though those aren't relevant to the public Internet.

Unbound is configured to serve records to IPv4 on the local network only, and over a globally-accessible IPv6 address.

"What makes you run unbound as an authority server to the wider internet?"

What got me started was that I needed a DNS server accessible via IPv6 only as part of the set up for a private instance of test-ipv6.

Currently, I'm continuing to run Unbound as the authority server for a single subdomain because it is more convenient to control that data locally than it is to go mess with my hosting service's DNS web interface when I want to make changes. It is, however, no longer required for truly technical reasons.

"Shouldn't you have a separate authority server (like NSD) on another IP address, that unbound queries as a stub-zone and the wider-population has full access to?"

That's reasonable from a general-principals standpoint. In this case, re-use of Unbound was the least-complicated solution. There are a number of ways which it could be set up in the manner you've described, but they'd require ripping up my infra to various degrees to implement.

- Use a second physical server. That's additional expense for my SOHO setup, and reduced runtime on the UPS.

- Set up virtualization and run a second (virtual) server. The machine is fairly resource-limited, and virtualization for just this task would be a pretty overkill solution.

- Issue two IPv6 addresses to the machine, and run two different DNS resolvers. 
* It looks like this would require switching off of radvd autoconf and onto DHCPv6 (which my router doesn't support as either a server or client, meaning it would have to take a static config of some sort).
* Use another Ethernet card/USB dongle and get another (permanent, global) IPv6 address assigned to it "for free" via radvd.
* That's a second piece of software that needs to be installed, configured, maintained, and understood... which serves pretty much the same purpose :)

- Run two isolated instances of the same DNS resolver. Most distros don't natively support starting multiple instances of the same service (Ubuntu doesn't seem to); would require creating and maintaining custom tweaks to the startup and configuration scripts.

Thus, it made the most sense to me to write this patch and serve up the data from just one place. The runner-up (for ease/least hassle) would be to get a USB Ethernet dongle.
Comment 3 Wouter Wijngaards 2013-11-12 11:10:10 CET
Hi Travis,

I have included the patch into our svn repository, it is in svn trunk.  Thanks for the additional code.  I changed it to add documentation for the new options.

Best regards, Wouter