[nsd-users] in-addr lame delegation DOS

Jeroen Koekkoek jeroen at nlnetlabs.nl
Fri Apr 22 07:26:07 UTC 2022


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



More information about the nsd-users mailing list