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

RE: Sporadic Timeouts after upgrading to bind9.20

[Klaus Darilion via bind-users]

As there just was another IXFR, for the records, here is another trace with 
debug symbols installed. Thanks
Klaus

PID 1605200 - process
TID 1605200:
#0  0x7b8ceb529ee0 epoll_pwait - /usr/lib/x86_64-linux-gnu/libc.so.6
#1  0x7b8cec52c9fa - 1 - /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#2  0x7b8cec513ce8 - 1 uv_run - /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#3  0x7b8cec6708d1 - 1 loop_thread - 
/usr/lib/x86_64-linux-gnu/libisc-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
/build/bind9-eFXXmL/bind9-9.20.1/lib/isc/loop.c:288:6
#4  0x57c70ed697a6 - 1 main - /usr/sbin/named

/usr/src/bind9-1:9.20.1-1+ubuntu24.04.1+deb.sury.org+1/bin/named/main.c:1575:2
#5  0x7b8ceb42a1ca - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6
#6  0x7b8ceb42a28b - 1 __libc_start_main - 
/usr/lib/x86_64-linux-gnu/libc.so.6
#7  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 free_gluetable - 
/usr/lib/x86_64-linux-gnu/libdns-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
/build/bind9-eFXXmL/bind9-9.20.1/lib/dns/qpzone.c:392:2
#2  0x7b8cebebb181 - 1 closeversion - 
/usr/lib/x86_64-linux-gnu/libdns-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
/build/bind9-eFXXmL/bind9-9.20.1/lib/dns/qpzone.c:1450:3
#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
/build/bind9-eFXXmL/bind9-9.20.1/lib/dns/db.c:415:14
#4  0x7b8cebf5e125 - 1 ixfr_apply_done - 
/usr/lib/x86_64-linux-gnu/libdns-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
/build/bind9-eFXXmL/bind9-9.20.1/lib/dns/xfrin.c:588:3
#5  0x7b8cec683e56 - 1 isc__after_work_cb - 
/usr/lib/x86_64-linux-gnu/libisc-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
/build/bind9-eFXXmL/bind9-9.20.1/lib/isc/work.c:42:2
#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 loop_thread - 
/usr/lib/x86_64-linux-gnu/libisc-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
/build/bind9-eFXXmL/bind9-9.20.1/lib/isc/loop.c:288:6
#11 0x7b8cec68502a - 1 thread_body - 
/usr/lib/x86_64-linux-gnu/libisc-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
/build/bind9-eFXXmL/bind9-9.20.1/lib/isc/thread.c:85:8
#12 0x7b8cec68502a - 1 thread_run - 
/usr/lib/x86_64-linux-gnu/libisc-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
/build/bind9-eFXXmL/bind9-9.20.1/lib/isc/thread.c:100:14
#13 0x7b8ceb49ca94 - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6
#14 0x7b8ceb529c3c - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6
TID 1605207:
#0  0x7b8ceb529ee0 epoll_pwait - /usr/lib/x86_64-linux-gnu/libc.so.6
#1  0x7b8cec52c9fa - 1 - /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#2  0x7b8cec513ce8 - 1 uv_run - /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#3  0x7b8cec6708d1 - 1 loop_thread - 
/usr/lib/x86_64-linux-gnu/libisc-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
/build/bind9-eFXXmL/bind9-9.20.1/lib/isc/loop.c:288:6
#4  0x7b8cec68502a - 1 thread_body - 
/usr/lib/x86_64-linux-gnu/libisc-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
/build/bind9-eFXXmL/bind9-9.20.1/lib/isc/thread.c:85:8
#5  0x7b8cec68502a - 1 thread_run - 
/usr/lib/x86_64-linux-gnu/libisc-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
/build/bind9-eFXXmL/bind9-9.20.1/lib/isc/thread.c:100:14
#6  0x7b8ceb49ca94 - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6
#7  0x7b8ceb529c3c - 1 - /usr/lib/x86_64-linux-gnu/libc.so.6
TID 1605208:
#0  0x7b8ceb529ee0 epoll_pwait - /usr/lib/x86_64-linux-gnu/libc.so.6
#1  0x7b8cec52c9fa - 1 - /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#2  0x7b8cec513ce8 - 1 uv_run - /usr/lib/x86_64-linux-gnu/libuv.so.1.0.0
#3  0x7b8cec6708d1 - 1 loop_thread - 
/usr/lib/x86_64-linux-gnu/libisc-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
/build/bind9-eFXXmL/bind9-9.20.1/lib/isc/loop.c:288:6
#4  0x7b8cec68502a - 1 thread_body - 
/usr/lib/x86_64-linux-gnu/libisc-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
/build/bind9-eFXXmL/bind9-9.20.1/lib/isc/thread.c:85:8
#5  0x7b8cec68502a - 1 thread_run - 
/usr/lib/x86_64-linux-gnu/libisc-9.20.1-1+ubuntu24.04.1+deb.sury.org+1-Ubuntu.so
/build/bind9-eFXXmL/bind9-9.20.1/lib/isc/thread.c:100:14
#6  0x7b8ceb49ca94 - 1 - /usr/lib/x86_64

RE: Sporadic Timeouts after upgrading to bind9.20

[Klaus Darilion via bind-users]

From: Ondřej Surý 
Sent: Friday, September 6, 2024 4:10 PM
To: Klaus Darilion 
Cc: Klaus Darilion via bind-users 
Subject: Re: Sporadic Timeouts after upgrading to bind9.20

Hmm, what is the churn in the zones? How often there’s IXFR and how large those 
changes are?


Every 30 minutes. See logs:

12:20:55 zone xx/IN: notify from 83.136.34.20#55138: serial 2024090624
12:20:55 zone xx/IN: notify from 2a02:850:9::5#42346: serial 2024090624: 
refresh in progress, refresh check queued
12:20:55 zone xx/IN: Transfer started.
12:20:55 0x7b38529d: transfer of 'xx/IN' from 83.136.34.20#53: connected 
using 83.136.34.20#53 TSIG rcode0-distribution
12:20:55 zone xx/IN: notify from 2a00:dd80:9:69::4#34743: serial 2024090624: 
refresh in progress, refresh check queued
12:20:55 zone xx/IN: notify from 185.40.233.229#44310: serial 2024090624: 
refresh in progress, refresh check queued
12:20:56 zone xx/IN: transferred serial 2024090624: TSIG 'rcode0-distribution'
12:20:56 0x7b38529d: transfer of 'xx/IN' from 83.136.34.20#53: Transfer 
status: success
12:20:56 0x7b38529d: transfer of 'xx/IN' from 83.136.34.20#53: Transfer 
completed: 132 messages, 23102 records, 2632938 bytes, 1.121 secs (2348740 
bytes/sec) (serial 2024090624)
12:20:56 zone xx/IN: notify from 83.136.34.4#48518: zone is up to date
12:20:56 zone xx/IN: notify from 2a02:850:8::5#41419: zone is up to date


12:50:57 zone xx/IN: notify from 83.136.34.20#47046: serial 2024090625
12:50:57 zone xx/IN: notify from 2a02:850:9::5#52732: serial 2024090625: 
refresh in progress, refresh check queued
12:50:57 zone xx/IN: Transfer started.
12:50:57 0x7b35fcfb: transfer of 'xx/IN' from 83.136.34.20#53: connected 
using 83.136.34.20#53 TSIG rcode0-distribution
12:50:58 zone xx/IN: notify from 2a00:dd80:9:69::4#56984: serial 2024090625: 
refresh in progress, refresh check queued
12:50:58 zone xx/IN: notify from 185.40.233.229#41328: serial 2024090625: 
refresh in progress, refresh check queued
12:50:59 zone xx/IN: notify from 83.136.34.4#55745: zone is up to date
12:50:59 zone xx/IN: notify from 2a02:850:8::5#58001: zone is up to date
12:51:11 zone xx/IN: transferred serial 2024090625: TSIG 'rcode0-distribution'
12:51:11 0x7b35fcfb: transfer of 'xx/IN' from 83.136.34.20#53: Transfer 
status: success
12:51:11 0x7b35fcfb: transfer of 'xx/IN' from 83.136.34.20#53: Transfer 
completed: 130 messages, 22833 records, 2586324 bytes, 13.500 secs (191579 
bytes/sec) (serial 2024090625)


13:21:56 zone xx/IN: notify from 2a00:dd80:9:69::4#49911: serial 2024090626
13:21:56 zone xx/IN: notify from 185.40.233.229#34402: serial 2024090626: 
refresh in progress, refresh check queued
13:21:56 zone xx/IN: Transfer started.
13:21:56 0x7b35fda6c000: transfer of 'xx/IN' from 185.40.233.229#53: connected 
using 185.40.233.229#53 TSIG rcode0-distribution
13:21:57 zone xx/IN: notify from 2a02:850:9::5#36734: serial 2024090626: 
refresh in progress, refresh check queued
13:21:57 zone xx/IN: notify from 83.136.34.20#48874: serial 2024090626: refresh 
in progress, refresh check queued
13:21:58 zone xx/IN: notify from 83.136.34.4#53682: zone is up to date
13:22:08 zone xx/IN: transferred serial 2024090626: TSIG 'rcode0-distribution'
13:22:08 0x7b35fda6c000: transfer of 'xx/IN' from 185.40.233.229#53: Transfer 
status: success
13:22:08 0x7b35fda6c000: transfer of 'xx/IN' from 185.40.233.229#53: Transfer 
completed: 132 messages, 23222 records, 2631441 bytes, 11.390 secs (231030 
bytes/sec) (serial 2024090626)
13:22:08 zone xx/IN: notify from 2a02:850:8::5#51426: zone is up to date
13:22:08 zone xx/IN: notify from 2a02:850:8::5#51426: zone is up to date


13:50:54 zone xx/IN: notify from 83.136.34.20#36630: serial 2024090627
13:50:54 zone xx/IN: notify from 2a02:850:9::5#57691: serial 2024090627: 
refresh in progress, refresh check queued
13:50:54 zone xx/IN: Transfer started.
13:50:54 0x7b35fd943000: transfer of 'xx/IN' from 83.136.34.20#53: connected 
using 83.136.34.20#53 TSIG rcode0-distribution
13:50:54 zone xx/IN: notify from 2a00:dd80:9:69::4#53297: serial 2024090627: 
refresh in progress, refresh check queued
13:50:54 zone xx/IN: notify from 185.40.233.229#35120: serial 2024090627: 
refresh in progress, refresh check queued
13:50:56 zone xx/IN: notify from 83.136.34.4#52671: zone is up to date
13:50:56 zone xx/IN: notify from 2a02:850:8::5#32936: zone is up to date
13:51:16 zone xx/IN: transferred serial 2024090627: TSIG 'rcode0-distribution'
13:51:16 0x7b35fd943000: transfer of 'xx/IN' from 83.136.34.20#53: Transfer 
status: success
13:51:16 0x7b35fd943000: transfer of 'xx/IN' from 83.136.34.20#53: Transfer 
completed: 121 messages, 21340 records, 2416628 bytes, 21.794 secs (110885 
bytes/sec) (serial 2024090627)



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

IS

RE: Sporadic Timeouts after upgrading to bind9.20

[Klaus Darilion via bind-users]

From: Ondřej Surý 
Sent: Friday, September 6, 2024 4:08 PM
To: Klaus Darilion 
Cc: Petr Špaček ; bind-users@lists.isc.org; Klaus Darilion via 
bind-users 
Subject: Re: Sporadic Timeouts after upgrading to bind9.20

Are your running with options { reuseport no; };  ?

You might want to try that.

After setting reuseport no; (and UV_THREADPOOL_SIZE=12) I have not seen any 
timeouts anymore.

Anyway, this:

TID 8917:
#0  0x7b385aa6daa9 cds_lfht_destroy - 
/usr/lib/x86_64-linux-gnu/liburcu-cds.so.8.1.0

caught my eye. Are the zones you are hosting particularly large on GLUE?

I don’T know and I have not checked yet. One of the affected zones is .ch.  You 
could download the zone from https://zonedata.switch.ch/ And they are using 
NSEC (not NSEC3 as I have written before)



Also if you have more eu-stack, can you confirm this is the pattern now?

After setting reuseport no; I do not have stack-traces any more. But if that 
would help you I can undo the workaround next week to collect traces.

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

RE: Sporadic Timeouts after upgrading to bind9.20

[Klaus Darilion via bind-users]

Correcting myself: event with { reuseport no; };  and UV_THREADPOOL_SIZE=12 
still timeouts happen, but the situation improved a lot.
Regards
Klaus

