date:20110715

Trouble forwarding queries

2011-07-15 Thread Jan Rademaker

Some time last night bind seems to have stopped forwarding queries. 
This is the error bind logs.


15-Jul-2011 09:30:10.074 resolver: debug 1: createfetch: nu.nl A
15-Jul-2011 09:30:10.074 query-errors: debug 1: client 
83.247.6.154#52497: query failed (SERVFAIL) for nu.nl/IN/A at query.c:4020


tcpdump show no traffic to or from the upstream dns servers.

Here's part of the named.conf:

options {
allow-transfer {
a.b.c.d;
};
forwarders {
  208.67.222.222;
  208.67.220.220;
};
directory "/etc/namedb";
version "BWSS DNS";
auth-nxdomain no;

allow-recursion { 127.0.0.1; 83.247.6.128/26; };
};

# named -V
BIND 9.7.0-P1 built with '--prefix=/usr' '--mandir=/usr/share/man' 
'--infodir=/usr/share/info' '--sysconfdir=/etc/bind' 
'--localstatedir=/var' '--enable-threads' '--enable-largefile' 
'--with-libtool' '--enable-shared' '--enable-static' 
'--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' 
'--with-dlz-postgres=no' '--with-dlz-mysql=no' '--with-dlz-bdb=yes' 
'--with-dlz-filesystem=yes' '--with-dlz-ldap=yes' '--with-dlz-stub=yes' 
'--with-geoip=/usr' '--enable-ipv6' 'CFLAGS=-fno-strict-aliasing 
-DDIG_SIGCHASE -O2' 'LDFLAGS=-Wl,-Bsymbolic-functions' 'CPPFLAGS='


Any idea where I shoud look?

--

Jan Rademaker
Tel +(31) 0570-665140
j.radema...@bwss.nl - http://www.bwss.nl
___
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: Trouble forwarding queries

2011-07-15 Thread Chris Buxton

On Jul 15, 2011, at 1:25 AM, Jan Rademaker wrote:

> Some time last night bind seems to have stopped forwarding queries. This is 
> the error bind logs.
> 
> 15-Jul-2011 09:30:10.074 resolver: debug 1: createfetch: nu.nl A
> 15-Jul-2011 09:30:10.074 query-errors: debug 1: client 83.247.6.154#52497: 
> query failed (SERVFAIL) for nu.nl/IN/A at query.c:4020
> 
> tcpdump show no traffic to or from the upstream dns servers.
> 
> Here's part of the named.conf:
> 
> options {
>allow-transfer {
>   a.b.c.d;
>};
>forwarders {
>  208.67.222.222;
>  208.67.220.220;
>};
>directory "/etc/namedb";
>version "BWSS DNS";
>auth-nxdomain no;
> 
>allow-recursion { 127.0.0.1; 83.247.6.128/26; };
> };
> 
> # named -V
> BIND 9.7.0-P1 built with '--prefix=/usr' '--mandir=/usr/share/man' 
> '--infodir=/usr/share/info' '--sysconfdir=/etc/bind' '--localstatedir=/var' 
> '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' 
> '--enable-static' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-gnu-ld' 
> '--with-dlz-postgres=no' '--with-dlz-mysql=no' '--with-dlz-bdb=yes' 
> '--with-dlz-filesystem=yes' '--with-dlz-ldap=yes' '--with-dlz-stub=yes' 
> '--with-geoip=/usr' '--enable-ipv6' 'CFLAGS=-fno-strict-aliasing 
> -DDIG_SIGCHASE -O2' 'LDFLAGS=-Wl,-Bsymbolic-functions' 'CPPFLAGS='
> 
> Any idea where I shoud look?

Restart named. Then upgrade it to something more current. 9.7.0-P1 has a few 
vulnerabilities.

Regards,
Chris Buxton
BlueCat Networks
___
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: big improvement in BIND9 auth-server startup time

2011-07-15 Thread Matthew Pounsett

On 2011/07/13, at 11:15, Evan Hunt wrote:

> 
> People who operate big authoritative name servers (particularly with
> large numbers of small zones, e.g., for domain hosting and parking),
> and have had trouble with slow startup, may find this information
> useful:
> 
> http://www.isc.org/community/blog/201107/major-improvement-bind-9-startup-performance

Thanks Evan.  I'll also point out to people this PDF which has some more detail 
on the actual performance improvements: 

Was there any work done on measuring the impact on 'reconfig' times, or is that 
an entirely separate piece of code?  I'm curious if the change makes any 
difference to adding large numbers of zones to an already-running server.  e.g. 
if I've got a server handling 500,000 zones and add another 20k, 50k, or 100k 
via 'reconfig'.

Thanks to the ISC folk for doing that work!
   Matt

