Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

We all know about open resolvers, this question is kind of for the inverse situation. I have a DNS server that is locked down to certain CIDRs acl trusted {[..]

options {
allow-query {
            // Accept queries from our "trusted" ACL.  We will
            // allow anyone to query our master zones below.
            // This prevents us from becoming a free DNS server
            // to the masses.

This works.

However it doesn't stop infected hosts within the allowed ranges to send spoofed (most commonly type ANY) requests. Those are resolved and the response still sent to the spoofed IP that "requested" it (which is usually the target of the attackers).

How to prevent the DNS server from resolving domains requested outside the trusted ranges? Is that even something bind should be doing?

share|improve this question
Can you clarify whether or not you are operating a mixed mode server? (recursive+auth) It is not an industry best practice, and the comment you included from the borrowed configuration may be leading answers in the wrong direction. – Andrew B Apr 12 '14 at 3:14
Yes turns out this is the restriction atm, they have to be able to do both jobs. – Recct Apr 14 '14 at 9:03

3 Answers 3

up vote 10 down vote accepted

This isn't a problem you should be trying to solve at the service layer.

  • Don't allow off-net traffic to make inbound requests to your DNS listeners.
  • Perform source address validation of packets generated by your customers (if applicable). This prevents amplification attacks originating from inside of your network.

These problems are rooted in the design of the network topology sitting in front of you. It is a losing battle to try and address these issues from the server itself.

share|improve this answer
"Perform source address validation of packets generated by your customers" do you mean validation on the edge of the network or customer equipment or? – Recct Apr 11 '14 at 16:14
Your routers would need functionality that allows you to drop packets spoofed by customers, i.e. have source addresses outside of your network. I'm not a networking engineer unfortunately, just a DNS admin. – Andrew B Apr 11 '14 at 16:29
@Recc covers the general idea – Håkan Lindqvist Apr 12 '14 at 0:46

The comments in the configuration excerpt in the question refer to your servers answering authoritatively for some zones. For a scenario where the attacker abuses an authoritative server it would make sense to configure Response Rate Limiting to mitigate this.

In the case of attacks abusing a server with recursion enabled, however, locking down recursion access to your own network in combination with ingress filtering is the best way to stop this. (As suggested by @Andrew-B.)

Regarding BIND specifically it's essential to understand how the different allow-* configuration directives interact when you override one of more of them (without that understanding it's not that obvious how, for instance, overriding allow-query affects other directives such as allow-recursion).

share|improve this answer
The comment in question comes from a stock BIND configuration. (Google) – Andrew B Apr 12 '14 at 3:02

There are a number of approaches you can take. You may want to combine them.

  • Use split DNS configure the external zone to reject recursion. Split DNS will allow you to provide an non-recursive authoritative DNS server externally, and a full functioning recursive DNS server internally. Consider logging the failed requests.
  • Block unwanted networks from sending requests to your servers. (Port 53 UDP and TCP.) This can be done at the external firewall or, on some systems including Debian, the server's firewall. Consider limiting the the CIDRs that can query your server to those it should support.
  • Use fail2ban to dynamically block requesting networks.

From your question it appears you have a number of computers infected with botnet software. It is important you identify and cleanse these systems. That is beyond the scope of this question. If your routers support it, consider limiting the IP addresses which can originate requests.

share|improve this answer
Upvoting, but keep in mind that these solutions do not scale to carrier grade. DNS is a known killer of firewalls, and fail2ban-esque solutions are not an option when you have business tier customers. – Andrew B Apr 12 '14 at 3:16

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.