From: bind-users  On Behalf Of Klaus Darilion 
via bind-users
Sent: Saturday, September 7, 2024 12:21 AM
To: Ondřej Surý 
Cc: Klaus Darilion via bind-users 
Subject: RE: Sporadic Timeouts after upgrading to bind9.20


From: Ondřej Surý mailto:ond...@isc.org>>
Sent: Friday, September 6, 2024 4:08 PM
To: Klaus Darilion mailto:klaus.daril...@nic.at>>
Cc: Petr Špaček mailto:pspa...@isc.org>>; 
bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>; Klaus Darilion via 
bind-users mailto:bind-users@lists.isc.org>>
Subject: Re: Sporadic Timeouts after upgrading to bind9.20

Are your running with options { reuseport no; };  ?

You might want to try that.

After setting reuseport no; (and UV_THREADPOOL_SIZE=12) I have not seen any 
timeouts anymore.

Anyway, this:

TID 8917:
#0  0x7b385aa6daa9 cds_lfht_destroy - 
/usr/lib/x86_64-linux-gnu/liburcu-cds.so.8.1.0

caught my eye. Are the zones you are hosting particularly large on GLUE?

I don’T know and I have not checked yet. One of the affected zones is .ch.  You 
could download the zone from https://zonedata.switch.ch/ And they are using 
NSEC (not NSEC3 as I have written before)



Also if you have more eu-stack, can you confirm this is the pattern now?

After setting reuseport no; I do not have stack-traces any more. But if that 
would help you I can undo the workaround next week to collect traces.

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

RE: Sporadic Timeouts after upgrading to bind9.20

[Klaus Darilion via bind-users]

As we still have several timeouts I downgraded our server to 9.18. If you know 
another workaround or need someone to test new version please let me know.

Thanks
Klaus

From: Klaus Darilion 
Sent: Saturday, September 7, 2024 12:36 AM
To: Klaus Darilion ; Ondřej Surý 
Cc: Klaus Darilion via bind-users 
Subject: RE: Sporadic Timeouts after upgrading to bind9.20

Correcting myself: event with { reuseport no; };  and UV_THREADPOOL_SIZE=12 
still timeouts happen, but the situation improved a lot.
Regards
Klaus

From: bind-users 
mailto:bind-users-boun...@lists.isc.org>> On 
Behalf Of Klaus Darilion via bind-users
Sent: Saturday, September 7, 2024 12:21 AM
To: Ondřej Surý mailto:ond...@isc.org>>
Cc: Klaus Darilion via bind-users 
mailto:bind-users@lists.isc.org>>
Subject: RE: Sporadic Timeouts after upgrading to bind9.20


From: Ondřej Surý mailto:ond...@isc.org>>
Sent: Friday, September 6, 2024 4:08 PM
To: Klaus Darilion mailto:klaus.daril...@nic.at>>
Cc: Petr Špaček mailto:pspa...@isc.org>>; 
bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>; Klaus Darilion via 
bind-users mailto:bind-users@lists.isc.org>>
Subject: Re: Sporadic Timeouts after upgrading to bind9.20

Are your running with options { reuseport no; };  ?

You might want to try that.

After setting reuseport no; (and UV_THREADPOOL_SIZE=12) I have not seen any 
timeouts anymore.

Anyway, this:

TID 8917:
#0  0x7b385aa6daa9 cds_lfht_destroy - 
/usr/lib/x86_64-linux-gnu/liburcu-cds.so.8.1.0

caught my eye. Are the zones you are hosting particularly large on GLUE?

I don’T know and I have not checked yet. One of the affected zones is .ch.  You 
could download the zone from https://zonedata.switch.ch/ And they are using 
NSEC (not NSEC3 as I have written before)



Also if you have more eu-stack, can you confirm this is the pattern now?

After setting reuseport no; I do not have stack-traces any more. But if that 
would help you I can undo the workaround next week to collect traces.

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: New BIND releases are available: 9.11.32, 9.16.16, and 9.17.13

[Klaus Darilion via bind-users]

Nevertheless I think there is a bug. IIR the previous default was 100% (switch 
to AXFR if IXFR would be grater than AXFR) and we also saw plenty of AXFR 
although the IXFR difference was very small and far away from 100%

regards
Klaus

> -Ursprüngliche Nachricht-
> Von: bind-users  Im Auftrag von Anand
> Buddhdev
> Gesendet: Donnerstag, 20. Mai 2021 16:38
> An: bind-users@lists.isc.org
> Betreff: Re: New BIND releases are available: 9.11.32, 9.16.16, and 9.17.13
> 
> On 20/05/2021 00:06, Michael McNally wrote:
> 
> Hi ISC people,
> 
> > RELEASE-NOTES-bind-9.16.16.html
> 
> I was just reading the release notes, and noticed:
> 
> "The default value of the max-ixfr-ratio option was changed to
> unlimited, for better backwards compatibility in the stable release series."
> 
> Thank you for this. Just yesterday, I was looking at XFRs between BIND
> 9.16.15, and a downstream Knot DNS server, which kept getting AXFRs
> instead of IXFRs. I was going to open an issue about this in GitLab.
> However, upgrading to 9.16.16 restored the previous (expected) behaviour.
> 
> Regards,
> Anand
> ___
> 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

failed trust-anchor-telemetry queries

[Klaus Darilion via bind-users]

Hello!

Bind version: 9.16.19-1+ubuntu18.04.1+isc+1

Recently I discovered these logs:
09:13:12 named[3234]: _default: sending trust-anchor-telemetry query 
'_ta-/NULL'
09:13:12 named[3234]:   validating ./NSEC: no valid signature found
09:13:12 named[3234]:   validating ./SOA: no valid signature found
09:13:12 named[3234]:   validating ./NSEC: no valid signature found
09:13:12 named[3234]:   validating ./SOA: no valid signature found
09:13:12 named[3234]: no valid RRSIG resolving '_ta-/DS/IN': 
2001:503:ba3e::2:30#53
09:13:13 named[3234]:   validating ./SOA: no valid signature found
09:13:13 named[3234]:   validating ./NSEC: no valid signature found
09:13:13 named[3234]: no valid RRSIG resolving '_ta-/DS/IN': 2001:dc3::35#53
09:13:13 named[3234]:   validating ./SOA: no valid signature found
09:13:13 named[3234]:   validating ./NSEC: no valid signature found
09:13:13 named[3234]: no valid RRSIG resolving '_ta-/DS/IN': 2001:7fe::53#53
09:13:13 named[3234]:   validating ./NSEC: no valid signature found
09:13:13 named[3234]:   validating ./SOA: no valid signature found
09:13:13 named[3234]: no valid RRSIG resolving '_ta-/DS/IN': 
2001:500:1::53#53
09:13:13 named[3234]:   validating ./SOA: no valid signature found
09:13:13 named[3234]:   validating ./NSEC: no valid signature found
09:13:13 named[3234]: no valid RRSIG resolving '_ta-/DS/IN': 
2001:500:9f::42#53
09:13:13 named[3234]:   validating ./SOA: no valid signature found
...

The config of the name server is authoritative-only, hence:
allow-recursion {
none;
};

May it be, that due to disabled recursion, these trust-anchor queries are 
failing? Or what might be other reasons?

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: Does BIND supports ANAME RR

[Klaus Darilion via bind-users]

> -Ursprüngliche Nachricht-
> Von: bind-users  Im Auftrag von Evan
> Hunt
> Gesendet: Samstag, 7. August 2021 20:21
> An: Gaurav Kansal 
> Cc: bind-users@lists.isc.org
> Betreff: Re: Does BIND supports ANAME RR
> 
> On Sat, Aug 07, 2021 at 11:05:51PM +0530, Gaurav Kansal wrote:
> > I need the help in figuring out whether BIND supports ANAME ? If yes,
> > then from which version on wards ?
> 
> No, it doesn't. The effort to standardize ANAME stalled, and I doubt
> it'll be coming back.
> 
> The new HTTPS and SVCB records look like a better approach anyway.
> BIND will have support for those pretty soon.

But honestly SVCB will not solve the ANAME problem. I will take years until all 
resolvers/client would support SVCB whereas ANAME would be implemented in the 
authoritative name server and hence would work for every client/resolver as 
client/resolver never sees the ANAME but only the A/ record.

regards
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: Does BIND supports ANAME RR

[Klaus Darilion via bind-users]

> On 09.08.21 13:55, Klaus Darilion via bind-users wrote:
> >But honestly SVCB will not solve the ANAME problem.  I will take years
> > until all resolvers/client would support SVCB whereas ANAME would be
> > implemented in the authoritative name server
> 
> resolving on authoritative server could in fact help, and wouldn't need
> protocol
> change at all, but the problem above is crucial (what would you do in case
> of failure? refuse whole zone?)

Resolving is done when there is an incoming query, not on zone loading. So if 
the auth's resolver (either a full blown resolver or a stub resolver which 
forwards to another resolver) fails to resolve I would just forward this error 
to the client's resolver.

regards
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: Does BIND supports ANAME RR

[Klaus Darilion via bind-users]

Does every application that uses gethostbyname have a benefit of HTTPS/SVCB? 
That is what I meant.
regards
Klaus

> -Ursprüngliche Nachricht-
> Von: Mark Andrews 
> Gesendet: Montag, 9. August 2021 15:55
> An: Klaus Darilion 
> Cc: Evan Hunt ; Gaurav Kansal ; bind-
> us...@lists.isc.org
> Betreff: Re: Does BIND supports ANAME RR
> 
> Every resolver on the planet already supports HTTPS and SVCB.  Every
> authoritative server on the planet already supports HTTPS and SVCB via
> unknown record format. iOS is already making HTTPS queries for every
> webpage. I believe other browsers also make HTTPS queries today. Go look
> at your DNS traffic.
> 
> The MR mentioned earlier allows named and the other tools to load and
> display the records in presentation format and to do the additional section
> processing.  None of that it required to be able to return these records.   It
> just makes it easier.
> 
> Just about all the other DNS vendors also have code that can read and
> display presentation format.
> 
> ANAME is dead.
> --
> Mark Andrews
> 
> > On 9 Aug 2021, at 21:53, Klaus Darilion via bind-users  us...@lists.isc.org> wrote:
> >
> > 
> >>
> >> -Ursprüngliche Nachricht-
> >> Von: bind-users  Im Auftrag von Evan
> >> Hunt
> >> Gesendet: Samstag, 7. August 2021 20:21
> >> An: Gaurav Kansal 
> >> Cc: bind-users@lists.isc.org
> >> Betreff: Re: Does BIND supports ANAME RR
> >>
> >>> On Sat, Aug 07, 2021 at 11:05:51PM +0530, Gaurav Kansal wrote:
> >>> I need the help in figuring out whether BIND supports ANAME ? If yes,
> >>> then from which version on wards ?
> >>
> >> No, it doesn't. The effort to standardize ANAME stalled, and I doubt
> >> it'll be coming back.
> >>
> >> The new HTTPS and SVCB records look like a better approach anyway.
> >> BIND will have support for those pretty soon.
> >
> > But honestly SVCB will not solve the ANAME problem. I will take years until
> all resolvers/client would support SVCB whereas ANAME would be
> implemented in the authoritative name server and hence would work for
> every client/resolver as client/resolver never sees the ANAME but only the
> A/ record.
> >
> > regards
> > 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: Does BIND supports ANAME RR

[Klaus Darilion via bind-users]

Do you think that we can get rid of CNAME too? 

regards
Klaus

