dns_diff_apply / "del not exact" logging

2024-02-13 Thread Andreas S. Kerber via bind-users 
Hi,

since upgrading our secondary to 9.18.24 yesterday, I'm seeing the logging 
messages below.

14-Feb-2024 07:52:24.850 general: error: dns_diff_apply: 
wur1-ps003.ad01.geXXX/A/IN: del not exact
14-Feb-2024 07:53:28.732 general: error: dns_diff_apply: 
1.0.e.4.1.1.0.0.2.ip6.arpa/SOA/IN: del not exact
14-Feb-2024 07:54:03.827 general: error: dns_diff_apply: ad01.idkXXX/RRSIG/IN: 
del not exact
14-Feb-2024 08:05:18.363 general: error: dns_diff_apply: 
HRO1-NB041.ad01.geXXX/A/IN: del not exact
14-Feb-2024 08:07:25.346 general: error: dns_diff_apply: 
lc7a5c2o2ur6umdqkvijckprpj74g6qr.ad01.idXXX/RRSIG/IN: del not exact
14-Feb-2024 08:17:58.873 general: error: dns_diff_apply: 
HRO1-NB002.ad01.geXXX/A/IN: del not exact
14-Feb-2024 08:18:34.160 general: error: dns_diff_apply: 
FUS1-MPC120.ad01.chXXX/A/IN: del not exact

The zone names mentioned are anonymized by me. primary of each zone is some 
kind of windows server.
Is this something to worry about? This kind of logging popped up since 
upgrading the secondary to 9.18.24.

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

rate-limit / nxdomains-per-second

2022-11-18 Thread Andreas S. Kerber 
I've been running with this configuration on some authoritative nameservers for
the last couple of years:

rate-limit {
responses-per-second 100;
errors-per-second 1000;
nxdomains-per-second 1000;
max-table-size 5;
slip 2;
}; 

options {
   tcp-clients 5000;
}

I understand these definitions are considered rather on the upper end of things.

Every once in a while some rather large query bursts come along and triggers
the NXDOMAIN limit (mostly on random names from google, microsoft or yahoo or 
cloudflare sources):

17-Nov-2022 21:42:45.196 rate-limit: client @0x7fa3dd9b1950 13.106.140.78#63673 
(3uPpY.): rate limit drop NXDOMAIN response to 13.106.140.0/24 for 
 (1c97f572)

As expected this forces them to use tcp instead of udp. This then quickly fills 
up the available
"tcp-clients" pool. Which is then of course having negative effects for other 
clients.

Does anyone want to share their take on how to handle such query bursts?
Is anyone using "nxdomains-per-second" experiencing similar things? Since 1000 
seems to be the
maximum, I tend to setting it to 0 to avoid filling up the tcp-clients pool.


-- 
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: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

2022-10-21 Thread Andreas S. Kerber 
Am Fri, Oct 21, 2022 at 01:21:36PM +0200 schrieb Borja Marcos:
> But tell your customer that their email message didn’t arrive on time because 
> the recipient has a misconfigured DNS server and
> try to explain to them that, yes, Google resolved it successfully but you are 
> working for the common good.

+1

While it's possible to enter those bad apples with a server{} statement in 
named.conf, this reactive approach is not always feasible. In our cases this 
week some mail bounced, since our MTAs could not resolve some domainnames and 
customers obviously don't like that, which triggered some support cases etc.

After further analysis of our logs the problem probably really is not all that 
big, just very few names where not resolvable. Nonetheless, we've decided to 
leave one of resolvers at 9.16 for now as a "last resort" for those faulty 
names, and the other resolvers continue to run fine with 9.18.

If I can find a few definite way to easily identify these bad apples from our 
resolver logs, I might notify the operators. I guess https://ednscomp.isc.org/ 
already has a way more comprehensive view on the issue and therefore better 
data for such notifications though ;-)
-- 
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: FORMERR responses after upgrading resolver from 9.16 to 9.18.8

