disabling "Any" requests

[Dns Administrator]

Hi  bind-users,

   please excuse my ignorance being a novice to dns, but is there some way of disabling or choking "Any" type requests?

Very best regards Peter

[Chuck Swiger]

On Jul 12, 2012, at 2:27 AM, Dns Administrator wrote:
> Hi bind-users,
> please excuse my ignorance being a novice to dns, but is there some way of disabling or choking "Any" type requests?

Sure-- a firewall or even taking a pair of wire-cutters to the ethernet cable will accomplish that. :-)

Regards,
--
-Chuck

[Phil Mayers]

On 12/07/12 14:38, Chuck Swiger wrote:
> On Jul 12, 2012, at 2:27 AM, Dns Administrator wrote:
>> Hi bind-users,
>> please excuse my ignorance being a novice to dns, but is there some way of disabling or choking "Any" type requests?

This has been discussed on the list recently - see the archives.

[Lightner, Jeff]

Your answer was clearly meant to be tongue in cheek but I'm not sure you understood.

The OP wasn't asking how to stop all (any) lookups - it was how to stop "dig -t any" which isn't the same thing at all. Presumably they still want to allow dig -t mx, dig www... etc...

Personally I don't know why "dig -t any" would be a problem. It's not exactly the same as doing an axfr transfer of the zone - it still only gets limited information.

-----Original Message-----
From: bind-users-bounces+jlightner=wate...@lists.isc.org [mailto:bind-users-bounces+jlightner=wate...@lists.isc.org] On Behalf Of Chuck Swiger
Sent: Thursday, July 12, 2012 9:39 AM
To: Dns Administrator
Cc: bind-...@lists.isc.org
Subject: Re: disabling "Any" requests

On Jul 12, 2012, at 2:27 AM, Dns Administrator wrote:
> Hi bind-users,
> please excuse my ignorance being a novice to dns, but is there some way of disabling or choking "Any" type requests?

Sure-- a firewall or even taking a pair of wire-cutters to the ethernet cable will accomplish that. :-)

Regards,
--
-Chuck

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

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




Athena(r), Created for the Cause(tm)
Making a Difference in the Fight Against Breast Cancer

---------------------------------
CONFIDENTIALITY NOTICE: This e-mail may contain privileged or confidential information and is for the sole use of the intended recipient(s). If you are not the intended recipient, any disclosure, copying, distribution, or use of the contents of this information is prohibited and may be unlawful. If you have received this electronic transmission in error, please reply immediately to the sender that you have received the message in error, and delete it. Thank you.
----------------------------------

[Phil Mayers]

On 12/07/12 15:16, Lightner, Jeff wrote:

> Personally I don't know why "dig -t any" would be a problem. It's
> not exactly the same as doing an axfr transfer of the zone - it still
> only gets limited information.

They're the current query type du jour for DDoS amplification attacks,
which I assume the OP is experiencing.

Personally I feel it's a mistake to focus on the query type; as others
have pointed out, DNSSEC-signed TXT/SPF records are large, and
plentiful. Best just focus on query rate.

[sth...@nethelp.no]

> > Personally I don't know why "dig -t any" would be a problem. It's
> > not exactly the same as doing an axfr transfer of the zone - it still
> > only gets limited information.
>
> They're the current query type du jour for DDoS amplification attacks,
> which I assume the OP is experiencing.

The attackers have already diversified. TXT queries work just as well,
e.g. against wroe.com. Blocking ANY queries is going to a rather short
term "fix".

Steinar Haug, Nethelp consulting, sth...@nethelp.no

[Phil Mayers]

On 12/07/12 16:48, sth...@nethelp.no wrote:
>>> Personally I don't know why "dig -t any" would be a problem. It's
>>> not exactly the same as doing an axfr transfer of the zone - it still
>>> only gets limited information.
>>
>> They're the current query type du jour for DDoS amplification attacks,
>> which I assume the OP is experiencing.
>
> The attackers have already diversified. TXT queries work just as well,
> e.g. against wroe.com. Blocking ANY queries is going to a rather short
> term "fix".

Not unexpected. They are, sadly, not idiots, and are probably reading
the same mailing lists we are.

[Chuck Swiger]

On Jul 12, 2012, at 7:16 AM, Lightner, Jeff wrote:
> Your answer was clearly meant to be tongue in cheek but I'm not sure you understood.

Please allow me to reassure you that I understood the intent of the question. :-)

The point was that if one isn't clear about what one should allow and what one should forbid, spending lots of money on a fancy firewall box, or complicated rules creating restrictions for certain DNS query types is silly-- a pair of wirecutters provides better security for your money:

http://www.ranum.com/security/computer_security/papers/a1-firewall/
http://www.google.com/search?q=firewall+wizards+wirecutters

> The OP wasn't asking how to stop all (any) lookups - it was how to stop "dig -t any" which isn't the same thing at all. Presumably they still want to allow dig -t mx, dig www... etc...
>

> Personally I don't know why "dig -t any" would be a problem. It's not exactly the same as doing an axfr transfer of the zone - it still only gets limited information.

That's an extremely good question to ask, yes.