> -Ursprüngliche Nachricht-
> Von: Ondřej Surý 
> Gesendet: Montag, 9. August 2021 19:19
> An: Klaus Darilion 
> Cc: Mark Andrews ; bind-users@lists.isc.org
> Betreff: Re: Does BIND supports ANAME RR
> 
> No, and there’s no strong usercase for that. The ANAME was wrong on every
> level from the protocol perspective and I am glad it is gone.
> 
> Ondřej
> --
> 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 9. 8. 2021, at 17:23, Klaus Darilion via bind-users  us...@lists.isc.org> wrote:
> >
> > Does every application that uses gethostbyname have a benefit of
> HTTPS/SVCB? That is what I meant.
> > regards
> > Klaus
> >
> >> -Ursprüngliche Nachricht-
> >> Von: Mark Andrews 
> >> Gesendet: Montag, 9. August 2021 15:55
> >> An: Klaus Darilion 
> >> Cc: Evan Hunt ; Gaurav Kansal ;
> bind-
> >> us...@lists.isc.org
> >> Betreff: Re: Does BIND supports ANAME RR
> >>
> >> Every resolver on the planet already supports HTTPS and SVCB.  Every
> >> authoritative server on the planet already supports HTTPS and SVCB via
> >> unknown record format. iOS is already making HTTPS queries for every
> >> webpage. I believe other browsers also make HTTPS queries today. Go
> look
> >> at your DNS traffic.
> >>
> >> The MR mentioned earlier allows named and the other tools to load and
> >> display the records in presentation format and to do the additional
> section
> >> processing.  None of that it required to be able to return these records.  
> >>  It
> >> just makes it easier.
> >>
> >> Just about all the other DNS vendors also have code that can read and
> >> display presentation format.
> >>
> >> ANAME is dead.
> >> --
> >> Mark Andrews
> >>
> >>> On 9 Aug 2021, at 21:53, Klaus Darilion via bind-users  >> us...@lists.isc.org> wrote:
> >>>
> >>>
> >>>>
> >>>> -Ursprüngliche Nachricht-
> >>>> Von: bind-users  Im Auftrag von
> Evan
> >>>> Hunt
> >>>> Gesendet: Samstag, 7. August 2021 20:21
> >>>> An: Gaurav Kansal 
> >>>> Cc: bind-users@lists.isc.org
> >>>> Betreff: Re: Does BIND supports ANAME RR
> >>>>
> >>>>>> On Sat, Aug 07, 2021 at 11:05:51PM +0530, Gaurav Kansal wrote:
> >>>>>> I need the help in figuring out whether BIND supports ANAME ? If
> yes,
> >>>>>> then from which version on wards ?
> >>>>>
> >>>>> No, it doesn't. The effort to standardize ANAME stalled, and I doubt
> >>>>> it'll be coming back.
> >>>>>
> >>>>> The new HTTPS and SVCB records look like a better approach anyway.
> >>>>> BIND will have support for those pretty soon.
> >>>
> >>> But honestly SVCB will not solve the ANAME problem. I will take years
> until
> >> all resolvers/client would support SVCB whereas ANAME would be
> >> implemented in the authoritative name server and hence would work for
> >> every client/resolver as client/resolver never sees the ANAME but only the
> >> A/ record.
> >>>
> >>> regards
> >>> 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
___
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: Deprecating auto-dnssec and inline-signing in 9.18+

[Klaus Darilion via bind-users]

Hi Matthijs!

> We would like to encourage you to change your configurations to
> 'dnssec-policy'. See this KB article for migration help:
> 
>  https://kb.isc.org/docs/dnssec-key-and-signing-policy

Some comments to this KB article and dnssec-policy:

- The article should mention how to retrieve the DS record from Bind.
- How does Bind handle duplicate keyids when generating new keys? Will Bind 
ensure that there will not be any duplicate key ideas or will it just use the 
duplicate keys? In the latter case the " rndc dnssec -checkds -key 12345 ..." 
commands will be ambiguous. (From an user perspective duplicate keyids should 
be avoided)

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: Deprecating auto-dnssec and inline-signing in 9.18+

[Klaus Darilion via bind-users]

> On 10-08-2021 13:38, Klaus Darilion wrote:
> > Hi Matthijs!
> >
> >> We would like to encourage you to change your configurations to
> >> 'dnssec-policy'. See this KB article for migration help:
> >>
> >> https://kb.isc.org/docs/dnssec-key-and-signing-policy
> >
> > Some comments to this KB article and dnssec-policy:
> >
> > - The article should mention how to retrieve the DS record from
> > Bind.
> 
> I am not sure what you are asking. Do you mean how to convert the DS
> from the DNSKEY record so you can submit it to the registrar?

Yes. By reading this KB I do not know how the user will be informed which DS 
(or DNSKEY) must be submitted to the parent zone. I know you to convert a 
DNSKEY to DS, but IMO the KB is very good but missest hat point.

> > - How does Bind handle duplicate keyids when generating new keys?
> > Will Bind ensure that there will not be any duplicate key ideas or
> > will it just use the duplicate keys? In the latter case the " rndc
> > dnssec -checkds -key 12345 ..." commands will be ambiguous. (From an
> > user perspective duplicate keyids should be avoided)
> 
> BIND will check for key id collision. When a conflict (for the same
> algorithm) is detected a new key will be generated.

Thanks for the info, could be mentioned somewhere
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: Bind 9, dnssec, and .key .private files physical deletion after the key id becomes deleted from zone (the key becomes outdated)

[Klaus Darilion via bind-users]

IIRC, Bind needs the key as long as there are signatures in the zone generated 
by this key. After key deactivation I waited the RRSIG lifetime before deleting 
them.

regards
Klaus

Von: bind-users  Im Auftrag von egoitz--- via 
bind-users
Gesendet: Montag, 24. Jänner 2022 13:00
An: bind-users@lists.isc.org
Betreff: Bind 9, dnssec, and .key .private files physical deletion after the 
key id becomes deleted from zone (the key becomes outdated)


Good morning,



I have a DNSSEC "bump in wire" server, which uses "inline-signing yes;"  and 
"auto-dnssec maintain;" for that reason.

I do the task of ensuring always are valid keys in the zone with an script that 
generates them whenever is needed. All fine until here and all working.

I have seen, that Bind logs in messages log file sometimes the following error 
logs :



dns_dnssec_keylistfromrdataset: error reading 
/xxx/xxx/xxx/xx-domain/named.aaa/aaa.xx.+008+41919.private: file not found



That "file not found" is due to a rename of ".key" and ".private" files to 
".key-OLD" and ".private-OLD".

I did the rename, because I have seen that the ZSK key 41919 was set to be 
deleted (and obviously always renamed after that deletion date) from the zone, 
so I renamed the ".key" and ".private" files to ".key-OLD" and ".private-OLD".

I do this rename, because this way my key checking script differentiates, any 
needed (in effect) key with the "supposedly" (I say supposedly because I would 
have said that Bind should not be using nowadays that non finding files for 
nothing!) non needed keys, in order to check that each zone, has always the 
needed keys for keeping properly signed by Bind (else it would generate them).

As I previously commented, I check with a script the existence of all needed 
keys for each domain. Obviuosly, it's not the same checking a couple of ZSK or 
just one ZSK and a KSK (per domain), than them plus all outdated keys that each 
month become outdated.

So, how many time should I wait in order to rename that files?. Should I handle 
them with another dnssec-__ command instead of renaming?. All seems to be 
working well but I see these errors and was wondering if I could improve the 
way of handling outdated keys.

I have been taking a look at the source code of Bind (the tag of version I'm 
using), and I have seen that Bind seems not remove any of that key files when 
they become outdated. Or does it with some param?. I have not been able to find 
it. I have been taking a look too the ARM, but still no luck on finding the 
answers I was trying to.



Any help very appreciated,

Best regards,
___
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: all resource record types and examples

[Klaus Darilion via bind-users]

As I have such a zone I will paste it here. But fore sure it is not complete as 
it was created some time ago.
regards
Klaus


$ cat types.test
$TTL 60 ; 1 minute
@   IN SOA  sec1.rcode0.net. rcodezero.ipcom.at. (
36   ; serial
1200   ; refresh (20 minutes)
3600   ; retry (1 hour)
604800 ; expire (1 week)
60; minimum (1 minutes)
)

@   NS  ns3.example.com.

A   IN  A   127.0.0.1
IN  2000::1
AFSDB   IN  AFSDB   1 afs.example.com.
ALIAS   IN  TYPE65401 \# 12 0377036E696302617400
CAA IN  CAA 128 issue "letsencrypt.org"
CDNSKEY IN  CDNSKEY 256 3 8 
AwEAAff+pyxoKgbxjywWKXe+sUkoygZpVvZubhpNCHVf727CwezWaXOMGg62Lz+ijAi2u7MNRN+LJtaleewNMAGJ+fx6GTn3pSgZjyI+J+YdWD+8dORyuag1rQ+04i/LjJpEtO/PNOoD7Pz1FQlLxzx36Vd/nSQSZbEZiLXCf3LDsjKTwWhRLnt85VOKcFylplFAhUoLRkQpOD/A3eZR7lL6Z5RijN+ii+DtPorzFbFmd0de/VPTwEK6l1f8FsfONBzzTQ==
CDS IN  CDS 49189 5 1 97d6d9dd5afa5ebe258e2c3631fed338ca613f9d
CERTIN  CERT6 0 0 
FGOzZ3SxhaY/J5YoupAK6P7+u74waHR0cDovL3BrYS5rbGVlbi5jaC9nbnVwZy5hc2M=
CNAME   IN  CNAME   cname.example.com.
DNAME   IN  DNAME   dname.example.com.
DNSKEY  IN  DNSKEY  256 3 8 
AwEAAff+pyxoKgbxjywWKXe+sUkoygZpVvZubhpNCHVf727CwezWaXOMGg62Lz+ijAi2u7MNRN+LJtaleewNMAGJ+fx6GTn3pSgZjyI+J+YdWD+8dORyuag1rQ+04i/LjJpEtO/PNOoD7Pz1FQlLxzx36Vd/nSQSZbEZiLXCf3LDsjKTwWhRLnt85VOKcFylplFAhUoLRkQpOD/A3eZR7lL6Z5RijN+ii+DtPorzFbFmd0de/VPTwEK6l1f8FsfONBzzTQ==
DS  IN  DS  49189 5 1 97d6d9dd5afa5ebe258e2c3631fed338ca613f9d
HINFO   IN  HINFO   PC-Intel-700mhz "Redhat Linux 7.1"
LOC IN  LOC 48 11 6.400 N 16 20 0.200 E 190.00m 1.00m 100.00m 10.00m
MB  IN  MB  mb.example.com.
MX  IN  MX  10 mail.example.com.
NAPTR   IN  NAPTR   0 0 "S" "SIP+D2U" "" _sip._udp.videogw.example.net.
NAPTR   IN  NAPTR   1 0 "S" "SIP+D2U" "" _sip._tcp.videogw.example.net.
NS  IN  NS  ns1.example.com.
NS  IN  NS  ns2.example.com.
OPENPGPKEY IN   OPENPGPKEY 
mQGiBEyXadoRBADTUoaVczNG3ras9/nqhHVduWDjxi0wbhMfRpciB2NK9T5YVVPqLPDtRCpso07a
PTR IN  PTR ptr.example.com.
RP  IN  RP  serveradmin.example.at. serveradmin.example.at.
SMIMEA  IN  SMIMEA  0 0 1 d2abde240d7cd3ee6b4b28c54df034b9 
7983a1d16e8a410e4561cb106618e971
; SPF hatte mal einen eigenen Typ, aber laut RFC soll nur TXT verwendet werden
SPF IN  SPF "v=spf1 mx -all"
SPF IN  TXT "v=spf1 mx -all"
SRV IN  SRV 0 0 5060 vgw1.a1.net.
SSHFP   IN  SSHFP   4 1 8915504c4136d16f6c9c81d15e295b66089fa4e2
TLSAIN  TLSA3 1 1 
0eb9e66d24d72f85db53a982af5befa1e6043565b5792ba8cde2ae17c9b8d92e
TXT IN  TXT ganzkurz
TXT IN  TXT "das ist ein kurzer Text"
TXT IN  TXT "dieser TXT record ist genau 255 zeichen lang 567890 
1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 
1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 1234567890 
1234567890 1234567890 1234567890 1234567890 12345"
;TXTIN  TXT "das ist ein langer, sehr sehr sehr langer Text 50" 
"das ist ein langer, sehr sehr sehr langer Text 50" "das ist ein langer, sehr 
sehr sehr langer Text 50" "das ist ein langer, sehr sehr sehr langer Text 50" 
"das ist ein langer, sehr sehr sehr langer Text 50" "das ist ein langer, sehr 
sehr sehr langer Text300"
URIIN  URI 10 1 "ftp://ftp1.example.com/public";
WKS IN  WKS 1.1.1.1 TCP ( smtp discard rpc )



Von: bind-users  Im Auftrag von rams
Gesendet: Dienstag, 12. April 2022 14:43
An: bind-users 
Betreff: all resource record types and examples

Hi,
Greetings ...
Could someone please share all supported DNS RRs and examples of each RR.

Regards,
Ramesh

-- 
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 did my DNS bill go up?

[Klaus Darilion via bind-users]

Hi Andrew!

DNSSEC is more costly: more Ressource Records to hold on disk, to hold in 
memory and more queries and more IP traffic. If the DNSSEC signing is also done 
by the DNS provider there would be additional ressources for the signing 
service and risks when doing something wrong.

