Workaround needed for TSIG Zone Transfer

[Frey, Rick E via bind-users]

I’ve got a case where using BIND (v9.16.41) as a secondary to a third party 
(commercial) primary nameserver.  Using TSIG for the zone transfers.  Have 
verified zone transfers and TSIG key using dig between hosts.  BIND is 
configured to use TSIG for the primary server using server x.x.x.x { keys 
“somekey”; } directive.

Problem is that the primary server does not sign the response with TSIG for the 
SOA query sent by BIND to determine if update is needed.   Since response to 
SOA query is not signed, BIND considers response invalid:

Sample log message when SOA not signed:
zone some-domain.com/IN: refresh: failure trying master x.x.x.x#53 (source 
0.0.0.0#0): expected a TSIG or SIG(0)

I know that BIND is not at fault and the primary server is breaking RFC8945 as 
any query with TSIG is required to return a TSIG RR in the response.  Working 
w/ vendor of the primary nameserver to resolve.  The vendor is a pretty widely 
used provider so I’m a bit surprised issue has not occurred before now.

Mainly wondering if there is any workaround available to allow BIND to either 
not send TSIG in SOA query to the primary server (but still use TSIG for zone 
transfer) or accept the SOA response w/o TSIG RR.  I was unable to find any 
means to configure this behavior in reading through BIND documentation.


  *   Rick

This email message and any attachments are for the sole use of the intended 
recipient(s). Any unauthorized review, use, disclosure or distribution is 
prohibited. If you are not the intended recipient, please contact the sender by 
reply email and destroy all copies of the original message and any attachments.

Sensitivity: Internal
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: lame-servers: SERVFAIL unexpected RCODE resolving

[Frey, Rick E via bind-users]

The .org TLD nameservers point to ns1 – ns4.opensuse.org as the authoritative 
nameservers for openSUSE.org.  Appears that while ns2 and and ns3.opensuse.org 
are working, ns1 and ns4.opensuse.org return SERVFAIL when querying for 
openSUSE.org records.  Your first  sample log entry for lists.opensuse.org NS 
record was against ns4.opensuse.org (195.135.221.195) which returns SERVFAIL 
for your query.  Problem is on openSUSE.org’s nameservers (not your end).

I’m unable to duplicate the second sample log message for SERVFAIL response for 
A record of 134.94.245.198.bb.barracudacentral.org .  Your log indicates that 
the nameserver 3.13.7.25 (which is the authoritative nameserver 
blacklist-ns-az1.bci.aws.cudaops.com) returned a SERVFAIL for the request.  The 
second sample log message may have been due to an anomaly on the authoritative 
nameserver.

From: bind-users  on behalf of Alex 

Date: Saturday, November 26, 2022 at 9:39 AM
To: bind-users@lists.isc.org 
Subject: lame-servers: SERVFAIL unexpected RCODE resolving
CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi,
Continuing in my quest to figure out why I'm seeing timeout issues from many of 
the same nameservers, I'm wondering if someone can help me identify the reason 
for these log entries:

26-Nov-2022 09:19:13.969 lame-servers: SERVFAIL unexpected RCODE resolving 
'lists.opensuse.org/NS/IN':
 195.135.221.195#53
26-Nov-2022 10:02:46.437 lame-servers: SERVFAIL unexpected RCODE resolving 
'134.94.245.198.bb.barracudacentral.org/A/IN':
 3.13.7.254#53

The vast majority of these types of entries are from the same nameservers as 
above. This is a mail server and at least the barracuda entry is a query to 
their blocklist service. Are others having problems with this barracuda service?

I realize generally lame-servers entries can be ignored, but it's a bit 
concerning to me, given the large amount of similar entries we're seeing every 
day. It also resulted in zero other similar questions when searching for this 
error.

Any ideas greatly appreciated.

Thanks,
Alex




Sensitivity: Internal
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: named log gaps/pause

[Frey, Rick E]

You don’t mention your query rates.   By chance is syslog rate limiting the 
messages sent by querylog channel?



From: bind-users  on behalf of Speagle, Andy 
via bind-users 
Hey Folks,

I'm seeing something really strange with 9.16.26 ... we're getting like
10min gaps in the logs sent to syslog... the server seems to work just
fine... it just stops logging for long periods of time. We're using
rsyslog on el8 ...

Our logging looks like this:

