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

9.16 needs more RAM then 9.11

[Klaus Darilion]

Hello!

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

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

Thank
Klaus

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

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


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

AW: AXFR Problems sind Upgrade to 9.16.12

[Klaus Darilion]

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

regards
Klaus

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

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


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

AW: AXFR Problems sind Upgrade to 9.16.12

[Klaus Darilion]

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

Thanks
Klaus

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

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

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


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

AW: AXFR Problems sind Upgrade to 9.16.12

[Klaus Darilion]

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

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

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


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

AXFR Problems sind Upgrade to 9.16.12

[Klaus Darilion]

Hello!

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

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

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

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

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

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

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

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

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

Thanks
Klaus

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

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


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

AW: AW: How to prepublish additional DNSKEY

[Klaus Darilion]

Thanks - now it works.
Klaus

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

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

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

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

Have a look at "dnssec-settime".

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

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

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

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


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

AW: How to prepublish additional DNSKEY

[Klaus Darilion]

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

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

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

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

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

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


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

How to prepublish additional DNSKEY

[Klaus Darilion]

Hello all!

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

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

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

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

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

Thanks
Klaus

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

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


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

AW: NSEC3 salt change - temporary performance decline

[Klaus Darilion]

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

Great news. Thank's for the work.
Klaus
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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


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

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

[Klaus Darilion]

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

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

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

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

Have a nice day
Klaus

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

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

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

[Klaus Darilion]

Thanks for answer!

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