2022-10-20 Thread Andreas S. Kerber 
Am Thu, Oct 20, 2022 at 01:23:47PM +0200 schrieb Ondřej Surý:
> did you try writing to elbrev.com  operators to fix their 
> servers to stop breaking DNS protocol? It often helps. (I'm ccing the contact 
> in their SOA records, so let's see if anything happens.)
>
> It's not lack of EDNS0 support, but they fail to properly process unknown 
> EDNS0 options - DNS Cookie in this specific example:

Hi Ondřej,

thanks for your quick reply and analysis regarding DNS cookies.
Is there maybe an option to configure 9.18 to act as if it was 9.16 in this 
regard?
Honestly I haven't contacted the elbrev.com people (see below).


> > Of course I would prefer to upgrade back to 9.18.X, but I guess I won't be 
> > able to find all EDNS0 incompatible servers and loosing customers to 
> > 8.8.8.8 - which is able to resolve these names..
> This is kind of moot argument - the DNS needs to evolve, and it can't evolve 
> if we keep supporting broken stuff. This needs to be fixed on the 
> authoritative operator side, not in BIND 9.

You're absolutely right. I guess I've just kind of given up on convincing other 
people the fix their stuff (dayjob trauma). Sorry about that.
-- 
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

FORMERR responses after upgrading resolver from 9.16 to 9.18.8

2022-10-20 Thread Andreas S. Kerber 
I've just finished upgrading our last resolver from 9.16 to 9.18.8 a few days 
ago.
As it turn out a number of zones are no longer resolveable with 9.18. Some 
nameservers out there don't seem to support EDNS0 and the number of FORMERR 
responses in our resolver logs went up quite a bit.  Here's an example:


zone bemacom.se when querying a 9.18.8 resolver (status: SERVFAIL):

# dig bemacom.se @213.182.0.X

; <<>> DiG 9.18.8 <<>> bemacom.se @213.182.0.X
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 25874


zone bemacom.se when querying a 9.16.34 resolver:

# dig bemacom.se @213.182.0.X

; <<>> DiG 9.18.8 <<>> bemacom.se @213.182.0.X
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5496



The NS for bemacom.se seem to be dnsX.elbrev.com and I'm seeing FORMERR 
messages in the BIND 9.18.8 logs:

Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns2.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns2.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns2.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns2.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:43 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:47 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving 
'dns2.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:51 frontend1 named[2577193]: received FORMERR resolving 
'dns2.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:55 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:55 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 92.33.14.98#53
Oct 20 12:46:55 frontend1 named[2577193]: received FORMERR resolving 
'dns1.elbrev.com//IN': 194.17.14.66#53
Oct 20 12:46:55 frontend1 named[2577193]: received FORMERR resolving 
'dns.elbrev.com//IN': 194.17.14.66#53


According to dnscheck.ripe.net the zones NS don't support EDNS0: 
https://dnscheck.ripe.net/result/93ee1d56756536dd

I could manually fix this by adding those IP adresses with a server statement 
to named.conf like this: "server x.x.x.x { edns no; };"
Since this is only one a example of about 10 so far, I chose to downgrade one 
of my resolvers back to 9.16.X, to catch those faulty zones.

Of course I would prefer to upgrade back to 9.18.X, but I guess I won't be able 
to find all EDNS0 incompatible servers and loosing customers to 8.8.8.8 - which 
is able to resolve these names..



-- 
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: 9.16.19 repeated crashes on FreeBSD 12.2-p6

2021-08-13 Thread Andreas S. Kerber 
Am Thu, Aug 12, 2021 at 05:03:33PM -0700 schrieb Randy Bush:
> FreeBSD 12.2-RELEASE-p6 GENERIC on amd64
> bind 9.16.19 from binary ports
> 
> ok, i was quietly waiting for a fix to magically appear and is hasn't.

I got lot's of crashes after upgrading from 9.16.18 to 9.16.19 too.
In my case it happened on Linux instead of FreeBSD though.
After reporting an issue (#2841) at gitlab.isc.org it turned out that there is a
already known problem which ought to be adressed in the August release. The
issue is marked as confidential though.

Just guessing, but maybe this will fix the crashes you are seeing as well.
___
Please 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: nsupdate - adding large/split TXT record (2048 bit DKIM key)

2020-06-01 Thread Andreas S. Kerber 
On Mon, Jun 01, 2020 at 04:11:43AM -0400, vom513 wrote:
> Can anyone point me to an example of how to do this ?  I have a script that 
> rotates my DKIM keys, and uses nsupdate to publish.  With 1024 bit - I must 
> be getting by by the skin of my teeth…
> 
> When I try 2048 bit, the record is obviously longer.  All of my attempts of 
> running it through the Rube Goldberg sed machine have failed - nsupdate 
> chokes on format.

Yeah, I had troubles with those 2048 bit DKIM records too. nsupdate will need 
it like this:

server X.X.X.X
zone ag-trek.de
update add test.ag-trek.de. 86400 IN TXT"v=DKIM1; 
k=rsa;p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3LmxUW2tnM07YbofiOGR3T6KS/BfHmyPYe0GOEEch/abeTjaL3OtuhmVmr4QMe2HV/6n5SBiVh4PE2wZxUcS2LMNbo5Hn7KO3UsTbIxCKuM6jvUpWtJPgC0uBGNkEARQVBSjW9pqYUQYkXzXLEULbu1AThgaUvCbVzWmvTQeEFXbBWP24O/"
 
"LkiprI+iKRskRv0qgIOV0CRm32tk4MP/IcZBdjZ3sHrg3myjVJPfSUBOUyISXKRtiwfIgPeCj4V97Q+psmHvnDz9EID0eZaKih8neroRBETYDLFYjd6Pv9JTqrY7jXOHhM4kmOZOUyNXEIz22JVuaNSJbtXzNWTKpyQIDAQAB"


Break up the record in chunks of less than 255 byte, enclose each of these 
parts with "" and feed nsupdate all of these chunks seperated with a space on 
one line.
___
Please 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: DNSSEC zones not updated

2020-01-22 Thread Andreas S. Kerber 
On Wed, Jan 22, 2020 at 11:11:05AM +, Jukka Pakkanen wrote:
> zone "gemtrade.fi" {
> type master;
> file "named.gemtrade";
> inline-signing yes;
> auto-dnssec maintain;
> };
> 
> $TTL 60
> @IN SOAns1.qnet.fi. helpdesk.qnet.fi. (
>   202001234  ; serial number

I once had a similar issue. Back then I fixed it using unixtime serialnumber 
format everywhere and using "rndc retransfer " on all slaves after the 
switch of the serial number format. Since then no further issues with inline 
signing.

___
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