logging {
channel dns_syslog {
syslog local0;
severity info;
};

category default { dns_syslog; };

//  Don't log denied queries (after closing recursive resolution).
//  In spite of the title, the security category is *only*
//  approval and denial of requests.
category security { null; };

//  Don't log format errors from lame servers.
category lame-servers { null; };

//  Don't log format errors of other types.
category resolver { null; };

//  Log queries of records for which we're authoritative.
//  They don't seem to be filterable in named so they're being
filtered
//  in syslog-ng.
channel querylog {
syslog local6;
severity debug 3;
print-category yes;
print-time yes;
};

category queries { querylog; };
};

This all looks pretty standard... anyone else seen this?

Thanks,

Andy



Sensitivity: Internal
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Bind suddenly starts responding clients with servfail

[Frey, Rick E]

Recursive clients are lookups/clients on your nameserver on behalf of a query 
received.  If you are seeing that your nameserver is running out of recursive 
clients after removing “all” traffic, it would indicate something is still 
querying your nameserver as BIND won’t spontaneously create recursive lookups.  
Perhaps something local on the server is generating queries?

A dump of existing recursive clients can be performed using “rndc recursing”.   
Output is normally “named.recursing” in your data directory.

I would suspect that your server may be unable to make outbound connections to 
authoritative servers.  This could cause high number of recursive clients.  
Note that behavior of BIND is to start dropping older outstanding recursive 
lookups once 90% of recursive clients is reached (900 recursive clients in your 
case).  Thus, a high number of recursive clients in itself normally doesn’t 
result in SERVFAIL for queries.

Not sure why you’re unable to run rndc commands (local or remote?).   Perhaps 
you are out of file descriptors as well?

From: bind-users  on behalf of Søren Andersen 

Date: Monday, April 27, 2020 at 4:00 AM
To: "bind-users@lists.isc.org" 
Subject: Bind suddenly starts responding clients with servfail

Hello List,

I'm running a few BIND servers, but lately one of my servers suddenly starts 
responding to clients with servfail for every request from the clients, and 
BIND doesn't respond to the rndc or statistics interface anymore.

My logs for client-channel show me this:
25-Apr-2020 21:52:04.501 client @XX XX.37#2921 
(google.dk):
 no more recursive clients (1000/900/1000): quota reached

I've removed all the dns traffic from the server, and the quota is still 
reached after 6+ hours?

Do you guys have some clue what all this is about? - Or any suggestions where 
to look for any further information?

I'm running BIND 9.16.1 on CentOS 7:

named -V
BIND 9.16.1 (Stable Release) 
running on Linux x86_64 3.10.0-1062.el7.x86_64 #1 SMP Wed Aug 7 18:08:02 UTC 
2019
built by make with '--build=x86_64-redhat-linux-gnu' 
'--host=x86_64-redhat-linux-gnu' '--program-prefix=' 
'--disable-dependency-tracking' '--prefix=/opt/isc/isc-bind/root/usr' 
'--exec-prefix=/opt/isc/isc-bind/root/usr' 
'--bindir=/opt/isc/isc-bind/root/usr/bin' 
'--sbindir=/opt/isc/isc-bind/root/usr/sbin' 
'--sysconfdir=/etc/opt/isc/isc-bind' 
'--datadir=/opt/isc/isc-bind/root/usr/share' 
'--includedir=/opt/isc/isc-bind/root/usr/include' 
'--libdir=/opt/isc/isc-bind/root/usr/lib64' 
'--libexecdir=/opt/isc/isc-bind/root/usr/libexec' 
'--localstatedir=/var/opt/isc/isc-bind' 
'--sharedstatedir=/var/opt/isc/isc-bind/lib' 
'--mandir=/opt/isc/isc-bind/root/usr/share/man' 
'--infodir=/opt/isc/isc-bind/root/usr/share/info' '--disable-static' 
'--enable-dnstap' '--with-pic' '--with-gssapi' '--with-json-c' '--with-libtool' 
'--with-libxml2' '--without-lmdb' 
'--with-docbook-xsl=/usr/share/sgml/docbook/xsl-stylesheets' '--with-python' 
'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 
'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions 
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 
-mtune=generic' 'LDFLAGS= -L/opt/isc/isc-bind/root/usr/lib64' 
'PKG_CONFIG_PATH=:/opt/isc/isc-bind/root/usr/lib64/pkgconfig:/opt/isc/isc-bind/root/usr/share/pkgconfig'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-39)
compiled with OpenSSL version: OpenSSL 1.0.2k-fips  26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips  26 Jan 2017
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with json-c version: 0.11
linked to json-c version: 0.11
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
compiled with protobuf-c version: 1.3.2
linked to protobuf-c version: 1.3.2
threads support is enabled

/Søren
___
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