Multiple queries for same host

[Rich Goodson]

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 <mysqlstudent at 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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4127 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20150917/9ef1f9ab/attachment.bin>