For a single domain, these additional ressources for DNSSEC would be 
neglectable, if you have 1 mio Zones signed or unsigned it makes a hughe 
difference to the DNS provider. So, yes, DNSSEC costs additional ressources, 
and depending on the business model of the DNS provider he will charge you for 
that (although everybody expects security to be for free)

regards
Klaus

> -Ursprüngliche Nachricht-
> Von: bind-users  Im Auftrag von Andrew
> P.
> Gesendet: Donnerstag, 14. April 2022 14:23
> An: bind-users@lists.isc.org
> Betreff: Why did my DNS bill go up?
> 
> Greetings, all.
> 
> I had a surprise on the bill from my secondary DNS provider after I turned on
> DNSSEC. The number of record queries on my domains increased by a factor
> of about 5, compared to the number of record queries when I didn't have
> DNSSEC. Is this normal for DNSSEC? It's been a consistent significantly higher
> query level since deploying DNSSEC 3 months ago on 2 small domains (total
> of 120 records across the two domains), and it was 57 new RRSIG, DNSKEY,
> and NSEC3PARAM records added the domains for the DNSSEC.
> 
> The average number of attacks per day on my webserver (according to the
> server logs) does not appear to have increased since the DNSSEC
> deployment.
> 
> This is for the ka2ddo.org and ka2ddo.radio domains.
> 
> So, is DNSSEC really that much more costly in terms of queries?
> 
> Andrew Pavlin
> --
> 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
-- 
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: High memory consumption in bind 9.18.2

[Klaus Darilion via bind-users]

I remember we had similar issues with 9.18 (isc ppa packages) and hence wen't 
back to 9.16. But I can not remember the details.

regards
Klaus

> -Ursprüngliche Nachricht-
> Von: bind-users  Im Auftrag von Ondrej
> Surý
> Gesendet: Mittwoch, 18. Mai 2022 08:37
> An: Raman kumar 
> Cc: bind-users@lists.isc.org
> Betreff: Re: High memory consumption in bind 9.18.2
> 
> You did not provided any details, so we can’t really help you.
> 
> What is “RAM consumption” anyway? VSZ, RSS, numbers pulled from stats
> channel from named?
> 
> What’s the hardware, what is the configuration, how was BIND 9 compiled
> (or packaged)?
> 
> The more details, the better
> 
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@isc.org
> 
> My working hours and your working hours may be different. Please do not
> feel obligated to reply outside your normal working hours.
> 
> > On 18. 5. 2022, at 8:32, Raman kumar 
> wrote:
> >
> > Hello Team,
> >
> > While upgrading from BIND 9.16.10 to 9.18.2, we have observed high
> memory consumption.
> >
> > On version 9.16.2, RAM consumption was 3.8 GB. And on 9.18.2, RAM
> consumption is 4.5 GB. Due to this an increase of approximately 20 %
> memory is observed.
> >
> > Is this the expected behaviour or any tuning is needed?
> >
> > Thanks in advance.
> >
> > Regards,
> > Raman
> > --
> > 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

-- 
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: High memory consumption in bind 9.18.2

[Klaus Darilion via bind-users]

Can you please provide some commands whose output you are interested? I want to 
collect the statistics for 9.16 before updating to 9.18.
Thanks
Klaus

> -Ursprüngliche Nachricht-
> Von: bind-users  Im Auftrag von Petr
> Špacek
> Gesendet: Mittwoch, 18. Mai 2022 18:20
> An: bind-users@lists.isc.org
> Betreff: Re: AW: High memory consumption in bind 9.18.2
> 
> I would be very interested in hearing more!
> 
> In majority of our internal testing 9.16 has higher memory consumption
> than 9.18, especially when 9.18 is compiled with libjemalloc. And the
> differences are not small, for some configurations it can be even 2x or
> 3x more on 9.16 than it is on 9.18.
> 
> If you encounter it again please get back to us so we can diagnose it.
> 
> Thank you!
> Petr Špaček
> 
> 
> On 18. 05. 22 8:56, Klaus Darilion via bind-users wrote:
> > I remember we had similar issues with 9.18 (isc ppa packages) and hence
> wen't back to 9.16. But I can not remember the details.
> >
> > regards
> > Klaus
> >
> >> -Ursprüngliche Nachricht-
> >> Von: bind-users  Im Auftrag von
> Ondrej
> >> Surý101 71 l t1h, 18. Mai 2022 08:37
> >> An: Raman kumar 
> >> Cc: bind-users@lists.isc.org
> >> Betreff: Re: High memory consumption in bind 9.18.2
> >>
> >> You did not provided any details, so we can’t really help you.
> >>
> >> What is “RAM consumption” anyway? VSZ, RSS, numbers pulled from
> stats
> >> channel from named?
> >>
> >> What’s the hardware, what is the configuration, how was BIND 9 compiled
> >> (or packaged)?
> >>
> >> The more details, the better
> >>
> >> Ondrej
> >> --
> >> Ondřej Surý (He/Him)
> >> ond...@isc.org
> >>
> >> My working hours and your working hours may be different. Please do
> not
> >> feel obligated to reply outside your normal working hours.
> >>
> >>> On 18. 5. 2022, at 8:32, Raman kumar 
> >> wrote:
> >>>
> >>> Hello Team,
> >>>
> >>> While upgrading from BIND 9.16.10 to 9.18.2, we have observed high
> >> memory consumption.
> >>>
> >>> On version 9.16.2, RAM consumption was 3.8 GB. And on 9.18.2, RAM
> >> consumption is 4.5 GB. Due to this an increase of approximately 20 %
> >> memory is observed.
> >>>
> >>> Is this the expected behaviour or any tuning is needed?
> >>>
> >>> Thanks in advance.
> >>>
> >>> Regards,
> >>> Raman
> >>> --
> >>> 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
> >
> 
> 
> --
> Petr Špaček
> --
> 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
-- 
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: High memory consumption in bind 9.18.2

[Klaus Darilion via bind-users]

Hi Petr!

Thanks for the commands. But it seems I do not need them. I have updated 2 of 
our RcodeZero nameservers and on both servers the memory consumption is now 
lower than it was with 9.16. So I am not sure any more if memory was the 
problem why we went back to 9.16. I will check again in a few days.

Meanwhile I think the problem with 9.18 was a different one: we use bind as 
"distribution" name server with several hughe zones. So XFR from customer in, 
and XRF out to 20+ slaves. When we upgraded to 9.18, suddenly the slaves (Bind, 
Nsd...) needed longer to update their zones. As we did not had time to 
investigate we went back to 9.16 and suddenly slaves updated fast again. If 
this is still an issue we will see when we upgrade our distribution master to 
9.18 and if yes, I will start another thread.

Thanks
Klaus

> -Ursprüngliche Nachricht-
> Von: Petr Špaček 
> Gesendet: Donnerstag, 19. Mai 2022 12:22
> An: Klaus Darilion 
> Cc: bind-users@lists.isc.org
> Betreff: Re: High memory consumption in bind 9.18.2
> 
> On 18. 05. 22 22:39, Ondřej Surý wrote:
> > Hi Klarstein,
> >
> > Gathering the output of named statschannel should be good enough for
> initial assessment (json please).
> >
> > For 9.18, make sure the jemalloc is being used at runtime.
> 
> Here are commands you asked for:
> 
> 1. when running ./configure, make sure the output at the end has this:
> 
> Configuration summary:
> ---
> Optional features enabled:
>  Memory allocator: jemalloc
> 
> 
> 2. Then, configure statistics channel in named.conf like this:
> 
> statistics-channels {
>   inet 127.0.0.1 port 8080;
> };
> 
> 
> 3. With that in place you can grab stats from this URL:
> http://127.0.0.1:8080/json/v1
> 
> Configuration for v9.16 is the same, just skip the jemalloc part.
> 
> 4. Bonus points for grabbing /proc//statm content at the same time
> as content of the JSON stats endpoint (if you are on Linux).
> 
> I hope it helps.
> Petr Špaček
> 
> 
> 
> >
> > 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 18. 5. 2022, at 22:32, Klaus Darilion via bind-users  us...@lists.isc.org> wrote:
> >>
> >> Can you please provide some commands whose output you are
> interested? I want to collect the statistics for 9.16 before updating to 9.18.
> >> Thanks
> >> Klaus
> >>
> >>> -Ursprüngliche Nachricht-
> >>> Von: bind-users  Im Auftrag von Petr
> >>> Špacek
> >>> Gesendet: Mittwoch, 18. Mai 2022 18:20
> >>> An: bind-users@lists.isc.org
> >>> Betreff: Re: AW: High memory consumption in bind 9.18.2
> >>>
> >>> I would be very interested in hearing more!
> >>>
> >>> In majority of our internal testing 9.16 has higher memory consumption
> >>> than 9.18, especially when 9.18 is compiled with libjemalloc. And the
> >>> differences are not small, for some configurations it can be even 2x or
> >>> 3x more on 9.16 than it is on 9.18.
> >>>
> >>> If you encounter it again please get back to us so we can diagnose it.
> >>>
> >>> Thank you!
> >>> Petr Špaček
> >>>
> >>>
> >>>> On 18. 05. 22 8:56, Klaus Darilion via bind-users wrote:
> >>>> I remember we had similar issues with 9.18 (isc ppa packages) and
> hence
> >>> wen't back to 9.16. But I can not remember the details.
> >>>>
> >>>> regards
> >>>> Klaus
> >>>>
> >>>>> -Ursprüngliche Nachricht-
> >>>>> Von: bind-users  Im Auftrag von
> >>> Ondrej
> >>>>> Surý101 71 l t1h, 18. Mai 2022 08:37
> >>>>> An: Raman kumar 
> >>>>> Cc: bind-users@lists.isc.org
> >>>>> Betreff: Re: High memory consumption in bind 9.18.2
> >>>>>
> >>>>> You did not provided any details, so we can’t really help you.
> >>>>>
> >>>>> What is “RAM consumption” anyway? VSZ, RSS, numbers pulled from
> >>> stats
> >>>>> channel from named?
> >>>>>
> >>>>> What’s the hardware, what is the configuration, how was BIND 9
> compiled
> >>>>> (or packaged)?
> >>>>>
> >>>>>

AW: BIND 9.18.6 disables RSASHA1 at runtime?

[Klaus Darilion via bind-users]

> Can you propose log line?
> 
> Should it be one line per algorithm? Or one line with all disabled? Or
> one one with all enabled? What log level? Log category? It it okay it
> will be almost always logging GOST? ...

I am not using Red Hat, but when debugging DNSSEC issues it would be helpful to 
have:
a) a single logline mentioning all supported algorithms at "info" level
b) a dedicate logline mentioning that SHA1 is not available and SHA1 signed 
zones will be downgraded to "unsigned", at "warn" level

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

Is there an rndc command to get the list of configured zones?

[Klaus Darilion via bind-users]

I checked all options of rndc to get the list of zones configured/served by 
bind - but I can't find any.
Is it really not possible to get this list from a running Bind process?

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

[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

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

[Klaus Darilion via bind-users]

Am 14.07.2018 um 00:38 schrieb Matthew Pounsett:
> On 13 July 2018 at 06:04, Michał Kępień  wrote:
> 
>> Hopefully this will shed some light on the matter:
>>
>> https://gitlab.isc.org/isc-projects/bind9/issues/339#note_12805
>>
>> That is helpful, thanks.  That comment says the issue requires a journal
> entry of over 4G, however the original bug report indicates it was
> triggered by a 1.6GiB IXFR.   But then I suppose there's not a 1:1
> relationship between the size of the zone transfer and the size of the
> journal entry.

The journal increases over time until it reaches "max-journal-size"
which will trigger a journal clean-up. I supsect if the journal is eg.
3G and you have an 1.6 IXFR it may crash your bind.

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: AW: Specifying NSEC3 salt with dnssec-policy

[Klaus Darilion via bind-users]

> > I always had the impression that dnssec-signzone is a stand-alone
> > utility and signing is done either with dnssec-signzone or with
> > Bind's dnssec-policy. Does it really work to use dnssec-signzone on a
> > zone and journal that is managed by named?
> 
> No, it doesn't work like that. You turn off automatic signing and use
> dnssec-signzone manually to sign the zone.
> 
> I was under the impression that you needed to sign a zone with a
> specific salt. dnssec-signzone can do that for you.

OK. So this is a worst-case workaround. I was hoping to find a workaround with 
still Bind9 doing all the signing automatically :)

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

Specifying NSEC3 salt with dnssec-policy

[Klaus Darilion via bind-users]

Hello!

With "auto-dnssec maintain;" I was used to specify the NSEC3 salt with 'rndc 
signing -nsec3param'. Today I used the "dnssec-policy" and I failed to specify 
the salt manually. Are there any tricks/workarounds to manually specify the 
NSEC3 salt?

