nsd users - Apr 2022 - in-addr lame delegation DOS

Our name servers have recently fallen victim to a group who literally 
delegated 100's of IPv4 in-addr.arpa zones to our name servers blindly.

None of these in-addr arpa zones were setup, so our servers are just 
refusing the queries. Unfortunately NAKs are not cached very long, so 
the noise is fierce from tens of thousands of queries per second looking 
for PTR's for these name servers.

Right now the only way I've been able to mitigate this is by adding the 
zone with a wildcard PTR that answers something with a long TTL. This 
cut down on the queries by like 95% or more.

The problem is, we keep finding more and more in-addr.arpa zones being 
blindly delegated to us.

Other than finding and adding these zones one by one, would it be 
possible to add a zone for the very root of in-addr.arpa and wildcard 
everything in the zone?

ie:

Create a zone for 31.in-addr.arpa

In the zone add RR's

*  86400 IN   PTR  null.invalid.


Or would I have to do:

*.*.* PTR null.invalid ?


Etc. ?


Just looking for a way to tell them to "back off" until we can find
the
offenders and have them fix their delegations..

-- 
inoc.net!rblayzor
XMPP: rblayzor.AT.inoc.net
PGP:  https://pgp.inoc.net/rblayzor/

Hi Robert,

Providing "*" works fine and will return an answer. You may also opt
to
create an empty zone, in which case the TTL from the SOA is used for
NXDOMAIN responses.

Background:
For non-hosted zone NSD returns REFUSED and those answers are not
cached and have no TTL.

Best regards,
Jeroen


(NXDOMAIN suggestion and background kindly provided by Wouter :))


On Thu, 2022-04-21 at 14:37 -0400, Robert Blayzor via nsd-users
wrote:
> Our name servers have recently fallen victim to a group who literally
> delegated 100's of IPv4 in-addr.arpa zones to our name servers
> blindly.
> 
> None of these in-addr arpa zones were setup, so our servers are just 
> refusing the queries. Unfortunately NAKs are not cached very long, so
> the noise is fierce from tens of thousands of queries per second
> looking 
> for PTR's for these name servers.
> 
> Right now the only way I've been able to mitigate this is by adding
> the 
> zone with a wildcard PTR that answers something with a long TTL. This
> cut down on the queries by like 95% or more.
> 
> The problem is, we keep finding more and more in-addr.arpa zones
> being 
> blindly delegated to us.
> 
> Other than finding and adding these zones one by one, would it be 
> possible to add a zone for the very root of in-addr.arpa and wildcard
> everything in the zone?
> 
> ie:
> 
> Create a zone for 31.in-addr.arpa
> 
> In the zone add RR's
> 
> *? 86400 IN?? PTR? null.invalid.
> 
> 
> Or would I have to do:
> 
> *.*.* PTR null.invalid ?
> 
> 
> Etc. ?
> 
> 
> Just looking for a way to tell them to "back off" until we can
find
> the 
> offenders and have them fix their delegations..
>