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