I know that actually the salt should be "-" but currently I am debugging a 
NSEC3 issue in our system and in such cases I always use Bind as a reference 
how the proper NSEC3 should look like. Hence I was in need to manually set the 
salt to be similar to the production zone. Luckily I was on 9.18 and switched 
back to auto-dnssec.

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: AW: AW: Specifying NSEC3 salt with dnssec-policy

[Klaus Darilion via bind-users]

Hi Petr!

> It can be said that the interface pushes people to follow RFC 9276, i.e.
> no salt and no extra iterations.
> 
> It is an pointless exercise which only makes servers easier to DoS for
> no benefit.

I understand your decision to push people towards RFC 9276.

> Why do you need extra salt? What part of RFC 9276 does not apply to your
> situation? I'm curious!

As said I was debugging NSEC3 issues of a zone which currently uses a salt, and 
I wanted to reproduce the same hasing as those zone currently use. So I do not 
want to use a salt in production, but only in testing.

So I am fine with the workaround of doing manual signing with dnssec-signzone.

Regards
Klaus

PS: All of nic.at/RcodeZero is using RFC 9276.
-- 
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: Specifying NSEC3 salt with dnssec-policy

[Klaus Darilion via bind-users]

Hi Matthijs!

I always had the impression that dnssec-signzone is a stand-alone utility and 
signing is done either with dnssec-signzone or with Bind's dnssec-policy. Does 
it really work to use dnssec-signzone on a zone and journal that is managed by 
named?

Regards
Klaus

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

> -Ursprüngliche Nachricht-
> Von: bind-users  Im Auftrag von
> Matthijs Mekking
> Gesendet: Dienstag, 1. Oktober 2024 08:49
> An: bind-users@lists.isc.org
> Betreff: Re: Specifying NSEC3 salt with dnssec-policy
> 
> Hi Klaus,
> 
> With dnssec-policy you can specify the salt length, not a specific salt.
> 
> You can still use dnssec-signzone -3 to manually set a salt.
> 
> Best regards,
> 
> Matthijs
> 
> On 9/30/24 22:38, Klaus Darilion via bind-users wrote:
> > Hello!
> >
> > With "auto-dnssec maintain;" I was used to specify the NSEC3 salt with
> > 'rndc signing -nsec3param'. Today I used the "dnssec-policy" and I
> > failed to specify the salt manually. Are there any tricks/workarounds
> to
> > manually specify the NSEC3 salt?
> >
> > I know that actually the salt should be "-" but currently I am
> debugging
> > a NSEC3 issue in our system and in such cases I always use Bind as a
> > reference how the proper NSEC3 should look like. Hence I was in need
> to
> > manually set the salt to be similar to the production zone. Luckily I
> > was on 9.18 and switched back to auto-dnssec.
> >
> > 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
-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

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


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

RE: Bind is not using the first master for freshness checks

[Klaus Darilion via bind-users]

Hi Mark!

I read https://kb.isc.org/docs/aa-01467 especially:
"The servers are queried in turn - named moves on to the next server in the 
list if either:
  -  It is unable to get a response from the server it is currently querying 
(this might be no response or an error response).
  -  The primary being queried returns the same (or smaller) SOA than the 
secondary is currently serving.
"

I guess, the "new refresh cycle", triggered by the NOTIFY during the concurrent 
refresh/XFR, does not remember the serial of the NOTIFY.
In my case, the NOTIFY that triggered the "new refresh" contained the same 
serial as the NOTIFY that triggered the previous refresh. (So, actually the 
"new refresh" would not be needed.) As the new refresh does not find a serial 
on the primary higher than the current served serial, the "new refresh check" 
tries all configured masters, and this is causing problems as the last master 
is not responding, correct?

Wouldn't it make sense to trigger a "new refresh" only if the received NOTIFY 
has a higher serial than the one handled in the current refresh?

Regards
Klaus

> -Original Message-
> From: Mark Andrews 
> Sent: Thursday, November 21, 2024 12:26 AM
> To: Klaus Darilion 
> Cc: bind-users@lists.isc.org
> Subject: Re: Bind is not using the first master for freshness checks
> 
> If a notify comes in while refresh / transfer is in progress that is noted 
> and a
> new
> refresh cycle is started when the current refresh cycle / transfer completes.
> 
> Note named is NOT logging every refresh attempt.  It is logging refresh
> attempt FAILURES
> so you know what to fix.
> 
> Mark
> 
> > On 21 Nov 2024, at 00:27, Klaus Darilion via bind-users  us...@lists.isc.org> wrote:
> >
> > Hello!
> >  Version: 9.18.30-1+ubuntu24.04.1+deb.sury.org+1
> >  masters {
> > AA.BB.4.13 key rcodezero;
> > 2xxx:xxx:9c:2031::4 key rcodezero;
> > AA.BB.6.13 key rcodezero;
> > 2xxx:xxx:40:2031::4 key rcodezero;
> > };
> >  For some reason, the last 2 IP addresses are currently not responding to
> requests. Nevertheless our Bind secondary tries to contact them. That
> confuses me, as I read quite some time that a NOTIFY (regardless of the 
> src-IP)
> just triggers a freshness check and during the freshness check, Bind uses the
> configured masters in the order of the configuration.
> >  Here is a log excerpt:
> >  10:47:48 zone redacted/IN: transferred serial 1106744096: TSIG
> 'rcodezero'
> > 10:47:48 transfer of 'redacted/IN' from AA.BB.4.13#53: Transfer status:
> success
> > 10:47:48 transfer of 'redacted/IN' from AA.BB.4.13#53: Transfer
> completed: 1 messages, 60 records, 9138 bytes, 0.026 secs (351461
> bytes/sec) (serial 1106744096)
> > 10:47:48 zone redacted/IN: sending notifies (serial 1106744096)
> >  10:47:53 zone redacted/IN: notify from AA.BB.4.13#49819: serial
> 1106744098: refresh in progress, refresh check queued
> > 10:47:53 zone redacted/IN: notify from 2xxx:xxx:9c:2031::4#32880: serial
> 1106744098: refresh in progress, refresh check queued
> > 10:47:53 zone redacted/IN: notify from 2xxx:xxx:40:2031::4#48244: serial
> 1106744098: refresh in progress, refresh check queued
> > 10:47:53 zone redacted/IN: notify from 2xxx:xxx:40:2031::4#48244: serial
> 1106744098: refresh in progress, refresh check queued
> > 10:47:58 zone redacted/IN: notify from AA.BB.4.13#49819: serial
> 1106744099: refresh in progress, refresh check queued
> > 10:47:58 zone redacted/IN: notify from 2xxx:xxx:9c:2031::4#36818: serial
> 1106744099: refresh in progress, refresh check queued
> > 10:47:58 zone redacted/IN: notify from 2xxx:xxx:40:2031::4#48244: serial
> 1106744099: refresh in progress, refresh check queued
> > 10:47:58 zone redacted/IN: notify from 2xxx:xxx:40:2031::4#48244: serial
> 1106744099: refresh in progress, refresh check queued
> > 10:48:03 zone redacted/IN: notify from AA.BB.4.13#49819: serial
> 1106744100: refresh in progress, refresh check queued
> > 10:48:03 zone redacted/IN: notify from 2xxx:xxx:9c:2031::4#56591: serial
> 1106744100: refresh in progress, refresh check queued
> > 10:48:03 zone redacted/IN: notify from 2xxx:xxx:40:2031::4#48244: serial
> 1106744101: refresh in progress, refresh check queued
> > 10:48:03 zone redacted/IN: notify from 2xxx:xxx:40:2031::4#48244: serial
> 1106744101: refresh in progress, refresh check queued
> > 10:48:08 zone redacted/IN: notify from AA.BB.4.13#49819: serial
> 1106744101: refresh in progress, refresh check queued
> > 10:48:08 zone redacted/IN: notify from 2xxx:xxx:9c

Inconsistent Logging of zone name

[Klaus Darilion via bind-users]

Hi!

Sometimes it is hard to grep the logs for a certain zone, as sometimes the zone 
name is within single quotation marks, sometimes not. For example:
zone at/IN: Transfer started.
transfer of 'at/IN' from ...
zone at/IN: transferred ...
transfer of 'at/IN' from ...
transfer of 'at/IN' from ...
zone at/IN: sending notifies (serial 1732525202)

Can I file a feature request to harmonize that? Or is there some trick? As far 
as I see, structured logging available is not available.

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

Bind is not using the first master for freshness checks

[Klaus Darilion via bind-users]

Hello!

Version: 9.18.30-1+ubuntu24.04.1+deb.sury.org+1

masters {
AA.BB.4.13 key rcodezero;
2xxx:xxx:9c:2031::4 key rcodezero;
AA.BB.6.13 key rcodezero;
2xxx:xxx:40:2031::4 key rcodezero;
};

For some reason, the last 2 IP addresses are currently not responding to 
requests. Nevertheless our Bind secondary tries to contact them. That confuses 
me, as I read quite some time that a NOTIFY (regardless of the src-IP) just 
triggers a freshness check and during the freshness check, Bind uses the 
configured masters in the order of the configuration.

Here is a log excerpt:

10:47:48 zone redacted/IN: transferred serial 1106744096: TSIG 'rcodezero'
10:47:48 transfer of 'redacted/IN' from AA.BB.4.13#53: Transfer status: success
10:47:48 transfer of 'redacted/IN' from AA.BB.4.13#53: Transfer completed: 1 
messages, 60 records, 9138 bytes, 0.026 secs (351461 bytes/sec) (serial 
1106744096)
10:47:48 zone redacted/IN: sending notifies (serial 1106744096)