___
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

Reverse lookup flood from a single host

2011-07-15 Thread Joshua Beard

Greetings,

I've noticed a specific client machine doing a crap load of reverse lookups in 
my named logs.  It's just reverse lookups for our internal network, and just 
from that machine.  I can't see that this machine is looking up anything else, 
actually.  Here's an example:
11-Jul-2011 08:11:00.997 client 172.30.116.116#53: view dsdk12.schoollocal: 
query: 99.115.30.172.in-addr.arpa IN PTR + (172.30.112.121)
11-Jul-2011 08:11:01.116 client 172.30.116.116#53: view dsdk12.schoollocal: 
query: 75.241.40.208.in-addr.arpa IN PTR + (172.30.112.121)
11-Jul-2011 08:11:01.392 client 172.30.116.116#53: view dsdk12.schoollocal: 
query: 1.162.30.172.in-addr.arpa IN PTR + (172.30.112.121)
11-Jul-2011 08:11:01.393 client 172.30.116.116#53: view dsdk12.schoollocal: 
query: 150.160.30.172.in-addr.arpa IN PTR + (172.30.112.121)
11-Jul-2011 08:11:01.590 client 172.30.116.116#53: view dsdk12.schoollocal: 
query: 25.96.30.172.in-addr.arpa IN PTR + (172.30.112.121)
11-Jul-2011 08:11:01.680 client 172.30.116.116#53: view dsdk12.schoollocal: 
query: 2.130.30.172.in-addr.arpa IN PTR + (172.30.112.121)
11-Jul-2011 08:11:01.940 client 172.30.116.116#53: view dsdk12.schoollocal: 
query: 40.207.115.66.in-addr.arpa IN PTR + (172.30.112.121)
11-Jul-2011 08:11:01.940 client 172.30.116.116#53: view dsdk12.schoollocal: 
query: 22.114.30.172.in-addr.arpa IN PTR + (172.30.112.121)
11-Jul-2011 08:11:02.588 client 172.30.116.116#53: view dsdk12.schoollocal: 
query: 55.98.30.172.in-addr.arpa IN PTR + (172.30.112.121)
11-Jul-2011 08:11:02.785 client 172.30.116.116#53: view dsdk12.schoollocal: 
query: 179.112.30.172.in-addr.arpa IN PTR + (172.30.112.121)
11-Jul-2011 08:11:02.786 client 172.30.116.116#53: view dsdk12.schoollocal: 
query: 105.248.250.17.in-addr.arpa IN PTR + (172.30.112.121)

It appears to be non-stop.  Middle of the night and through the day.  I don't 
have physical access to the machine at this time, so I can't investigate too 
much.

Is this abuse?  If so, is it likely intentional?

Thanks in advance,
Josh


___
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: Reverse lookup flood from a single host

2011-07-15 Thread Chuck Swiger

On Jul 15, 2011, at 12:24 PM, Joshua Beard wrote:
> Greetings,
> 
> I've noticed a specific client machine doing a crap load of reverse lookups 
> in my named logs.  It's just reverse lookups for our internal network, and 
> just from that machine.  I can't see that this machine is looking up anything 
> else, actually.  Here's an example:
> 11-Jul-2011 08:11:00.997 client 172.30.116.116#53: view dsdk12.schoollocal: 
> query: 99.115.30.172.in-addr.arpa IN PTR + (172.30.112.121)
> 11-Jul-2011 08:11:01.116 client 172.30.116.116#53: view dsdk12.schoollocal: 
> query: 75.241.40.208.in-addr.arpa IN PTR + (172.30.112.121)
> 11-Jul-2011 08:11:01.392 client 172.30.116.116#53: view dsdk12.schoollocal: 
> query: 1.162.30.172.in-addr.arpa IN PTR + (172.30.112.121)
> 11-Jul-2011 08:11:01.393 client 172.30.116.116#53: view dsdk12.schoollocal: 
> query: 150.160.30.172.in-addr.arpa IN PTR + (172.30.112.121)
> 11-Jul-2011 08:11:01.590 client 172.30.116.116#53: view dsdk12.schoollocal: 
> query: 25.96.30.172.in-addr.arpa IN PTR + (172.30.112.121)
> 11-Jul-2011 08:11:01.680 client 172.30.116.116#53: view dsdk12.schoollocal: 
> query: 2.130.30.172.in-addr.arpa IN PTR + (172.30.112.121)
> 11-Jul-2011 08:11:01.940 client 172.30.116.116#53: view dsdk12.schoollocal: 
> query: 40.207.115.66.in-addr.arpa IN PTR + (172.30.112.121)
> 11-Jul-2011 08:11:01.940 client 172.30.116.116#53: view dsdk12.schoollocal: 
> query: 22.114.30.172.in-addr.arpa IN PTR + (172.30.112.121)
> 11-Jul-2011 08:11:02.588 client 172.30.116.116#53: view dsdk12.schoollocal: 
> query: 55.98.30.172.in-addr.arpa IN PTR + (172.30.112.121)
> 11-Jul-2011 08:11:02.785 client 172.30.116.116#53: view dsdk12.schoollocal: 
> query: 179.112.30.172.in-addr.arpa IN PTR + (172.30.112.121)
> 11-Jul-2011 08:11:02.786 client 172.30.116.116#53: view dsdk12.schoollocal: 
> query: 105.248.250.17.in-addr.arpa IN PTR + (172.30.112.121)
> 
> It appears to be non-stop.  Middle of the night and through the day.  I don't 
> have physical access to the machine at this time, so I can't investigate too 
> much.
> 
> Is this abuse?  If so, is it likely intentional?

