Link to home
Start Free TrialLog in
Avatar of JWeb Admin
JWeb Admin

asked on

BIND rate-limit - DNS for web server requests

I have recently been reading up on securing our BIND installation, which includes the rate-limit feature of BIND 9.

I want to put into place the following rate-limit parameters:

rate-limit { responses-per-second 10; window 5; };

Open in new window


Our DNS servers are primarily responsible for doing non-recursive lookups for our company's email, and web sites.  I need to make sure that putting rate-limit into place won't affect the DNS lookups for several of our website domains.  We have high volumes of traffic and want to make sure this rate limiting won't cause lookups to time out.  I would expect that 10 responses per second is a good amount to start with, correct?

Also, I found that incorporating iptables rules help in dropping certain types of requests.  Will this work below? It translates to Accept no more than 11 packets within a timeframe of 60 seconds, drop all other packets.

iptables -A INPUT -p udp --dport 53 -m recent --set --name dnslimit
iptables -A INPUT -p udp --dport 53 -m recent --update --seconds 60 --hitcount 11 --name dnslimit -j DROP

Open in new window


Would like to confirm that both of these changes to our BIND config will not interfere and block legitimate traffic or requests.
Avatar of Jan Bacher
Jan Bacher
Flag of United States of America image

Have you looked at the logs or run wireshark for any period of time to determine what your threshold should be?
Avatar of JWeb Admin
JWeb Admin

ASKER

Do you recommend that we run wireshark on our BIND servers and analyze?

Also - I don't currently have BIND logging configured.
Set these in your named.conf:

statistics-file /path/to/filename;
zone-statistics yes;

and reload named.

If you're chrooted, put the file in /var/named/chroot/var/named/data with the owner/group of named.

You should be able to use "rndc stats".
OK great - so I'll collect some data and see if I can report back.  We have 4 public DNS servers.
I would create a script and set a cron job to run every 5 minutes that does an "rndc stats", parses the output file and gets the delta between the two for the number during that 5 minute period.

Or manually run it once a day at the same time for a few days to get an idea of how many queries you can expect.
websites don't use DNS, browsers use DNS. Email is a heavy user of DNS.  Rather than using rate limiting why don't you just block port 53 from the WAN using your firewall?

If you insist on using rate limiting you should at least get a baseline of the DNS requests, find out what your peak is and then add 10% as a cushion.
I'm getting:

Error in named configuration:
/etc/named.conf:13: unknown option 'statistics-file'
/etc/named.conf:14: unknown option 'zone-statistics'

Open in new window

what version of bind are you running?
@David Johnson - I understand websites don't use DNS - however when a browser requests a domain name it does a lookup on our DNS servers on port 53 UDP, so blocking port 53 would result in the request being blocked.  

My goal is to ensure that if a web browser does a DNS lookup on our name servers, that rate limiting doesn't cause lookups to time out.  I am unsure how many requests per second a web browser does a lookup.
@ Jan Springer - BIND 9.8.2rc1-RedHat-9.8.2-0.37.rc1.el6_7.5
Did you place them in the "options" section?
options {
        statistics-file "/var/named/data/named_stats.txt";
      zone-statistics yes;

        //other option statements

};

If you're chrooted:

    named-checkconf -t /var/named/chroot /etc/named.conf

If you're not chrooted:

    named-checkconf /etc/named.conf
I got it - Had to move the lines up, it must have been trying to load those commands under the notify section, was off by a semi colon.  Thanks, trying rndc now.
It should print to STDOUT.  If not, "cat" the file.

And, the file gets updated every time that you run that command.
I've specified the following in named.conf:

statistics-file "/var/named/chroot/var/named/data/named_stats.txt";
zone-statistics yes;

Open in new window


Created the dir here (we are chrooted):

/var/named/chroot/var/named/data

Owners:

root@DNS1 named]# ll
total 44
drwxr-xr-x  2 named named  4096 Apr  6 09:55 data
drwxr-xr-x. 2 named named 36864 Apr  5 09:09 masters

Open in new window