10:47:53 zone redacted/IN: notify from AA.BB.4.13#49819: serial 1106744098: 
refresh in progress, refresh check queued
10:47:53 zone redacted/IN: notify from 2xxx:xxx:9c:2031::4#32880: serial 
1106744098: refresh in progress, refresh check queued
10:47:53 zone redacted/IN: notify from 2xxx:xxx:40:2031::4#48244: serial 
1106744098: refresh in progress, refresh check queued
10:47:53 zone redacted/IN: notify from 2xxx:xxx:40:2031::4#48244: serial 
1106744098: refresh in progress, refresh check queued
10:47:58 zone redacted/IN: notify from AA.BB.4.13#49819: serial 1106744099: 
refresh in progress, refresh check queued
10:47:58 zone redacted/IN: notify from 2xxx:xxx:9c:2031::4#36818: serial 
1106744099: refresh in progress, refresh check queued
10:47:58 zone redacted/IN: notify from 2xxx:xxx:40:2031::4#48244: serial 
1106744099: refresh in progress, refresh check queued
10:47:58 zone redacted/IN: notify from 2xxx:xxx:40:2031::4#48244: serial 
1106744099: refresh in progress, refresh check queued
10:48:03 zone redacted/IN: notify from AA.BB.4.13#49819: serial 1106744100: 
refresh in progress, refresh check queued
10:48:03 zone redacted/IN: notify from 2xxx:xxx:9c:2031::4#56591: serial 
1106744100: refresh in progress, refresh check queued
10:48:03 zone redacted/IN: notify from 2xxx:xxx:40:2031::4#48244: serial 
1106744101: refresh in progress, refresh check queued
10:48:03 zone redacted/IN: notify from 2xxx:xxx:40:2031::4#48244: serial 
1106744101: refresh in progress, refresh check queued
10:48:08 zone redacted/IN: notify from AA.BB.4.13#49819: serial 1106744101: 
refresh in progress, refresh check queued
10:48:08 zone redacted/IN: notify from 2xxx:xxx:9c:2031::4#37105: serial 
1106744101: refresh in progress, refresh check queued
10:48:14 zone redacted/IN: notify from AA.BB.4.13#49819: serial 1106744102: 
refresh in progress, refresh check queued
10:48:14 zone redacted/IN: notify from 2xxx:xxx:9c:2031::4#36695: serial 
1106744102: refresh in progress, refresh check queued
10:48:14 zone redacted/IN: notify from 2xxx:xxx:40:2031::4#48244: serial 
1106744102: refresh in progress, refresh check queued
10:48:14 zone redacted/IN: notify from 2xxx:xxx:40:2031::4#48244: serial 
1106744102: refresh in progress, refresh check queued
10:48:18 zone redacted/IN: refresh: retry limit for primary AA.BB.6.13#53 
exceeded (source 83.136.34.6#0)

So, the last inbound XFR was successful performed using the first configured 
master. Hence, that master should not be tagged as "down".

A few seconds later, the received NOTIFY is ignored with "refresh check 
queued". That is strange as nobody triggered a refresh and SOA refresh is high 
and max-refresh-time=300.
Anyway the "refresh in progress" takes very long, and after 30s the reason is 
obvious: retry limit for primary AA.BB.6.13#53 exceeded

So why is Bind using a master for refresh which is not the first in the list?

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

blocking rndc retrieve

[Klaus Darilion via bind-users]

Hello!

Sometimes (serial quirks) it is necessary to force an AXFR. The "rndc retrieve" 
only queues the request, so I have to "tail -f" the log file to see if the AXFR 
was performed, which requires manual inspection.

I would like to have a possibility, to trigger the AXFR, and wait until the 
AXFR either succeeded or failed.

Does somebody have an idea if this is somehow possible?

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

RE: Sporadic Timeouts after upgrading to bind9.20

[Klaus Darilion via bind-users]

Hi Ondřej!

We run Ubuntu 24.04. Can you please update the dev-ppa too?

Thanks
Klaus

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

From: Ondřej Surý 
Sent: Monday, December 9, 2024 2:54 PM
To: Klaus Darilion 
Cc: Klaus Darilion via bind-users 
Subject: Re: Sporadic Timeouts after upgrading to bind9.20

Hi Klaus,

the bind-dev repository is now at 9.21.2-302-gebe0db5daad-1 as I remember
you are using Debian on the servers, right?

Could you test that version if you can see the same timeouts you've been
encountering before?

Thanks,
Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org<mailto:ond...@isc.org>

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


On 6. 12. 2024, at 0:28, Klaus Darilion 
mailto:klaus.daril...@nic.at>> wrote:

Hi Ondřej!

I can test also the development branch. I prefer deb packages (do you have 
nightly builds?), but I can fallback to make&&make install

Regards
KLaus


From: Ondřej Surý mailto:ond...@isc.org>>
Sent: Thursday, December 5, 2024 8:36 PM
To: Klaus Darilion mailto:klaus.daril...@nic.at>>
Cc: Klaus Darilion via bind-users 
mailto:bind-users@lists.isc.org>>
Subject: Re: Sporadic Timeouts after upgrading to bind9.20

Hi Klaus,

we've identified an issue in the glue cache that have been causing drops in the 
performance.

Can you test a development branch or do you need fix on top of 9.20?

Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org<mailto:ond...@isc.org>

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



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

As we still have several timeouts I downgraded our server to 9.18. If you know 
another workaround or need someone to test new version please let me know.

Thanks
Klaus

From: Klaus Darilion mailto:klaus.daril...@nic.at>>
Sent: Saturday, September 7, 2024 12:36 AM
To: Klaus Darilion mailto:klaus.daril...@nic.at>>; 
Ondřej Surý mailto:ond...@isc.org>>
Cc: Klaus Darilion via bind-users 
mailto:bind-users@lists.isc.org>>
Subject: RE: Sporadic Timeouts after upgrading to bind9.20

Correcting myself: event with { reuseport no; };  and UV_THREADPOOL_SIZE=12 
still timeouts happen, but the situation improved a lot.
Regards
Klaus

From: bind-users 
mailto:bind-users-boun...@lists.isc.org>> On 
Behalf Of Klaus Darilion via bind-users
Sent: Saturday, September 7, 2024 12:21 AM
To: Ondřej Surý mailto:ond...@isc.org>>
Cc: Klaus Darilion via bind-users 
mailto:bind-users@lists.isc.org>>
Subject: RE: Sporadic Timeouts after upgrading to bind9.20


From: Ondřej Surý mailto:ond...@isc.org>>
Sent: Friday, September 6, 2024 4:08 PM
To: Klaus Darilion mailto:klaus.daril...@nic.at>>
Cc: Petr Špaček mailto:pspa...@isc.org>>; 
bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>; Klaus Darilion via 
bind-users mailto:bind-users@lists.isc.org>>
Subject: Re: Sporadic Timeouts after upgrading to bind9.20

Are your running with options { reuseport no; };  ?

You might want to try that.

After setting reuseport no; (and UV_THREADPOOL_SIZE=12) I have not seen any 
timeouts anymore.

Anyway, this:

TID 8917:
#0  0x7b385aa6daa9 cds_lfht_destroy - 
/usr/lib/x86_64-linux-gnu/liburcu-cds.so<http://liburcu-cds.so/>.8.1.0

caught my eye. Are the zones you are hosting particularly large on GLUE?

I don’T know and I have not checked yet. One of the affected zones is .ch.  You 
could download the zone fromhttps://zonedata.switch.ch/ And they are using NSEC 
(not NSEC3 as I have written before)



Also if you have more eu-stack, can you confirm this is the pattern now?

After setting reuseport no; I do not have stack-traces any more. But if that 
would help you I can undo the workaround next week to collect traces.

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<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: BIND 9.20.4 exiting

[Klaus Darilion via bind-users]

I confirm that I hit the same crash, but had not time yet to fill a bug report 
and provide details
Regards
Klaus

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

From: Guillaume Bibaut 
Sent: Wednesday, December 18, 2024 3:34 PM
To: Ondřej Surý 
Cc: Klaus Darilion ; bind-users@lists.isc.org
Subject: Re: BIND 9.20.4 exiting

Issue has been created on gitlab.
It is marked as confidential, and its title is "BIND 9.20.4 exiting".
Everything is detailed there.

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

Hi Ondřej!

I can test also the development branch. I prefer deb packages (do you have 
nightly builds?), but I can fallback to make&&make install

Regards
KLaus


From: Ondřej Surý 
Sent: Thursday, December 5, 2024 8:36 PM
To: Klaus Darilion 
Cc: Klaus Darilion via bind-users 
Subject: Re: Sporadic Timeouts after upgrading to bind9.20

Hi Klaus,

we've identified an issue in the glue cache that have been causing drops in the 
performance.

Can you test a development branch or do you need fix on top of 9.20?

Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org<mailto:ond...@isc.org>

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


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

As we still have several timeouts I downgraded our server to 9.18. If you know 
another workaround or need someone to test new version please let me know.

Thanks
Klaus

From: Klaus Darilion mailto:klaus.daril...@nic.at>>
Sent: Saturday, September 7, 2024 12:36 AM
To: Klaus Darilion mailto:klaus.daril...@nic.at>>; 
Ondřej Surý mailto:ond...@isc.org>>
Cc: Klaus Darilion via bind-users 
mailto:bind-users@lists.isc.org>>
Subject: RE: Sporadic Timeouts after upgrading to bind9.20

Correcting myself: event with { reuseport no; };  and UV_THREADPOOL_SIZE=12 
still timeouts happen, but the situation improved a lot.
Regards
Klaus

From: bind-users 
mailto:bind-users-boun...@lists.isc.org>> On 
Behalf Of Klaus Darilion via bind-users
Sent: Saturday, September 7, 2024 12:21 AM
To: Ondřej Surý mailto:ond...@isc.org>>
Cc: Klaus Darilion via bind-users 
mailto:bind-users@lists.isc.org>>
Subject: RE: Sporadic Timeouts after upgrading to bind9.20


From: Ondřej Surý mailto:ond...@isc.org>>
Sent: Friday, September 6, 2024 4:08 PM
To: Klaus Darilion mailto:klaus.daril...@nic.at>>
Cc: Petr Špaček mailto:pspa...@isc.org>>; 
bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>; Klaus Darilion via 
bind-users mailto:bind-users@lists.isc.org>>
Subject: Re: Sporadic Timeouts after upgrading to bind9.20

Are your running with options { reuseport no; };  ?

You might want to try that.

After setting reuseport no; (and UV_THREADPOOL_SIZE=12) I have not seen any 
timeouts anymore.

Anyway, this:

TID 8917:
#0  0x7b385aa6daa9 cds_lfht_destroy - 
/usr/lib/x86_64-linux-gnu/liburcu-cds.so.8.1.0

caught my eye. Are the zones you are hosting particularly large on GLUE?

I don’T know and I have not checked yet. One of the affected zones is .ch.  You 
could download the zone fromhttps://zonedata.switch.ch/ And they are using NSEC 
(not NSEC3 as I have written before)



Also if you have more eu-stack, can you confirm this is the pattern now?

After setting reuseport no; I do not have stack-traces any more. But if that 
would help you I can undo the workaround next week to collect traces.

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<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: Binary zone file and journal compatibility between Bind9 versions

[Klaus Darilion via bind-users]

Hello Evan and Petr!
Thanks for the details.
Klaus


> -Original Message-
> From: Evan Hunt 
> Sent: Thursday, January 9, 2025 7:32 PM
> To: Klaus Darilion 
> Cc: Greg Choules via bind-users 
> Subject: Re: Binary zone file and journal compatibility between Bind9 versions
> 
> On Thu, Jan 09, 2025 at 11:40:33AM +0000, Klaus Darilion via bind-users
> wrote:
> > For testing I often up- and downgrade Bind versions, ie. Between 9.18,
> > 9.20 and 9.21. I wonder how stable the binary zone file format and
> > journal file format is, and if there are changes in the binary format, if
> > Bind would detect that and behave properly.
> >
> > I am concerned about zones that end up containing some garbage. I never
> > had any issues, but I wonder if that could happen.
> 
> So far as I can recall, raw zone file format hasn't changed.
> 
> Journal file format did change once, but the change should be detected
> and handled correctly when upgrading, and there's a tool for upgrading or
> downgrading manually if needed (named-journalprint -u and -d, respectively).
> 
> There was also a "map" file format for a while, and it was much touchier,
> but it's been removed now.
> 
> --
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.
-- 
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]

Hi Ondrey and others!

I have tested 9.20.4-3+ubuntu24.04.1+deb.sury.org+1 on one of our RcodeZero 
production nodes for 1 week and have not encountered any timeouts anymore.
XFR speed also seems fine now.

Regards
Klaus


From: Ondřej Surý 
Sent: Thursday, December 5, 2024 8:36 PM
To: Klaus Darilion 
Cc: Klaus Darilion via bind-users 
Subject: Re: Sporadic Timeouts after upgrading to bind9.20

Hi Klaus,

we've identified an issue in the glue cache that have been causing drops in the 
performance.

Can you test a development branch or do you need fix on top of 9.20?

Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org<mailto:ond...@isc.org>

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


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

As we still have several timeouts I downgraded our server to 9.18. If you know 
another workaround or need someone to test new version please let me know.

Thanks
Klaus

From: Klaus Darilion mailto:klaus.daril...@nic.at>>
Sent: Saturday, September 7, 2024 12:36 AM
To: Klaus Darilion mailto:klaus.daril...@nic.at>>; 
Ondřej Surý mailto:ond...@isc.org>>
Cc: Klaus Darilion via bind-users 
mailto:bind-users@lists.isc.org>>
Subject: RE: Sporadic Timeouts after upgrading to bind9.20

Correcting myself: event with { reuseport no; };  and UV_THREADPOOL_SIZE=12 
still timeouts happen, but the situation improved a lot.
Regards
Klaus

From: bind-users 
mailto:bind-users-boun...@lists.isc.org>> On 
Behalf Of Klaus Darilion via bind-users
Sent: Saturday, September 7, 2024 12:21 AM
To: Ondřej Surý mailto:ond...@isc.org>>
Cc: Klaus Darilion via bind-users 
mailto:bind-users@lists.isc.org>>
Subject: RE: Sporadic Timeouts after upgrading to bind9.20


From: Ondřej Surý mailto:ond...@isc.org>>
Sent: Friday, September 6, 2024 4:08 PM
To: Klaus Darilion mailto:klaus.daril...@nic.at>>
Cc: Petr Špaček mailto:pspa...@isc.org>>; 
bind-users@lists.isc.org<mailto:bind-users@lists.isc.org>; Klaus Darilion via 
bind-users mailto:bind-users@lists.isc.org>>
Subject: Re: Sporadic Timeouts after upgrading to bind9.20

Are your running with options { reuseport no; };  ?

You might want to try that.

After setting reuseport no; (and UV_THREADPOOL_SIZE=12) I have not seen any 
timeouts anymore.

Anyway, this:

TID 8917:
#0  0x7b385aa6daa9 cds_lfht_destroy - 
/usr/lib/x86_64-linux-gnu/liburcu-cds.so.8.1.0

caught my eye. Are the zones you are hosting particularly large on GLUE?

I don’T know and I have not checked yet. One of the affected zones is .ch.  You 
could download the zone fromhttps://zonedata.switch.ch/ And they are using NSEC 
(not NSEC3 as I have written before)



Also if you have more eu-stack, can you confirm this is the pattern now?

