[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