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

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

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

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

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

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 

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

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

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

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

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

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)?
> >>>>>
> >>>>> The

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]

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

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

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

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

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

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