configure syslog prefix

[Klaus Darilion]

Hi!

I have several bind instances running on the same host. All of them use 
the same logging prefix, e.g:


named[11926]: zone mydomain/IN: Transfer started.
named[11926]: transfer of 'mydomain/IN' from 2.3.4.5#53: connected using 
2.3.4.5#44224
named[13479]: client 2.3.4.5#44224: transfer of 'mydomain/IN': 
AXFR-style IXFR started: TSIG mydomain
named[13479]: client 2.3.4.5#44224: transfer of 'mydomain/IN': 
AXFR-style IXFR ended



So I only have the PID to separate the different bind processes.

Some software allows to configure the syslog prefix, but I couldn't find 
that for bind.


Is there a workaround to get something like that?

named-incoming[11926]: zone mydomain/IN: Transfer started.
named-incoming[11926]: transfer of 'mydomain/IN' from 2.3.4.5#53: 
connected using 2.3.4.5#44224
named-outgoing[13479]: client 2.3.4.5#44224: transfer of 'mydomain/IN': 
AXFR-style IXFR started: TSIG mydomain
named-outgoing[13479]: client 2.3.4.5#44224: transfer of 'mydomain/IN': 
AXFR-style IXFR ended


Thanks
Klaus
___
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: configure syslog prefix

[Klaus Darilion]

On 02.07.2013 14:59, Tony Finch wrote:

Klaus Darilion  wrote:


Some software allows to configure the syslog prefix, but I couldn't find that
for bind.


Rename the named executable.


I would prefer a configuration options, but I guess I have to use this 
workaround.


Tested with symlinks, it works.

Thanks
Klaus
___
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

rndc refresh fails for signed zones

[Klaus Darilion]

Hi!

# named -V
BIND 9.9.3-rl.13204.02-P2

I have configured slave zones with inline signing:

zone "mydomain.at" {
type slave;
file "/etc/bind/mydomain.at";
masters { 1.2.3.4; };
key-directory "/etc/bind/keys";
auto-dnssec maintain;
inline-signing yes;
allow-transfer { 5.6.7.8; };
also-notify { 5.6.7.8; };
};


# rndc refresh mydomain.at
rndc: 'refresh' failed: failure
not a slave or stub zone


For normal slave zones (unsigned) it works fine. Is this a known bug?
Where can I open a bug report? Any workarounds?


Thanks
Klaus
___
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: rndc refresh fails for signed zones

[Klaus Darilion]

Same problem with:

# named -V
BIND 9.9.4-P1


On 11.12.2013 13:39, Klaus Darilion wrote:

Hi!

# named -V
BIND 9.9.3-rl.13204.02-P2

I have configured slave zones with inline signing:

zone "mydomain.at" {
 type slave;
 file "/etc/bind/mydomain.at";
 masters { 1.2.3.4; };
 key-directory "/etc/bind/keys";
 auto-dnssec maintain;
 inline-signing yes;
 allow-transfer { 5.6.7.8; };
 also-notify { 5.6.7.8; };
};


# rndc refresh mydomain.at
rndc: 'refresh' failed: failure
not a slave or stub zone


For normal slave zones (unsigned) it works fine. Is this a known bug?
Where can I open a bug report? Any workarounds?


Thanks
Klaus

___
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: rndc refresh fails for signed zones

[Klaus Darilion]

On 11.12.2013 21:09, Mark Andrews wrote:

For normal slave zones (unsigned) it works fine. Is this a known bug?
>Where can I open a bug report? Any workarounds?

You can report bugs tobind9-b...@isc.org.  That being said this one is
trivial.


Thanks, works fine.

regards
Klaus
___
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

How to query the "incoming" serial of a zone while inline signing

[Klaus Darilion]

Hi!

I use Bind for inline signing between a hidden master and the public 
slaves. AFAIS Bind maintains 2 serials: one for the incoming unsigned 
zone (eg. used to match incoming NOTIFYs) and one for the outgoing 
signed zone.


I want to monitor if my name servers are all up2date by monitoring and 
comparing the serial. This works to compare the serial of the public 
slave with the outgoing serial of Bind. But if I want to know if Bind is 
in sync with the hidden master, I somehow have to find out the 
"incoming" serial of Bind.


Are there any tools/ways to query Bind for the incoming serial?

Thanks
Klaus
___
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: How to query the "incoming" serial of a zone while inline signing

[Klaus Darilion]

On 30.01.2014 14:19, Mark Andrews wrote:

In message <52ea4c56.5060...@pernau.at>, Klaus Darilion writes:

Hi!

I use Bind for inline signing between a hidden master and the public
slaves. AFAIS Bind maintains 2 serials: one for the incoming unsigned
zone (eg. used to match incoming NOTIFYs) and one for the outgoing
signed zone.

I want to monitor if my name servers are all up2date by monitoring and
comparing the serial. This works to compare the serial of the public
slave with the outgoing serial of Bind. But if I want to know if Bind is
in sync with the hidden master, I somehow have to find out the
"incoming" serial of Bind.

Are there any tools/ways to query Bind for the incoming serial?


rndc zonestatus  [class [view]]


AFAIS this is only supported with bind 9.10.

Any tricks for stable bind (9.9.4)?

Thanks
Klaus
___
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: How to query the "incoming" serial of a zone while inline signing

[Klaus Darilion]

On 30.01.2014 14:28, Tony Finch wrote:

Mark Andrews  wrote:

In message <52ea4c56.5060...@pernau.at>, Klaus Darilion writes:


Are there any tools/ways to query Bind for the incoming serial?


rndc zonestatus  [class [view]]


I think that's a BIND-9.10 feature :-)

On 9.9 I think you either have to look at named's logs and/or look at the
unsigned zone file and journal using named-compilezone -j.


Thanks, that's what I was looking for.

For the records:

named-compilezone -j -f raw -o - example.com \
  /etc/bind/zones/example.com 2>&1| grep SOA|awk '{print $7;}'

regards
Klaus


___
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

NSEC3 hash collision

[Klaus Darilion]

Hi!

I just stumbled across section 7.1 of RFC 5155 
(http://tools.ietf.org/search/rfc5155#section-7.1):


As the "owner name" is hashed, there is potential for a hash collision. 
What confuses me is:



   If a hash collision is detected, then a new salt has to be chosen,
   and the signing process restarted.


But the salt is not chosen by Bind, but provided manually. So, I wonder 
how Bind reacts if a collision is detected. Or is Bind not checking for 
collisions at all?


Thanks
Klaus
___
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

missing NOTIFY after rndc signing -clear all zone

[Klaus Darilion]

Hi!

I just noticed that on "rndc signing -clear all zone", Bind removes the 
private RRs, updates the NSEC3 RR, and increases the serial, but it does 
not send NOTIFYs.


I guess this is a bug.

I tested bind 9.9.5, with inline-signing of a zone.

regards
Klaus
___
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: changing NSEC3 salt

[Klaus Darilion]

On 06.02.2014 14:58, Cathy Almond wrote:

On 06/02/2014 12:58, Timothe Litt wrote:

On 06-Feb-14 05:56, Cathy Almond wrote:

On 05/02/2014 18:54, David Newman wrote:

The Michael W. Lucas DNSSEC book recommends changing NSEC3 salt every
time a zone's ZSK changes.

Is this just a matter of a new 'rndc signing' command, or is some action
needed to remove the old salt?

thanks

dn

rndc signing -nsec3param ...

I would expect the old NSEC3 chain and old NSEC3PARAM record to be
removed, once the new chain is in place.

(Similarly, the new NSEC3PARAM record will not appear in the zone until
the new NSEC3 chain has been completely generated).

Cathy


This seems silly.  Why should a person have to select a salt at all?
It's just a random number, and people are really bad at picking random
numbers.  Seems like a miss in 'DNSSEC for humans' :-)

There should be a mechanism to tell named to pick a random number and
use it for the salt.  (I suggest '*' - '-' already means 'none'.)  named
already has to know how to get random numbers, so this should not be
difficult.  It should work for records supplied in UPDATE transactions
as well as rndc signing.

A bit more work to have it function when loaded from a zone file, though
that doesn't seem unreasonable.  (E.g. if read from a zone file, pick a
salt, treat the record as if loaded with that value, and do all the
requisite (re-)signing.)

I'm copying bind9-bugs so this doesn't get lost.  Please don't copy that
list if you comment on this. (Careful with that 'reply all'!)

Timothe Litt
ACM Distinguished Engineer


Sounds like a good idea - thanks.


Indeed. It would also solve the theoretical problem of NSEC3 hash 
collisions (see my email from 3. Feb 2014)


regards
Klaus

___
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: changing NSEC3 salt

[Klaus Darilion]

On 06.02.2014 11:56, Cathy Almond wrote:

On 05/02/2014 18:54, David Newman wrote:

The Michael W. Lucas DNSSEC book recommends changing NSEC3 salt every
time a zone's ZSK changes.

Is this just a matter of a new 'rndc signing' command, or is some action
needed to remove the old salt?

thanks

dn


rndc signing -nsec3param ...

I would expect the old NSEC3 chain and old NSEC3PARAM record to be
removed, once the new chain is in place.

(Similarly, the new NSEC3PARAM record will not appear in the zone until
the new NSEC3 chain has been completely generated).


And I recommend to use 9.9.5 - I had some NSEC3 troubles with 9.9.4.

regards
Klaus
___
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.5 assertion failure

[Klaus Darilion]

Hi all!

I just managed to "crash" Bind 9.9.5 with an assertion failure - see 
attached log file.


What my script does is:

