# BIND DNS format error: Possible DDoS attack?



## micski (Apr 22, 2021)

I was notified, that a BIND DNS server, which is authorative for a number of domains, is open to abuse for DDoS attacks, targeting other networks. When testing on MX Tool, there is no problems according to the report.

Looking into the logs, there actually is tons of messages about a format error on different unknown IP adresses. I have not been unable to find out, what that error message is about.


```
Apr 22 15:01:02 thisserver named[705]: DNS format error from 104.243.45.190#53 resolving 75.208.54.110.in-addr.arpa/PTR for 127.0.0.1#25018: Name in-addr.arpa (SOA) not subdomain of zone 208.54.110.in-addr.arpa -- invalid response
```

The DNS server is authoritative for a number of domains, so I assume, it should be open for queries, but otherwise restricted. Is it possible, that the configuration below can lead to abuse? Keep in mind, that the DNS server is authoritative for a number of domains, and, that it has other primary DNS servers (GratisDNS).


```
options {
  directory             "/usr/local/etc/namedb/working";
  pid-file              "/var/run/named/pid";
  dump-file             "/var/dump/named_dump.db";
  statistics-file       "/var/stats/named.stats";
  listen-on { any; };
  disable-empty-zone "255.255.255.255.IN-ADDR.ARPA";
  disable-empty-zone "0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0>
  disable-empty-zone "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0>
  allow-query { any; };
  allow-query-cache { any; };
  allow-recursion { users; };
  allow-transfer { users; gratisdns; };
};
```

One of the domains:


```
zone "somedomain.dk"
{
  type master;
  notify yes;
  also-notify { 91.221.196.11; };
  allow-transfer { gratisdns; };
  file "/usr/local/etc/namedb/master/somedomain.dk";
};
```

I would be very glad, if any kind soul could bring a hint to solve a possible security concern in this configuration.


----------



## SirDice (Apr 22, 2021)

Bots are constantly scanning for badly configured DNS servers they can abuse. Usually via a spoofed recursive query. If you really want to know what's happening you're going to need to capture the traffic and analyze it. But I'm assuming they're just trying all sorts of tricks to "fool" your server into responding.


----------



## micski (Apr 22, 2021)

So, if I understand this correct, what is happening is, that DDoS bots are running tricky DNS spoofed recursive queries and is succesful, because the BIND access control list system is not sufficient?


----------



## SirDice (Apr 22, 2021)

As far as I can tell they're not successful, but those modified queries are causing errors to be logged. Because BIND does find there's something wrong with those queries, and it's warning you about it.

But the best way would be to capture that traffic and analyze it yourself. Then you can try to figure out what they're actually trying to do.


----------



## covacat (Apr 22, 2021)

if you are not a public dns just deny queries for non authoritative zones (eg dont allow outsiders to ask you about google / facebook  / whatever just the domains you are authoritative)
allow query only for "users / local networks or what have you)


----------



## SirDice (Apr 22, 2021)

covacat said:


> if you are not a public dns just deny queries for non authoritative zones (eg dont allow outsiders to ask you about google / facebook / whatever just the domains you are authoritative)
> allow query only for "users / local networks or what have you)


That's what `allow-recursion` does.


----------



## covacat (Apr 22, 2021)

SirDice said:


> That's what `allow-recursion` does.


right. but why are you allowing cache access to the world ?


----------



## Jose (Apr 23, 2021)

covacat said:


> right. but why are you allowing cache access to the world ?


That does seem like a problem


> If a query is blocked by *allow-query-cache*, the response is REFUSED,  as with *allow-query*. If it passes *allow-query-cache* but is blocked by *allow-recursion* (an unusual situation these days), the query is  handled as if it were not recursive.











						What's the difference between allow-query-cache and allow-recursion?
					

allow-query governs who can send any query to the BIND 9 server, not just queries against authoritative data.




					kb.isc.org


----------



## sko (Apr 23, 2021)

What that notification was talking about were probably DNS reflection/amplification attacks. Those could be carried out on *any* open resolver, as those attacks are using nothing but the desired behaviour of a nameserver: They send hundreds of thousands of (non-resolvable) request from a spoofed source address (=target) via botnets to as many nameservers as possible, so that target gets DDoSed by the millions of error replies frem the nameservers that think this host asked for some non-existent DNS record.

For nameservers that are authorative for a/some zone(s), you usually don't want them to serve as 'generic' nameservers (i.e. recursive resolvers for clients), but *only* serve the zones they are responsible for. This way you can close down that nameserver very tightly and also identify and mitigate attacks relatively easily by blacklisting hosts/IPs that repeatedly send request for zones that the server isn't responsible for. As a first line of defense you should also always configure rate-limits.
To serve the clients in your networks you usually use separate, internal (caching) resolvers, not the authorative nameservers for your zones.

If you *have* to run an open resolver, you should absolutely have finely tuned rate-limits [1] in place. IIRC from BIND 9.10 onwards rate-limit can be set globally and per view, so you could set higher thresholds for your own networks than for the rest of the world. Usually you don't need to run an open resolver even if you run big networks and/or public prefixes - so double- and triple-check if you think you *really* need a fully open resolver, because in most cases you were wrong...

[1] https://bind9.readthedocs.io/en/latest/reference.html?#response-rate-limiting


----------

