7

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.
            trusted;
};

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?

Andrew B
  • 32,588
  • 12
  • 93
  • 131
Recct
  • 370
  • 1
  • 3
  • 22
  • 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 03:14
  • Yes turns out this is the restriction atm, they have to be able to do both jobs. – Recct Apr 14 '14 at 09:03

3 Answers3

10

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.

Andrew B
  • 32,588
  • 12
  • 93
  • 131
  • "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
  • 1
    @Recc http://tools.ietf.org/html/bcp38 covers the general idea – Håkan Lindqvist Apr 12 '14 at 00:46
2

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.

BillThor
  • 27,737
  • 3
  • 37
  • 69
  • 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 03:16
  • fail2ban is going to do the wrong thing when UDP IP addresses are spoofed. – user1133275 Jul 06 '23 at 14:45
2

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).

Håkan Lindqvist
  • 35,011
  • 5
  • 69
  • 94
  • The comment in question comes from a stock BIND configuration. ([Google](https://www.google.com/search?q="This+prevents+us+from+becoming+a+free+DNS+server"&oq="This+prevents+us+from+becoming+a+free+DNS+server")) – Andrew B Apr 12 '14 at 03:02