Given that the client is using a RFC-1918 unrouteable IP, presumably it's local 
to your network.  

The data you've shown is less than 10 queries per second; whether this is 
abusive depends on your policies, but it's not a high query rate.  It wouldn't 
surprise me if a webserver log analysis program like analog/Unison/webalyzer or 
a virus/malware scanner would generate such traffic.

Regards,
-- 
-Chuck

___
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: Reverse lookup flood from a single host

2011-07-15 Thread Kevin Oberman

On Jul 15, 2011 12:36 PM, "Joshua Beard"  wrote:
>
> Greetings,
>
> I've noticed a specific client machine doing a crap load of reverse
lookups in my named logs.  It's just reverse lookups for our internal
network, and just from that machine.  I can't see that this machine is
looking up anything else, actually.  Here's an example:
> 11-Jul-2011 08:11:00.997 client 172.30.116.116#53: view
dsdk12.schoollocal: query: 99.115.30.172.in-addr.arpa IN PTR +
(172.30.112.121)
> 11-Jul-2011 08:11:01.116 client 172.30.116.116#53: view
dsdk12.schoollocal: query: 75.241.40.208.in-addr.arpa IN PTR +
(172.30.112.121)
> 11-Jul-2011 08:11:01.392 client 172.30.116.116#53: view
dsdk12.schoollocal: query: 1.162.30.172.in-addr.arpa IN PTR +
(172.30.112.121)
> 11-Jul-2011 08:11:01.393 client 172.30.116.116#53: view
dsdk12.schoollocal: query: 150.160.30.172.in-addr.arpa IN PTR +
(172.30.112.121)
> 11-Jul-2011 08:11:01.590 client 172.30.116.116#53: view
dsdk12.schoollocal: query: 25.96.30.172.in-addr.arpa IN PTR +
(172.30.112.121)
> 11-Jul-2011 08:11:01.680 client 172.30.116.116#53: view
dsdk12.schoollocal: query: 2.130.30.172.in-addr.arpa IN PTR +
(172.30.112.121)
> 11-Jul-2011 08:11:01.940 client 172.30.116.116#53: view
dsdk12.schoollocal: query: 40.207.115.66.in-addr.arpa IN PTR +
(172.30.112.121)
> 11-Jul-2011 08:11:01.940 client 172.30.116.116#53: view
dsdk12.schoollocal: query: 22.114.30.172.in-addr.arpa IN PTR +
(172.30.112.121)
> 11-Jul-2011 08:11:02.588 client 172.30.116.116#53: view
dsdk12.schoollocal: query: 55.98.30.172.in-addr.arpa IN PTR +
(172.30.112.121)
> 11-Jul-2011 08:11:02.785 client 172.30.116.116#53: view
dsdk12.schoollocal: query: 179.112.30.172.in-addr.arpa IN PTR +
(172.30.112.121)
> 11-Jul-2011 08:11:02.786 client 172.30.116.116#53: view
dsdk12.schoollocal: query: 105.248.250.17.in-addr.arpa IN PTR +
(172.30.112.121)
>
> It appears to be non-stop.  Middle of the night and through the day.  I
don't have physical access to the machine at this time, so I can't
investigate too much.
>
> Is this abuse?  If so, is it likely intentional?

There are many apps that can generate the volume of queries you are seeing.
The query rate is really not that high.

My first guess is some sort of logging tool, but there are a great many
other possibilities.

R. Kevin Oberman, Network Engineer
Retired
kob6...@gmail.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: Reverse lookup flood from a single host

2011-07-15 Thread Benny Pedersen


On Fri, 15 Jul 2011 13:24:29 -0600, Joshua Beard wrote:


Is this abuse?  If so, is it likely intentional?


100% guess, the client ip running a mailserver ?

if so all is ok

___
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

ISC BIND 9.8.1b3 is now available

