Re: 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  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

RHEL, Centos, Fedora rpm 9.10.3

[Carl Byington]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

http://www.five-ten-sg.com/mapper/bind contains links to the source
rpms, and build instructions.


-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAlX6+HoACgkQL6j7milTFsHhlwCeKkAbd+/OG9KlcVTDJXDcCsPc
tdoAn0EnZQQo40V07J4khtbEbW8WifQl
=/JQC
-END PGP 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

Re: Multiple queries for same host

[Alex]

Hi,

> 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.

I don't know how I missed that. Thanks for double-checking.

> 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.

Yes, that's correct, it's a mail server with postfix and postscreen
weighting similar to something like this:

postscreen_dnsbl_sites = mykey.zen.dq.spamhaus.net=127.0.0.[10;11]*8
dnsbl.sorbs.net=127.0.0.10*8
b.barracudacentral.org*7
dnsbl.sorbs.net=127.0.0.5*6
mykey.zen.dq.spamhaus.net=127.0.0.[4..7]*6
bl.mailspike.net*4
bl.spamcop.net*4
bl.spameatingmonkey.net*4
mykey.zen.dq.spamhaus.net=127.0.0.3*4
list.dnswl.org=127.[0..255].[0..255].0*-2
list.dnswl.org=127.[0..255].[0..255].1*-3
list.dnswl.org=127.[0..255].[0..255].[2..255]*-4

Thanks again,
Alex
___
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

BIND 9.10.2p4 SERVFAIL Error

[Amy Briggs]

Last week I upgraded to BIND 9.10.2p4 from BIND 9.9.7p2 and started getting 
this strange behavior.   Twice now a subdomain of viebit.com has stopped 
resolving on our nameservers and gives a  SERVFAIL error.  I have to kill the 
named process and restart it, then it resolves again.   Has any one experienced 
this behavior?  Does anyone know of any issues with BIND 9.10.2p4 or a problem 
with viebit.com that would cause this issue?

Thank you for any help you can provide,

Amy




___
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

Bind9 backend MySQL reverse lookup problem

[Alexandre Vilarinho]

Hello all,
Recently I've installed bind9 (ubuntu version) wirh backend MySQL, but I'm 
having some problems with the reverse lookup.
I've configured the named.conf.local file with the following string but bind is 
not accepting it.
dlz "Mysql zone" {
    database "mysql
    {host=127.0.0.1 dbname=db_name user=db_user pass=db_pass}
    {select zone from dns_records where zone = '$zone$'}
    {select ttl, type, mx_priority, case when lower(type)='txt' 
then concat('\"', data, '\"') when lower(type) = 'soa' then concat_ws(' ', 
data, resp_person, serial, refresh, retry, expire, minimum) else data end from 
dns_records where zone = '$zone$' and host = '$record$' and not (type = 'SOA' 
or type = 'NS')}
    {}
    {select zone from reverse_records where zone = '$zone$'}
    {select ttl, type, mx_priority, case when lower(type)='txt' 
then concat('\"', data, '\"') when lower(type) = 'soa' then concat_ws(' ', 
data, resp_person, serial, refresh, retry, expire, minimum) else data end from 
reverse_records where zone = '$zone$' and host = '$record$' and not (type = 
'SOA' or type = 'NS')}";
};

Since with the TXT named.conf.file, the reverse lookup is a different zone, I 
presume I had to create a second database to store its records. Can anyone help 
me solve this problem? I've search in many discussion lists and everyone 
complain abou the difficulty to set up the reverse lookup with MySQL as backend.
Regards
Alex___
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: BIND 9.10.2p4 SERVFAIL Error

[Mark Andrews]

In message 
,
 Amy Briggs writes:
>
> Last week I upgraded to BIND 9.10.2p4 from BIND 9.9.7p2 and started
> getting this strange behavior.   Twice now a subdomain of viebit.com has
> stopped resolving on our nameservers and gives a  SERVFAIL error.  I have
> to kill the named process and restart it, then it resolves again.   Has
> any one experienced this behavior?  Does anyone know of any issues with
> BIND 9.10.2p4 or a problem with viebit.com that would cause this issue?
>
> Thank you for any help you can provide,
>
> Amy

Sorry our crystal balls are broken.  Why can't anyone report the
actual domain name they are having problems with?  "A subdomain of
viebit.com" is *not* reporting the actual domain name.  If you
want help from people stop making them guess where the problem
is.

viebit.com had mismatching NS RRsets at the delegation but that
shouldn't cause resolution issues.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
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

BIND 9.9.8-S1 Release Notes (What's 'S' stands for?)

[stutiredboy]

BIND 9.9.8-S1  was released, but
what's 'S' stands for?

I did not found any docs described this.

Can this version be used on production environment?

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

Re: BIND 9.9.8-S1 Release Notes (What's 'S' stands for?)

[Evan Hunt]

On Fri, Sep 18, 2015 at 12:07:22PM +0800, stutiredboy wrote:
> BIND 9.9.8-S1  was released, but
> what's 'S' stands for?
> 
> I did not found any docs described this.
> 
> Can this version be used on production environment?

The -S suffix is for a "subscription" branch that we make available to
ISC support customers and others on request.  It provides early access,
in a supported and stable form, to features under development that are
of particular interest to large-scale DNS operators.

For example, the "fetchlimit" recursive client rate-limiting features
for addressing recent DDoS attacks, which are in 9.10.3 and 9.9.8, were
released first in the subscription branch while they were still
experimental. Currently it also has negative trust anchor support and
SERVFAIL caching, both slated for 9.11.

Nothing in it is secret or closed-source; it's a just customized version
of the 9.9 branch with certain 9.10 and 9.11 features backported into it,
plus occasionally some experimental features that will be merged to 9.11
after we're satisfied with them.  You can get all the same stuff by cloning
the development branch in our git repository at source.isc.org. (I
can't guarantee not to have broken anything recently, though.)

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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