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?

2
  • 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, 2014 at 3:14
  • Yes turns out this is the restriction atm, they have to be able to do both jobs.
    – Recct
    Apr 14, 2014 at 9:03

3 Answers 3

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.

3
  • "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, 2014 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, 2014 at 16:29
  • 1
    @Recc tools.ietf.org/html/bcp38 covers the general idea Apr 12, 2014 at 0:46
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).

1
  • The comment in question comes from a stock BIND configuration. (Google)
    – Andrew B
    Apr 12, 2014 at 3:02
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.

2
  • 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, 2014 at 3:16
  • fail2ban is going to do the wrong thing when UDP IP addresses are spoofed. Jul 6, 2023 at 14:45

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .