DNS NXDOMAIN flood

[Björn Persson]

Mosharaf Hossain wrote:
> Hello Folks
> I have come across a challenge with our BIND nameserver, specifically
> related to a "*DNS NXDOMAIN flood*" problem. Despite upgrading the BIND
> version from 9.10 to 9.18, the issue persists.
> 
> The attack originates from an external network, and it periodically
> saturates our entire internet bandwidth. While we've implemented various
> measures to combat the attack, it continues to be a significant problem,
> rendering our DNS server incapable of resolving queries during these
> onslaughts.
> 
> Current DNS server spec:
> OS Debian 12
> BIND: BIND 9.18.19-1~deb12u1-Debian (Extended Support Version) <id:>
> 
> 
> *DNS NXDOMAIN flood Sample log:*
> Nov 02 09:00:23 ns1.bol-online.com named[2202594]: client @0x7fce7d2c1768
> 47.74.84.139#28827 (bearnote.primebank.com.bd): rate limit drop NXDOMAIN
> response to 47.74.84.0/24 for primebank.c>
> Nov 02 09:00:23 ns1.bol-online.com named[2202594]: client @0x7fce720cdd68
> 192.221.176.14#34882 (2014-06-24.pRiMEBANK.cOM.BD): rate limit drop
> NXDOMAIN response to 192.221.176.0/24 for prim>
> Nov 02 09:00:23 ns1.bol-online.com named[2202594]: client @0x7fce65cb9d68
> 74.125.187.132#53017 (HUbBY.PRimEBaNK.cOm.bD): rate limit drop NXDOMAIN
> response to 74.125.187.0/24 for primebank.>
> Nov 02 09:00:23 ns1.bol-online.com named[2202594]: client @0x7fce90fdb768
> 172.217.47.5#65160 (GEoVIsIOn.PrimeBAnk.COm.bD): rate limit drop NXDOMAIN
> response to 172.217.47.0/24 for primeban>
> Nov 02 09:00:23 ns1.bol-online.com named[2202594]: client @0x7fce99901b68
> 77.59.227.211#61265 (lanyware.primebank.com.bd): rate limit slip NXDOMAIN
> response to 77.59.227.0/24 for primebank>
> Nov 02 09:00:23 ns1.bol-online.com named[2202594]: client @0x7fce7ee5cd68
> 1.20.200.152#37953 (debianmeetingresume200809-kansai.primebank.com.bd):
> rate limit slip NXDOMAIN response to 1.20.>
> Nov 02 09:00:23 ns1.bol-online.com named[2202594]: client @0x7fce69846968
> 162.158.207.78#44948 (stacking.primebank.com.bd): rate limit drop NXDOMAIN
> response to 162.158.207.0/24 for primeb>

This looks like a DDOS attack on primebank.com.bd. It does not look
like a reflection attack on some other victim (and the log messages
indicate that rate limiting is in place to prevent amplification of
reflection attacks, so you seem to be good in that regard).

Of the seven client addresses in that sample, three belong to Google
and Cloudflare, who run well-known public resolvers (and the two
requests from Google have Google's signature mix of uppercase and
lowercase). One is an open resolver at a small company in Switzerland.
One seems to be a cloud datacenter in Australia. Two are assigned to
telecom companies in Thailand and the USA. A reflection attack wouldn't
attack all of those simultaneously.

My educated guess is that a botnet sends lots of requests to various
resolvers around the world, causing all of those resolvers to contact
the authoritative name servers for primebank.com.bd.

The attack seems designed to overload the processing capacity of the
authoritative name servers by requesting lots of nonexistent records.
An attack meant to saturate your bandwidth would usually just send big
packets full of nonsense. Either way the packets would need to be
dropped before they reach Bind, so the Bind configuration isn't the
right place to prevent this attack.

A beefy firewall might be able to detect the large number of NXDOMAIN
responses and drop requests from those source addresses before they
enter the saturated link – but that would also deny service to
legitimate clients using those same resolvers.

In general there's unfortunately little a victim of a DDOS attack can
do to stop the attack, other than hiding behind a DDOS mitigation
provider whose massive resources can absorb the onslaught. The only
real solution would be if the entire software industry would grow up
and stop shipping garbage that's easily hijacked and enrolled in
botnets.

Björn Persson
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signatur
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20231103/bdce873d/attachment-0001.sig>