2011-07-15 Thread Evan Hunt


Introduction

   ISC BIND 9.8.1 is now available.

   This release includes startup-performance improvements described
   in http://www.isc.org/files/imce/startup-performance.pdf.

   BIND 9.8.1b3 is the third beta release of BIND 9.8.

   This document summarizes changes from BIND 9.8.0 to BIND 9.8.1b3.
   Please see the CHANGES file in the source code release for a complete
   list of all changes.

Download

   The latest versions of BIND 9 software can always be found on our web
   site at http://www.isc.org/downloads/all. There you will find
   additional information about each release, source code, and some
   pre-compiled versions for certain operating systems.

Support

   Product support information is available on
   http://www.isc.org/services/support for paid support options. Free
   support is provided by our user community via a mailing list.
   Information on all public email lists is available at
   https://lists.isc.org/mailman/listinfo.

New Features

 * Added a new include file with function typedefs for the DLZ
   "dlopen" driver. [RT #23629]
 * Added a tool able to generate malformed packets to allow testing of
   how named handles them. [RT #24096]

Security Fixes

 * If named is configured with a response policy zone (RPZ) and a
   query of type RRSIG is received for a name configured for RRset
   replacement in that RPZ, it will trigger an INSIST and crash the
   server. RRSIG. [RT #24280]
 * named, set up to be a caching resolver, is vulnerable to a user
   querying a domain with very large resource record sets (RRSets)
   when trying to negatively cache the response. Due to an off-by-one
   error, caching the response could cause named to crash. [RT #24650]
   [CVE-2011-1910]
 * Using Response Policy Zone (RPZ) to query a wildcard CNAME label
   with QUERY type SIG/RRSIG, it can cause named to crash. Fix is
   query type independant. [RT #24715]
 * Using Response Policy Zone (RPZ) with DNAME records and querying
   the subdomain of that label can cause named to crash. Now logs that
   DNAME is not supported. [RT #24766]
 * Change #2912 populated the message section in replies to UPDATE
   requests, which some Windows clients wanted. This exposed a latent
   bug that allowed the response message to crash named. With this
   fix, change 2912 has been reduced to copy only the zone section to
   the reply. A more complete fix for the latent bug will be released
   later. [RT #24777]

Feature Changes

 * Improved the startup time for an authoritative server with a large
   number of zones by making the zone task table of variable size
   rather than fixed size. This means that authoritative servers with
   lots of zones will be serving that zone data much sooner. [RT
   #24406]
 * Merged in the NetBSD ATF test framework (currently version 0.12)
   for development of future unit tests. Use configure --with-atf to
   build ATF internally or configure --with-atf=prefix to use an
   external copy. [RT #23209]
 * Added more verbose error reporting from DLZ LDAP. [RT #23402]
 * The DLZ "dlopen" driver is now built by default, no longer
   requiring a configure option. To disable it, use "configure
   --without-dlopen". (Note: driver not supported on win32.) [RT
   #23467]
 * Replaced compile time constant with STDTIME_ON_32BITS. [RT #23587]
 * Make --with-gssapi default for ./configure. [RT #23738]

Bug Fixes

 * During RFC5011 processing some journal write errors were not
   detected. This could lead to managed-keys changes being committed
   but not recorded in the journal files, causing potential
   inconsistencies during later processing. [RT #20256]
   A potential NULL pointer deference in the DNS64 code could cause
   named to terminate unexpectedly. [RT #20256]
   A state variable relating to DNSSEC could fail to be set during
   some infrequently-executed code paths, allowing it to be used
   whilst in an unitialized state during cache updates, with
   unpredictable results. [RT #20256]
   A potential NULL pointer deference in DNSSEC signing code could
   cause named to terminate unexpectedly [RT #20256]
   Several cosmetic code changes were made to silence warnings
   generated by a static code analysis tool. [RT #20256]
 * When using the -x (sign with only KSK) option on dnssec-signzone,
   it could incorrectly count the number of ZSKs in the zone. (And in
   9.9.0, some code cleanup and improved warning messages). [RT
   #20852]
 * When using _builtin in named.conf, named.conf changes were not
   found when reloading the config file. Now checks _builtin zone
   arguments to see if the zone is re-usable or not. [RT #21914]
 * Running dnssec-settime -f on an old-style key will now force the
   key to be rewritten to the new key for

Trouble forwarding queries

Re: Trouble forwarding queries

Re: big improvement in BIND9 auth-server startup time

Reverse lookup flood from a single host

Re: Reverse lookup flood from a single host

Re: Reverse lookup flood from a single host

Re: Reverse lookup flood from a single host

ISC BIND 9.8.1b3 is now available

8 matches

Site Navigation

Mail list logo

Footer information