Mitigation of server's load by queries for non-existing domains

[Tomas Hozza]

Hello all.

Recently I was trying to find a mechanism in BIND that could prevent the server 
from processing a recursive query for non-existing domains. The issue I was 
trying to solve was that when server was getting too many queries for such 
domains it was not able to handle other relevant queries. The non-exiting 
domains have just few common non-existing parent domains, so one can match most 
of them by wildcard RR.

I was thinking about using RPZ with QNAME policy trigger, but this applies only 
to the responses to queries and still makes the server to try to resolve it. As 
far as I'm familiar with RRL, it will also not help, since it also applies to 
the response to a query.

One possible solution that came to my mind was to define a zone for each of the 
"parent" domains and then just return localhost address or something similar to 
any query to that domain. I know this is kind of dummy, but this was the first 
thing that came to my mind. I know the server will still process the query, but 
will at least not do any recursion.

Is there any better mechanism to solve such problem?

Thank you in advance.

Regards,
Tomas
-- 
Tomas Hozza
Senior Software Engineer - EMEA ENG Developer Experience

PGP: 1D9F3C2D
UTC+1 (CET)
Red Hat Inc. http://cz.redhat.com
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Mitigation of server's load by queries for non-existing domains

[Tony Finch]

Tomas Hozza  wrote:
>
> Recently I was trying to find a mechanism in BIND that could prevent the
> server from processing a recursive query for non-existing domains.

Have a look at https://www.isc.org/blogs/tldr-resolver-ddos-mitigation/

> I was thinking about using RPZ with QNAME policy trigger, but this
> applies only to the responses to queries and still makes the server to
> try to resolve it.

RPZ has a "qname-wait-recurse no" option.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Rockall, Malin: Northwest becoming cyclonic later, 5 to 7 occasionally gale 8
at first. Rough or very rough, becoming moderate or rough. Rain or showers.
Moderate or good.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Mitigation of server's load by queries for non-existing domains

[Mukund Sivaraman]

Hi Tomas

On Tue, Jan 12, 2016 at 05:53:20PM +0100, Tomas Hozza wrote:
> Hello all.
> 
> Recently I was trying to find a mechanism in BIND that could prevent
> the server from processing a recursive query for non-existing
> domains. The issue I was trying to solve was that when server was
> getting too many queries for such domains it was not able to handle
> other relevant queries. The non-exiting domains have just few common
> non-existing parent domains, so one can match most of them by wildcard
> RR.

The attack you are describing is probably the well-known-by-now attack
called "water torture" or "random subdomain" attack. If you search for
these phrases, you'll see several presentations made on the topic.

> I was thinking about using RPZ with QNAME policy trigger, but this
> applies only to the responses to queries and still makes the server to
> try to resolve it. As far as I'm familiar with RRL, it will also not
> help, since it also applies to the response to a query.
> 
> One possible solution that came to my mind was to define a zone for
> each of the "parent" domains and then just return localhost address or
> something similar to any query to that domain. I know this is kind of
> dummy, but this was the first thing that came to my mind. I know the
> server will still process the query, but will at least not do any
> recursion.
> 
> Is there any better mechanism to solve such problem?

This is an on-going problem for DNS and several measures are being
considered:

Making aggressive use of NSEC/NSEC3:
https://tools.ietf.org/html/draft-fujiwara-dnsop-nsec-aggressiveuse-01

Bloom filtering from queries:
https://github.com/hdais/unbound-bloomfilter

Evan Hunt is considering proposing another bloom filtering method by
using a bloom bitfield RR. We are thinking of what else could help,
including tagging of malware clients via RPZ zones provided by relevant
feed providers.

There are some measures in 9.10.3 (read about "fetches-per-server" and
"fetches-per-zone" in the ARM).

Mukund


signature.asc
Description: PGP signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

named.conf Default Location?

[Tim Daneliuk]

I have two FreeBSD 10 machines on which I have installed the bind99 port.

The manpage for named on machine 1 says that it looks for the named.conf
by default in /usr/local/etc/namedb.  Machine 2's manpage says it looks
in /etc/namedb.   

Which is correct?  Is the /etc/namedb symlink even needed anymore?

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: named.conf Default Location?

[John W. Blue]

Tim,

I too prefer to run BIND on FreeBSD boxes.  I am running 9.10.3-P2 from ports 
and named.conf can only be found in:

/use/local/etc/named/

Not know the exact history of your boxes, I would say it is not needed.

John

Sent from Nine

From: Tim Daneliuk 
Sent: Jan 12, 2016 11:31 AM
To: Bind Users
Subject: named.conf Default Location?

I have two FreeBSD 10 machines on which I have installed the bind99 port.

The manpage for named on machine 1 says that it looks for the named.conf
by default in /usr/local/etc/namedb.  Machine 2's manpage says it looks
in /etc/namedb.

Which is correct?  Is the /etc/namedb symlink even needed anymore?

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users