lot of 'ripe.net IN ANY +ED' queries
Hi all, I am new subscriber of your list. I browsed the archive but didn't find answer/hint for my problem. I am running (at FreeBSD 9.1-PRERELEASE) public caching DNS server. Since about 2 months I've been receiving lot of (DNS flood attack?) queries like: 23-Jul-2012 14:03:28.813 queries: info: client 96.44.152.125#53: view external: query: ripe.net IN ANY +ED (my.dns.server.ip) What I made now, is just to parse logs and block IPs that ask for ripe.net via ipfw. But is there any other solutions for that permanent attacks? Or should I contact my ISP ? Thanks for help! Regards, -- Marek Salwerowicz ___ 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: lot of 'ripe.net IN ANY +ED' queries
On 23/07/12 13:07, Marek Salwerowicz wrote: Hi all, I am new subscriber of your list. I browsed the archive but didn't find answer/hint for my problem. I am running (at FreeBSD 9.1-PRERELEASE) public caching DNS server. Since about 2 months I've been receiving lot of (DNS flood attack?) queries like: 23-Jul-2012 14:03:28.813 queries: info: client 96.44.152.125#53: view external: query: ripe.net IN ANY +ED (my.dns.server.ip) What I made now, is just to parse logs and block IPs that ask for ripe.net via ipfw. But is there any other solutions for that permanent attacks? This is getting to be an FAQ. It's a source-spoofed amplification attacks. See the list archives for discussion, including links to a patch for bind with per-client rate-limiting. ___ 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: lot of 'ripe.net IN ANY +ED' queries
On Mon, Jul 23, 2012 at 02:07:51PM +0200, Marek Salwerowicz marek_...@wp.pl wrote a message of 30 lines which said: What I made now, is just to parse logs and block IPs that ask for ripe.net via ipfw. As mentioned by Phil Mayers, the source IP address is forged. By blocking this IP, you strike the victim. But is there any other solutions for that permanent attacks? The operators of F-root use this on their FreeBSD machines to rate-limit per source IP: add pipe 1 udp from any to any 53 in pipe 1 config mask src-ip 0x buckets 1024 bw 400Kbit/s queue 3 add pipe 2 tcp from any to any 53 in pipe 2 config mask src-ip 0x buckets 1024 bw 100Kbit/s queue 3 ___ 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: lot of 'ripe.net IN ANY +ED' queries
W dniu 2012-07-23 14:33, Stephane Bortzmeyer pisze: But is there any other solutions for that permanent attacks? The operators of F-root use this on their FreeBSD machines to rate-limit per source IP: add pipe 1 udp from any to any 53 in pipe 1 config mask src-ip 0x buckets 1024 bw 400Kbit/s queue 3 add pipe 2 tcp from any to any 53 in pipe 2 config mask src-ip 0x buckets 1024 bw 100Kbit/s queue 3 It looks nice, as I can now block the traffic on my firewall, instead of DNS server. Thanks. BTW - is this attack any new kind of virus/spyware or sth ? -- Marek Salwerowicz ___ 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: lot of 'ripe.net IN ANY +ED' queries
On Mon, Jul 23, 2012 at 03:09:35PM +0200, Marek Salwerowicz marek_...@wp.pl wrote a message of 18 lines which said: BTW - is this attack any new kind of virus/spyware or sth ? Not every security problem on the Internet is a virus. And I do not see why a spyware would like to DoS people. There are apparently different attackers, the specifics of the attack varies a lot. Let's say it it now a recognized weapon in the typical bad guy's toolbox (it is theoretically known for many years but has been widely adopted only in last november/december when the number of reports suddenly increased). ___ 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: lot of 'ripe.net IN ANY +ED' queries
Dne 23.7.2012 15:09, Marek Salwerowicz napsal(a): BTW - is this attack any new kind of virus/spyware or sth ? Actually, I think these queries to ripe.net ANY with EDNS0 are caused by some common malware. My servers are receiving these from time to time and complaining to a person responsible for source IP address is enough to stop it. So in this case, the source address is probably not spoofed. The only question is: Why is the malware doing it? I use linux netfilter's hashlimit target to limit queries to reasonable rate, with a special lower rate for ANY-type queries. I use this iptables matcher to identify incoming query type: https://github.com/oskar456/xt_dns Cheers, Ondřej Caletka, CESNET, z.s.p.o. http://www.ces.net smime.p7s Description: Elektronický podpis S/MIME ___ 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: lot of 'ripe.net IN ANY +ED' queries
On Mon, Jul 23, 2012 at 04:42:11PM +0200, Ond?ej Caletka ondrej.cale...@cesnet.cz wrote a message of 159 lines which said: I use this iptables matcher to identify incoming query type: https://github.com/oskar456/xt_dns Buggy. It parses the DNS packet from the end and therefore fails with EDNS packets (which have the OPT resource record at the end). ___ 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: rndc stats command
Hi, Thanks for your kind response. sorry for the delay. Currently i make a logic with shell scripts is that i run my statistics.sh by cron via every 1 minute and collect INCOMING QUERY AND CACHE HIT RATIO. CACHE HIT RATIO = (IN COMING QUERY - RECURSION ) / INCOMING QUERY. Let say i run first time : 10.00 AM First i clean named_Stat file and then run rndc stats command so it will write statistics to named_stat file and then i collect incoming query numbers and cache hit ratio. Second time run same logic : 10.01 AM so this time i again get incoming query numbers and hit ratio value and while plotting these by rrdtool, i remove old value ( 10.00 AM ) from current value ( 10.01 AM) and get actual value. same fashion, i run above logic for time frame. Kindly correct me , if i am running wrong logic. when i run rndc stats , it gives me full outpur.can i get only certain output from it by any command or something? My concern is that to find QPS / no. of queries per RR / hit ratio. Best Regards, Ben On Jul 18 2012, Ben wrote: Hi, As per man page and my understanding rndc stats writes a current named statistics into defined file in named.conf so suppose, if i run rndc stats command and then i take required information from named statistics file. And after some time, ( after 5 minutes or approx.) when i do again rndc stats , so that times it provides new statistics.? My understanding is that while running rndc stats , it writes current named statistics to defined file and internally it flush named statistics ( which wrote into file as per named.conf ) And while second time run same command , again it append fresh/new named statistics to defined fiel, is it so? Or is there any interval for rndc / named to generate fresh/new statistics.? Kindly correct me if I am missing something... I think you are missing at least the following: rndc stats *appends* to the statistics file. It doesn't overwrite any previous contents. rndc stats does not reset the internal statistics counters (I take it that was what you meant by flush). They are always accumulative from when named was last started. From two successive set of ststistics written by rndc stats, you can deduce what happened during the interval by taking the difference in the values of corresponding counters, and to deduce rates you divide by the length of the interval which you can deduce from the difference in their timestamps +++ Statistics Dump +++ (1342566900) ... --- Statistics Dump --- (1342566900) ^^ which are in time_t format (seconds since the Unix epoch). [What's annoyingly missing, by the way, is the time when named was in fact started. That's present in the XML on the statistics channel, but not in the file written by rndc stats.] ___ 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: lot of 'ripe.net IN ANY +ED' queries
On Mon, 23 Jul 2012, Stephane Bortzmeyer wrote: The operators of F-root use this on their FreeBSD machines to rate-limit per source IP: add pipe 1 udp from any to any 53 in pipe 1 config mask src-ip 0x buckets 1024 bw 400Kbit/s queue 3 add pipe 2 tcp from any to any 53 in pipe 2 config mask src-ip 0x buckets 1024 bw 100Kbit/s queue 3 But that will totally ruin djb's claim that dnssec is the cause of the internet melt down! Paul ___ 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
using 127.0.0.1 in resolv.conf
Hey there folks, I was just going back through the good ol' cricket book, and ran into the following: If you use multiple nameserver directives, don't use the loopback address! There's a bug in some Berkeley-derived TCP/IP implementations that can cause problems with BIND if the local nameserver is down. The resolver's connected datagram socket won't rebind to a new local address if the local nameserver isn't running, and consequently the resolver sends query packets to the fallback remote nameservers with a source address of 127.0.0.1. When the remote nameservers try to reply, they end up sending the reply packets to themselves. Given that this same text is in the fourth edition of Cricket Paul's book as well, I'm assuming this was an old bug (pre-BIND 9) and has long since been fixed. Could someone point me to a bug report and/or changelog for this? A quick Google search for 'bind resolver source address bug' didn't yield much. John -- John Miller Systems Engineer Brandeis University 781-736-4619 johnm...@brandeis.edu ___ 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: using 127.0.0.1 in resolv.conf
We've been running with 127.0.0.1 in /etc/resolv.conf for years, on a wide variety of platforms (including Berkeley-derived ones), and never run into this bug. 127.0.0.1 in /etc/resolv.conf is good from a configuration-consistency standpoint: it helps prevent the fairly-common accident where /etc/resolv.conf is copied verbatim from an old server to its replacement, and then DNS resolution on the replacement stops working or degrades performance, when the old server is shut down and the IP address that's listed first in /etc/resolv.conf is no longer available (or other permutations, such as highly-firewalled environments where the server configured with the blindly-copied /etc/resolv.conf can't even talk to the server from which that file was copied). In theory, using 127.0.0.1 in /etc/resolv.conf might also help to offload traffic from a NIC, if the NIC driver is written so poorly that it fails to recognize and short circuit traffic destined for one of the local addresses configured on the NIC. The only minor drawback is that one can experience unexpected results, in sortlisting terms, when performing diagnostics from the box itself, since the loopback address is normally not included in a sortlist statement. This is only a minor drawback, however, since it only applies to one use case for a feature (sortlisting) that most folks don't use anyway... - Kevin On 7/23/2012 5:13 PM, John Miller wrote: Hey there folks, I was just going back through the good ol' cricket book, and ran into the following: If you use multiple nameserver directives, don't use the loopback address! There's a bug in some Berkeley-derived TCP/IP implementations that can cause problems with BIND if the local nameserver is down. The resolver's connected datagram socket won't rebind to a new local address if the local nameserver isn't running, and consequently the resolver sends query packets to the fallback remote nameservers with a source address of 127.0.0.1. When the remote nameservers try to reply, they end up sending the reply packets to themselves. Given that this same text is in the fourth edition of Cricket Paul's book as well, I'm assuming this was an old bug (pre-BIND 9) and has long since been fixed. Could someone point me to a bug report and/or changelog for this? A quick Google search for 'bind resolver source address bug' didn't yield much. John ___ 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: using 127.0.0.1 in resolv.conf
I also use loopback regularly if running a localhost resolver; in fact I use a script that goes as far as changing resolv.conf if it detects an interface address instead of loopback. [Our rules require listening on loopback minimally here] If you do use it, I recommend you make sure you don't have options rotate set as that'll cause confusion as it's most likely not your intent if you're running a nameserver locally. On Mon, Jul 23, 2012 at 5:13 PM, John Miller johnm...@brandeis.edu wrote: Hey there folks, I was just going back through the good ol' cricket book, and ran into the following: If you use multiple nameserver directives, don't use the loopback address! There's a bug in some Berkeley-derived TCP/IP implementations that can cause problems with BIND if the local nameserver is down. The resolver's connected datagram socket won't rebind to a new local address if the local nameserver isn't running, and consequently the resolver sends query packets to the fallback remote nameservers with a source address of 127.0.0.1. When the remote nameservers try to reply, they end up sending the reply packets to themselves. Given that this same text is in the fourth edition of Cricket Paul's book as well, I'm assuming this was an old bug (pre-BIND 9) and has long since been fixed. Could someone point me to a bug report and/or changelog for this? A quick Google search for 'bind resolver source address bug' didn't yield much. John -- John Miller Systems Engineer Brandeis University 781-736-4619 johnm...@brandeis.edu __**_ Please visit https://lists.isc.org/mailman/**listinfo/bind-usershttps://lists.isc.org/mailman/listinfo/bind-usersto unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/**listinfo/bind-usershttps://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
Re: PATCH: dig warn user when querying ANY towards recursive server (fwd)
On 7/22/2012 7:27 PM, Andris Kalnozols wrote: On 7/22/2012 10:19 AM, Paul Wouters wrote: (I don't think this made it to the list before, mixup of email addresses) Please consider including this patch, Paul -- Forwarded message -- Date: Mon, 2 Jul 2012 17:45:08 From: Paul Wouters p...@nohats.ca Cc: Paul Vixie p...@redbarn.org To: bind-users@lists.isc.org Subject: PATCH: dig warn user when querying ANY towards recursive server Hi, As recently came up, when querying a recursive caching server for ANY will only result on cached entries being returned, and not the whole possible set. For that you need to query the authoritative server. I wasn't aware of this, and since I'm sure I'll forget about this again too, I wrote a patch for dig to remind me. Please apply :) Don't forget that recursive servers can also host the zone being queried. Testing for the aa flag makes the message more accurate. if ((query-lookup-rdtype == dns_rdatatype_any) ((msg-flags DNS_MESSAGEFLAG_RA) != 0) (msg-flags DNS_MESSAGEFLAG_AA) == 0) printf(\n\n;; WARNING: Requested ANY data from a non-authoritative recursive server.\n;; The cached answer might be incomplete.\n\n); The DNS_MESSAGEFLAG_AA conditional should completely replace the DNS_MESSAGEFLAG_RA conditional, since it's perfectly valid to deny recursion to a particular client (RA=0), while at the same time allowing it to access cached data -- Samba: An Introduction which might be an incomplete nameset and therefore should prompt the warning -- built up by other clients which are allowed to recurse from the same nameserver instance. The only thing that really matters is the AA flag. - Kevin ___ 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: PATCH: dig warn user when querying ANY towards recursive server (fwd)
On 7/23/2012 6:23 PM, Kevin Darcy wrote: On 7/22/2012 7:27 PM, Andris Kalnozols wrote: On 7/22/2012 10:19 AM, Paul Wouters wrote: (I don't think this made it to the list before, mixup of email addresses) Please consider including this patch, Paul -- Forwarded message -- Date: Mon, 2 Jul 2012 17:45:08 From: Paul Wouters p...@nohats.ca Cc: Paul Vixie p...@redbarn.org To: bind-users@lists.isc.org Subject: PATCH: dig warn user when querying ANY towards recursive server Hi, As recently came up, when querying a recursive caching server for ANY will only result on cached entries being returned, and not the whole possible set. For that you need to query the authoritative server. I wasn't aware of this, and since I'm sure I'll forget about this again too, I wrote a patch for dig to remind me. Please apply :) Don't forget that recursive servers can also host the zone being queried. Testing for the aa flag makes the message more accurate. if ((query-lookup-rdtype == dns_rdatatype_any) ((msg-flags DNS_MESSAGEFLAG_RA) != 0) (msg-flags DNS_MESSAGEFLAG_AA) == 0) printf(\n\n;; WARNING: Requested ANY data from a non-authoritative recursive server.\n;; The cached answer might be incomplete.\n\n); The DNS_MESSAGEFLAG_AA conditional should completely replace the DNS_MESSAGEFLAG_RA conditional, since it's perfectly valid to deny recursion to a particular client (RA=0), while at the same time allowing it to access cached data -- Samba: An Introduction which might be an incomplete nameset and therefore should prompt the warning -- built up by other clients which are allowed to recurse from the same nameserver instance. The only thing that really matters is the AA flag. Whoops, copy paste error: please ignore the Samba stuff in the paragraph above... - Kevin ___ 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
erros on slave server refresh: unexpected rcode (NXDOMAIN)
Hi. I have a bind 9 primary server and a bind 9 secondary server, I added a new sub domain to the primary and as a slave zone on the secondary. i have obviously missed something. What does : named[13931]: zone domain.example.com/IN: refresh: unexpected rcode (NXDOMAIN) from master 209.234.97.14#53 (source 0.0.0.0#0) mean ?? As far as the primary server logs goes there is nothing that indicates an issue . Thanks ___ 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
RESOLVED Re: erros on slave server refresh: unexpected rcode (NXDOMAIN)
Last admin didn't have correct master ip set, put the correct on and all good. On Tue, Jul 24, 2012 at 2:30 PM, Gregory Machin g...@linuxpro.co.za wrote: Hi. I have a bind 9 primary server and a bind 9 secondary server, I added a new sub domain to the primary and as a slave zone on the secondary. i have obviously missed something. What does : named[13931]: zone domain.example.com/IN: refresh: unexpected rcode (NXDOMAIN) from master 209.234.97.14#53 (source 0.0.0.0#0) mean ?? As far as the primary server logs goes there is nothing that indicates an issue . Thanks ___ 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