After setting reuseport no; I do not have stack-traces any more. But if that 
would help you I can undo the workaround next week to collect traces.

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

Binary zone file and journal compatibility between Bind9 versions

[Klaus Darilion via bind-users]

Hello!

For testing I often up- and downgrade Bind versions, ie. Between 9.18, 9.20 and 
9.21. I wonder how stable the binary zone file format and journal file format 
is, and if there are changes in the binary format, if Bind would detect that 
and behave properly.

I am concerned about zones that end up containing some garbage. I never had any 
issues, but I wonder if that could happen.

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

RE: Some operational questions about TSIG / XoT

[Klaus Darilion via bind-users]

Hi Michael!

I think you mix up two unrelated topics. One, how your name servers are 
connected together and how routing and High-Availability is managed in your 
(virtual) network. The second thing is which protocol to use for zone 
transfers. IMO they have nothing to do with each other.

For the network part, other mailing lists may be better suited,

For the DNS part, it depends on your policy, and what are the dangers you want 
to protect DNS zone transfers from. If you trust your internal network, and you 
are sure that the DNS never traverses public Internet (due to the VPN), then 
there is nothing the protect from and plain AXFR over TCP would be fine.

If you want to protect your zone transfers also internally where there is no 
VPN anymore, then you need some more:
- Protection from sniffing (e.g. your DNS data is not public, and has secrets 
inside): Then you need to use encryption on the application, i.e. XoT. Do not 
use XoT with ephemeral TLS as it is vulnerable to MITM.
- Protection from manipulation: Here you can use either TSIG (with our without 
TLS) or XoT with mutual TLS

TLS uses private and public keys for encryption and authentication, and either 
you use self-signed or public signed certificates.
TSIG uses a pre-shared key

Regards
Klaus

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

From: bind-users  On Behalf Of Michael De 
Roover
Sent: Saturday, March 8, 2025 7:36 AM
To: bind-users@lists.isc.org
Subject: Some operational questions about TSIG / XoT


Hi all,


Currently I'm reading a couple of articles about TSIG and XoT, to better 
understand how XFR between networks can be done securely. For this, I am 
currently looking at these resources:


- https://www.ietf.org/rfc/rfc9103.html

- https://dnsprivacy.org/encrypted-zone-transfer/

- https://bind9.readthedocs.io/en/stable/chapter7.html#tsig


Not directly related:

- https://kb.isc.org/docs/aa-00851#example-3-adding-a-second-server

Perhaps the footnote "Further information on TSIG" could use a re-reference to 
Chapter 7.5? Nonetheless, this is how I found the TSIG documentation.


Currently, the network configuration would be three LANs that talk to each 
other over two VPNs (WireGuard). The primary LAN has 3 name servers, 1 primary 
and 2 secondaries. Only ns1 is expected to perform XFR, maybe ns2 if need be. 
Not sure how that affects operational availability vs. security.


The secondary LAN is a more fleshed out version of a road warrior setup, it is 
what I take with me for travel. This has one or two name servers at most. Each 
of these networks has a local zone, for which it is a local primary and 
secondary for the other.


The third network is just something internal to my laptop, so it can be a child 
of either of the previous networks, or whatever else that laptop connects to 
(via double NAT).


They each communicate with each other via a gateway / set of VRRP gateways, 
over the WireGuard tunnels. During XFR receipt, the receiving DNS server sees 
the XFR as if it's coming from that local gateway. This is.. not ideal.


So that's where TSIG or XoT would come into play. So far, it seems that TSIG is 
just a signed plaintext transfer, while XoT would encapsulate the whole thing 
in TLS. Both of them seem to have their merits, but would XoT be necessary if 
WireGuard is encrypting the "public" part of the connection anyway?


Another thing I noticed in VRRP in particular, is that by default it uses 
anycast and just passes on the secret itself in plain to all network members. 
So anyone with a packet sniffer can just.. well, sniff it and pull a "look at 
me, I am the gateway now". Unicast is possible but not default and seemingly 
only for keepalived. How's the situation here with TSIG? Are the transactions 
only given a signature, or the shared secret itself?


As far as XoT is concerned, I like that it adds another layer of encryption, 
but that would have to be self-signed. Also, how's that for troubleshooting? 
I'd rather not have to deal with the pain in the rear of TLS MiTM during such 
times. So far I think I'm more inclined towards just having WireGuard deal with 
that, and leave everything else transparent to me. But any amount of anycast or 
secrets exposure would be a dealbreaker here.


What are your thoughts on this?


N.B.: I liked this note in the views article: "DNS servers are social creatures 
and like to have company, so the operator of this network has decided to add a 
second DNS server."


Your work on the ARM is amazing Suzanne, and indeed we/they are :)

--

Met vriendelijke groet,

Michael De Roover


Mail: i...@nixmagic.com

Web: michael.de.roover.eu.org
-- 
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
bin

RE: XoT Testing: TLS peer certificate verification failed

[Klaus Darilion via bind-users]

I think I have solved the mistery: Bind (or openssl, who ever does the 
validation) requires Subject Alternative Name. Regardless if using the hostname 
or the IP address, they must be in the subject alternative name. When using 
self-signed certificates, it is probably best to put both in the SAN. Using the 
following certificate on the server, the validation in dig works fine, 
regardless if using the hostname or IP address.

If somebody wants to test XoT, that might help bootstrapping:
openssl req -x509 -newkey rsa:4096 -sha256 -days 3650 -nodes -keyout 
san-private.key -out san-certificate.crt -subj 
"/CN=xot-test-primary.ops.nic.at" -addext 
"subjectAltName=DNS:xot-test-primary.ops.nic.at,IP:193.46.106.51"

regards
Klaus


From: bind-users  On Behalf Of Klaus Darilion 
via bind-users
Sent: Tuesday, March 4, 2025 11:31 AM
To: Ondřej Surý 
Cc: bind-us...@isc.org
Subject: RE: XoT Testing: TLS peer certificate verification failed

In my case it should not be SNI relevant, as the server only has 1 certificate 
to present. Anyways, I will now test with a certificate that uses the IP 
address in the Subject CN.

Regards
Klaus

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

From: Ondřej Surý mailto:ond...@isc.org>>
Sent: Tuesday, March 4, 2025 10:05 AM
To: Klaus Darilion mailto:klaus.daril...@nic.at>>
Cc: bind-us...@isc.org<mailto:bind-us...@isc.org>
Subject: Re: XoT Testing: TLS peer certificate verification failed

Sounds like this: https://gitlab.isc.org/isc-projects/bind9/-/issues/3896
--
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. 3. 2025, at 10:01, Klaus Darilion via bind-users 
mailto:bind-users@lists.isc.org>> wrote:

May it be, that the validation is just broken? Even when using dig, and 
explicitely use the hostname of the Primary (which uses its hostname in its 
certificate) in @... and tls-hostname, the verification fails due to hostname 
mismatch:

# dig @xot-test-primary.ops.nic.at test.klaus +tls axfr +tls-ca=ca.crt 
+tls-hostname=xot-test-primary.ops.nic.at +tls-certfile=certificate.crt 
+tls-keyfile=private.key
;; TLS peer certificate verification for 193.46.106.51#853 failed: hostname 
mismatch


Regards
Klaus


From: Klaus Darilion
Sent: Thursday, February 27, 2025 5:11 PM
To: Greg Choules via bind-users 
mailto:bind-users@lists.isc.org>>
Subject: XoT Testing: TLS peer certificate verification failed

Hi! I want to test XoT between Bind9.20.6 primary and secondary.

On the primary I created a self-signed certificate with 
CN=xot-test-primary.ops.nic.at and configured bind:

# Create a 10years valid self-signed certificate:
#   openssl genpkey -algorithm RSA -out private.key -pkeyopt 
rsa_keygen_bits:2048
#   openssl req -new -key private.key -out request.csr -subj 
"/CN=xot-test-primary.ops.nic.at"
#   openssl x509 -req -days 3650 -in request.csr -signkey private.key -out 
certificate.crt
#   openssl x509 -text -noout -in certificate.crt
#   chmod g+r private.key
#
# Create DH-params file to enable Diffie-Hellman Perfect Forward Secrecy:
#   openssl dhparam -out dhparam.pem 4096
#
# https://bind9.readthedocs.io/en/v9.20.6/reference.html#namedconf-statement-tls
tls xot-test {
cert-file "/etc/bind/certificate.crt";
dhparam-file "/etc/bind/dhparam.pem";
key-file  "/etc/bind/private.key";
};

options {
listen-on  { 193.46.106.51; };
listen-on-v6   { 2a02:850:1:4::51; };
listen-ontls xot-test  { 193.46.106.51; };
listen-on-v6 tls xot-test  { 2a02:850:1:4::51; };
};

That seems to work fine. Then I configured the secondary similar:
# Create a 10years valid self-signed certificate:
#   openssl genpkey -algorithm RSA -out private.key -pkeyopt 
rsa_keygen_bits:2048
#   openssl req -new -key private.key -out request.csr -subj 
"/CN=xot-test-secondary.ops.nic.at"
#   openssl x509 -req -days 3650 -in request.csr -signkey private.key -out 
certificate.crt
#   openssl x509 -text -noout -in certificate.crt
#   chmod g+r private.key
#
# Create DH-params file to enable Diffie-Hellman Perfect Forward Secrecy:
#   openssl dhparam -out dhparam.pem 4096
#
# https://bind9.readthedocs.io/en/v9.20.6/reference.html#namedconf-statement-tls
tls xot-test {
#ca-file   "/etc/bind/ca.crt";  # Activating ca-file force 
client-certificates for incoming TLS connections
cert-file "/etc/bind/certificate.crt";
dhparam-file "/etc/bind/dhparam.pem";
key-file  "/etc/bind/private.key";
#remote-hostname "xot-test-primary.ops.nic.at";
}; // may occur multiple times

