Multiple queries for same host
Barry Margolin
barmar at alum.mit.edu
Thu Sep 17 02:51:38 UTC 2015
In article <mailman.2720.1442450331.26362.bind-users at lists.isc.org>,
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.
If the client application doesn't have a cache, it will repeat queries
like this.
>
> Can someone help me understand why this is happening? Is the query
> being broken down into multiple pieces, perhaps?
What makes you think that? They're all the same full name, not broken
down.
>
> I've included my named.conf here in case I'm missing something, in
> hopes someone could help me review.
You need to be looking at the client, not the server, to see why it's
repeating the same query.
>
> 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; };
> };
--
Barry Margolin
Arlington, MA
More information about the bind-users
mailing list