Alex,

These queries in your logs (at least the ones you’ve sent as examples) are not 
identical.

Sometimes stub resolvers will rapid-fire queries at an iterative resolver for 
the same record, but that doesn’t appear to be happening in this case.  These 
queries are just for very similar looking records in very similar domains, but 
the example you sent is 5 queries for 5 different names.

In the first 2 queries, the client is requesting to see whether 69.16.223.254 
is in the Spamhaus Block List as well as the ZEN.  Since the SBL is a subset of 
ZEN, I would argue that if they are querying ZEN, also querying the SBL is 
redundant and the (I assume it’s a mail server) client machine should be 
configured to only query ZEN.  Same with the next 2 queries.  69.16.222.254 
this time, two different blackhole lists.  Fifth query is querying the SBL for 
216.69.185.13.

-Rich

> On Sep 16, 2015, at 7:38 PM, Alex <mysqlstud...@gmail.com> wrote:
> 
> HI,
> 
> I have a fedora22 system with bind-9.10.2 that is configured to be
> authoritative for its domain and also provides recursive query
> services for a number of trusted hosts.
> 
> I'm seeing a situation where multiple queries for the same host are
> occurring in the logs, and I don't understand why. In this case, it's
> queries to IPs at spamhaus, although I've changed my key and our
> public IP to 192.168.1.27 in this example:
> 
> 16-Sep-2015 20:18:47.947 queries: client 192.168.1.27#34798
> (254.223.16.69.mykey.sbl.dq.spamhaus.net): query:
> 254.223.16.69.mykey.sbl.dq.spamhaus.net IN A +E (192.168.1.3)
> 16-Sep-2015 20:18:47.947 queries: client 192.168.1.27#34798
> (254.223.16.69.mykey.zen.dq.spamhaus.net): query:
> 254.223.16.69.mykey.zen.dq.spamhaus.net IN A +E (192.168.1.3)
> 16-Sep-2015 20:18:47.948 queries: client 192.168.1.27#34798
> (254.222.16.69.mykey.sbl.dq.spamhaus.net): query:
> 254.222.16.69.mykey.sbl.dq.spamhaus.net IN A +E (192.168.1.3)
> 16-Sep-2015 20:18:47.949 queries: client 192.168.1.27#34798
> (254.222.16.69.mykey.zen.dq.spamhaus.net): query:
> 254.222.16.69.mykey.zen.dq.spamhaus.net IN A +E (192.168.1.3)
> 16-Sep-2015 20:18:47.949 queries: client 192.168.1.27#34798
> (13.185.69.216.mykey.sbl.dq.spamhaus.net): query:
> 13.185.69.216.mykey.sbl.dq.spamhaus.net IN A +E (192.168.1.3)
> 
> It appears to happen most frequently with spamhaus queries, but also
> occurs with random other domains.
> 
> Can someone help me understand why this is happening? Is the query
> being broken down into multiple pieces, perhaps?
> 
> I've included my named.conf here in case I'm missing something, in
> hopes someone could help me review.
> 
> acl "trusted" {
>    { 127.0.0.0/8; };
>    { 192.168.1.0/24; };
> };
> 
> options {
>    version "None of your business.";
> 
>    transfers-out 200;
> 
>        // The following paths are necessary for this chroot
>    listen-on-v6 { none; };
>    listen-on port 53 { 192.168.1.3; 127.0.0.1; };
> 
>        directory "/var/named";
>        dump-file "/var/tmp/named_dump.db";             // _PATH_DUMPFILE
>        pid-file "/var/run/named/named.pid";            // _PATH_PIDFILE
>        statistics-file "/var/named/data/named.stats";         // _PATH_STATS
>        memstatistics-file "/var/tmp/named.memstats";   // _PATH_MEMSTATS
>        // End necessary chroot paths
> 
>        check-names master warn;                        /* default. */
>        datasize 20M;
>    allow-transfer {
>        127.0.0.1;
>        192.168.1.3;
>        192.168.1.27;
>    };
>    // Prevent outsiders from using juggernaut
>    // as their name server for unauthorized queries
>    allow-query { trusted; };
>    allow-recursion { trusted; };
> };
> 
> logging {
> 
>    category default { named_info; };
>    category general { named_info; };
>    category lame-servers { null; };
> 
>        // Configure general default info
>        channel named_info {
>                file "/var/log/named.info.log" versions 4 size 10m;
>                severity info;
>                print-time yes;
>                print-category yes;
>        };
> 
> };
> 
> zone "." {
>    type hint;
>    file "/var/named/named.ca";
> };
> 
> zone "localhost" {
>        type master;
>        file "masters/localhost";
>        check-names fail;
>        allow-update { none; };
>        allow-transfer { any; };
> };
> 
> zone "0.0.127.in-addr.arpa" {
>        type master;
>        file "masters/db.127.0.0";
>        allow-update { none; };
>        allow-transfer { any; };
> };
> 
> zone "0/27.1.168.192.in-addr.arpa" {
>    type master;
>    file "masters/db.1.168.192";
>    allow-query { any; };
>    allow-transfer { trusted; };
> };
> 
> zone "mydomain.com" {
>    type master;
>    file "masters/db.mydomain.com";
>    allow-query { any; };
>    allow-transfer { trusted; };
> };
> _______________________________________________
> 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
> 

Attachment: smime.p7s
Description: S/MIME cryptographic 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

Reply via email to