I will miss the bind9 service :-(

Klaus


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

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

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

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

[Klaus Darilion]

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

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

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

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

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

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

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

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

[Klaus Darilion]

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

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

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

regards
Klaus


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

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

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

[Klaus Darilion]

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

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

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

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

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

[Klaus Darilion]

Hello!

What is the rationale of:

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


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

So I really do not understand this renaming.

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

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

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

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

max-ixfr-ratio values

[Klaus Darilion]

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


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


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


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

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

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

[Klaus Darilion]

Hello all!

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

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

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

Re: NSEC3 salt change - temporary performance decline

[Klaus Darilion]

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

thanks for giving priority to this issue.

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

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

Re: NSEC3 salt change - temporary performance decline

[Klaus Darilion]

Hello Niels!

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

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

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

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

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

regards
Klaus


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


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

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

Re: BIND setup for GSLB (Global Service Load Balancing)

[Klaus Darilion]

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


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


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


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

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

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

Re: journal file is out of date: removing journal file

[Klaus Darilion]

Hi Tony!

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

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

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

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

Thanks
Klaus

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

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

journal file is out of date: removing journal file

[Klaus Darilion]

Hello!

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

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

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

Thanks
Klaus

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

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

Re: IXFR fallback to AXFR if diff is bigger than zone

[Klaus Darilion]

Hi Tony!

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

We have a setup with severals Bind in a row:

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

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

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

See log details below.

Thanks
Klaus


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


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



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

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

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

Re: Bind max socket/query per IP

[Klaus Darilion]

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


btw - how high is the "extremely load"?

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

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

Re: BIND 9.10 fast only on alias IP

[Klaus Darilion]

Am 20.05.2019 um 20:16 schrieb Ict Security:

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


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


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


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

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

Re: max file size or line count for BIND zone file

[Klaus Darilion]

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


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


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

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

Bind Auth responds slow during incoming XFR

[Klaus Darilion]

Hello!

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

Response Time   normal  during
Window  operation   IXFR

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

Sum 54150   10102

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

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

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

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

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


Thanks
Klaus

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

[2] Seen on Ubuntu 14.04/16.04/18.04 aka Bind 9.9.5/9.10.3/9.11.3
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

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

Re: 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: timestamp in journal

[Klaus Darilion]

Hi Anand!

Am 09.07.2018 um 14:04 schrieb Anand Buddhdev:

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

Hi Klaus,


named-journalprint dumps the journal without any time information.

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

If yes, can I somehow extract the timestamps?

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

Thanks for the info!

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


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

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

timestamp in journal

[Klaus Darilion]

Hi!

named-journalprint dumps the journal without any time information.

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

If yes, can I somehow extract the timestamps?

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

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

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

[Klaus Darilion]

Am 04.06.2018 um 14:20 schrieb Ict Security:

Hi guys,

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

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


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


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


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


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

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

Re: sporadic timeouts querying bind9

[Klaus Darilion]

This time with log file attached
Thanks
Klaus


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

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

[Klaus Darilion]

Hi Latitude!

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


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


Am 07.03.2018 um 07:10 schrieb Latitude:

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

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


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




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


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



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

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


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


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


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


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



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


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



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


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



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


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

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

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


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

sporadic timeouts querying bind9

[Klaus Darilion]

Hi!

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

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

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

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

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

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

Re: are journal files required on slave?

[Klaus Darilion]

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

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

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

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

Re: are journal files required on slave?

[Klaus Darilion]

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

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


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

Is it save to delete them?

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

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

Re: are journal files required on slave?

[Klaus Darilion]

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

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

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

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

Re: Maximum zone file size

[Klaus Darilion]

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

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

Thanks for the feedback.

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

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

Maximum zone file size

[Klaus Darilion]

Hi!

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

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

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

are journal files required on slave?

[Klaus Darilion]

Hi!

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

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

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

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

questions about rndc zonestatus

[Klaus Darilion]

Hi!

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

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

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

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

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

thanks
Klaus


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

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

Re: How to check slave zone freshness

[Klaus Darilion]

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

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

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

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

Re: How to check slave zone freshness

[Klaus Darilion]

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

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


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

Thanks
Klaus

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

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

Re: How to check slave zone freshness

[Klaus Darilion]

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

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

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

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

How to check slave zone freshness

[Klaus Darilion]

Hi!

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

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

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

Re: How to check slave zone freshness

[Klaus Darilion]

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

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

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

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

Thanks for the info
Klaus


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

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

Re: How to check slave zone freshness

[Klaus Darilion]

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

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

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

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

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

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

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

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

Re: rndc (and now nsupdate too)

[Klaus Darilion]

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

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


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

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

Retrying failed zone transfer

[Klaus Darilion]

Hi!

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

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

Thanks
Klaus


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

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

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

dynamically adding/removing TSIG configuration

[Klaus Darilion]

Hi!

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

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

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

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

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

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

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

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

incomplete NSEC3 chains

[Klaus Darilion]

Release: BIND 9.9.5

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

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

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

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

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

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

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

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

Re: Bind ignoring signing -nsec3param when inline-signing a zone

[Klaus Darilion]

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

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

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

Thanks
Klaus

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

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

Re: KSK signing incomplete

[Klaus Darilion]

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

It seems that this happens when Bind is restarted.

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

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

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

Re: KSK signing incomplete

[Klaus Darilion]

On 21.05.2014 12:39, Phil Mayers wrote:
 On 21 May 2014 10:24:23 BST, Klaus Darilion klaus.mailingli...@pernau.at 
 wrote:
 Further, I see that sometimes there are no private records at all.
 When
 does this happen? (I never called rndc signing -clear) 

 It seems that this happens when Bind is restarted.

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

 Thanks
 Klaus
 
 We bodge this by axfr'ing the zone and parsing the rrsig to see which keys 
 are generating which sigs (or not). Nasty and slow, but reliable, and also 
 lets you look for signatures that haven't been regenerated on schedule.

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

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

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

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

KSK signing incomplete

[Klaus Darilion]

Hi!

Using Bind 9.9.5.

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

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

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

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

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

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

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


What else should the KSK sign?

Also forcing resign does not change anything:

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


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



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

Thanks
Klaus



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

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

DNSSEC: recover from missing keys

[Klaus Darilion]

Hi!

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

This leads to such errors:

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

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

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

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

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

nsec3 opt-out confusion

[Klaus Darilion]

Hi!

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


example.com 0   IN  NSEC3PARAM 1 0 10 BEEF

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


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


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


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



So, I am confused.

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

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


Thanks
Klaus

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

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

Re: nsec3 opt-out confusion (bug report)

[Klaus Darilion]

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


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


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

  NSEC3PARAM 1 0 10 BEEF


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


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



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


Thanks
Klaus

On 01.04.2014 15:35, Klaus Darilion wrote:

Hi!

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

example.com 0   IN  NSEC3PARAM 1 0 10 BEEF

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

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

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

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


So, I am confused.

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

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

Thanks
Klaus

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

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

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

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

Re: nsec3 opt-out confusion (bug report)

[Klaus Darilion]

On 01.04.2014 17:09, Chris Thompson wrote:

On Apr 1 2014, Klaus Darilion wrote:

[...]

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


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


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


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


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




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


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


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

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

Re: Sporadic but noticable SERVFAILs in specific nodes of an anycast resolving farm running BIND

[Klaus Darilion]

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


regards
Klaus

On 05.03.2014 16:15, Klaus Darilion wrote:

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

klaus

On 05.03.2014 14:16, Kostas Zorbadelos wrote:


Greetings to all,

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

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

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

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

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

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

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

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

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

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

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

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

The main actions we have done on the problem machines are

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

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

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

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

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

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


Thanks in advance,

Kostas



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

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

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

bind-users mailing list
bind-users@lists.isc.org
https

Re: Sporadic but noticable SERVFAILs in specific nodes of an anycast resolving farm running BIND

[Klaus Darilion]

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

klaus

On 05.03.2014 14:16, Kostas Zorbadelos wrote:


Greetings to all,

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

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

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

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

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

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

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

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

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

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

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

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

The main actions we have done on the problem machines are

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

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

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

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

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

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

Thanks in advance,

Kostas



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

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

Bind 9.9.5 assertion failure

[Klaus Darilion]

Hi all!

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


What my script does is:

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

6. rndc retransfer ...

Thanks
Klaus


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

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

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

Re: Bind 9.9.5 assertion failure

[Klaus Darilion]

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

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

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


Only the second startup worked.

Thanks
Klaus


On 11.02.2014 12:44, Klaus Darilion wrote:

Hi all!

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

What my script does is:

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

Thanks
Klaus




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

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


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

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

missing NOTIFY after rndc signing -clear all zone

[Klaus Darilion]

Hi!

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


I guess this is a bug.

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

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

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

Re: changing NSEC3 salt

[Klaus Darilion]

On 06.02.2014 14:58, Cathy Almond wrote:

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

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

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

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

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

thanks

dn

rndc signing -nsec3param ...

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

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

Cathy


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

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

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

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

Timothe Litt
ACM Distinguished Engineer


Sounds like a good idea - thanks.


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


regards
Klaus

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

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

Re: changing NSEC3 salt

[Klaus Darilion]

On 06.02.2014 11:56, Cathy Almond wrote:

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

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

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

thanks

dn


rndc signing -nsec3param ...

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

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


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

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

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

NSEC3 hash collision

[Klaus Darilion]

Hi!

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


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



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


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


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

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

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

[Klaus Darilion]

Hi!

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


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


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

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

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

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

[Klaus Darilion]

On 30.01.2014 14:19, Mark Andrews wrote:

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

Hi!

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

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

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


rndc zonestatus zone [class [view]]


AFAIS this is only supported with bind 9.10.

Any tricks for stable bind (9.9.4)?

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

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