Restarted named, I don't see a file in there yet.
SOLUTION
Avatar of David Johnson, CD
David Johnson, CD
Flag of Canada image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
After you restart named, run "rndc stats" to generate a file.
Thank you - but I still need to know if responses-per-second being set to 10 with a window of 5 is appropriate, which is why I'm trying to collect stats and analyze them based on the number of lookups that are happening on any given server at a time in order to prevent response timeouts.
This is what happens:

root@DNS1 data]# rndc stats
rndc: 'stats' failed: file not found

Open in new window

I had to set this in named.conf (I am chrooted, which is why I don't understand why the file didn't get created)

statistics-file "/var/named/data/named_stats.txt";

Open in new window

Now that I have this file created and its collecting stats, how can I take the data within that file and confirm which value for responses-per-second is appropriate?
Then my suggestion is to log queries and parse the log or wireshark the queries and parse the results.
ASKER CERTIFIED SOLUTION
Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Great help as always.
Looks like we're somewhere around 45-50 average queries per second.  Based on rndc querylog and a test rate limit of 15 requests per second with a window of 5, I'm still seeing some requests potentially being dropped.

However, I don't know if this is related to BIND, or syslog rate-limiting??

Apr  6 13:19:32 ns1 rsyslogd-2177: imuxsock begins to drop messages from pid 6325 due to rate-limiting
Apr  6 13:19:33 ns1 rsyslogd-2177: imuxsock lost 34 messages from pid 6325 due to rate-limiting
Apr  6 13:19:37 ns1 rsyslogd-2177: imuxsock begins to drop messages from pid 6325 due to rate-limiting
Apr  6 13:19:39 ns1 rsyslogd-2177: imuxsock lost 64 messages from pid 6325 due to rate-limiting
Apr  6 13:19:50 ns1 rsyslogd-2177: imuxsock begins to drop messages from pid 6325 due to rate-limiting
Apr  6 13:19:51 ns1 rsyslogd-2177: imuxsock lost 42 messages from pid 6325 due to rate-limiting
Apr  6 13:19:54 ns1 rsyslogd-2177: imuxsock begins to drop messages from pid 6325 due to rate-limiting
Apr  6 13:19:57 ns1 rsyslogd-2177: imuxsock lost 157 messages from pid 6325 due to rate-limiting
Apr  6 13:20:00 ns1 rsyslogd-2177: imuxsock begins to drop messages from pid 6325 due to rate-limiting
Apr  6 13:20:03 ns1 rsyslogd-2177: imuxsock lost 112 messages from pid 6325 due to rate-limiting
Apr  6 13:20:08 ns1 rsyslogd-2177: imuxsock begins to drop messages from pid 6325 due to rate-limiting
Apr  6 13:20:09 ns1 rsyslogd-2177: imuxsock lost 8 messages from pid 6325 due to rate-limiting
Apr  6 13:20:19 ns1 rsyslogd-2177: imuxsock begins to drop messages from pid 6325 due to rate-limiting
Apr  6 13:20:21 ns1 rsyslogd-2177: imuxsock lost 76 messages from pid 6325 due to rate-limiting
Apr  6 13:20:21 ns1 named[6325]: *would stop limiting error responses to 199.7.48.0/24
Apr  6 13:20:23 ns1 rsyslogd-2177: imuxsock begins to drop messages from pid 6515 due to rate-limiting
Apr  6 13:20:36 ns1 rsyslogd-2177: imuxsock lost 975 messages from pid 6515 due to rate-limiting

Open in new window

syslog is doing the rate limiting here.
That's what I thought - I gave it a few more minutes (doing log-only) and started seeing these:

Apr  6 13:29:13 ns1 named[6865]: would limit  responses to 208.255.90.0/24

Open in new window


Thank you!
Just so I understand this correctly:

responses-per-second is how many responses per second for an identical query from a single subnet.

So, if a client/subnet makes a DNS request and receives an answer, why would they make another additional, identical request?  If we drop their connection, does the client actually see a failure to resolve and perform the DNS lookup, or will they not notice because they already have an answer?  Why would they perform a duplicate, identical query?  Do you happen to know what types of clients make identical queries this many times per second?
You dont drop a connection as there is no connection with UDP. You just dont respond to queries for short time after. Duplicate query can come in due to network problems. Common resolvers retry 3-5 times at 5-45s intervals. And it does not happen often...