However, it should also lead to asking "why would you want to answer DNS queries at all for some client, if you've decided you want to block some types of queries?" If whoever it is making the DNS requests is a valid user of the nameserver, then you probably ought to figure out what's going on by talking with them before simply breaking things. If the queries aren't from a valid user, consider not answering any of queries, rather than just blocking some.

If the intent is to mitigate a DDOS/amplification attack but still allow public access to the nameserver, well, rate limiting queries seems to be a much more appropriate solution than blocking type=any.

Regards,
--
-Chuck

[Dns Administrator]

Thank you all very much for your advice.

Doing a general check on some dns servers in connection with an upcoming systems upgrade I noticed an unexpected spikiness when looking at the query logs

This I found was apparently caused by "ANY" queries from some few addresses and with a volume and a frequency, which lead me to believe that these queries didn't originate from "bono fido" users

Googling the issue I found that it was well known and had something to do with dns amplification and denial of service.

Stopping their ingress at a firewall doesn't appeal to me and as the "ANY" query isn't a realy type but more a wild card funtion I thought that maybe the isc folks had implemented some sort of configuration option which could control this 

But as so rightly pointed out the scamps who engage in this sort of foolishness would also be aware of this and change their scripts accordingly

Kind Regards Peter

ps I haven't stumbled across any coax cabling since the last millenium

---------- Forwarded message ----------
From: Chuck Swiger <csw...@mac.com>
Date: Thu, Jul 12, 2012 at 6:15 PM
Subject: Re: disabling "Any" requests

Regards,
--
-Chuck

[Stephane Bortzmeyer]

On Fri, Jul 13, 2012 at 10:26:55AM +0200,
Dns Administrator <dnsa...@gmail.com> wrote

a message of 186 lines which said:

> Googling the issue I found that it was well known and had something
> to do with dns amplification and denial of service.

Yes. Already discussed a lot on this list and on dns-operations.

> maybe the isc folks had implemented some sort of configuration
> option which could control this

You can do it outside of the name server, also. For instance, on
Linux, if the QNAME is fixed, let's say 'bad.example':

1) Get
<http://www.bortzmeyer.org/files/generate-netfilter-u32-dns-rule.py>

2) Run it with the proper options:

rule=$(python generate-netfilter-u32-dns-rule.py --qname bad.example --qtype ANY)

3) Use the output in a Netfilter rule:

iptables -A INPUT -p udp --dport 53 --match u32 --u32 "$rule" -j RATELIMITER

4) Rate-limit:

iptables -A RATELIMITER -m hashlimit \
--hashlimit-name DNS --hashlimit-above 20/second --hashlimit-mode srcip \
--hashlimit-burst 100 --hashlimit-srcmask 28 -j DROP

> But as so rightly pointed out the scamps who engage in this sort of
> foolishness would also be aware of this and change their scripts
> accordingly

My experience is that they don't do it immediately. Bad guys are
human, not demi-gods. Most attacks have obvious optimisations they do
not even use. A bad attitude in security is dismissing a partial and
limited solution because "attackers will adapt" while the reality is
that, even if they do, you'll have buy time.

Typical example: email greylisting, which works very well for many
years while several naysayers repeated "it's no good because the
spammers will adapt".

[Dns Administrator]

Hi

I though that it was a bit drastic removing the requests with iptables

I altered the code slightly - it appears to have the desired effect

ns_query_start() from query.c 

  if (dns_rdatatype_ismeta(qtype)) {

                switch (qtype) {

                case dns_rdatatype_any:

                        /* break; Let query_find handle it. */

                        ns_client_next(client, ISC_R_NOTIMPLEMENTED);

                        return;

                case dns_rdatatype_ixfr:

                case dns_rdatatype_axfr:

                        ns_xfr_start(client, rdataset->type);

                        return;

                case dns_rdatatype_maila:

                case dns_rdatatype_mailb:

                        query_error(client, DNS_R_NOTIMP, __LINE__);

                        return;

                case dns_rdatatype_tkey:

                        result = dns_tkey_processquery(client->message,

                                                ns_g_server->tkeyctx,

                                                client->view->dynamickeys);

                        if (result == ISC_R_SUCCESS)

                                query_send(client);

                        else

                                query_error(client, result, __LINE__);

                        return;

                default: /* TSIG, etc. */

                        query_error(client, DNS_R_FORMERR, __LINE__);

                        return;

                }

        }

---------- Forwarded message ----------
From: <WBr...@e1b.org>
Date: Fri, Jul 13, 2012 at 2:55 PM
Subject: Re: Fwd: disabling "Any" requests
To: Dns Administrator <dnsa...@gmail.com>

Peter wrote on 07/13/2012 04:26:55 AM:

> ps I haven't stumbled across any coax cabling since the last millenium

Wirecutters work on twisted pair just as well.  And as a extra bonus, they
work on fiber cables too!



Confidentiality Notice:
This electronic message and any attachments may contain confidential or
privileged information, and is intended only for the individual or entity
identified above as the addressee. If you are not the addressee (or the
employee or agent responsible to deliver it to the addressee), or if this
message has been addressed to you in error, you are hereby notified that
you may not copy, forward, disclose or use any part of this message or any
attachments. Please notify the sender immediately by return e-mail or
telephone and delete this message from your system.