zone "test.klaus" {
type secondary;
file "/var/cache/bind/test.klaus";  // Path 

RE: XoT Testing: TLS peer certificate verification failed

[Klaus Darilion via bind-users]

> -Original Message-
> From: Petr Špaček 
> Sent: Tuesday, March 4, 2025 6:11 PM
> To: Robert Wagner ; Klaus Darilion
> 
> Cc: bind-us...@isc.org
> Subject: Re: XoT Testing: TLS peer certificate verification failed
> 
> > I think I have solved the mistery: Bind (or openssl, who ever does the
> > validation) requires Subject Alternative Name. Regardless if using the
> > hostname or the IP address, they must be in the subject alternative
> > name. When using self-signed certificates, it is probably best to put
> > both in the SAN. Using the following certificate on the server, the
> > validation in dig works fine, regardless if using the hostname or IP
> > address.
> 
> The DNS-over-TLS specification insists on this behavior. See
> https://datatracker.ietf.org/doc/html/rfc8310.html#section-8.1
> 
> Quote:
> A compliant DNS client MUST only inspect the certificate's
> subjectAltName extension for the reference identifier.  In
> particular, it MUST NOT inspect the Subject field itself.

Thanks for the reference. It seems I should have read the whole RFC before 
playing around with TLS. 😊

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

RE: XoT Testing: TLS peer certificate verification failed

[Klaus Darilion via bind-users]

May it be, that the validation is just broken? Even when using dig, and 
explicitely use the hostname of the Primary (which uses its hostname in its 
certificate) in @... and tls-hostname, the verification fails due to hostname 
mismatch:

# dig @xot-test-primary.ops.nic.at test.klaus +tls axfr +tls-ca=ca.crt 
+tls-hostname=xot-test-primary.ops.nic.at +tls-certfile=certificate.crt 
+tls-keyfile=private.key
;; TLS peer certificate verification for 193.46.106.51#853 failed: hostname 
mismatch


Regards
Klaus


From: Klaus Darilion
Sent: Thursday, February 27, 2025 5:11 PM
To: Greg Choules via bind-users 
Subject: XoT Testing: TLS peer certificate verification failed

Hi! I want to test XoT between Bind9.20.6 primary and secondary.

On the primary I created a self-signed certificate with 
CN=xot-test-primary.ops.nic.at and configured bind:

# Create a 10years valid self-signed certificate:
#   openssl genpkey -algorithm RSA -out private.key -pkeyopt 
rsa_keygen_bits:2048
#   openssl req -new -key private.key -out request.csr -subj 
"/CN=xot-test-primary.ops.nic.at"
#   openssl x509 -req -days 3650 -in request.csr -signkey private.key -out 
certificate.crt
#   openssl x509 -text -noout -in certificate.crt
#   chmod g+r private.key
#
# Create DH-params file to enable Diffie-Hellman Perfect Forward Secrecy:
#   openssl dhparam -out dhparam.pem 4096
#
# https://bind9.readthedocs.io/en/v9.20.6/reference.html#namedconf-statement-tls
tls xot-test {
cert-file "/etc/bind/certificate.crt";
dhparam-file "/etc/bind/dhparam.pem";
key-file  "/etc/bind/private.key";
};

options {
listen-on  { 193.46.106.51; };
listen-on-v6   { 2a02:850:1:4::51; };
listen-ontls xot-test  { 193.46.106.51; };
listen-on-v6 tls xot-test  { 2a02:850:1:4::51; };
};

That seems to work fine. Then I configured the secondary similar:
# Create a 10years valid self-signed certificate:
#   openssl genpkey -algorithm RSA -out private.key -pkeyopt 
rsa_keygen_bits:2048
#   openssl req -new -key private.key -out request.csr -subj 
"/CN=xot-test-secondary.ops.nic.at"
#   openssl x509 -req -days 3650 -in request.csr -signkey private.key -out 
certificate.crt
#   openssl x509 -text -noout -in certificate.crt
#   chmod g+r private.key
#
# Create DH-params file to enable Diffie-Hellman Perfect Forward Secrecy:
#   openssl dhparam -out dhparam.pem 4096
#
# https://bind9.readthedocs.io/en/v9.20.6/reference.html#namedconf-statement-tls
tls xot-test {
#ca-file   "/etc/bind/ca.crt";  # Activating ca-file force 
client-certificates for incoming TLS connections
cert-file "/etc/bind/certificate.crt";
dhparam-file "/etc/bind/dhparam.pem";
key-file  "/etc/bind/private.key";
#remote-hostname "xot-test-primary.ops.nic.at";
}; // may occur multiple times

zone "test.klaus" {
type secondary;
file "/var/cache/bind/test.klaus";  // Path to your zone file

primaries  {
  193.46.106.51key "tsig-key" tls xot-test;
  2a02:850:1:4::51 key "tsig-key" tls xot-test;
};

I copied the primary's certificate.crt to the secondary as ca.crt.

Using opportunistic TLS, zone transfer works fine.

But if I enable strict TLS, either by uncommenting 'ca-file' or 
'remote-hostname' option, the TLS verification fails:

   transfer of 'test.klaus/IN' from 193.46.106.51#853: failed to connect: TLS 
peer certificate verification failed

But the setup on the primary looks fine. I can successfully open a TLS 
connection when using curl:
# curl -v https://xot-test-primary.ops.nic.at:853 --cacert ca.crt
* Host xot-test-primary.ops.nic.at:853 was resolved.
* IPv6: (none)
* IPv4: 193.46.106.51
*   Trying 193.46.106.51:853...
* Connected to xot-test-primary.ops.nic.at (193.46.106.51) port 853
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: ca.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / RSASSA-PSS
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: CN=xot-test-primary.ops.nic.at
*  start date: Feb 27 14:02:56 2025 GMT
*  expire date: Feb 25 14:02:56 2035 GMT
*  common name: xot-test-primary.ops.nic.at (matched)
*  issuer: CN=xot-test-primary.ops.nic.at
*  SSL certificate verify ok.
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed 
using sha256WithRSAEncryption


So, what am I doing wrong? Is Bind using a not-trivial TLS certificate 
verification? I also failed getting more verbose verification details. Any help 
is appreciated.

Thanks

RE: XoT Testing: TLS peer certificate verification failed

[Klaus Darilion via bind-users]

In my case it should not be SNI relevant, as the server only has 1 certificate 
to present. Anyways, I will now test with a certificate that uses the IP 
address in the Subject CN.

Regards
Klaus

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

From: Ondřej Surý 
Sent: Tuesday, March 4, 2025 10:05 AM
To: Klaus Darilion 
Cc: bind-us...@isc.org
Subject: Re: XoT Testing: TLS peer certificate verification failed

Sounds like this: https://gitlab.isc.org/isc-projects/bind9/-/issues/3896
--
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. 3. 2025, at 10:01, Klaus Darilion via bind-users 
mailto:bind-users@lists.isc.org>> wrote:

May it be, that the validation is just broken? Even when using dig, and 
explicitely use the hostname of the Primary (which uses its hostname in its 
certificate) in @... and tls-hostname, the verification fails due to hostname 
mismatch:

# dig @xot-test-primary.ops.nic.at test.klaus +tls axfr +tls-ca=ca.crt 
+tls-hostname=xot-test-primary.ops.nic.at +tls-certfile=certificate.crt 
+tls-keyfile=private.key
;; TLS peer certificate verification for 193.46.106.51#853 failed: hostname 
mismatch


Regards
Klaus


From: Klaus Darilion
Sent: Thursday, February 27, 2025 5:11 PM
To: Greg Choules via bind-users 
mailto:bind-users@lists.isc.org>>
Subject: XoT Testing: TLS peer certificate verification failed

Hi! I want to test XoT between Bind9.20.6 primary and secondary.

On the primary I created a self-signed certificate with 
CN=xot-test-primary.ops.nic.at and configured bind:

# Create a 10years valid self-signed certificate:
#   openssl genpkey -algorithm RSA -out private.key -pkeyopt 
rsa_keygen_bits:2048
#   openssl req -new -key private.key -out request.csr -subj 
"/CN=xot-test-primary.ops.nic.at"
#   openssl x509 -req -days 3650 -in request.csr -signkey private.key -out 
certificate.crt
#   openssl x509 -text -noout -in certificate.crt
#   chmod g+r private.key
#
# Create DH-params file to enable Diffie-Hellman Perfect Forward Secrecy:
#   openssl dhparam -out dhparam.pem 4096
#
# https://bind9.readthedocs.io/en/v9.20.6/reference.html#namedconf-statement-tls
tls xot-test {
cert-file "/etc/bind/certificate.crt";
dhparam-file "/etc/bind/dhparam.pem";
key-file  "/etc/bind/private.key";
};

options {
listen-on  { 193.46.106.51; };
listen-on-v6   { 2a02:850:1:4::51; };
listen-ontls xot-test  { 193.46.106.51; };
listen-on-v6 tls xot-test  { 2a02:850:1:4::51; };
};

That seems to work fine. Then I configured the secondary similar:
# Create a 10years valid self-signed certificate:
#   openssl genpkey -algorithm RSA -out private.key -pkeyopt 
rsa_keygen_bits:2048
#   openssl req -new -key private.key -out request.csr -subj 
"/CN=xot-test-secondary.ops.nic.at"
#   openssl x509 -req -days 3650 -in request.csr -signkey private.key -out 
certificate.crt
#   openssl x509 -text -noout -in certificate.crt
#   chmod g+r private.key
#
# Create DH-params file to enable Diffie-Hellman Perfect Forward Secrecy:
#   openssl dhparam -out dhparam.pem 4096
#
# https://bind9.readthedocs.io/en/v9.20.6/reference.html#namedconf-statement-tls
tls xot-test {
#ca-file   "/etc/bind/ca.crt";  # Activating ca-file force 
client-certificates for incoming TLS connections
cert-file "/etc/bind/certificate.crt";
dhparam-file "/etc/bind/dhparam.pem";
key-file  "/etc/bind/private.key";
#remote-hostname "xot-test-primary.ops.nic.at";
}; // may occur multiple times

zone "test.klaus" {
type secondary;
file "/var/cache/bind/test.klaus";  // Path to your zone file

primaries  {
  193.46.106.51key "tsig-key" tls xot-test;
  2a02:850:1:4::51 key "tsig-key" tls xot-test;
};

I copied the primary’s certificate.crt to the secondary as ca.crt.

Using opportunistic TLS, zone transfer works fine.

But if I enable strict TLS, either by uncommenting ‘ca-file’ or 
‘remote-hostname’ option, the TLS verification fails:

   transfer of 'test.klaus/IN' from 193.46.106.51#853: failed to connect: TLS 
peer certificate verification failed

But the setup on the primary looks fine. I can successfully open a TLS 
connection when using curl:
# curl -v https://xot-test-primary.ops.nic.at:853 --cacert ca.crt
* Host xot-test-primary.ops.nic.at:853 was resolved.
* IPv6: (none)
* IPv4: 193.46.106.51
*   Trying 193.46.106.51:853...
* Connected to xot-test-primary.ops.nic.at (193.46.106.51) port 853
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: ca.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server h

XoT Testing: TLS peer certificate verification failed

[Klaus Darilion via bind-users]

Hi! I want to test XoT between Bind9.20.6 primary and secondary.

On the primary I created a self-signed certificate with 
CN=xot-test-primary.ops.nic.at and configured bind:

# Create a 10years valid self-signed certificate:
#   openssl genpkey -algorithm RSA -out private.key -pkeyopt 
rsa_keygen_bits:2048
#   openssl req -new -key private.key -out request.csr -subj 
"/CN=xot-test-primary.ops.nic.at"
#   openssl x509 -req -days 3650 -in request.csr -signkey private.key -out 
certificate.crt
#   openssl x509 -text -noout -in certificate.crt
#   chmod g+r private.key
#
# Create DH-params file to enable Diffie-Hellman Perfect Forward Secrecy:
#   openssl dhparam -out dhparam.pem 4096
#
# https://bind9.readthedocs.io/en/v9.20.6/reference.html#namedconf-statement-tls
tls xot-test {
cert-file "/etc/bind/certificate.crt";
dhparam-file "/etc/bind/dhparam.pem";
key-file  "/etc/bind/private.key";
};

options {
listen-on  { 193.46.106.51; };
listen-on-v6   { 2a02:850:1:4::51; };
listen-ontls xot-test  { 193.46.106.51; };
listen-on-v6 tls xot-test  { 2a02:850:1:4::51; };
};

That seems to work fine. Then I configured the secondary similar:
# Create a 10years valid self-signed certificate:
#   openssl genpkey -algorithm RSA -out private.key -pkeyopt 
rsa_keygen_bits:2048
#   openssl req -new -key private.key -out request.csr -subj 
"/CN=xot-test-secondary.ops.nic.at"
#   openssl x509 -req -days 3650 -in request.csr -signkey private.key -out 
certificate.crt
#   openssl x509 -text -noout -in certificate.crt
#   chmod g+r private.key
#
# Create DH-params file to enable Diffie-Hellman Perfect Forward Secrecy:
#   openssl dhparam -out dhparam.pem 4096
#
# https://bind9.readthedocs.io/en/v9.20.6/reference.html#namedconf-statement-tls
tls xot-test {
#ca-file   "/etc/bind/ca.crt";  # Activating ca-file force 
client-certificates for incoming TLS connections
cert-file "/etc/bind/certificate.crt";
dhparam-file "/etc/bind/dhparam.pem";
key-file  "/etc/bind/private.key";
#remote-hostname "xot-test-primary.ops.nic.at";
}; // may occur multiple times

zone "test.klaus" {
type secondary;
file "/var/cache/bind/test.klaus";  // Path to your zone file

primaries  {
  193.46.106.51key "tsig-key" tls xot-test;
  2a02:850:1:4::51 key "tsig-key" tls xot-test;
};

I copied the primary's certificate.crt to the secondary as ca.crt.

Using opportunistic TLS, zone transfer works fine.

But if I enable strict TLS, either by uncommenting 'ca-file' or 
'remote-hostname' option, the TLS verification fails:

   transfer of 'test.klaus/IN' from 193.46.106.51#853: failed to connect: TLS 
peer certificate verification failed

But the setup on the primary looks fine. I can successfully open a TLS 
connection when using curl:
# curl -v https://xot-test-primary.ops.nic.at:853 --cacert ca.crt
* Host xot-test-primary.ops.nic.at:853 was resolved.
* IPv6: (none)
* IPv4: 193.46.106.51
*   Trying 193.46.106.51:853...
* Connected to xot-test-primary.ops.nic.at (193.46.106.51) port 853
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
*  CAfile: ca.crt
*  CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / RSASSA-PSS
* ALPN: server did not agree on a protocol. Uses default.
* Server certificate:
*  subject: CN=xot-test-primary.ops.nic.at
*  start date: Feb 27 14:02:56 2025 GMT
*  expire date: Feb 25 14:02:56 2035 GMT
*  common name: xot-test-primary.ops.nic.at (matched)
*  issuer: CN=xot-test-primary.ops.nic.at
*  SSL certificate verify ok.
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed 
using sha256WithRSAEncryption


So, what am I doing wrong? Is Bind using a not-trivial TLS certificate 
verification? I also failed getting more verbose verification details. Any help 
is appreciated.

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