1. delete zone via rndc (in this case the zone does not exist)
2. add zone via rndc
3. rndc signing -nsec3param 
4. rndc sign 
5. rndc signing -nsec3param  (this is redundant, but I had to do it 
with bind 9.9.4 otherwise it didn't worked)

6. rndc retransfer ...

Thanks
Klaus


Feb 11 11:31:02 named[13309]: received control channel command 'delzone 
pernau.at'
Feb 11 11:31:02 named[13309]: received control channel command 'addzone 
pernau.at {#012  type slave;#012  file 
"/etc/bind/zones/p/pernau.at/pernau.at";#012  masters { 88.198.53.113; };  
//not escaped as masters are separated by ;#012  key-directory 
"/etc/bind/keys/p/pernau.at";#012  auto-dnssec maintain;#012  inline-signing 
yes;#012};'
Feb 11 11:31:02 named[13309]: zone pernau.at added to view _default via addzone
Feb 11 11:31:02 named[13309]: zone pernau.at/IN (unsigned): Transfer started.
Feb 11 11:31:02 named[13309]: transfer of 'pernau.at/IN (unsigned)' from 
88.198.53.113#53: connected using 11.22.33.28#49098
Feb 11 11:31:02 named[13309]: zone pernau.at/IN (unsigned): transferred serial 
84
Feb 11 11:31:02 named[13309]: transfer of 'pernau.at/IN (unsigned)' from 
88.198.53.113#53: Transfer completed: 1 messages, 77 records, 1979 bytes, 0.347 
secs (5703 bytes/sec)
Feb 11 11:31:02 named[13309]: zone pernau.at/IN (signed): loaded serial 84
Feb 11 11:31:02 named[13309]: zone pernau.at/IN (signed): 
receive_secure_serial: unchanged
Feb 11 11:31:02 named[13309]: zone pernau.at/IN (signed): 
receive_secure_serial: unchanged
Feb 11 11:31:02 named[13309]: zone pernau.at/IN (signed): sending notifies 
(serial 84)
Feb 11 11:31:02 named[13309]: zone pernau.at/IN (signed): reconfiguring zone 
keys
Feb 11 11:31:02 named[13309]: zone pernau.at/IN (signed): next key event: 
11-Feb-2014 12:31:02.881
Feb 11 11:31:02 named[13309]: received control channel command 'signing 
-nsec3param 1 0 3 E5B40FA62813D79C pernau.at'
Feb 11 11:31:02 named[13309]: zone pernau.at/IN (signed): 
zone_addnsec3chain(1,CREATE,3,E5B40FA62813D79C)
Feb 11 11:31:02 named[13309]: received control channel command 'sign pernau.at'
Feb 11 11:31:02 named[13309]: zone pernau.at/IN (signed): reconfiguring zone 
keys
Feb 11 11:31:03 named[13309]: received control channel command 'signing 
-nsec3param 1 0 3 E5B40FA62813D79C pernau.at'
Feb 11 11:31:03 named[13309]: zone pernau.at/IN (signed): 
zone_addnsec3chain(1,CREATE,3,E5B40FA62813D79C)
Feb 11 11:31:03 named[13309]: zone pernau.at/IN (signed): next key event: 
11-Feb-2014 12:31:02.997
Feb 11 11:31:03 named[13309]: zone pernau.at/IN (signed): 
zone_addnsec3chain(1,REMOVE,3,E5B40FA62813D79C)
Feb 11 11:31:03 named[13309]: zone pernau.at/IN (signed): 
zone_addnsec3chain(1,CREATE,3,E5B40FA62813D79C)
Feb 11 11:31:03 named[13309]: received control channel command 'retransfer 
pernau.at'
Feb 11 11:31:03 named[13309]: zone pernau.at/IN (unsigned): Transfer started.
Feb 11 11:31:03 named[13309]: transfer of 'pernau.at/IN (unsigned)' from 
88.198.53.113#53: connected using 11.22.33.28#39132
Feb 11 11:31:03 named[13309]: zone pernau.at/IN (unsigned): transferred serial 
84
Feb 11 11:31:03 named[13309]: transfer of 'pernau.at/IN (unsigned)' from 
88.198.53.113#53: Transfer completed: 1 messages, 77 records, 1979 bytes, 0.053 
secs (37339 bytes/sec)
Feb 11 11:31:03 named[13309]: rdata.c:509: REQUIRE(((rdata)->data == ((void 
*)0) && (rdata)->length == 0 && (rdata)->rdclass == 0 && (rdata)->type == 0 && 
(rdata)->flags == 0 && !((void *)(((rdata))->link.prev) != (void *)(-1 
failed, back trace
Feb 11 11:31:03 named[13309]: #0 0x7f4eb371cc1f in ??
Feb 11 11:31:03 named[13309]: #1 0x7f4eb20ac6ca in ??
Feb 11 11:31:03 named[13309]: #2 0x7f4eb2fc806a in ??
Feb 11 11:31:03 named[13309]: #3 0x7f4eb2f742a7 in ??
Feb 11 11:31:03 named[13309]: #4 0x7f4eb3058bc1 in ??
Feb 11 11:31:03 named[13309]: #5 0x7f4eb20cff20 in ??
Feb 11 11:31:03 named[13309]: #6 0x7f4eb1a7e9ca in ??
Feb 11 11:31:03 named[13309]: #7 0x7f4eb148b1cd in ??
Feb 11 11:31:03 named[13309]: exiting (due to assertion failure)

___
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.5 assertion failure

[Klaus Darilion]

Very strange, it got another assertion when starting Bind after the crash:

Feb 11 11:49:48 named[22328]: transfer of 'pernau.at/IN (unsigned)' from 
88.198.53.113#53: connected using 11.22.33.28#46467
Feb 11 11:49:48 named[22328]: zone pernau.at/IN (unsigned): transferred 
serial 84
Feb 11 11:49:48 named[22328]: transfer of 'pernau.at/IN (unsigned)' from 
88.198.53.113#53: Transfer completed: 1 messages, 77 records, 1979 
bytes, 0.065 secs (30446 bytes/sec)
Feb 11 11:49:48 named[22328]: rdata.c:509: REQUIRE(((rdata)->data == 
((void *)0) && (rdata)->length == 0 && (rdata)->rdclass == 0 && 
(rdata)->type == 0 && (rdata)->flags == 0 && !((void 
*)(((rdata))->link.prev) != (void *)(-1 failed, back trace

Feb 11 11:49:48 named[22328]: #0 0x7f8061153c1f in ??
Feb 11 11:49:48 named[22328]: #1 0x7f805fae36ca in ??
Feb 11 11:49:48 named[22328]: #2 0x7f80609ff06a in ??
Feb 11 11:49:48 named[22328]: #3 0x7f80609ab2a7 in ??
Feb 11 11:49:48 named[22328]: #4 0x7f8060a8fbc1 in ??
Feb 11 11:49:48 named[22328]: #5 0x7f805fb06f20 in ??
Feb 11 11:49:48 named[22328]: #6 0x7f805f4b59ca in ??
Feb 11 11:49:48 named[22328]: #7 0x7f805eec21cd in ??
Feb 11 11:49:48 named[22328]: exiting (due to assertion failure)


Only the second startup worked.

Thanks
Klaus


On 11.02.2014 12:44, Klaus Darilion wrote:

Hi all!

I just managed to "crash" Bind 9.9.5 with an assertion failure - see
attached log file.

What my script does is:

1. delete zone via rndc (in this case the zone does not exist)
2. add zone via rndc
3. rndc signing -nsec3param 
4. rndc sign 
5. rndc signing -nsec3param  (this is redundant, but I had to do it
with bind 9.9.4 otherwise it didn't worked)
6. rndc retransfer ...

Thanks
Klaus




___
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


___
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: Sporadic but noticable SERVFAILs in specific nodes of an anycast resolving farm running BIND

[Klaus Darilion]

Does it only happen for IPv6 DNS requests? Maybe it is related to this:
https://open.nlnetlabs.nl/pipermail/nsd-users/2014-January/001783.html

klaus

On 05.03.2014 14:16, Kostas Zorbadelos wrote:


Greetings to all,

we operate an anycast caching resolving farm for our customer base,
based on CentOS (6.4 or 6.5), BIND (9.9.2, 9.9.5 or the stock CentOS
package BIND 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1) and quagga (the
stock CentOS package).

The problem is that we have noticed sporadic but noticable SERVFAILs in
3 out of 10 total machines. Cacti measurements obtained via the BIND XML
interface show traffic from 1.5K queries/sec (lowest loaded machines) to
15K queries/sec (highest). The problem is that in 3 specific machines in
a geolocation with a BIND restart we notice after a period of time that
can range between half an hour and several hours SERVFAILs in
resolutions. The 3 machines do not have the highest load in the farm
(6-8K q/sec). The resolution problems are noticable in the customers
ending up in these machines but do not show up as high numbers in the
BIND XML Resolver statistics (ServFail number).

We reproduce the problem, by querying for a specific domain name using
a loop of the form

while [ 1 ]; do clear; rndc flushname www.linux-tutorial.info; sleep 1;
dig www.linux-tutorial.info @localhost; sleep 2; done  | grep SERVFAIL

The www.linux-tutorial.info is not the only domain experiencing
resolution problems of course. The above loop can run for hours even
without issues on low-traffic hours (night, after a clean BIND restart)
but during the day it shows quite a few SERVFAILs, which affect other
domains as well.

During the problem we notice with tcpdump, that when SERVFAIL is
produced, no query packet exits the server for resolution. We have
noticed nothing in BIND logs (we even tried to raise debugging levels
and log all relevant categories). An example capture running the above
loop:

# tcpdump -nnn -i any -p dst port 53 or src port 53 | grep 'linux-tutorial'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes

14:33:03.590908 IP6 ::1.53059 > ::1.53: 15773+ A? www.linux-tutorial.info. (41)
14:33:03.591292 IP 83.235.72.238.45157 > 213.133.105.6.53: 19156% [1au] A? 
www.linux-tutorial.info. (52)
 Success

14:33:06.664411 IP6 ::1.45090 > ::1.53: 48526+ A? www.linux-tutorial.info. (41)
14:33:06.664719 IP6 2a02:587:50da:b::1.23404 > 2a00:1158:4::add:a3.53: 30244% 
[1au] A? www.linux-tutorial.info. (52)
 Success

14:33:31.434209 IP6 ::1.43397 > ::1.53: 26607+ A? www.linux-tutorial.info. (41)
 SERVFAIL

14:33:43.672405 IP6 ::1.58282 > ::1.53: 27125+ A? www.linux-tutorial.info. (41)
 SERVFAIL

14:33:49.706645 IP6 ::1.54936 > ::1.53: 40435+ A? www.linux-tutorial.info. (41)
14:33:49.706976 IP6 2a02:587:50da:b::1.48961 > 2a00:1158:4::add:a3.53: 4287% 
[1au] A? www.linux-tutorial.info. (52)
 Success

The main actions we have done on the problem machines are

- change the BIND version (we initially used a custom compiled 9.9.2, we
   moved to 9.9.5 and finally switched over to the CentOS stock package
   9.8.2rc1). We noticed the problem in all versions

- disable IPtables (we use a ruleset with connection tracking in all of
   our machines with no problems on the other machines in the
   farm). Again no solution

- introduce query-source-v6 address in named.conf (we already had
   query-source). Each machine has a single physical interface and 3
   loopbacks with the anycast IPs, announced via Quagga ospfd to the rest
   of the network. No solution.

The main difference in the 3 machines from the rest is the IPv6
operation. Those machines are dual stack, having /30 (v4) and /127 (v6)
on the physical interface. Needless to say that the next trial is to
remove the relevant IPv6 configuration.

I understand that there are many parameters to the problem, we try and
debug the issue several days now. Any suggestion, suspicion or hint is
highly welcome. I can provide all sorts of traces from the machines (I
already have pcap files at the moment of the problem, plus pstack, rndc
status, OS process limits, rndc recursing, rndc dumpdb -all, according
to

https://kb.isc.org/article/AA-00341/0/What-to-do-with-a-misbehaving-BIND-server.html)

Thanks in advance,

Kostas



___
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: Sporadic but noticable SERVFAILs in specific nodes of an anycast resolving farm running BIND

[Klaus Darilion]

Answering myself: This bug is probably not your problem, as Bind has 
received the DNS query, otherwise it would not answer with SERVFAIL.


regards
Klaus

On 05.03.2014 16:15, Klaus Darilion wrote:

Does it only happen for IPv6 DNS requests? Maybe it is related to this:
https://open.nlnetlabs.nl/pipermail/nsd-users/2014-January/001783.html

klaus

On 05.03.2014 14:16, Kostas Zorbadelos wrote:


Greetings to all,

we operate an anycast caching resolving farm for our customer base,
based on CentOS (6.4 or 6.5), BIND (9.9.2, 9.9.5 or the stock CentOS
package BIND 9.8.2rc1-RedHat-9.8.2-0.23.rc1.el6_5.1) and quagga (the
stock CentOS package).

The problem is that we have noticed sporadic but noticable SERVFAILs in
3 out of 10 total machines. Cacti measurements obtained via the BIND XML
interface show traffic from 1.5K queries/sec (lowest loaded machines) to
15K queries/sec (highest). The problem is that in 3 specific machines in
a geolocation with a BIND restart we notice after a period of time that
can range between half an hour and several hours SERVFAILs in
resolutions. The 3 machines do not have the highest load in the farm
(6-8K q/sec). The resolution problems are noticable in the customers
ending up in these machines but do not show up as high numbers in the
BIND XML Resolver statistics (ServFail number).

We reproduce the problem, by querying for a specific domain name using
a loop of the form

while [ 1 ]; do clear; rndc flushname www.linux-tutorial.info; sleep 1;
dig www.linux-tutorial.info @localhost; sleep 2; done  | grep SERVFAIL

The www.linux-tutorial.info is not the only domain experiencing
resolution problems of course. The above loop can run for hours even
without issues on low-traffic hours (night, after a clean BIND restart)
but during the day it shows quite a few SERVFAILs, which affect other
domains as well.

During the problem we notice with tcpdump, that when SERVFAIL is
produced, no query packet exits the server for resolution. We have
noticed nothing in BIND logs (we even tried to raise debugging levels
and log all relevant categories). An example capture running the above
loop:

# tcpdump -nnn -i any -p dst port 53 or src port 53 | grep
'linux-tutorial'
tcpdump: verbose output suppressed, use -v or -vv for full protocol
decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size
65535 bytes

14:33:03.590908 IP6 ::1.53059 > ::1.53: 15773+ A?
www.linux-tutorial.info. (41)
14:33:03.591292 IP 83.235.72.238.45157 > 213.133.105.6.53: 19156%
[1au] A? www.linux-tutorial.info. (52)
 Success

14:33:06.664411 IP6 ::1.45090 > ::1.53: 48526+ A?
www.linux-tutorial.info. (41)
14:33:06.664719 IP6 2a02:587:50da:b::1.23404 > 2a00:1158:4::add:a3.53:
30244% [1au] A? www.linux-tutorial.info. (52)
 Success

14:33:31.434209 IP6 ::1.43397 > ::1.53: 26607+ A?
www.linux-tutorial.info. (41)
 SERVFAIL

14:33:43.672405 IP6 ::1.58282 > ::1.53: 27125+ A?
www.linux-tutorial.info. (41)
 SERVFAIL

14:33:49.706645 IP6 ::1.54936 > ::1.53: 40435+ A?
www.linux-tutorial.info. (41)
14:33:49.706976 IP6 2a02:587:50da:b::1.48961 > 2a00:1158:4::add:a3.53:
4287% [1au] A? www.linux-tutorial.info. (52)
 Success

The main actions we have done on the problem machines are

- change the BIND version (we initially used a custom compiled 9.9.2, we
   moved to 9.9.5 and finally switched over to the CentOS stock package
   9.8.2rc1). We noticed the problem in all versions

- disable IPtables (we use a ruleset with connection tracking in all of
   our machines with no problems on the other machines in the
   farm). Again no solution

- introduce query-source-v6 address in named.conf (we already had
   query-source). Each machine has a single physical interface and 3
   loopbacks with the anycast IPs, announced via Quagga ospfd to the rest
   of the network. No solution.

The main difference in the 3 machines from the rest is the IPv6
operation. Those machines are dual stack, having /30 (v4) and /127 (v6)
on the physical interface. Needless to say that the next trial is to
remove the relevant IPv6 configuration.

I understand that there are many parameters to the problem, we try and
debug the issue several days now. Any suggestion, suspicion or hint is
highly welcome. I can provide all sorts of traces from the machines (I
already have pcap files at the moment of the problem, plus pstack, rndc
status, OS process limits, rndc recursing, rndc dumpdb -all, according
to

https://kb.isc.org/article/AA-00341/0/What-to-do-with-a-misbehaving-BIND-server.html)


Thanks in advance,

Kostas



___
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

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

nsec3 opt-out confusion

[Klaus Darilion]

Hi!

I use Bind 9.9.5 for inline signing. The zone is configured to use NSEC3 
without opt-out:


example.com 0   IN  NSEC3PARAM 1 0 10 BEEF

Nevertheless, most of the resulting NSEC3 records have the opt-out bit 
set and insecure delegations are indeed skipped (no NSEC3 records for 
insecure delegations), eg:


V24FPFCF9JU69PJH09ID0VEGDKLSN410.nic.at.  900 IN NSEC3  1 1 10 
BEEF 0OTL3SD4PC0BGU4IVRM0DI2OV4DE8QQN A RRSIG


The only NSEC3 records having the opt-out bit cleared are the NSEC3 
records for empty non-terminals, eg:


V1PD6GJFRL9AKKJLS8SLSFGE4D506CFN.example.com.  900 IN NSEC3  1 0 
10 BEEF V24FPFCF9JU69PJH09ID0VEGDKLSN410



So, I am confused.

1. Why does Bind uses opt-out although it is configured to not use opt-out?

2. What would be the behavior for empty non-terminal NSEC3 records if 
opt-out is enabled? Would the generated NSEC3 record still have the 
opt-out bit cleared?


Thanks
Klaus

___
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: nsec3 opt-out confusion (bug report)

[Klaus Darilion]

It seems Bind is a bit broken. I just removed NSEC3 and added NSEC3 
again with "1 0 10 BEEF", and suddenly all NSEC3 records had the opt-out 
flag clear.


Then I changed NSEC3 params to "1 1 10 BEEF". Then almost all NSEC3 
records had the opt-out flag set, but two NSEC3 records still had the 
flag clear. These two NSEC3 records correspond with empty non-terminal 
records for an insecure delegation (I guess they are not needed at all 
as the delegation is insecure and were forgotten to be deleted)


Then I removed NSEC3 and added NSEC3 params "1 1 10 BEEF". This time all 
the NSEC3 records had the opt-out flag set, but the NSEC3PARAM record shows:

  NSEC3PARAM 1 0 10 BEEF


Thus, it seems that I had opt-out activated, but the broken NSEC3PARAM 
header made me believe that opt-out was not enabled.


Nevertheless, it seems there are still two bugs:
1. The NSEC3 chain is not properly cleared when switching from 
non-opt-out to opt-out
2. The NSEC3PARAM record always has the opt-out flag clear, even if 
opt-out is activated.



Finally a question: The NSEC3 RFC allows a mixed opt-out mode within a 
zone. Is this used by Bind or does Bind always either use opt-out or 
non-opt-out?


Thanks
Klaus

On 01.04.2014 15:35, Klaus Darilion wrote:

Hi!

I use Bind 9.9.5 for inline signing. The zone is configured to use NSEC3
without opt-out:

example.com 0   IN  NSEC3PARAM 1 0 10 BEEF

Nevertheless, most of the resulting NSEC3 records have the opt-out bit
set and insecure delegations are indeed skipped (no NSEC3 records for
insecure delegations), eg:

V24FPFCF9JU69PJH09ID0VEGDKLSN410.nic.at.  900 IN NSEC3  1 1 10
BEEF 0OTL3SD4PC0BGU4IVRM0DI2OV4DE8QQN A RRSIG

The only NSEC3 records having the opt-out bit cleared are the NSEC3
records for empty non-terminals, eg:

V1PD6GJFRL9AKKJLS8SLSFGE4D506CFN.example.com.  900 IN NSEC3  1 0
10 BEEF V24FPFCF9JU69PJH09ID0VEGDKLSN410


So, I am confused.

1. Why does Bind uses opt-out although it is configured to not use opt-out?

2. What would be the behavior for empty non-terminal NSEC3 records if
opt-out is enabled? Would the generated NSEC3 record still have the
opt-out bit cleared?

Thanks
Klaus

___
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

___
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: nsec3 opt-out confusion (bug report)

[Klaus Darilion]

On 01.04.2014 17:09, Chris Thompson wrote:

On Apr 1 2014, Klaus Darilion wrote:

[...]

Nevertheless, it seems there are still two bugs:
1. The NSEC3 chain is not properly cleared when switching from
non-opt-out to opt-out
2. The NSEC3PARAM record always has the opt-out flag clear, even if
opt-out is activated.


That last, at least, is not a bug. It is mandated by RFC 5155 - see
section 4.1.2.


Indeed. Thanks. That's confusing. From the RFC:


The NSEC3PARAM RR contains the NSEC3 parameters (hash algorithm,
   flags, iterations, and salt) needed by authoritative servers to
   calculate hashed owner names


So it can be used to instruct the authoritative name server about 
iterations, algorithm and salt, but not for flags. What is the reason 
behind this rule?




This was really nic.at (and not example.com), wasn't it? Your domain
obfustication was half-hearted! I tried looking at it, but things
were changing too fast for me to get consistent results...


Yes, half hearted. It is now stable again. The "zombie" NSEC3 records 
left over from a switch to opt-out were causing problems on validating 
resolvers.


regards
Klaus
___
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

DNSSEC: recover from missing keys

[Klaus Darilion]

Hi!

During rollover testing I quite often delete keys without properly
settings the timestamps in the keys - it is testing only.

This leads to such errors:

error reading private key file example.com/NSEC3RSASHA1/64337: file not
found

To recover and restart my testing I:
- remove the zone from the config
- rndc reconfig
- delete the signed zone and journal files
- ad the zone to the config
- rndc reconfig

This works but is cumbersome. Is there a method to instruct Bind to just
remove all references to the missing keys and start a fresh signing with
the existing keys?

Thanks
Klaus
___
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

KSK signing incomplete

[Klaus Darilion]

Hi!

Using Bind 9.9.5.

I have some questions about the private records which indicate the
signing status. From my external key management and monitoring tool I
query the private records to get the signing status, e.g. if the signing
after a rollover is finished, if a key can be deleted from disk, ...

But sometimes I see that the KSK signing is incomplete (last octet=0).

As you can see, the KSK (63963, 0xF9DB) is used to sign the DNSKEYs:

# dig @83.136.34.28 DNSKEY +dnssec tld-box.com +multi
tld-box.com.60 IN DNSKEY 257 3 7 (
AwEAAa3+Y3K0FTZkaLZqsERhGAHKjHOnCTO+hQMsj8yQ
Sw+U/tmplyHTy5zEG6T26G8aGHbS8fnrCGs0EPXKkiWJ
jfw+xRgiqbTJmT7o8LTd1CIHO+J4GbKXRV95EjoUH/P9
qfJTbcqjwWblkzhEDuSNilec1pnJ0uEMcN+7z3p7VcC3
H8uFPT2A2PhQ5OPDoGRym4HPkn2zL+hzpSboUeWGoAHw
zowuc1/Dt2nKUNoUzDECDZusWDdws9SG+g6CAMSxshvJ
haM0GKO9LdlMqkUrP2wdS6bomTM4gTvk2HFFLuzY+ZpX
kFkJSx1xjDN4iJxcDtxCpz53jPYaz3ObfbKRzBc=
) ; KSK; alg = NSEC3RSASHA1; key id = 63963
tld-box.com.60 IN DNSKEY 256 3 7 (
...
tld-box.com.60 IN RRSIG DNSKEY 7 2 60 (
20140619162004 20140520152004 63963 tld-box.com.
Oywivr89OgqlJHeR6xOtzjTCsH90Jp4NivuC5W8jiGO4
aeWVZOZZhyZs/QkVifUCupjZ/uAlAyTNC1WNeKjej+4P
0A7a++p1U96CF0A1PIWblcNN7HbLv+0JGd6yddIHuNkF
ZseefyD2OzRMiKix+5u5xH1NavaOt8ggBPUSlpp/YOdL
UFIhoFwkCbAp4a7WYhMZZj+6gCk9RZAZXHo1EuFPtwt4
xd/tl4EK6i37yNxnimS1/KsHx6Gip0yQW0Qt6fOJsk79
laOmLm/xozgwH1CqNq4hjypoPib07m0Aot+7LKP5Svcy
+MfG7BLeNVfRqWPI3+ztWVjXZvp/Rlpdzg== )

But the private records indicate:
# dig @83.136.34.28 TYPE65534 tld-box.com
tld-box.com.0   IN  TYPE65534 \# 5 071D960001
tld-box.com.0   IN  TYPE65534 \# 5 07F9DB
tld-box.com.0   IN  TYPE65534 \# 5 07213E0001

As the first octet is not 0, the last octet should indicate the signing
status: !=0 means "completed", which is not the case: 5 07F9DB

Same with rndc:
# rndc signing -list tld-box.com
Done signing with key 7574/NSEC3RSASHA1
Done signing with key 8510/NSEC3RSASHA1
Signing with key 63963/NSEC3RSASHA1


What else should the KSK sign?

Also forcing resign does not change anything:

# rndc sign tld-box.com
# rndc signing -list tld-box.com
Done signing with key 7574/NSEC3RSASHA1
Done signing with key 8510/NSEC3RSASHA1
Signing with key 63963/NSEC3RSASHA1


So, why is the signing not finished? I would like to force Bind to
finish the signing so that my monitoring can reliable check the private
records.



Further, I see that sometimes there are no private records at all. When
does this happen? (I never called "rndc signing -clear") How can I force
Bind to always show the private records?

Thanks
Klaus



___
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: KSK signing incomplete

[Klaus Darilion]

> Further, I see that sometimes there are no private records at all. When
> does this happen? (I never called "rndc signing -clear") 

It seems that this happens when Bind is restarted.

So, what is the suggested (and reliable) way for external tools to get
the signing status from Bind? I.e. if a key is still used for signing or
can be deleted?

Thanks
Klaus
___
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: KSK signing incomplete

[Klaus Darilion]

On 21.05.2014 12:39, Phil Mayers wrote:
> On 21 May 2014 10:24:23 BST, Klaus Darilion  
> wrote:
>>> Further, I see that sometimes there are no private records at all.
>> When
>>> does this happen? (I never called "rndc signing -clear") 
>>
>> It seems that this happens when Bind is restarted.
>>
>> So, what is the suggested (and reliable) way for external tools to get
>> the signing status from Bind? I.e. if a key is still used for signing
>> or
>> can be deleted?
>>
>> Thanks
>> Klaus
> 
> We bodge this by axfr'ing the zone and parsing the rrsig to see which keys 
> are generating which sigs (or not). Nasty and slow, but reliable, and also 
> lets you look for signatures that haven't been regenerated on schedule.

That's actually what I wanted to avoid. I thought there will be an "API"
or similar to get the signing status of the zone and thought that the
private records will solve my troubles, but it seems I was wrong.

I think I will do something similar - not nice if you have plenty of
zones ...

thanks
Klaus
___
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 ignoring signing -nsec3param when inline-signing a zone

[Klaus Darilion]

Hi!

Today I managed that Bind 9.9.5 created a signed zone with all RRs
signed except the SOA. The private RRs showed "finshed signing". Only
after another "rndc loadkeys" also the SOA was signed.

Unfortunately I can not reproduce the problem, but I suspect it may be
related to the order how I add the zone for signing to Bind, as up to
now I sent lots of rndc commands to Bind.

Therefore I simplified my provision to only:

1. Create the keys

2. Add the zone to Bind via rndc:

zone "pernau.at" {
  type slave;
  file "/etc/bind/zones/p/pernau.at/pernau.at";
  masters { 88.198.53.113; };
  key-directory "/etc/bind/keys/p/pernau.at";
  auto-dnssec maintain;
  inline-signing yes;
};

Is it safe to consider that this will start the incoming zone transfer
and signing (without the need for an "rndc sign" command)?

3. Configure NSEC3:
rndc signing -nsec3param 1 0 10 E1BDC7F3624A9508 pernau.at

The problem is, that the nsec3param command is received by Bind but
ignored: as you can see there is no zone_addnsec3chain() logging:


11:47:53: received control channel command 'addzone pernau.at {...}'
11:47:53: zone pernau.at added to view _default via addzone
11:47:53: received control channel command 'signing -nsec3param 1 0 10
F2195A3D604B7EC8 pernau.at'
11:47:53: zone pernau.at/IN (unsigned): Transfer started.
11:47:53: transfer of 'pernau.at/IN (unsigned)' from 88.198.53.113#53:
connected using 83.136.34.28#53286
11:47:53: zone pernau.at/IN (unsigned): transferred serial 85
11:47:53: transfer of 'pernau.at/IN (unsigned)' from 88.198.53.113#53:
Transfer completed: 1 messages, 78 records, 2007 bytes, 0.033 secs
(60818 bytes/sec)
11:47:53: zone pernau.at/IN (signed): loaded serial 85
11:47:53: zone pernau.at/IN (signed): receive_secure_serial: unchanged
11:47:53: zone pernau.at/IN (signed): receive_secure_serial: unchanged
11:47:53: zone pernau.at/IN (signed): sending notifies (serial 85)
11:47:53: zone pernau.at/IN (signed): reconfiguring zone keys
11:47:53: zone pernau.at/IN (signed): next key event: 05-Jun-2014
12:47:53.563



# rndc signing -nsec3param 1 0 10 E1BDC7F3624A9508 pernau.at
request queued

11:48:23: received control channel command 'signing -nsec3param 1 0 10
E1BDC7F3624A9508 pernau.at'
11:48:23: zone pernau.at/IN (signed):
zone_addnsec3chain(1,CREATE,10,E1BDC7F3624A9508)
11:48:23: zone pernau.at/IN (signed): sending notifies (serial 106)

As you see, only after the second "rndc signing -nsec3param" command
Bind switched to NSEC3. I think this is due to the nsec3 command is sent
immediately after the "add zone" command.


So, is this a bug in Bind or do I have to provision Bind different?


Another question: is it possible to instruct Bind to use NSEC3 from the
beginning? I read this can be done with dynamic updates, but in my setup
with inline-signing I suspect this is not possible.

Thanks
Klaus
___
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 ignoring signing -nsec3param when inline-signing a zone

[Klaus Darilion]

I have a suspect: May it be that "rndc signing nsec3param" adds the
NSEC3PARAM RR internally to the unsigned zone file. Thus, calling "rndc
signing nsec3param" does not work before the initial zone transfer.

This would mean I have to check when the initial transfer succeeded
before calling "rndc signing nsec3param" - this is not nice.

Are there any workarounds for that? IMO it would be cool if Bind would
store NSEC3 options outside of the zone.

Thanks
Klaus

On 05.06.2014 14:02, Klaus Darilion wrote:
> Hi!
> 
> Today I managed that Bind 9.9.5 created a signed zone with all RRs
> signed except the SOA. The private RRs showed "finshed signing". Only
> after another "rndc loadkeys" also the SOA was signed.
> 
> Unfortunately I can not reproduce the problem, but I suspect it may be
> related to the order how I add the zone for signing to Bind, as up to
> now I sent lots of rndc commands to Bind.
> 
> Therefore I simplified my provision to only:
> 
> 1. Create the keys
> 
> 2. Add the zone to Bind via rndc:
> 
> zone "pernau.at" {
>   type slave;
>   file "/etc/bind/zones/p/pernau.at/pernau.at";
>   masters { 88.198.53.113; };
>   key-directory "/etc/bind/keys/p/pernau.at";
>   auto-dnssec maintain;
>   inline-signing yes;
> };
> 
> Is it safe to consider that this will start the incoming zone transfer
> and signing (without the need for an "rndc sign" command)?
> 
> 3. Configure NSEC3:
> rndc signing -nsec3param 1 0 10 E1BDC7F3624A9508 pernau.at
> 
> The problem is, that the nsec3param command is received by Bind but
> ignored: as you can see there is no zone_addnsec3chain() logging:
> 
> 
> 11:47:53: received control channel command 'addzone pernau.at {...}'
> 11:47:53: zone pernau.at added to view _default via addzone
> 11:47:53: received control channel command 'signing -nsec3param 1 0 10
> F2195A3D604B7EC8 pernau.at'
> 11:47:53: zone pernau.at/IN (unsigned): Transfer started.
> 11:47:53: transfer of 'pernau.at/IN (unsigned)' from 88.198.53.113#53:
> connected using 83.136.34.28#53286
> 11:47:53: zone pernau.at/IN (unsigned): transferred serial 85
> 11:47:53: transfer of 'pernau.at/IN (unsigned)' from 88.198.53.113#53:
> Transfer completed: 1 messages, 78 records, 2007 bytes, 0.033 secs
> (60818 bytes/sec)
> 11:47:53: zone pernau.at/IN (signed): loaded serial 85
> 11:47:53: zone pernau.at/IN (signed): receive_secure_serial: unchanged
> 11:47:53: zone pernau.at/IN (signed): receive_secure_serial: unchanged
> 11:47:53: zone pernau.at/IN (signed): sending notifies (serial 85)
> 11:47:53: zone pernau.at/IN (signed): reconfiguring zone keys
> 11:47:53: zone pernau.at/IN (signed): next key event: 05-Jun-2014
> 12:47:53.563
> 
> 
> 
> # rndc signing -nsec3param 1 0 10 E1BDC7F3624A9508 pernau.at
> request queued
> 
> 11:48:23: received control channel command 'signing -nsec3param 1 0 10
> E1BDC7F3624A9508 pernau.at'
> 11:48:23: zone pernau.at/IN (signed):
> zone_addnsec3chain(1,CREATE,10,E1BDC7F3624A9508)
> 11:48:23: zone pernau.at/IN (signed): sending notifies (serial 106)
> 
> As you see, only after the second "rndc signing -nsec3param" command
> Bind switched to NSEC3. I think this is due to the nsec3 command is sent
> immediately after the "add zone" command.
> 
> 
> So, is this a bug in Bind or do I have to provision Bind different?
> 
> 
> Another question: is it possible to instruct Bind to use NSEC3 from the
> beginning? I read this can be done with dynamic updates, but in my setup
> with inline-signing I suspect this is not possible.
> 
> Thanks
> Klaus
> ___
> 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
> 
___
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

incomplete NSEC3 chains

[Klaus Darilion]

Release: BIND 9.9.5

I regularly perform key rollovers and zone validation of an
inline-signed zone. The zone validator receives NOTIFYs and then it
transfers the zone and validates it (using dnssec-verify and validns).

I also regularly call "rndc retransfer" to make sure to have an correct
zone.

Sometimes my zone validator receives zone files with incomplete NSEC3
chains (NSEC3 RRs are missing and the chain skips this missing RRs, and
the NSEC3PARM RR is missing.

I suspect that due to the "rndc retransfer" Bind starts to recalculate
the complete NSEC3 chain and my zone validator fetches the zone while
Bind recalculates the NSEC3 chain.

1. Why does Bind provide an incomplete zone file for zone transfer? The
transferred zone is broken. IMO Bind should not provide broken zones.
Either it should provide the old zone while re-calculating the NSEC3
chain, or it should refuse the zone transfer until the NSEC3 chain is
correct again.

2. Why does the "rndc retransfer" re-calculates the NSEC3 chain, but
normal zone transfer (increase serial + NOTIFY) not? Both use AXFR to
fetch the zone.

Thanks
Klaus
___
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

dynamically adding/removing TSIG configuration

[Klaus Darilion]

Hi!

I currently use rndc addzone/delzone to manage zones on my slave. I now
want to add TSIG for some of these zones and I want to be able to
enable/disable TSIG dynamically per zone.

Unfortunately I haven't found a nice solution yet. My results are:

1. delzone/addzone with adding the tsig key name to the { zone-options;
} and include named.conf.tsigkeys where I add the key.

Not nice because I have to touch 2 interfaces (rndc and manuelly edit
config files)

2. do not use delzone/addzone anymore but manually rewrite the
named.conf.local file and add/delete/update the zone. IMO it is not nice
fumbling around in the config file - I have to take care of locks and so on.

Thus, does anybody has an idea how I can configure TSIG via some kind of
API?

Thanks
Klaus
___
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

Retrying failed zone transfer

[Klaus Darilion]

Hi!

I have a Bind 9.9.5 running as slave. The master is not configured
correctly and rejects the zone transfer. It seems that if Bind has never
received the zone yet, it tries endlessly to fetch the zone (see below),
~3 times per second.

It would be nice if Bind for example retries only every minute or so. Is
it possible to configure Bind for such a behavior?

Thanks
Klaus


Jul 22 13:45:34 zone example.it/IN (unsigned): Transfer started.
Jul 22 13:45:35 transfer of 'example.it/IN (unsigned)' from
11.22.142.96#53: connected using 33.44.34.24#53814
Jul 22 13:45:35 transfer of 'example.it/IN (unsigned)' from
11.22.142.96#53: failed while receiving responses: NOTAUTH
Jul 22 13:45:35 transfer of 'example.it/IN (unsigned)' from
11.22.142.96#53: Transfer completed: 0 messages, 0 records, 0 bytes,
0.031 secs (0 bytes/sec)
Jul 22 13:45:35 zone example.it/IN (unsigned): Transfer started.
Jul 22 13:45:35 transfer of 'example.it/IN (unsigned)' from
11.22.142.96#53: connected using 33.44.34.24#42776
Jul 22 13:45:35 transfer of 'example.it/IN (unsigned)' from
11.22.142.96#53: failed while receiving responses: NOTAUTH
Jul 22 13:45:35 transfer of 'example.it/IN (unsigned)' from
11.22.142.96#53: Transfer completed: 0 messages, 0 records, 0 bytes,
0.031 secs (0 bytes/sec)
Jul 22 13:45:35 zone example.it/IN (unsigned): Transfer started.
Jul 22 13:45:35 transfer of 'example.it/IN (unsigned)' from
11.22.142.96#53: connected using 33.44.34.24#44017
Jul 22 13:45:35 transfer of 'example.it/IN (unsigned)' from
11.22.142.96#53: failed while receiving responses: NOTAUTH
Jul 22 13:45:35 transfer of 'example.it/IN (unsigned)' from
11.22.142.96#53: Transfer completed: 0 messages, 0 records, 0 bytes,
0.031 secs (0 bytes/sec)
Jul 22 13:45:35 zone example.it/IN (unsigned): Transfer started.
Jul 22 13:45:35 transfer of 'example.it/IN (unsigned)' from
11.22.142.96#53: connected using 33.44.34.24#60674
Jul 22 13:45:35 transfer of 'example.it/IN (unsigned)' from
11.22.142.96#53: failed while receiving responses: NOTAUTH
Jul 22 13:45:35 transfer of 'example.it/IN (unsigned)' from
11.22.142.96#53: Transfer completed: 0 messages, 0 records, 0 bytes,
0.031 secs (0 bytes/sec)
Jul 22 13:45:36 zone example.it/IN (unsigned): Transfer started.
Jul 22 13:45:36 transfer of 'example.it/IN (unsigned)' from
11.22.142.96#53: connected using 33.44.34.24#33693
Jul 22 13:45:36 transfer of 'example.it/IN (unsigned)' from
11.22.142.96#53: failed while receiving responses: NOTAUTH
Jul 22 13:45:36 transfer of 'example.it/IN (unsigned)' from
11.22.142.96#53: Transfer completed: 0 messages, 0 records, 0 bytes,
0.031 secs (0 bytes/sec)

___
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: Reload BIND to listen on additional interface?

[Klaus Darilion]

If you manually configure the listen-on IP addresses, that may help:
http://linux-ip.net/html/adv-nonlocal-bind.html

regards
Klaus

On 31.07.2014 13:24, Johannes Kastl wrote:
> Hi everyone,
> 
> in the quest to use a master behind a Router with changing IPs, I set
> up a VPN and told bind on both sides to listen on the additional VPN-IPs.
> 
> But, sometimes they are not available at bind startup or the VPN loses
> connection. So, when the VPN connection is ready again, I can let
> OpenVPN run a script. My idea was to use this script to tell bind,
> that it can now bind to the interface again.
> 
> Question now is, which (rndc) command does that? Does a ‘rndc
> reconfig‘ tell BIND to newly bind to the interfaces?
> 
> Thanks in advance.
> 
> Regards,
> Johannes
> 
> ___
> 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
> 
___
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: rndc (and now nsupdate too)

[Klaus Darilion]

Am 31.07.2014 21:08, schrieb /dev/rob0:

The proper tool to manage named configuration and operation, and
which in the best Unix ethic is well suited for automation, is
rndc(8).
You can not always use rndc. For example you can add and delete zones, 
but you can not modify zones via rndc.


regards
Klaus
___
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

How to check slave zone freshness

[Klaus Darilion]

Hi!

I want to monitor the freshness of my slaves zones. Is it somehow
possible to extract the status of slave-zones from bind?

Thanks
Klaus
___
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: How to check slave zone freshness

[Klaus Darilion]

Am 08.02.2016 um 14:59 schrieb Warren Kumari:
> The standard, compatible way to do this is simply to do a lookup for the
> SOA record and make sure that the serial number matches what you expect
> it to be / what is on the master. I'm not sure what monitoring tool you
> are using (or if you are writing your own), but most standard monitoring
> tools have such a script already written -
> e.g: 
> https://exchange.nagios.org/directory/Plugins/Network-Protocols/DNS/checkexpire/details

This does not detect problems between the master and slave as long as
the master is not updated.

Further I can not fetch the serial easily from the slave as our slave is
a "bump in the wire" signer, so the SOA is the internal increased
"DNSSEC serial". So I would need to extract it from the local zone
files/journal.

> I believe that BIND also updates the mtime on the zone file when it does
> the check (not only when something changes):
> root@eric:/etc/namedb/slave# date
> Mon Feb  8 08:36:58 EST 2016
> root@eric:/etc/namedb/slave# ls -al superficialinjurymonkey.com
> *
> -rw-r--r-- 1 named named  714 Feb  8 03:51 superficialinjurymonkey.com
> 
> -rw-r--r-- 1 named named 1236 Feb  8 03:51 superficialinjurymonkey.com.jnl
> root@eric:/etc/namedb/slave#
> 
> So, you should be able to just run 'ls' and see if the 'mtime' is larger
> than you expect...

This is an interesting hint and good starting point. Thanks.

Nevertheless, additionally I would to need to extract the SOA refresh
value for every zone to find out if a zone is not fresh any more.

Thanks
Klaus
___
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: How to check slave zone freshness

[Klaus Darilion]

Am 08.02.2016 um 14:58 schrieb Tony Finch:
> Klaus Darilion  wrote:
>>
>> I want to monitor the freshness of my slaves zones. Is it somehow
>> possible to extract the status of slave-zones from bind?
> 
> If you are running 9.10 or later you can use `rndc zonestatus`.

Ah. Nice, as updating to 9.10 is on my plan.

I guess I need to iterate over all configured zones, may be a bit slow
for several thousand zones. I will seee ...

> I have an older script which just looks at the timestamp of the zone
> files; BIND bumps the timestamp whenever it successfully refreshes the
> zone, even if it didn't need to transfer any changes.

Thanks for the info
Klaus


___
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: How to check slave zone freshness

[Klaus Darilion]

On 08.02.2016 20:49, Mark Andrews wrote:
> With a modern nameserver that supports the expire edns option you can
> also do "dig +expire soa zone @server" which will tell you how long
> until the zone will expire on this server.

Aha, but isn't this a different kind of information? A zone which is not
fresh anymore (refresh interval expired and checks to the master failed)
may still be valid (not expired yet).

regards
Klaus
___
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: How to check slave zone freshness

[Klaus Darilion]

On 08.02.2016 14:58, Tony Finch wrote:
> Klaus Darilion  wrote:
>>
>> I want to monitor the freshness of my slaves zones. Is it somehow
>> possible to extract the status of slave-zones from bind?
> 
> If you are running 9.10 or later you can use `rndc zonestatus`.
> 
> I have an older script which just looks at the timestamp of the zone
> files; BIND bumps the timestamp whenever it successfully refreshes the
> zone, even if it didn't need to transfer any changes.

This does not work as expected. When bind checks the SOA on the master
and detects a bigger serial, it tries to transfer the zone. Although the
zone transfer fails, the timestamp gets updated. Thus, the zone looks
fresh, but it isn't.

regards
Klaus
___
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: How to check slave zone freshness

[Klaus Darilion]

On 10.02.2016 09:27, Klaus Darilion wrote:
> 
> 
> On 08.02.2016 14:58, Tony Finch wrote:
>> Klaus Darilion  wrote:
>>>
>>> I want to monitor the freshness of my slaves zones. Is it somehow
>>> possible to extract the status of slave-zones from bind?
>>
>> If you are running 9.10 or later you can use `rndc zonestatus`.
>>
>> I have an older script which just looks at the timestamp of the zone
>> files; BIND bumps the timestamp whenever it successfully refreshes the
>> zone, even if it didn't need to transfer any changes.
> 
> This does not work as expected. When bind checks the SOA on the master
> and detects a bigger serial, it tries to transfer the zone. Although the
> zone transfer fails, the timestamp gets updated. Thus, the zone looks
> fresh, but it isn't.

Another test: I changed the master IP on the slave to 1.1.1.1. Thus,
every SOA check and zone transfer will fail. Nevertheless bind updates
the zone file's timestamp every time it tries to transfer the zone.
Tested with 9.9.8-P3.


Thus, any other options with bind 9.9.8? (I have not managed to build
Debian packages for bind 9.10)

Thanks
Klaus

___
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

What happens if the max-tcp-connections limit is reached?

[Klaus Darilion]

Hello all!

Will bind refuse (close) the new TCP connections, or will it accept the
new connection and closes the longest idle TCP connection? Or even better?

Thanks
Klaus
___
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

max-ixfr-ratio values

[Klaus Darilion]

max-ixfr-ratio introduced with 9.17.0 sounds like a workaround instead 
of a bugfix.


Anyway, can you recommend a sensible settings? I.e. when does the 
performance problem of "large" IXFR starts to happen? Does this depend 
on the ratio of the IXFR-size to zone-size, or does it depend on the 
size of the IXFR, regardless how big the zone is? (I hope the first 
thing, otherwise it would be better to define a max-ixfr-size instead of 
a ratio.)


I would like to know in more detail when the peformance drop happens, to 
find a proper value for the max-ixfr-ratio. Or do I have to play around 
with the value to find a compromise fast updates vs IXFR-triggered DoS?


Thanks
Klaus
___
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

Debian/Ubuntu: Why was the service renamed from bind9 to named?

[Klaus Darilion]

Hello!

What is the rationale of:

bind9 (1:9.13.6-1) experimental; urgency=medium
...
  * Rename the init scripts to named to match the name of the daemon


Since years, Debian and Ubuntu User, and plenty of scripts and automation 
software (Puppet ...), know that the service is called "bind9". I think it is 
very confusing and will cause lots of headaches once Ubuntu 18.04 or Debian 11 
is released.

So I really do not understand this renaming.

The software is "Bind 9". The package is "bind9". The service for long time was 
"bind9". The config is in /etc/bind. Only the binary is named. So it would have 
made more sense to rename the binary. (actually the binary is not so important 
for end users: they install the package and manage the service and usually do 
not have to worry about the name of the binary).

It would be great if you undo this change before release of 18.04.

regards
Klaus
___
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

AW: Debian/Ubuntu: Why was the service renamed from bind9 to named?

[Klaus Darilion]

> -Ursprüngliche Nachricht-
> Von: bind-users  Im Auftrag von Reindl
> Harald
> Gesendet: Mittwoch, 15. April 2020 09:05
> An: bind-users@lists.isc.org
> Betreff: Re: Debian/Ubuntu: Why was the service renamed from bind9 to
> named?
> 
> 
> 
> Am 15.04.20 um 08:56 schrieb Reindl Harald:
> >
> >
> > Am 15.04.20 um 08:51 schrieb Klaus Darilion:
> >> Hello!
> >>
> >> What is the rationale of:
> >>
> >> bind9 (1:9.13.6-1) experimental; urgency=medium
> >> ...
> >>   * Rename the init scripts to named to match the name of the daemon
> >>
> >>
> >> Since years, Debian and Ubuntu User, and plenty of scripts and
> automation software (Puppet ...), know that the service is called "bind9". I
> think it is very confusing and will cause lots of headaches once Ubuntu 18.04
> or Debian 11 is released.
> >>
> >> So I really do not understand this renaming.
> >>
> >> The software is "Bind 9". The package is "bind9". The service for long time
> was "bind9". The config is in /etc/bind. Only the binary is named. So it would
> have made more sense to rename the binary. (actually the binary is not so
> important for end users: they install the package and manage the service and
> usually do not have to worry about the name of the binary).
> >>
> >> It would be great if you undo this change before release of 18.04
> >
> > you confuse the upstream project with your distribution
> >
> > bind9 was completly wrong in the debian world as well as apache2 for
> > httpd, on sane distributions it's "httpt" and "named" all the years
> > beause it's nonsense to throw vesions in service names
> 
> BTW in case Debian/Ubuntu when they do RTFM it wouldn't be an issue at all
> 
> [root@srv-rhsoft:~]$ systemctl status sddm
> ● sddm.service - Simple Desktop Display Manager
>Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled; vendor
> preset: enabled)
>   Drop-In: /etc/systemd/system/display-manager.service.d
> 
> [root@srv-rhsoft:~]$ systemctl status display-manager.service
> ● sddm.service - Simple Desktop Display Manager
>Loaded: loaded (/usr/lib/systemd/system/sddm.service; enabled; vendor
> preset: enabled)
>   Drop-In: /etc/systemd/system/display-manager.service.d
>└─security.conf, start-before.conf
> 
> [root@srv-rhsoft:~]$ cat /usr/lib/systemd/system/sddm.service
> [Unit]
> Description=Simple Desktop Display Manager
> Conflicts=getty@tty1.service
> After=getty@tty1.service systemd-logind.service
> 
> [Service]
> ExecStart=/usr/bin/sddm
> Restart=always
> EnvironmentFile=-/etc/sysconfig/sddm
> 
> [Install]
> Alias=display-manager.service

Can you please describe what you want to point out? I can not follow you.

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

AW: Debian/Ubuntu: Why was the service renamed from bind9 to named?

[Klaus Darilion]

> > It would be great if you undo this change before release of 18.04
> 
> you confuse the upstream project with your distribution
> 
> bind9 was completly wrong in the debian world as well as apache2 for
> httpd, on sane distributions it's "httpt" and "named" all the years
> beause it's nonsense to throw vesions in service names

I do not complain about the version number, but of the name.

And in my opinion it is not sane to call a service/package httpd if the name of 
the software is Apache.

regards
Klaus


___
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

AW: Debian/Ubuntu: Why was the service renamed from bind9 to named?

[Klaus Darilion]

> -Ursprüngliche Nachricht-
> Von: bind-users  Im Auftrag von Reindl
> Harald
> Gesendet: Mittwoch, 15. April 2020 09:17
> An: bind-users@lists.isc.org
> Betreff: Re: Debian/Ubuntu: Why was the service renamed from bind9 to
> named?
> 
> 
> 
> Am 15.04.20 um 09:09 schrieb Klaus Darilion:
> >>> It would be great if you undo this change before release of 18.04
> >>
> >> you confuse the upstream project with your distribution
> >>
> >> bind9 was completly wrong in the debian world as well as apache2 for
> >> httpd, on sane distributions it's "httpt" and "named" all the years
> >> beause it's nonsense to throw vesions in service names
> >
> > I do not complain about the version number, but of the name.
> >
> > And in my opinion it is not sane to call a service/package httpd if the name
> of the software is Apache
> 
> seriously?
> 
> https://www.apache.org/
> 
> https://downloads.apache.org/httpd/
> https://downloads.apache.org/tomcat/
> https://downloads.apache.org/trafficserver/
> 
> and what do you do after httpd-3.0 is out?
> 
> you won't have httpd2 and httpd3 on the same system from your
> distribution

Why not? With postgresql it is very common. You have postgresql-X and a meta 
package pointing to the newest version. That's propapbly not what "every 
distribution" does, but how a good distribution like Debian and Ubuntu does it.

It is very very sane to have the version number in the package, and a package 
without version number pointing to the newest version. Eg. this is how the 
Linux kernel is handled in Debian/Ubuntu.

What about python? Only a single python interpreter is allowed with your good 
distros? In Debian you have all oft hem installed at the same time - this is a 
very very good approach!

But as you have missed again - I do not complain about the version number, but 
that a "winning team" was changed without seeing a problem.

regards
Klaus
___
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

AW: Debian/Ubuntu: Why was the service renamed from bind9 to named?

[Klaus Darilion]

Thanks for answer!

So actually it is just a cosmetic change not addressing a real problem.

I will miss the bind9 service :-(

Klaus


> -Ursprüngliche Nachricht-
> Von: Ondřej Surý 
> Gesendet: Mittwoch, 15. April 2020 10:15
> An: Klaus Darilion 
> Cc: bind-users@lists.isc.org
> Betreff: Re: Debian/Ubuntu: Why was the service renamed from bind9 to
> named?
> 
> Klaus,
> 
> the default and preferred init system on both Debian and Ubuntu is systemd,
> and the unit has proper Alias, so it is recognized also under "bind9" name.
> 
> The sysv-rc script doesn’t have the capability of aliases, so unfortunately,
> there’s
> a downfall from the renaming, but it would not make sense to have a
> different name
> for different init systems. If you are using sysvinit, the choice and the
> suffering that
> comes from that choice is all yours.
> 
> The renaming was done as it was a logical choice, the service is starting a
> daemon,
> and not a package, and daemon name is `named`. Also it is the name used by
> RPM
> based systems and Arch Linux and Gentoo, so it was also made to make BIND
> 9 packages
> in Debian/Ubuntu more unified with rest of the Linux world.
> 
> Ondrej
> --
> Ondřej Surý
> ond...@isc.org
> 
> > On 15 Apr 2020, at 08:51, Klaus Darilion  wrote:
> >
> > Hello!
> >
> > What is the rationale of:
> >
> > bind9 (1:9.13.6-1) experimental; urgency=medium
> > ...
> >  * Rename the init scripts to named to match the name of the daemon
> >
> >
> > Since years, Debian and Ubuntu User, and plenty of scripts and automation
> software (Puppet ...), know that the service is called "bind9". I think it is 
> very
> confusing and will cause lots of headaches once Ubuntu 18.04 or Debian 11 is
> released.
> >
> > So I really do not understand this renaming.
> >
> > The software is "Bind 9". The package is "bind9". The service for long time
> was "bind9". The config is in /etc/bind. Only the binary is named. So it would
> have made more sense to rename the binary. (actually the binary is not so
> important for end users: they install the package and manage the service and
> usually do not have to worry about the name of the binary).
> >
> > It would be great if you undo this change before release of 18.04.
> >
> > regards
> > Klaus
> > ___
> > 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

___
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

AW: Debian/Ubuntu: Why was the service renamed from bind9 to named?

[Klaus Darilion]

> Am 15.04.20 um 10:08 schrieb Ondřej Surý:
> > you need to stop being rude to people on the bind-users mailing list,
> > personal attacks are not acceptable behaviour here. You should apologize
> > to Klaus.
> 
> it's not a personal attack to clearly point out that discussions of
> distribution level changes don't belong to upstream lists and that one

As it seems your are very smart you probably have noticed that Ondřej did the 
change in den Debian package and is also very active an this mailing list. 
Further I am not they only bind-user using Debian/Ubuntu so probably other 
bind-user are also interested in the reason for the renaming. Hence, I on 
purpose used this mailing list.

> within a company should at least consult someone internally with more
> expierience and after "it is not sane to call a service/package httpd if
> the name of the software is Apache" i simply had enough

Your personal experience is not the gobal truth. It is your opinion but other 
experienced pepole see it different than you.

Have a nice day
Klaus

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

AW: NSEC3 salt change - temporary performance decline

[Klaus Darilion]

> -Ursprüngliche Nachricht-
> Von: bind-users  Im Auftrag von Cathy
> Almond
> Gesendet: Dienstag, 9. Juni 2020 14:30
> An: bind-users@lists.isc.org
> Betreff: Re: NSEC3 salt change - temporary performance decline
...
> 
> FYI this will be fixed in the June 2020 BIND releases (in 9.11.20,
> 9.16.4 and 9.17.2):
> 
> https://gitlab.isc.org/isc-projects/bind9/-/issues/1834

Great news. Thank's for the work.
Klaus
___
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

How to prepublish additional DNSKEY

[Klaus Darilion]

Hello all!

A signed zone shall be moved to another DNS provider. Hence I want to add the 
public KSK of the gaining DNS provider as additional DNSKEY to the zone. My 
setup ist:

Bind1 as hidden primary --> Bind2 as bump-in-the-wire signer -> public facing 
secondaries

I tried to add the DNSKEY to the zone file of Bind1. Bind1 accepts the DNSKEY. 
But Bind2 only shows the DNSKEYs from the local key-directory, the original 
DNSKEY is removed/ignored.

I also tried to add the additonal DNSKEY into the key-directory of Bind2 (no 
.private file, only .key file). It did not worked too.

So, how is the correct process to add an additional DNSKEY (only the public key 
is known).

Thanks
Klaus

___
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

AW: How to prepublish additional DNSKEY

[Klaus Darilion]

> > So, how is the correct process to add an additional DNSKEY (only the public
> key is known).
> 
> I think you are looking for `dnssec-importkey`.

Indeed. I imported the key and got a .key and .private file. I put those files 
in the same directory as the other keys, gave read permissions to bind and 
executed:
rndc loadkeys myzone
rndc sign myzone

But the additional key is not added to the reponse of DNSKEY queries.

I am using Bind - 9.12.2-P2. Is this supported by Bind 9.12? (upgrade/downgrade 
is currently not possible)

Thanks
Klaus
___
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

AW: AW: How to prepublish additional DNSKEY

[Klaus Darilion]

Thanks - now it works.
Klaus

Von: Shumon Huque 
Gesendet: Donnerstag, 9. Juli 2020 13:44
An: Daniel Stirnimann 
Cc: Klaus Darilion ; bind-users@lists.isc.org
Betreff: Re: AW: How to prepublish additional DNSKEY

On Thu, Jul 9, 2020 at 6:44 AM Daniel Stirnimann 
mailto:daniel.stirnim...@switch.ch>> wrote:

On 09.07.20 11:51, Klaus Darilion wrote:
>>> So, how is the correct process to add an additional DNSKEY (only the public
>> key is known).
>>
>> I think you are looking for `dnssec-importkey`.
>
> Indeed. I imported the key and got a .key and .private file. I put those 
> files in the same directory as the other keys, gave read permissions to bind 
> and executed:
> rndc loadkeys myzone
> rndc sign myzone
>
> But the additional key is not added to the reponse of DNSKEY queries.

Does the key have correct timing metadata in the key file?

Have a look at "dnssec-settime".

You can also set the timing metadata with dnssec-importkey itself (so that you 
don't have to separately run dnssec-settime), e.g. to activate key 5 minutes 
from now:

dnssec-importkey -P +5mi -K Kexample.com.+013+23941.key

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

AXFR Problems sind Upgrade to 9.16.12

[Klaus Darilion]

Hello!

Our setup: Customer Primary --> bind-1 --> bind-2 --> public secondaries 
(NSD/bind)

Today we upgraded bind-1 and bind-2 from: 
9.16.6-3+ubuntu18.04.1+isc+3   --->   9.16.12-2+ubuntu18.04.1+isc+1

AXFR from customer to bind-1 still works. But since the upgrade, bind-2 can not 
transfer the zone from bind-1 anymore:

bind-1[3591]: client @0x7f6090274c78 xx.xx.xx.20#42767/key rcode0-internal 
(example): transfer of 'example/IN': send: operation canceled
bind2[4699]: transfer of 'example/IN' from xx.xx.xx.22#53: failed while 
receiving responses: end of file
bind2[4699]: transfer of 'example/IN' from xx.xx.xx.22#53: Transfer status: end 
of file
bind2[4699]: transfer of 'example/IN' from xx.xx.xx.22#53: Transfer completed: 
25079 messages, 9787583 records, 334058940 bytes, 30.171 secs (11072186 
bytes/sec) (serial 1069865757)

I tried "dig axfr @bind-1 ..." which also fails:
;; communications error to xx.xx.xx.22#53: end of file

Same with kdig:
;; WARNING: can't connect to 83.136.34.24@53(TCP)
;; ERROR: failed to query server 83.136.34.24@53(TCP)

The AXFR fails after receiving ~ 400MB. The full zone would be ~600MB.

Of course also AXFR from bind-2 to our public secondaries fail to. So I suspect 
this is problem on the "sending" side of bind9. As it worked without problem 
until the upgrade I think this is a regression.

Are there any known issues with 9.16.12?
Do you provide old PPA packages so that we can downgrade?

Thanks
Klaus

___
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

AW: AXFR Problems sind Upgrade to 9.16.12

[Klaus Darilion]

I just wanted to add, that AXFR of all other hosted zones work fine (even 
bigger ones). Only this single zone fails.
Thanks
Klaus

> -Ursprüngliche Nachricht-
> Von: bind-users  Im Auftrag von Klaus
> Darilion
> Gesendet: Donnerstag, 11. März 2021 21:24
> An: bind-users@lists.isc.org
> Betreff: AXFR Problems sind Upgrade to 9.16.12
> 
> Hello!
> 
> Our setup: Customer Primary --> bind-1 --> bind-2 --> public secondaries
> (NSD/bind)
> 
> Today we upgraded bind-1 and bind-2 from:
> 9.16.6-3+ubuntu18.04.1+isc+3   --->   9.16.12-2+ubuntu18.04.1+isc+1
> 
> AXFR from customer to bind-1 still works. But since the upgrade, bind-2 can
> not transfer the zone from bind-1 anymore:
> 
> bind-1[3591]: client @0x7f6090274c78 xx.xx.xx.20#42767/key rcode0-
> internal (example): transfer of 'example/IN': send: operation canceled
> bind2[4699]: transfer of 'example/IN' from xx.xx.xx.22#53: failed while
> receiving responses: end of file
> bind2[4699]: transfer of 'example/IN' from xx.xx.xx.22#53: Transfer status:
> end of file
> bind2[4699]: transfer of 'example/IN' from xx.xx.xx.22#53: Transfer
> completed: 25079 messages, 9787583 records, 334058940 bytes, 30.171 secs
> (11072186 bytes/sec) (serial 1069865757)
> 
> I tried "dig axfr @bind-1 ..." which also fails:
> ;; communications error to xx.xx.xx.22#53: end of file
> 
> Same with kdig:
> ;; WARNING: can't connect to 83.136.34.24@53(TCP)
> ;; ERROR: failed to query server 83.136.34.24@53(TCP)
> 
> The AXFR fails after receiving ~ 400MB. The full zone would be ~600MB.
> 
> Of course also AXFR from bind-2 to our public secondaries fail to. So I 
> suspect
> this is problem on the "sending" side of bind9. As it worked without problem
> until the upgrade I think this is a regression.
> 
> Are there any known issues with 9.16.12?
> Do you provide old PPA packages so that we can downgrade?
> 
> Thanks
> Klaus
> 
> ___
> 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
___
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

AW: AXFR Problems sind Upgrade to 9.16.12

[Klaus Darilion]

I will - in the meantime: do you have older ppa packages somewhere on archive?

Thanks
Klaus

> -Ursprüngliche Nachricht-
> Von: Ondřej Surý 
> Gesendet: Donnerstag, 11. März 2021 21:49
> An: Klaus Darilion 
> Cc: bind-users@lists.isc.org
> Betreff: Re: AXFR Problems sind Upgrade to 9.16.12
> 
> Hi Klaus,
> 
> can you please fill a proper issue in the gitlab.isc.org?  We are going to 
> need
> more details and anonymizing the logs isn’t a good way to go forward. In the
> GitLab you can make the issue confidential and we will sanitize any user data
> before making it public.
> 
> Thanks,
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@isc.org
> 
> > On 11. 3. 2021, at 21:24, Klaus Darilion  wrote:
> >
> > Hello!
> >
> > Our setup: Customer Primary --> bind-1 --> bind-2 --> public secondaries
> (NSD/bind)
> >
> > Today we upgraded bind-1 and bind-2 from:
> > 9.16.6-3+ubuntu18.04.1+isc+3   --->   9.16.12-2+ubuntu18.04.1+isc+1
> >
> > AXFR from customer to bind-1 still works. But since the upgrade, bind-2 can
> not transfer the zone from bind-1 anymore:
> >
> > bind-1[3591]: client @0x7f6090274c78 xx.xx.xx.20#42767/key rcode0-
> internal (example): transfer of 'example/IN': send: operation canceled
> > bind2[4699]: transfer of 'example/IN' from xx.xx.xx.22#53: failed while
> receiving responses: end of file
> > bind2[4699]: transfer of 'example/IN' from xx.xx.xx.22#53: Transfer status:
> end of file
> > bind2[4699]: transfer of 'example/IN' from xx.xx.xx.22#53: Transfer
> completed: 25079 messages, 9787583 records, 334058940 bytes, 30.171 secs
> (11072186 bytes/sec) (serial 1069865757)
> >
> > I tried "dig axfr @bind-1 ..." which also fails:
> > ;; communications error to xx.xx.xx.22#53: end of file
> >
> > Same with kdig:
> > ;; WARNING: can't connect to 83.136.34.24@53(TCP)
> > ;; ERROR: failed to query server 83.136.34.24@53(TCP)
> >
> > The AXFR fails after receiving ~ 400MB. The full zone would be ~600MB.
> >
> > Of course also AXFR from bind-2 to our public secondaries fail to. So I
> suspect this is problem on the "sending" side of bind9. As it worked without
> problem until the upgrade I think this is a regression.
> >
> > Are there any known issues with 9.16.12?
> > Do you provide old PPA packages so that we can downgrade?
> >
> > Thanks
> > Klaus
> >
> > ___
> > 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

___
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

AW: AXFR Problems sind Upgrade to 9.16.12

[Klaus Darilion]

For the records. With the help of Ondrej we found the cause: The problem is 
related to TCP timeouts not working as expected. If you are affected set 
tcp-initial-timeout and tcp-idle-timeout to 1200 (=120s). If you have huge 
zones with AXFRs > 120s you can download the source, increase the max 
timeoutvalue to some higher value and rebuild bind9.
I guess the problem is not related with 9.16.12 but we didn't noticed it as we 
usually use IXFR. For whatever reason our Bind used AXFR and now the timeout 
problems appeared.

regards
Klaus

> -Ursprüngliche Nachricht-
> Von: bind-users  Im Auftrag von Klaus
> Darilion
> Gesendet: Donnerstag, 11. März 2021 21:24
> An: bind-users@lists.isc.org
> Betreff: AXFR Problems sind Upgrade to 9.16.12
> 
> Hello!
> 
> Our setup: Customer Primary --> bind-1 --> bind-2 --> public secondaries
> (NSD/bind)
> 
> Today we upgraded bind-1 and bind-2 from:
> 9.16.6-3+ubuntu18.04.1+isc+3   --->   9.16.12-2+ubuntu18.04.1+isc+1
> 
> AXFR from customer to bind-1 still works. But since the upgrade, bind-2 can
> not transfer the zone from bind-1 anymore:
> 
> bind-1[3591]: client @0x7f6090274c78 xx.xx.xx.20#42767/key rcode0-
> internal (example): transfer of 'example/IN': send: operation canceled
> bind2[4699]: transfer of 'example/IN' from xx.xx.xx.22#53: failed while
> receiving responses: end of file
> bind2[4699]: transfer of 'example/IN' from xx.xx.xx.22#53: Transfer status:
> end of file
> bind2[4699]: transfer of 'example/IN' from xx.xx.xx.22#53: Transfer
> completed: 25079 messages, 9787583 records, 334058940 bytes, 30.171 secs
> (11072186 bytes/sec) (serial 1069865757)
> 
> I tried "dig axfr @bind-1 ..." which also fails:
> ;; communications error to xx.xx.xx.22#53: end of file
> 
> Same with kdig:
> ;; WARNING: can't connect to 83.136.34.24@53(TCP)
> ;; ERROR: failed to query server 83.136.34.24@53(TCP)
> 
> The AXFR fails after receiving ~ 400MB. The full zone would be ~600MB.
> 
> Of course also AXFR from bind-2 to our public secondaries fail to. So I 
> suspect
> this is problem on the "sending" side of bind9. As it worked without problem
> until the upgrade I think this is a regression.
> 
> Are there any known issues with 9.16.12?
> Do you provide old PPA packages so that we can downgrade?
> 
> Thanks
> Klaus
> 
> ___
> 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
___
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

9.16 needs more RAM then 9.11

[Klaus Darilion]

Hello!

On our servers where we use Bind 9.16, named needs approx. 29G RAM. On the 
servers with Bind 9.11 named needs approx. 25G RAM.

Is this a known issue? Are there some config options to tune memory consumption?

Thank
Klaus

___
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

faster fail-over between multiple masters

[Klaus Darilion]

Hi!

I have 9.7.0-P1 as slave configured with two masters: M1 and M2. M2 is
currently down.

When M1 sends a NOTIFY to inform the salve of the new zone, bind starts
querying for the SOA record at M2. As M2 is down, bind sends
retransmissions and tries it several times. It takes up to 2 minutes
until bind starts asking M1 - then the transfer of course works fine.

The question is: can I tweak bind to fail-over to other master servers
faster?

Thanks
Klaus
___
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: faster fail-over between multiple masters

[Klaus Darilion]

Am 30.08.2011 00:04, schrieb Mark Andrews:
> In message <4e5b6098.80...@pernau.at>, Klaus Darilion writes:
>> Hi!
>>
>> I have 9.7.0-P1 as slave configured with two masters: M1 and M2. M2 is
>> currently down.
>>
>> When M1 sends a NOTIFY to inform the salve of the new zone, bind starts
>> querying for the SOA record at M2. As M2 is down, bind sends
>> retransmissions and tries it several times. It takes up to 2 minutes
>> until bind starts asking M1 - then the transfer of course works fine.
>>
>> The question is: can I tweak bind to fail-over to other master servers
>> faster?
> 
>   try-tcp-refresh no;

Hi Mark!

Thanks for the hint. But I do not see how this can help us, as the slave
never used TCP. The SOA lookups are always done via UDP.


Some more debugging showed, that the problem happens in the following
scenario:

1. On the slave we have set max-refresh-time to 5 minutes. (We have
added this in case the slave missed some NOTIFYs due to network problems).

2. Thus, every 4.5 minutes the slave asks both masters for the serial.
The lookup to M1 works fine, the lookup to M2 of course fails as M2 is
down and thus bind starts with retransmissions: every lookup has 2
retransmissions every 15 seconds, then bind this again with a new
"transaction"

3. If bind receives a NOTIFY while it tries to query M2, the NOTIFY is
more or less ignored:

  client 1.1.1.1#15733: received notify for zone 'xyz': TSIG 'foobar'
  zone xyz/IN: notify from 1.1.1.1: refresh in progress, refresh check
queued

Thus, it takes up two 2 minutes until bind gives up querying M2 and
starting again with querying M1.


Is it possible to tweak the retransmission timers and query timeouts
when bind performs SOA lookups?

Thanks
Klaus


___
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: faster fail-over between multiple masters

[Klaus Darilion]

Am 30.08.2011 18:17, schrieb Klaus Darilion:
> 2. Thus, every 4.5 minutes the slave asks both masters for the serial.
> The lookup to M1 works fine, the lookup to M2 of course fails as M2 is
> down and thus bind starts with retransmissions: every lookup has 2
> retransmissions every 15 seconds, then bind this again with a new
> "transaction"

small correction: I observe that bind uses 4 "transactions", with every
transaction having 2 retransmissions with a timeout of 15 seconds. Thus,
during 4x45s=180s bind "blocks" and does not process the notification.

Unfortunately I fail to find the options where I can configure the
number of retransmissions, timeouts and number of transactions - please
give me some hints.

Thanks
Klaus
___
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: faster fail-over between multiple masters

[Klaus Darilion]

Hi Michael!

Am 30.08.2011 20:33, schrieb Michael Graff:
> On 2011-08-30 12:06 PM, Klaus Darilion wrote:
> 
>> Unfortunately I fail to find the options where I can configure the 
>> number of retransmissions, timeouts and number of transactions -
>> please give me some hints.
> 
> I don't believe there are external knobs for this behavior.
> 
> I can think of several possible fixes here:
> 
> (1)  if we get a notify during a SOA check, proceed as usual but flag
> this so we will just start another SOA check.  We may transfer the
> zone between these checks (and probably should.)
> 
> (2)  send all SOA requests in parallel, and use an overall max time to
> wait (perhaps 20 seconds) and re-send the SOA to servers which have
> not responded every 4 seconds.  This limits the total time an SOA
> check will take.
> 
> (3)  If any of the servers respond with better SOA serial numbers than
> we have, transfer from the masters as listed in the config file or
> whichever is better, depending on current behavior.
> 
> I do not know when we would be able to get to this change, but I'll
> put them on the back-log for future releases.
> 
> If you want to go code diving, you can likely find the timeouts and
> change the behavior for your servers.  However, you'll have to track
> this each time we do a release for the foreseeable future.

I'm not a coder, thus I will wait until someone else improves it. :-)

Anyway, regardles off what option will be implemented, I think it would
be good to make the retransmission paramters configureable, e.g:
- query-timeout (currently 15 seconds)
- query-retransmissions (number of retransmissions with same
 transaction id, currently 2)
- query-attempts (number of transactions, currently 4)

Thanks
Klaus

___
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

questions about rndc zonestatus

[Klaus Darilion]

Hi!

I would like to use this feature to check the status of my slave zones.

# rndc zonestatus nic.at
name: nic.at
type: slave
files: /etc/bind/zones/nic.at
serial: 2017121119
nodes: 77
next refresh: Tue, 19 Dec 2017 08:34:53 GMT
expires: Tue, 02 Jan 2018 07:50:08 GMT
secure: yes
inline signing: no
key maintenance: none
dynamic: no
reconfigurable via modzone: no

Unfortunately the slave-status is not dumped, e.g. if the zone is n
sync, if SOA refresh-checks suceed, if XFRs succeed? Do I miss
something? In the above example the configured masters is not available
and SOA-checks and XFR failed. Nevertheless there is no information
about the failing refresh checks for the zone.

Further, I would like to know if there are existing tools to parse the
output, or if it is possible to get the data in a more structured form.

Further it would be great to get a dump of all zones (e.g. without
specifying the zone), or at least to get a dump of the configured zone
of Bind.

thanks
Klaus


___
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

are journal files required on slave?

[Klaus Darilion]

Hi!

The default setting of max-journal-size filled my disk. I do have plenty
of zone from KByte to GByte. So I wonder, what would be the perfect size
to configure. So, I wondered - do I need a journal at all? I know the
journal is needed for ixfr-from-differences and DDNS.

But on a server with slave-zone only (fetched by ixfr) - do I need a
journal at all? How can I disable it - by setting the max-size to 0?

Thanks
Klaus
___
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

Maximum zone file size

[Klaus Darilion]

Hi!

I couldn't find it online - is there a limit on the zone file size?

Thanks
Klaus
___
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: Maximum zone file size

[Klaus Darilion]

Am 14.03.2018 um 13:10 schrieb Ray Bellis:
> On 14/03/2018 12:08, Anand Buddhdev wrote:
> 
>> Not that I know of. The amount of RAM in a server is probably the most
>> significant limit for loading zones into BIND.
> 
> Anand is correct - there's no intrinsic limit other than RAM.
> 
> I personally know of BIND instances running with in the region of 25 -
> 30M RRs in them.

We do have 26M with 2.5G file size. So I feel reassured.

Thanks for the feedback.

Klaus
___
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: are journal files required on slave?

[Klaus Darilion]

Am 14.03.2018 um 13:04 schrieb Tony Finch:
> Klaus Darilion  wrote:
>>
>> But on a server with slave-zone only (fetched by ixfr) - do I need a
>> journal at all? How can I disable it - by setting the max-size to 0?
> 
> The journal reduces the cost of re-writing zone files: basically, the IXFR
> just gets appended to the journal, which is relatively cheap. For BIND
> 9.11 and earlier, it's probably worth setting it to some modest non-zero
> size (64KB? 1MB?). If you have any large frequently-updated zones they
> might benefit from a bigger journal to reduce zone file re-writes. In BIND
> 9.12 the max-journal-size is automatically set based on the zone size, so
> you should be able to remove any max-journal-size settings from your
> config. (I contributed this feature because I got fed up with worrying
> about them.)

Thanks for the detailed answer. So I will use a few MBytes. But would it
be possible to set max-journal-size=0?

thanks
Klaus
___
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: are journal files required on slave?

[Klaus Darilion]

Am 14.03.2018 um 13:38 schrieb Tony Finch:
> Klaus Darilion  wrote:
>>
>> Thanks for the detailed answer. So I will use a few MBytes. But would it
>> be possible to set max-journal-size=0?
> 
> There's a minimum journal size (the calculation in the code comes to about
> 1KB I think), so if you set max-journal-size to 0 (or any other tiny
> value) it is rounded up to the minimum.

I have now set
max-journal-size 50M;
and restartet bind a few times. But the journal files are still GBytes.
When should Bind flush the journal into the zone file?


Also, next to the zone and journal files I do have left-over tmp files
in the style of:
-rw-r--r-- 1 bind bind 1.2G Mar 12 08:29 tmp-36Do9oUZgU
-rw-r--r-- 1 bind bind 1.2G Mar 14 12:22 tmp-6g1o7nm7lT

Is it save to delete them?

Thanks
Klaus
___
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: are journal files required on slave?

[Klaus Darilion]

Am 14.03.2018 um 15:20 schrieb Tony Finch:
> Klaus Darilion  wrote:
>>
>> I have now set
>> max-journal-size 50M;
>> and restartet bind a few times. But the journal files are still GBytes.
>> When should Bind flush the journal into the zone file?
> 
> I think `rndc sync` should do what you want. I can't remember what the
> internal triggers for journal compacting are (probably the next ixfr
> and/or zone maintenance).

Now, after the night, the journal files are 50M as expected.

Thanks
Klaus
___
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

sporadic timeouts querying bind9

[Klaus Darilion]

Hi!

I use bind 9.9.5.dfsg-3ubuntu0.17 with around 20 slave zones (from small
to huge).

I query the SOA of every configured zone once a second to monitor bind.

Once a day my script reports timeouts (3 seconds) querying a SOA. This
server is a test server, hence it is idle except the monitoring checks.

When inspecting the logs the timeouts are always very close to NOTIFYs
and zone transfers. Are there any known issues that e.g. bind may
suspend queries wile applying the zone transfer? Any other ideas what
could be the reason?

Thanks
Klaus
___
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: Suggestions for a distributed DNS zone hosting solution I'm designing

[Klaus Darilion]

Hi Latitude!

Short answer: I think 2s delay is not possible in a distributed system 
with many global distributed slaves and limited ressources.


Long answer: It all depends on how much money you have and time in 
setting up such a service - long comments inline.


Am 07.03.2018 um 07:10 schrieb Latitude:

I would like to solicit constructive feedback in regards to a distributed DNS
zone hosting proof of concept I'd like to design and establish.

I must deploy a DNS system with the following requirements:
- single master server, multiple slave servers
- minimal time for name resolving for Americas, Europe and Asia
- up to millions records in a domain zone
- changes propagate in real time (master -> slaves), 2 sec max delay
- automatic slave data re-syncing on master link restore after disconnect
- API for zone records manipulation (insert, update, delete)


There is one important thing you did not mention: how often do you 
update the zone? once a day? once an hour? once a minute? a few times 
per second?




So far I am considering using (free) DC/OS on Amazon Web Services with the
latest version of BIND containerized using docker on a Linux or Unix OS. Dyn
and Infoblox are also on my list of items to research but I have never used
either and I enjoy working with BIND on Linux. After all this is the BIND
Users group, but I would be interested to know if someone can make a case
for using Dyn or Infoblox in this case.


The challenges are somewhere else. First, design the distribution, then 
think about OS, software, cloud provider, 



Considerations/questions I have about this deployment for this Bind-Users
forum are:

1. How can I examine DNS resolution times using this platform (or other
platforms to compare with) in different geographic areas of the world
without first deploying it? I will need to have benchmark data to test
against to verify I am getting the fastest speeds possible on name
resolutions.


You can not measure something you have not built yet. But what you can 
do is, measuring what somebody else built, and then clone there setup 
are build it similar, or buy there service. There are plenty of existing 
DNS providers. You can for example us RIPE Atlas to test them. There is 
also dnsperf.com and their entrprise service perfops.net which would 
give you a rough idea what DNS resolution times are possible.


You did not mention what your use case is. Who will do the DNS queries? 
a) A web browser on some standard PC or b) a dedicated application


For a) you do not have any control about the resolver used by the end 
user. HEnce, it may use its provider resolver, 8.8.8.8 (or similar) or 
its own. This resolver may be good in choosing the best announced 
nameserver (from the zone's NS records) or not. In this case I would 
suggest using Anycast - but be warned. Anycast for performance works 
only if you carefully choose your location, where 'location' means the 
location in the network, e.g. which transit providers, which exchanges, 
AS path length,  If you do the hosting all by yourself and carefully 
choose transit providers you can have great performance (ie Cloudflare), 
but it is very expensive. Choosing bad will give you bad performance.


For b) I would definitely avoid Anycast. Provision the application with 
the namne server known in the region, or make the application smart an 
let it probe which name server answers fastest.



2. How to handle millions of records in a DNS zone, and how common is it to
have millions of records in a DNS zone?


It is probably not that common, but there are several TLDs which have 
millions of records. One fo our customers zone has 25Mio RR and we do 
not see any problems with Bind (or NSD or Knot).



3. What API solutions for DNS zone edits currently exist or should I be
lookin into?


It all depends on your setup. If you go with Bind I would suggest DNS 
UPDATE. If you choose some other replication technique there are other 
tools (see below).



I will research more in the next day but so far I know I can manually
configure named.conf to propagate zone changes to slave servers rapidly
(aiming for 2 seconds or less) using NOTIFY messages and zone transfers, and
also configure slave servers to automatically re-synch zone data with the
master server upon reestablishing a connection. That should satisfy two of
my requirements above.


In fact it is not only NOTIFY+XFR. It is:

- Applying the zone change on the master, ie. DNS UPDATE

- NOTIFY all the slaves. With lots of slaves this may take some time and 
AFAIK Bind may throttle NOTIFYs


- NOTIFYs are UDP, and may get lost on the way, so you have 
retransmission. And if all NOTIFYs are lost, the slave will stay out of 
sync until there is the next zone update or SOA refresh value expires. 
This can be worked around ie by pushing your slaves to query the master 
every second for the current SOA (or even more optimzed: request an IXFR 
every second. for sure this will generate load on the

Re: sporadic timeouts querying bind9

[Klaus Darilion]

This time with log file attached
Thanks
Klaus


Am 23.04.2018 um 14:55 schrieb Klaus Darilion via bind-users:
> Hi all!
> 
> Upgrading to Ubuntu 16.04 with Bind 9.10.3 did not solved the problem.
> 
> I enabled debug log (trace 2) and query logging. Unless my monitoring
> traffic (~20 Queries every second) the server is idle.
> 
> The server is a xen domU (on a idle hypervisor) with 4 vCPUs and 20G RAM.
> 
> Here the logs from my checker script:
> Apr 23 10:35:17 tld-all-tst1 darilion: OK:
> Apr 23 10:35:18 tld-all-tst1 darilion: OK:
> Apr 23 10:35:24 tld-all-tst1 darilion: FAILED - timeout (3 sec) or
> network error querying SOA for hu
> Apr 23 10:35:31 tld-all-tst1 darilion: FAILED - timeout (3 sec) or
> network error querying SOA for hu
> Apr 23 10:35:32 tld-all-tst1 darilion: OK:
> Apr 23 10:35:33 tld-all-tst1 darilion: OK:
> 
> Hence, no responses from Bind between 10:35:18 and 10:35:32
> 
> The debug log during this time is attached. It seems Bind hangs from
> 10:35:19.126 to 10:35:30.036, maybe at the end of writing the zone file.
> The zone file is around 2.2G.
> 
> The query log also show nothing during this time:
> 23-Apr-2018 10:35:18.760 queries: info: client 127.0.0.1#54902 (at):
> query: at IN SOA - (83.136.32.84)
> 23-Apr-2018 10:35:30.037 queries: info: client 127.0.0.1#53148 (hu):
> query: hu IN SOA - (83.136.32.84)
> 
> Continuous Write performance of the disk is ~130MB/s. To me it seems
> that Bind is somehow blocked at the end of the zone dump and hence not
> answering queries anymore.
> 
> May this be possible? Is somewhere documented how Bind as slave applies
> the incoming IXFR to the loaded zone, the journal  Are there any
> locking operations in bind?
> 
> Thanks
> Klaus
> 
> 
> 
> 
> 
> 
> 
> Am 15.03.2018 um 14:45 schrieb Klaus Darilion:
>> Hi!
>>
>> I use bind 9.9.5.dfsg-3ubuntu0.17 with around 20 slave zones (from small
>> to huge).
>>
>> I query the SOA of every configured zone once a second to monitor bind.
>>
>> Once a day my script reports timeouts (3 seconds) querying a SOA. This
>> server is a test server, hence it is idle except the monitoring checks.
>>
>> When inspecting the logs the timeouts are always very close to NOTIFYs
>> and zone transfers. Are there any known issues that e.g. bind may
>> suspend queries wile applying the zone transfer? Any other ideas what
>> could be the reason?
>>
>> Thanks
>> Klaus
>> ___
>> 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
>>
> ___
> 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
> 
23-Apr-2018 10:34:54.954 general: debug 1: zone_timer: zone si/IN: enter
23-Apr-2018 10:34:54.954 general: debug 1: zone_maintenance: zone si/IN: enter
23-Apr-2018 10:34:54.954 general: debug 1: queue_soa_query: zone si/IN: enter
23-Apr-2018 10:34:54.954 general: debug 1: zone_settimer: zone si/IN: enter
23-Apr-2018 10:34:54.954 general: debug 1: soa_query: zone si/IN: enter
23-Apr-2018 10:34:54.956 general: debug 1: refresh_callback: zone si/IN: enter
23-Apr-2018 10:34:54.956 general: debug 1: refresh_callback: zone si/IN: 
serial: new 1524474022, old 1524474022
23-Apr-2018 10:34:54.956 general: debug 1: queue_soa_query: zone si/IN: enter
23-Apr-2018 10:34:55.455 general: debug 1: soa_query: zone si/IN: enter
23-Apr-2018 10:34:55.463 general: debug 1: refresh_callback: zone si/IN: enter
23-Apr-2018 10:34:55.463 general: debug 1: refresh_callback: zone si/IN: 
serial: new 1524474022, old 1524474022
23-Apr-2018 10:34:55.463 general: debug 1: queue_soa_query: zone si/IN: enter
23-Apr-2018 10:34:55.463 general: debug 1: soa_query: zone si/IN: enter
23-Apr-2018 10:34:55.464 general: debug 1: refresh_callback: zone si/IN: enter
23-Apr-2018 10:34:55.465 general: debug 1: refresh_callback: zone si/IN: 
serial: new 1524474022, old 1524474022
23-Apr-2018 10:34:55.465 general: debug 1: queue_soa_query: zone si/IN: enter
23-Apr-2018 10:34:55.963 general: debug 1: soa_query: zone si/IN: enter
23-Apr-2018 10:34:55.971 general: debug 1: refresh_callback: zone si/IN: enter
23-Apr-2018 10:34:55.971 general: debug 1: refresh_callback: zone si/IN: 
serial: new 1524474022, old 1524474022
23-Apr-2018 10:34:55.972 general: debug 1: zone_settimer: zone si/IN: enter
23-Apr-2018 10:35:01.608 general: debug 1: zone_timer: zone nl/IN: enter
23-Apr-2018 1

Re: Slow reply under heavy load (on a specific NIC ip)

[Klaus Darilion]

Am 04.06.2018 um 14:20 schrieb Ict Security:

Hi guys,

we are running a Bind 9.x Server, everything is going fine.
Under particular heavy load mometns, with some hundreds of concurrent
queries coming in, sometime Bing stops answering for some seconds or
answer with important delays.

But, when i try to query the same server/same Bind on a NIC alias IP
during congestion on the main IP, everything is fast!


Just a shot in the dark: I guess Bind opens multiple sockets, one for 
each IP address. Every socket has its own receive-buffer. Under heavy 
load, the receive buffer gets full and you have packet loss. So your 
client send retransmissions and sometimes the packet goes through and 
you receive an answer (high delay)


When you query the other IP, the socket is idle, hence no full buffers 
and your query gets received and processed immediately.


Checking the state of the receive buffer can be done with netstat, and 
packet loss due to full receive buffer can be seens in the "dropped 
packets" of the respective interface.


regards
Klaus
___
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

timestamp in journal

[Klaus Darilion]

Hi!

named-journalprint dumps the journal without any time information.

Does the journal include time information? (Timestamp of add/del)

If yes, can I somehow extract the timestamps?

thanks
Klaus
___
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: timestamp in journal

[Klaus Darilion]

Hi Anand!

Am 09.07.2018 um 14:04 schrieb Anand Buddhdev:

On 09/07/2018 13:50, Klaus Darilion wrote:

Hi Klaus,


named-journalprint dumps the journal without any time information.

Does the journal include time information? (Timestamp of add/del)

If yes, can I somehow extract the timestamps?

As far as I know, the journal does not have any time information in it.

Thanks for the info!

If the zone was updated by dynamic DNS updates, then you may be able to
match up serial numbers in the journal with DDNS updates from BIND's log.
Actually it is a slave with incoming XFR, but matching serial numbers 
with Bind's log worked.


Thanks
Klaus
___
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

Fwd: Operational Notification: Extremely large zone transfers can result in corrupted journal files or server process termination

[Klaus Darilion]

What is an "extraordinarily large zone transfer"? We do have regularly 
AXFR and IXFRs around 2GB. Is this "extraordinarily large"?


regards
Klaus



 Weitergeleitete Nachricht 
Betreff: 	Operational Notification: Extremely large zone transfers can 
result in corrupted journal files or server process termination

Datum:  Wed, 4 Jul 2018 17:41:10 -0800
Von:Michael McNally 
An: bind-annou...@lists.isc.org



Summary:

   In versions of BIND released prior to July 2018 (before BIND
   9.9.13, 9.10.8, 9.11.4, 9.12.2, and BIND 9.13.1) it is possible
   for extraordinarily large zone transfers to cause several related
   problems, with possible outcomes including corrupted journal
   files or server exit due to assertion failure.

Posting date:03 July 2018
Program Impacted:BIND
Versions affected:   9.0.x -> 9.8.8, 9.9.0 -> 9.9.12, 9.10.0 -> 9.10.7,
 9.11.0 -> 9.11.3, 9.12.0 -> 9.12.1, and versions
 9.13.0 -> 9.13.1 of the 9.13 development branch

Description:

   A problem in named can potentially lead to corrupted journal
   files when handling extraordinarily large zone transfers.

Impact:

   This problem potentially affects authoritative servers providing
   slave service for zones if the server accepts zone data via
   incremental zone transfer (IXFR) from a master source or if a
   large zone transfer (AXFR) is received and ixfr-from-differences
   is not set to "no" (the default setting is "yes", and possible
   values are "yes", "no", "slave", and "master").

   We warned of a similar class of problems in 2016 in this previous
   Operational Notification "A party that is allowed control over
   zone data can overwhelm a server by transferring huge quantities
   of data." (https://kb.isc.org/article/AA-01390)

Workarounds:

   Like any unvalidated input, zone transfers are a potential source
   of risk for servers under any circumstances.  BIND therefore
   supports a variety of mechanisms to control zone transfer
   permissions.  Permission to transfer can be restricted to trusted
   servers using IP-address-based ACLs or shared secrets (TSIG keys)
   or both.  Under most circumstances a slave server should not
   encounter this defect when receiving data from a trusted server,
   but it can be prevented entirely by forbidding incremental zone
   transfer as a zone data transfer mechanism.  It may be preferable
   to instead set a reasonable limit for the number of records which
   may be in a zone (using the max-records parameter) which should
   also prevent accidentally encountering this defect.

   Servers which must accept zone data from untrusted sources (for
   example, when seconding zones for other parties) are at slightly
   higher risk if a party decides to deliberately feed a dangerously
   large zone transfer.  Operators of servers which must accept
   untrusted zone data should consider limiting zone size using
   max-records, setting "ixfr-from-differences no;", or upgrading
   to a version of BIND which will reject dangerously large transfers.

Active exploits:

   No known active exploits.

Solution:

   It is our opinion that most customers do not need to worry about
   this issue unless they accept zone data via zone transfer from
   untrusted sources, but we have included changes in upcoming
   maintenance releases of BIND which will prevent the condition
   from being reached.

   Maintenance releases of BIND issued on or after 4 July 2018 will
   contain change #4984, which will cause BIND to reject an
   extraordinarily large IXFR if it is potentially large enough to
   corrupt the journal file. These release candidates are available
   now via https://www.isc.org/downloads and the change will be
   included in future versions of BIND

BIND 9 version 9.9.13rc2
BIND 9 version 9.10.8rc2
BIND 9 version 9.11.4rc2
BIND 9 version 9.12.2rc2


Do you still have questions?  Questions regarding this advisory
should go to security-offi...@isc.org.  To report a new issue,
please encrypt your message using security-offi...@isc.org's PGP
key which can be found here:

   https://www.isc.org/downloads/software-support-policy/openpgp-key/.

If you are unable to use encrypted email, you may also report new
issues at: https://www.isc.org/community/report-bug/.

Note:

   ISC patches only currently supported versions. When possible we
   indicate EOL versions affected.  (For current information on
   which versions are actively supported, please see
   http://www.isc.org/downloads/).

ISC Security Vulnerability Disclosure Policy:

   Details of our current security advisory policy and practice can
   be found here: https://kb.isc.org/article/AA-00861

This Knowledge Base article https://kb.isc.org/article/AA-01627
is the complete and official security advisory document.

Legal Disclaimer:

   Internet Systems Consortium (ISC) is providing this notice on
   an "AS IS" basis. No warranty or guarantee of any kind

Bind Auth responds slow during incoming XFR

[Klaus Darilion]

Hello!

We have a problem with Bind [2] during incoming IXFR. When there is a
huge IXFR (ie 1,8GB tranferred in 15minutes [1]), the response time
heavily increases. Using dsc's newest "Reponse Time Indexer" we clearly
see that Bind answers slow:

Response Time   normal  during
Window  operation   IXFR

1-10us  2
10-100us16033
100-1000us  37768
1-10ms  180 21
10-100ms43  179
100-1000ms  748
1-10s   2224
timeout 124 6930

Sum 54150   10102

(The drop in total happens as the resolvers switch to other
authoritative nameservers)

The VM has 4 vCPUs which are all at 100% (99% user-space load)during the
incoming IXFR. The memory consumption doubled during the IXFR but there
is enough RAM in the server (no swapping)

So I have 2 theories:
a) While "patching" the in-memory zone the "IXFR-worker" somehow locks
the zone so that the "request-handler" has to wait and becomes slow.

b) The "IXFR-worker" eats all CPU so that there is no more CPU left for
the "request-handler".

So, what do Bind developers mean about my theories? Are there any ideas
to improve response time during IXFR? Ie. throttling CPU of the "IXFR
handler"? Were there related changed in 9.12 or 9.14?


Thanks
Klaus

[1] Transfer completed: 27733 messages, 12689911 records, 1789M bytes,
847.424 secs (2111887 bytes/sec)

[2] Seen on Ubuntu 14.04/16.04/18.04 aka Bind 9.9.5/9.10.3/9.11.3
___
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: max file size or line count for BIND zone file

[Klaus Darilion]

Am 25.04.2019 um 14:10 schrieb Martin Meadows via bind-users:
Wondering if anyone is aware of a max file size or max number of lines 
that a given BIND zone file can contain?


IF you use a journal, things may get complicated if your journal is over 
2G: https://kb.isc.org/docs/aa-01627


regards
Klaus
___
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 fast only on alias IP

[Klaus Darilion]

Am 20.05.2019 um 20:16 schrieb Ict Security:

How could i increase the number of socket on a single IP address,
since Bind is working perfectly on the secondary address,
when the first one is stucked?


If the incoming traffic is bursty it may happen that the receive queue 
of the socket is full and hence packets are dropped.


You can try to increase the receive queue with sysctl (just google). But 
if you make it too big, you may queue too much requests and start to 
queue also retransmission.


regards
Klaus
___
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 max socket/query per IP

[Klaus Darilion]

Am 21.05.2019 um 22:31 schrieb Ict Security:
Under heavy load, Bind becomes extremely load above a certain number of 
Qps but, if i query an alias IP address (where normally queries don't 
arrive), Bind answers immediately.


btw - how high is the "extremely load"?

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

IXFR fallback to AXFR if diff is bigger than zone

[Klaus Darilion]

Hi!

I wonder how Bind as master handles IXFR when the requested IXFR would
be much than the AXFR. (For example: if you change the NSEC3 salt).

Are there some mechanisms to detect such a situation and trigger a
fallback to AXFR or will Bind always perform IXFR?

thanks
Klaus

PS: AFAIK the max journal size is 2 GB. In my case, the IXFR due to
NSEC3 salt changes is around 2.5GB. So actually I am surprised that such
big updates can be handled as IXFR.
___
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: IXFR fallback to AXFR if diff is bigger than zone

[Klaus Darilion]

Hi Tony!

Am 12.07.2019 um 13:00 schrieb Tony Finch:
> Yes, that is curious. Are you sure it isn't actually doing an
> IXFR-flavoured AXFR of the whole zone, rather than a delta?

We have a setup with severals Bind in a row:

hidden master
customer
(software unknown)
|
|
V
our incoming nameserver
Bind 9.9.5
|
|
V
our distribution nameserver
Bind 9.9.5
|
|
V
our anycast nameserver
Bind 9.11.3+dfsg-1ubuntu1.8

According to our logs, the was no IXFR-style AXFR. The IXFR from the
customer to us was around 1.87GB (at least on the wire).

>From our "incoming" nameserver to our "distribution" nameserver, and
from there to our Anycast node it was around 2.37G.

See log details below.

Thanks
Klaus


09:30:55.119017+00:00 incoming: zone example/IN: notify from
1.1.1.18#40718: refresh in progress, refresh check queued
09:30:55.681438+00:00 incoming: zone example/IN: Transfer started.
09:30:55.775361+00:00 incoming: transfer of 'example/IN' from
1.1.1.18#53: connected using 2.2.2.6#58024
09:39:58.568221+00:00 incoming: zone example/IN: transferred serial
2019051621: TSIG 'foo'
09:39:58.568634+00:00 incoming: transfer of 'example/IN' from
1.1.1.18#53: Transfer completed: 117626 messages, 27995004 records,
1873889978 bytes, 542.793 secs (3452310 bytes/sec)
09:39:58.570937+00:00 incoming: zone example/IN: sending notifies
(serial 2019051621)
09:39:59.573796+00:00 incoming: client 2.2.2.4#49520/key foo (example):
transfer of 'example/IN': IXFR started: TSIG foo
09:42:55.240267+00:00 incoming: client 2.2.2.4#49520/key foo (example):
transfer of 'example/IN': IXFR ended


09:39:59.573447+00:00 distribution: transfer of 'example/IN' from
2.2.2.6#53: connected using 2.2.2.4#49520
09:43:02.203543+00:00 distribution: zone example/IN: transferred serial
2019051621: TSIG 'foo'
09:43:02.203646+00:00 distribution: transfer of 'example/IN' from
2.2.2.6#53: Transfer completed: 36596 messages, 12744969 records,
2370686132 bytes, 182.630 secs (12980814 bytes/sec)
09:43:02.205126+00:00 distribution: zone example/IN: sending notifies
(serial 2019051621)
09:43:05.903528+00:00 distribution: client 3.3.3.23#52515 (example):
transfer of 'example/IN': IXFR started
09:49:34.058714+00:00 distribution: client 3.3.3.23#52515 (example):
transfer of 'example/IN': IXFR ended



09:43:04.766583+00:00 anycast: zone example/IN: notify from
2.2.2.4#7332: serial 2019051621
09:43:04.836184+00:00 anycast: zone example/IN: Transfer started.
09:43:05.891331+00:00 anycast: transfer of 'example/IN' from 2.2.2.4#53:
connected using 3.3.3.23#52515
09:49:41.251490+00:00 anycast: zone example/IN: transferred serial
2019051621
09:49:41.251719+00:00 anycast: transfer of 'example/IN' from 2.2.2.4#53:
Transfer status: success
09:49:41.251812+00:00 anycast: transfer of 'example/IN' from 2.2.2.4#53:
Transfer completed: 36573 messages, 12744969 records, 2367460025 bytes,
395.360 secs (5988112 bytes/sec)

___
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

journal file is out of date: removing journal file

[Klaus Darilion]

Hello!

BIND 9.12.2-P2, max-journal-size 1m;

What does the log message "journal file is out of date: removing journal
file" exactly mean? Is it somehow problematic?

I have bind as bump in the wire signer, and regularly problems with slow
zone updates for a specific zone which often, almost every AXFR, shows
this log message.

Thanks
Klaus

___
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: journal file is out of date: removing journal file

[Klaus Darilion]

Hi Tony!

Am 31.07.2019 um 12:44 schrieb Tony Finch:
> Klaus Darilion  wrote:
>>
>> What does the log message "journal file is out of date: removing journal
>> file" exactly mean? Is it somehow problematic?
> 
> After loading a zone, named discovers the serial number of the zone
> doesn't match the serial number of the journal.
> 
> Something weird is happening, because I would expect that the zone either
> had an incremental change, which goes via the journal, so the journal will
> be up to date; or it's a full reload (e.g. thaw or axfr), in which case
> the journal should be quietly removed in the reload process; or there is
> ixfr-from-differences, in which case the journal is updated instead of
> removed when a reload happens.

In my case, ixfr-from-differences is off, and incoming and outgoing is
always AXFR. Zone config is:
  type slave;
  auto-dnssec maintain;
  dnssec-dnskey-kskonly no;
  inline-signing yes;

> If I'm skim-reading the code right, the problem might be that it checks
> the journal for staleness (in zone_postload) before checking that the
> journal needs to be removed (in zone_replacedb which is called towards the
> end of zone_postload) which is the wrong order and will cause this log
> message more frequently than it should.

So, is this then a bug or just some suboptimal processing which should
not cause any operational issues?

Thanks
Klaus

___
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 setup for GSLB (Global Service Load Balancing)

[Klaus Darilion]

Am 12.09.2019 um 17:39 schrieb Roberto Carna:
Hi people, is it possible to setup BIND in order to implement GSLB 
(Global Service Load Balancing) between two sites ?


I need a near Active-Active scenario between two datacenters in 
different locations, and I want to do this with an open source solution.


If you want to change DNS responses depending on the status of a web 
server, you can use PDNS Authoritative >= 4.2 with LUA-Records.


https://doc.powerdns.com/authoritative/lua-records/index.html

regards
Klaus
___
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: NSEC3 salt change - temporary performance decline

[Klaus Darilion]

Hello Niels!

Thanks for bringing this to attention. I have reported it before [1][2]
without response.

We see this regulary. AFAIS it happens actually always, but if the IXFR
is small, the performance decline is so short that you usually won't
notice it.

The bigger the zonechange ie NSEC3 change, full resigning * the
longer is the performance decline and you will notice it more often.

*we don't resalt or resign completele - but this is what several of our
TLD customers do.

I hope it will be fixed soon, we already test other software.

regards
Klaus


[1] https://lists.isc.org/pipermail/bind-users/2018-March/099814.html
[2] https://lists.isc.org/pipermail/bind-users/2019-March/101579.html


Am 21.01.2020 um 15:43 schrieb Niels Haarbo via bind-users:
> Hello BIND users
> 
> Our DNSSEC signer changes NSEC3 salt every 30 days. The signer resigns all 
> the relevant records and the zone is transferred using IXFR to the 
> authoritative servers (6 nodes).
> 
> Two of the 6 authoritative servers (BIND 9.11.13 and 9.11.14) are affected by 
> a performance decline shortly after the change of salt. This has happened 
> after the last 3 changes of salt and the period of performance decline is 
> within 30 - 90 minutes. Most queries are dropped by the affected nodes during 
> the period. The normal rate is between 1.000 and 1.500 queries/second.
> 
> Other nodes running NSD and Knot are not affected.
> 
> What could be the reason for the performance decline?
> 
> Best regards
> 
> Niels Haarbo
> DK Hostmaster A/S
> 
> 
> ___
> 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
> 
___
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: NSEC3 salt change - temporary performance decline

[Klaus Darilion]

Am 21.01.2020 um 16:40 schrieb Ondřej Surý:
> We are currently investigating performance degradation related to big IXFRs.  
> Do you use ixfr-from-differences in your BIND configuration?  You could try 
> enforcing AFRX on salt change.
> 
> This is currently tracked as 
> https://gitlab.isc.org/isc-projects/bind9/issues/1447
> 
> and associated feature request: 
> https://gitlab.isc.org/isc-projects/bind9/issues/1515

thanks for giving priority to this issue.

Regards
Klaus
___
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

AW: Simplistic serial number roll back

[Klaus Darilion via bind-users]

Yes it does. I guess all name servers offer a command to force a transfer of 
the zone without checking the serial. The ones I use support that:

Bind: rndc retransfer 
NSD: nsd-control force_transfer 
PowerDNS: pdns_control retrieve 
Knot: knotc zone-retransfer 

regards
Klaus

> -Ursprüngliche Nachricht-
> Von: bind-users  Im Auftrag von John
> Thurston
> Gesendet: Freitag, 17. Februar 2023 21:43
> An: bind-users@lists.isc.org
> Betreff: Re: Simplistic serial number roll back
> 
> Agreed.
> 
> 
> I'm not considering rolling back to old zone data, but considering
> changing the algorithm used to generate the serial number for new zone
> data. The new algorithm would result in the new data being published
> with serial numbers which would be ignored as being "older" if they were
> generated with the old algorithm. But I feel like we've wandered off the
> path.
> 
> 
> My question is seeking clarification of the behavior of "rndc
> retransfer" - does this command perform the transfer, regardless of what
> serial number it has or finds?
> 
> 
> 
> 
> 
> --
> Do things because you should, not just because you can.
> 
> John Thurston907-465-8591
> john.thurs...@alaska.gov 
> Department of Administration
> State of Alaska
> On 2/17/2023 10:46 AM, Ondřej Surý wrote:
> 
> 
>   Well, the serial number arithmetics is there for a reason - you
> usually don’t want to rollback to previous version of the zone - you can
> have multiple primaries with different serial numbers.

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

AW: DNS DDoS protection

[Klaus Darilion via bind-users]

> -Ursprüngliche Nachricht-
> Von: bind-users  Im Auftrag von Bob
> Harold
> Gesendet: Freitag, 24. Februar 2023 19:26
> An: bind-users 
> Betreff: DNS DDoS protection
> 
> Before answering this question, can you tell me the proper place where I
> should be asking this question?
> 
> "We are researching DDoS protection, including DNS.  What companies or
> products or methods should I be looking at?"

When talking about DDoS on DNS you have to differ between:
a) Volumetric attacks: the attacker fills up your Internet connections with 
junk traffic
b) Application layer attacks: the attacker sends plenty of valid DNS queries 
which overloads your name servers

For a) you have to look out for the typical DDoS Mitigation providers 
(Cloudlfare, Voxility, . just Google, there are plenty of them). They can 
filter junk traffic, but not DNS queries which look like valid DNS requests

For b) you need a DNS provider which either detects such queries and drops them 
or who has enough name servers to just answer them. I guess most of the DNS 
provider also have contracts with a) to handle also volumetric attacks.

To not promote our service, as a starting point take a look at dnsperf.com 
where plenty of DNS providers are compared regarding their RTT from all around 
the world.

Of course you can also build your own infrastructure that can handle DDoS 
loads. But that may only be reasonable if you are hosting millions of zones. 
For just a few or hundreds domains it would be cheaper to outsource the DNS 
hosting, instead of building it yourself.

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

Correlation between NOTIFY-Source and AXFR-Source

[Klaus Darilion via bind-users]

Hello!

I always was quite sure that Bind will request XFR from the Primary that sent 
the NOTIFY.

config:
masters {
X.X.X.4;
X.X.X.20;
};

Bind Version 9.11.5.P4+dfsg-5.1+deb10u8

But I just saw this in the logs that the first NOTIFY is received from .20, but 
AXFR is performed from .4:

15:31:17.715 general: info: zone versicherung/IN: notify from X.X.X.20#39334: 
serial 1678375865
15:31:17.716 general: info: zone versicherung/IN: Transfer started.
15:31:17.716 xfer-in: info: transfer of 'versicherung/IN' from X.X.X.4#53: 
connected using X.X.X.113#43555 TSIG rcode0-distribution
15:31:17.720 general: info: zone versicherung/IN: transferred serial 
1678375865: TSIG 'rcode0-distribution'
15:31:17.720 xfer-in: info: transfer of 'versicherung/IN' from X.X.X.4#53: 
Transfer status: success
15:31:17.720 xfer-in: info: transfer of 'versicherung/IN' from X.X.X.4#53: 
Transfer completed: 1 messages, 82 records, 14703 bytes, 0.004 secs (3675750 
bytes/sec)
15:31:20.001 notify: info: client @0x7fdb840c94a0 X.X.X.4#49990/key 
rcode0-distribution: received notify for zone 'versicherung': TSIG 
'rcode0-distribution'
15:31:20.001 general: info: zone versicherung/IN: notify from X.X.X.4#49990: 
zone is up to date

Is there really no correlation between the notification source and the XFR 
source?

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

AW: Correlation between NOTIFY-Source and AXFR-Source

[Klaus Darilion via bind-users]

> -Ursprüngliche Nachricht-
> Von: bind-users  Im Auftrag von Mark
> Andrews
> Gesendet: Donnerstag, 9. März 2023 21:04
> An: Jan-Piet Mens 
> Cc: bind-users@lists.isc.org
> Betreff: Re: Correlation between NOTIFY-Source and AXFR-Source
> 
> Named just uses the notify to trigger an early refresh process. It then just 
> asks
> the primaries in configured order.There is no real point in trying the 
> notifier
> first.

It depends. If one of the primaries is faster then the other in updating its 
version of the zone, named as secondary would have the update faster if it 
talks to fastest primary first. So there can be a benefit. Also if a primary is 
not reachable, for example maintenance and network issues, then named would not 
have to wait for timeouts before asking other primaries. So I see benefits.

On the other hand, we do not have a problem with the current behavior.

Thanks for the clarifications
Klaus

PS: Latest PowerDNS tries the NOTIFY source first. MAybe someone knows how Knot 
and NSD behave?
-- 
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

Bind not sending notifies for some time

[Klaus Darilion via bind-users]

Hi!

root@cc-tld-sbg1:/var/log/tld-acct-by-customer# dpkg -l|grep bind9
ii  bind9 1:9.18.6-1+ubuntu22.04.1+isc+1
 amd64Internet Domain Name Server

Please help me debugging this issue: We have a TLD zone with ~3mio delegations 
and updates every few seconds in such a setup:

customer --> incoming-bind --> distribution-bind --> public facing secondaries

Once a day, the distribution server stops sending NOTIFYs for some minutes (the 
incoming is working fine), while still processing incoming NOTIFY and fetching 
the zones. See logs below.

I could not spot other uncommon log messages. This bind instance also XFRs 
other TLD zones in and out. While bind stop sending NOTIFYs for this zone, it 
still processes other zones (NOTIFY+XFR in and out).

Do you have any hints to debug this issue? Is there some rate liming in Bind?

Frankly this is every day around 730-830 UTC. So my first guess was something 
that happens once a day to one of the hosted zones, but I could not spot 
something suspicious.

Thanks
Klaus


...
07:45:26 named-distribution[1148]: transfer of 'example/IN' from 
83.136.34.22#53: Transfer completed: 1 messages, 112 records, 17540 bytes, 
0.032 secs (548125 bytes/sec) (serial 1089775037)
07:45:26 named-distribution[1148]: zone example/IN: sending notifies (serial 
1089775037)
07:45:31 named-distribution[1148]: transfer of 'example/IN' from 
83.136.34.22#53: Transfer completed: 1 messages, 52 records, 8220 bytes, 0.004 
secs (2055000 bytes/sec) (serial 1089775039)
07:45:31 named-distribution[1148]: zone example/IN: sending notifies (serial 
1089775039)
07:45:36 named-distribution[1148]: transfer of 'example/IN' from 
83.136.34.22#53: Transfer completed: 1 messages, 80 records, 12750 bytes, 0.008 
secs (1593750 bytes/sec) (serial 1089775042)
07:45:41 named-distribution[1148]: transfer of 'example/IN' from 
83.136.34.22#53: Transfer completed: 1 messages, 28 records, 4349 bytes, 0.004 
secs (1087250 bytes/sec) (serial 1089775043)
07:45:41 named-distribution[1148]: zone example/IN: sending notifies (serial 
1089775043)
07:45:46 named-distribution[1148]: transfer of 'example/IN' from 
83.136.34.22#53: Transfer completed: 1 messages, 28 records, 4421 bytes, 0.004 
secs (1105250 bytes/sec) (serial 1089775044)
07:45:52 named-distribution[1148]: transfer of 'example/IN' from 
83.136.34.22#53: Transfer completed: 1 messages, 54 records, 8579 bytes, 0.008 
secs (1072375 bytes/sec) (serial 1089775046)
07:45:52 named-distribution[1148]: zone example/IN: sending notifies (serial 
1089775046)
07:45:57 named-distribution[1148]: transfer of 'example/IN' from 
83.136.34.22#53: Transfer completed: 1 messages, 54 records, 8640 bytes, 0.004 
secs (216 bytes/sec) (serial 1089775048)
07:45:57 named-distribution[1148]: zone example/IN: sending notifies (serial 
1089775048)
07:46:03 named-distribution[1148]: transfer of 'example/IN' from 
83.136.34.22#53: Transfer completed: 1 messages, 54 records, 8552 bytes, 0.004 
secs (2138000 bytes/sec) (serial 1089775050)
07:46:03 named-distribution[1148]: zone example/IN: sending notifies (serial 
1089775050)
07:46:07 named-distribution[1148]: transfer of 'example/IN' from 
83.136.34.22#53: Transfer completed: 1 messages, 28 records, 4398 bytes, 0.001 
secs (4398000 bytes/sec) (serial 1089775051)
07:46:08 named-distribution[1148]: zone example/IN: sending notifies (serial 
1089775051)
07:46:12 named-distribution[1148]: transfer of 'example/IN' from 
83.136.34.22#53: Transfer completed: 1 messages, 54 records, 8549 bytes, 0.004 
secs (2137250 bytes/sec) (serial 1089775053)
07:46:13 named-distribution[1148]: zone example/IN: sending notifies (serial 
1089775053)
07:46:17 named-distribution[1148]: transfer of 'example/IN' from 
83.136.34.22#53: Transfer completed: 1 messages, 86 records, 13545 bytes, 0.008 
secs (1693125 bytes/sec) (serial 1089775057)
07:46:18 named-distribution[1148]: zone example/IN: sending notifies (serial 
1089775057)
07:46:29 named-distribution[1148]: transfer of 'example/IN' from 
83.136.34.22#53: Transfer completed: 1 messages, 52 records, 8285 bytes, 0.004 
secs (2071250 bytes/sec) (serial 1089775059)
07:46:29 named-distribution[1148]: zone example/IN: sending notifies (serial 
1089775059)
07:46:35 named-distribution[1148]: transfer of 'example/IN' from 
83.136.34.22#53: Transfer completed: 1 messages, 45 records, 5834 bytes, 0.004 
secs (1458500 bytes/sec) (serial 1089775061)
07:46:44 named-distribution[1148]: transfer of 'example/IN' from 
83.136.34.22#53: Transfer completed: 1 messages, 28 records, 4419 bytes, 0.001 
secs (4419000 bytes/sec) (serial 1089775062)
07:46:54 named-distribution[1148]: transfer of 'example/IN' from 
83.136.34.22#53: Transfer completed: 1 messages, 28 records, 4401 bytes, 0.001 
secs (4401000 bytes/sec) (serial 1089775063)
07:46:59 named-distribution[1148]: transfer of 'example/IN' from 
83.136.34.22#53: Transfer completed: 1 messages, 106 records, 17001 bytes, 
0.008 sec

RE: Bind not sending notifies for some time

[Klaus Darilion via bind-users]

>
> https://bind9.readthedocs.io/en/stable/reference.html#namedconf-statement-notify-rate

Will that feature throttle Notifys or stop them completely for some minutes?

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

AW: Bind not sending notifies for some time

[Klaus Darilion via bind-users]

> > On 24. 3. 2023, at 14:36, Klaus Darilion via bind-users  us...@lists.isc.org> wrote:
> >
> >  Is there some rate liming in Bind?
> 
> https://bind9.readthedocs.io/en/stable/reference.html#namedconf-
> statement-notify-rate

For the records: Increasing the notify rate solved our problems.

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

AW: Tools to mesure performance and benchmarking of a DNS

[Klaus Darilion via bind-users]

There are several tools with different features and behavior. I would take 
alook at dnsperf, kxdpgun and flamethrower
regards

> -Ursprüngliche Nachricht-
> Von: bind-users  Im Auftrag von
> sami.ra...@sofrecom.com
> Gesendet: Mittwoch, 21. Juni 2023 17:59
> An: bind-users@lists.isc.org
> Betreff: Tools to mesure performance and benchmarking of a DNS
> 
> Hello
> 
> Please, what is the recommended open source tool to test the performance
> and benchmarking of a DNS server i.e. capture packets and then send them
> to a DNS server to measure response time, latency, cache usage etc.
> 
> Regards
> 
> Sami
> 
> 

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

Why are XFRs to Secondaries equally fast?

[Klaus Darilion via bind-users]

Hello!

Yesterday I made some tests transferring a zone with 50mio RRs to 35 
Secondaries. I measured the time between:

-  Primary logs "zone test/IN: sending notifies"

-  Primary logs "client : transfer of 'test/IN': AXFR-style IXFR 
ended"

What makes we wonder is, that for several secondaries the XFR duration is 
equally fast although these secondaries are globally distributed with different 
RTTs and different VMs:
173  seconds
173  seconds
404  seconds
405  seconds
609  seconds
620  seconds
622  seconds
638  seconds
838  seconds
838  seconds
839  seconds
839  seconds
843  seconds
848  seconds
859  seconds
1031 seconds
1032 seconds
1032 seconds
1035 seconds
1037 seconds
1038 seconds
1038 seconds
1038 seconds
1043 seconds
1702 seconds
2359 seconds
2361 seconds
2361 seconds
2361 seconds
2361 seconds
2361 seconds
2361 seconds
2361 seconds
2361 seconds
2362 seconds

For example, there are 8 secondaries (Mumbai, LosAngeles, Melbourne, Atlante, 
SaoPaulo...) to which the XFR took 2361 seconds.


Are there some mechanisms in Bind that put multiple XFRs together into a common 
stream? Or do you have any other ideas how it come that several XFRs are 
equally fast?

Thanks
Klaus


--
Klaus Darilion, Head of Operations
nic.at GmbH, Jakob-Haringer-Straße 8/V
5020 Salzburg, Austria
-- 
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

AW: Why are XFRs to Secondaries equally fast?

[Klaus Darilion via bind-users]

Hi Petr!

> > For example, there are 8 secondaries (Mumbai, LosAngeles, Melbourne,
> > Atlante, SaoPaulo...) to which the XFR took 2361 seconds.
> >
> > Are there some mechanisms in Bind that put multiple XFRs together into
> a
> > common stream? Or do you have any other ideas how it come that several
> > XFRs are equally fast?
> 
> Are you sure all these transfers were _actually_ running in parallel?

Yes. I checked the logs on the secondaries too and also these logs say that the 
XFR were finished at the same second.

> I suspect it will boil down to some sort of configured limit like
> transfers-out
> transfers-in
> transfers-per-ns
> serial-query-rate
> which cause some transfers to serialize and reduce parallelism.

$ egrep 'serial-query-rate|transfers' *
named.conf.options:serial-query-rate 500;
named.conf.options:transfers-in 50;// number of total 
concurrent zone transfers from the masters to me
named.conf.options:transfers-per-ns 50;// number of concurrent zone 
transfers per master from the masters to me
named.conf.options:transfers-out 200;  // number of concurrent zone 
transfers from me to my slaves

regards
Klaus


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

AW: migration from auto-dnssec to dnssec-policy deletes keys immediately

[Klaus Darilion via bind-users]

Hi all!



I also know a colleague which was hit by the same issue, causing problems to 
their zone.



Migrating from auto-dnssec to dnssec-policy can lead to operational issues. For 
example that problem with different algos should be mentioned in 
https://kb.isc.org/docs/dnssec-key-and-signing-policy



Further, I suggest to add something like the following sentence to that 
article: Changing DNSSEC configuration can lead to unexpected zone changes and 
should be tested on dedicated test systems before. If you do this on a hidden 
master, you could also temporarily disable outgoing XFR by configuring 
'allow-transfer {"none";};' on that zone to prevent leakage of broken DNSSEC 
zones. This way you can check the zone after migration and only after 
successful testing (i.e. using https://dnsviz.net/d/ops.nic.at/analyze/ with 
advanced options, pointing directly to the hidden master) re-enable outgoing 
XFR.



Regards

Klaus

Von: bind-users  Im Auftrag von Nick Tait via 
bind-users
Gesendet: Donnerstag, 28. Dezember 2023 04:01
An: bind-users@lists.isc.org
Betreff: Re: migration from auto-dnssec to dnssec-policy deletes keys 
immediately

On 28 Dec 2023, at 1:05 PM, Adrian Zaugg 
mailto:lists.isc@mailgurgler.com>> wrote:
2023-12-27 23:51:24: zone myzone.ch/IN (signed): reconfiguring zone keys
2023-12-27 23:51:24: keymgr: retire DNSKEY myzone.ch/ECDSAP256SHA256/14076
(KSK)
2023-12-27 23:51:24: keymgr: retire DNSKEY myzone.ch/ECDSAP256SHA256/3654
(ZSK)
2023-12-27 23:51:24: keymgr: DNSKEY myzone.ch/ED25519/2336 (KSK) created for
policy mypolicy
2023-12-27 23:51:24: keymgr: DNSKEY myzone.ch/ED25519/35413 (ZSK) created for
policy mypolicy

Your DNSSEC policy “mypolicy” specifies a different algorithm (ED25519) to what 
was previously in effect (ECDSAP256SHA256), which is why Bind generated new 
keys. If you want Bind to keep the old keys when transitioning to dnssec-policy 
you should initially specify the same algorithm in your policy.

My understanding is that after you’ve transitioned to using dnssec-policy you 
should be able to change the algorithm and Bind should do a graceful roll-over? 
Just make sure everything is “omnipresent” in your state files (in the keys 
directory) first.

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

AW: Problem upgrading to 9.18 - important feature being removed

[Klaus Darilion via bind-users]

> -Ursprüngliche Nachricht-
> Von: bind-users  Im Auftrag von Carsten
...
> It would be nice to have a "dry-run" mode in BIND 9, where BIND 9 would
> report steps it would do because of "dnssec-policy", but will not execute the
> changes.

If this Bind9 is only a hidden primary, disable all outgoing XFR for the 
respective zone, and make a copy of the Bind config and zone/journal files. 
That way you could test the new config and avoid leakage of broken/unwanted 
zones.

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

AW: Crafting a NOTIFY message from the command line?

[Klaus Darilion via bind-users]

> -Ursprüngliche Nachricht-
> Von: bind-users  Im Auftrag von Arsen
> STASIC
> Gesendet: Donnerstag, 21. März 2024 08:47
> An: Petr Špaček 
> Cc: bind-users@lists.isc.org
> Betreff: Re: Crafting a NOTIFY message from the command line?
> 
> * Petr Špaček  [2024-03-20 09:32 (+0100)]:
> > On 19. 03. 24 23:10, Anand Buddhdev wrote:
> > > You can try something like:
> > >
> > > dig +norec +opcode=notify  soa @server
> >
> > As an alternative, script
> >
> https://github.com/rthalley/dnspython/blob/main/examples/send_notify.py
> > allows you to specify SOA serial in the NOTIFY message as well.
> 
> As an further alternative written in perl:
> https://github.com/gbxyz/pnotify

One more:

$ pdns_notify
Syntax: pdns_notify IP_ADDRESS/HOSTNAME[:PORT] DOMAIN

(from package pdns-tools)

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

AW: [OFF-TOPIC] Question about ClouDNS (and others') ALIAS records

[Klaus Darilion via bind-users]

> -Ursprüngliche Nachricht-
> Von: bind-users  Im Auftrag von Jan
> Schaumann via bind-users
> Gesendet: Dienstag, 26. März 2024 14:44
> An: bind-users@lists.isc.org
> Betreff: Re: [OFF-TOPIC] Question about ClouDNS (and others') ALIAS records
> 
> Karl Auer  wrote:
> > I'm puzzled by the ClouDNS "ALIAS" record. I was wondering if anyone
> > knows how it is handled "under the hood"?
> 
> Many DNS service providers have some sort of variation
> of this, since "aliases at the apex" is a feature many
> customers need:
> 
> Akamai uses "Zone apex mapping":
> https://techdocs.akamai.com/edge-dns/docs/features#zone-apex-mapping
> 
> Cloudflare uses "CNAME flattening":
> https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-
> at-a-domains-root/
> 
> AWS uses "alias records":
> https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/resource-record-
> sets-choosing-alias-non-alias.html
> ...

Some more info can be found in the deprecated draft: 
https://datatracker.ietf.org/doc/draft-ietf-dnsop-aname/
This is for example very similar how ALIAS is implemented in PowerDNS Auth. But 
as there is no standard for the "CNAME-like at apex" there is no definition on 
how TTLs  should be implemented.

Regards
Klaus

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

Sporadic Timeouts after upgrading to bind9.20

[Klaus Darilion via bind-users]

Hello!

On our production name servers we have check every 30s if bind is alive by 
sending a SOA query to bind. Today I upgraded a few nodes from 9.18.x (x 
between 17 and 27) to 9.20.1 (Ubuntu 24.04 with packages from ISC ppa).

Since that, we have sporadic timeouts (3s). On the nodes with more qps we see 
it more often.

Before I dig into the problem, are there any specific changes to 9.20 that I 
should look at? Maybe some default value changes for socket buffers, thread 
handling ...?

Thanks
Klaus

--
Klaus Darilion, Head of Operations
nic.at GmbH, Jakob-Haringer-Straße 8/V
5020 Salzburg, Austria

-- 
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: Sporadic Timeouts after upgrading to bind9.20

[Klaus Darilion via bind-users]

Sorry, I forgot to mention that this is an authoritative nameserver. (For 
several ccTLDs. Each customers has its own Bind process. Currently I only 
noticed timeouts on Binds hosting bigger ccTLDs).

I will look how to integrate eu-stack into our monitoring check.

Thanks
Klaus


--
Klaus Darilion, Head of Operations
nic.at GmbH, Jakob-Haringer-Straße 8/V
5020 Salzburg, Austria

From: Ondřej Surý 
Sent: Wednesday, September 4, 2024 7:23 PM
To: Klaus Darilion 
Cc: bind-users@lists.isc.org
Subject: Re: Sporadic Timeouts after upgrading to bind9.20

Klaus,

is that recursive or authoritative? Anything unusual like RPZ or catz?

Try snapshoting the call stack with eu-stack and save the one when the timeout 
happens.

Ondrej
--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.


On 4. 9. 2024, at 19:06, Klaus Darilion via bind-users 
mailto:bind-users@lists.isc.org>> wrote:

Hello!

On our production name servers we have check every 30s if bind is alive by 
sending a SOA query to bind. Today I upgraded a few nodes from 9.18.x (x 
between 17 and 27) to 9.20.1 (Ubuntu 24.04 with packages from ISC ppa).

Since that, we have sporadic timeouts (3s). On the nodes with more qps we see 
it more often.

Before I dig into the problem, are there any specific changes to 9.20 that I 
should look at? Maybe some default value changes for socket buffers, thread 
handling …?

Thanks
Klaus

--
Klaus Darilion, Head of Operations
nic.at GmbH, Jakob-Haringer-Straße 8/V
5020 Salzburg, Austria

--
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<mailto:bind-users@lists.isc.org>
https://lists.isc.org/mailman/listinfo/bind-users
-- 
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: Sporadic Timeouts after upgrading to bind9.20

[Klaus Darilion via bind-users]

/x86_64-linux-gnu/libuv.so.1.0.0
#3  0x7b8cec6708d1 - 1 - 
/usr/lib/x86_64-linux-gnu/libisc-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
#4  0x7b8cec68502a - 1 - 
/usr/lib/x86_64-linux-gnu/libisc-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
#5  0x7b8ceb49ca94 - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6
#6  0x7b8ceb529c3c - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6
TID 1605213:
#0  0x7b8ceb52725d syscall - /usr/lib/x86_64-linux-gnu/libc.so.6
#1  0x7b8cec0a6a85 - 1 - /usr/lib/x86_64-linux-gnu/liburcu.so.8.1.0
#2  0x7b8ceb49ca94 - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6
#3  0x7b8ceb529c3c - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6
TID 1606172:
#0  0x7b8ceb498d61 - /usr/lib/x86_64-linux-gnu/libc.so.6
#1  0x7b8ceb49b7dd - 1 pthread_cond_wait - 
/usr/lib/x86_64-linux-gnu/libc.so.6
#2  0x7b8cec5253ad - 1 uv_cond_wait - 
/usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#3  0x7b8cec5177fe - 1 - /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#4  0x7b8ceb49ca94 - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6
#5  0x7b8ceb529c3c - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6
TID 1606173:
#0  0x7b8ceb498d61 - /usr/lib/x86_64-linux-gnu/libc.so.6
#1  0x7b8ceb49b7dd - 1 pthread_cond_wait - 
/usr/lib/x86_64-linux-gnu/libc.so.6
#2  0x7b8cec5253ad - 1 uv_cond_wait - 
/usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#3  0x7b8cec5177fe - 1 - /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#4  0x7b8ceb49ca94 - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6
#5  0x7b8ceb529c3c - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6
TID 1606174:
#0  0x7b8ceb498d61 - /usr/lib/x86_64-linux-gnu/libc.so.6
#1  0x7b8ceb49b7dd - 1 pthread_cond_wait - 
/usr/lib/x86_64-linux-gnu/libc.so.6
#2  0x7b8cec5253ad - 1 uv_cond_wait - 
/usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#3  0x7b8cec5177fe - 1 - /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#4  0x7b8ceb49ca94 - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6
#5  0x7b8ceb529c3c - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6
TID 1606175:
#0  0x7b8ceb498d61 - /usr/lib/x86_64-linux-gnu/libc.so.6
#1  0x7b8ceb49b7dd - 1 pthread_cond_wait - 
/usr/lib/x86_64-linux-gnu/libc.so.6
#2  0x7b8cec5253ad - 1 uv_cond_wait - 
/usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#3  0x7b8cec5177fe - 1 - /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#4  0x7b8ceb49ca94 - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6
#5  0x7b8ceb529c3c - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6
TID 1606176:
#0  0x7b8ceb498d61 - /usr/lib/x86_64-linux-gnu/libc.so.6
#1  0x7b8ceb49b7dd - 1 pthread_cond_wait - 
/usr/lib/x86_64-linux-gnu/libc.so.6
#2  0x7b8cec5253ad - 1 uv_cond_wait - 
/usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#3  0x7b8cec5177fe - 1 - /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#4  0x7b8ceb49ca94 - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6
#5  0x7b8ceb529c3c - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6
TID 1606177:
#0  0x7b8ceb498d61 - /usr/lib/x86_64-linux-gnu/libc.so.6
#1  0x7b8ceb49b7dd - 1 pthread_cond_wait - 
/usr/lib/x86_64-linux-gnu/libc.so.6
#2  0x7b8cec5253ad - 1 uv_cond_wait - 
/usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#3  0x7b8cec5177fe - 1 - /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#4  0x7b8ceb49ca94 - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6
#5  0x7b8ceb529c3c - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6
TID 1606178:
#0  0x7b8ceb498d61 - /usr/lib/x86_64-linux-gnu/libc.so.6
#1  0x7b8ceb49b7dd - 1 pthread_cond_wait - 
/usr/lib/x86_64-linux-gnu/libc.so.6
#2  0x7b8cec5253ad - 1 uv_cond_wait - 
/usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#3  0x7b8cec5177fe - 1 - /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#4  0x7b8ceb49ca94 - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6
#5  0x7b8ceb529c3c - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6
TID 1606179:
#0  0x7b8ceb498d61 - /usr/lib/x86_64-linux-gnu/libc.so.6
#1  0x7b8ceb49b7dd - 1 pthread_cond_wait - 
/usr/lib/x86_64-linux-gnu/libc.so.6
#2  0x7b8cec5253ad - 1 uv_cond_wait - 
/usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#3  0x7b8cec5177fe - 1 - /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#4  0x7b8ceb49ca94 - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6
#5  0x7b8ceb529c3c - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6



--
Klaus Darilion, Head of Operations
nic.at GmbH, Jakob-Haringer-Straße 8/V
5020 Salzburg, Austria

From: Ondřej Surý 
Sent: Wednesday, September 4, 2024 7:23 PM
To: Klaus Darilion 
Cc: bind-users@lists.isc.org
Subject: Re: Sporadic Timeouts after upgrading to bind9.20

Klaus,

is that recursive or authoritative? Anything unusual like RPZ or catz?

Try snapshoting the call stack with eu-stack and save the one when the timeout 
happens.

Ondrej
--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.


On 4. 9. 2024, at 19:06, Klaus Darilion via bind-users 
mailto:bind-users@lists.isc.org>> wrote:

Hello!

On our production name servers w

RE: Sporadic Timeouts after upgrading to bind9.20

[Klaus Darilion via bind-users]

I just happened again. I have not yet installed the debug symbols.

I query the SOA every second with 1 second timeout. Here are the traces. I 
happened a few times in a row.

Below are the traces.

I noticed the timeout happened during Bind9 starting an inbound IXFR:
Sep 06 07:20:55 named[1605200]: zone xx/IN: Transfer started.
[ here inbetween were timeouts ]
Sep 06 07:25:56 named[1605200]: 0x7b8a8fdff000: transfer of xx/IN' from 
83.136.xx.xx#53: Transfer completed: 166 messages, 28386 records, 3319665 
bytes, 301.177 secs (11022 bytes/sec) (serial 2024090614)

Is bind applying IXFR during the inbound IXFR? Because 11kByte/sec is very slow 
(iperf shows 400Mbit network speed) and seems like Bind is also slow processing 
the inbound IXFR.

This zone has the following characteristic:
- 2.7GByte on disk
- ~ 6mio delegation
- NSEC3 without opt-out

Maybe NSEC3 calculations make bind9 busy? Up to now we noticed that problem 
with 2 zones, both have NSEC3 without opt-out.

Thanks
Klaus


FAILED - timeout (1 sec) or network error querying SOA at port 53024
PID 1605200 - process
TID 1605200:
#0  0x7b8ceb52bfa2 __sendmmsg - /usr/lib/x86_64-linux-gnu/libc.so.6
#1  0x7b8cec527e74 - 1 - /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#2  0x7b8cec51522b - 1 uv_udp_send - 
/usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#3  0x7b8cec65f6ba - 1 isc__nm_udp_send - 
/usr/lib/x86_64-linux-gnu/libisc-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
#4  0x7b8cec5e90ad - 1 - 
/usr/lib/x86_64-linux-gnu/libns-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
#5  0x7b8cec5f0a87 - 1 ns_client_send - 
/usr/lib/x86_64-linux-gnu/libns-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
#6  0x7b8cec5f1909 - 1 - 
/usr/lib/x86_64-linux-gnu/libns-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
#7  0x7b8cec60ff60 - 1 ns_query_done - 
/usr/lib/x86_64-linux-gnu/libns-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
#8  0x7b8cec6015c2 - 1 - 
/usr/lib/x86_64-linux-gnu/libns-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
#9  0x7b8cec601f27 - 1 ns__query_start - 
/usr/lib/x86_64-linux-gnu/libns-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
#10 0x7b8cec60273e - 1 - 
/usr/lib/x86_64-linux-gnu/libns-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
#11 0x7b8cec5f222b - 1 - 
/usr/lib/x86_64-linux-gnu/libns-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
#12 0x7b8cec5f2e1f - 1 ns_client_request - 
/usr/lib/x86_64-linux-gnu/libns-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
#13 0x7b8cec64a478 - 1 isc__nm_readcb - 
/usr/lib/x86_64-linux-gnu/libisc-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
#14 0x7b8cec65f2b9 - 1 isc__nm_udp_read_cb - 
/usr/lib/x86_64-linux-gnu/libisc-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
#15 0x7b8cec52b802 - 1 - /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#16 0x7b8cec52b9b3 - 1 - /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#17 0x7b8cec52cbdb - 1 - /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#18 0x7b8cec513ce8 - 1 uv_run - /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#19 0x7b8cec6708d1 - 1 - 
/usr/lib/x86_64-linux-gnu/libisc-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
#20 0x57c70ed697a6 - 1 main - /usr/sbin/named
#21 0x7b8ceb42a1ca - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6
#22 0x7b8ceb42a28b - 1 __libc_start_main - 
/usr/lib/x86_64-linux-gnu/libc.so.6
#23 0x57c70ed6a175 - 1 _start - /usr/sbin/named
TID 1605201:
#0  0x7b8ceb52725d syscall - /usr/lib/x86_64-linux-gnu/libc.so.6
#1  0x7b8cec0418ec - 1 - /usr/lib/x86_64-linux-gnu/liburcu-cds.so.8.1.0
#2  0x7b8cec041da5 - 1 - /usr/lib/x86_64-linux-gnu/liburcu-cds.so.8.1.0
#3  0x7b8ceb49ca94 - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6
#4  0x7b8ceb529c3c - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6
TID 1605202:
#0  0x7b8cec04029b cds_lfht_next - 
/usr/lib/x86_64-linux-gnu/liburcu-cds.so.8.1.0
#1  0x7b8cebeb3edf - 1 - 
/usr/lib/x86_64-linux-gnu/libdns-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
#2  0x7b8cebebb181 - 1 - 
/usr/lib/x86_64-linux-gnu/libdns-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
#3  0x7b8cebe45222 - 1 dns__db_closeversion - 
/usr/lib/x86_64-linux-gnu/libdns-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
#4  0x7b8cebf5e125 - 1 - 
/usr/lib/x86_64-linux-gnu/libdns-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
#5  0x7b8cec683e56 - 1 - 
/usr/lib/x86_64-linux-gnu/libisc-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
#6  0x7b8cec5172d9 - 1 - /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#7  0x7b8cec50e513 - 1 - /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#8  0x7b8cec52cbdb - 1 - /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#9  0x7b8cec513ce8 - 1 uv_run - /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#10 0x7b8cec6708d1 - 1 - 
/usr/lib/x86_64-linux-gnu/libisc-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
#11 0x7b8cec68502a - 1 - 
/usr/lib/x86_64-linux-gnu/libisc-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
#12 0x7b8ceb49ca94