BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-03-16T08:59:16Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3779catalog zone grammar does not enforce default-primaries key / should we suppo...2023-03-16T08:59:16ZPetr Špačekpspacek@isc.orgcatalog zone grammar does not enforce default-primaries key / should we support primary zones in catalog?### Summary
Catalog zones grammar in named.conf does not enforce/require `default-primaries` key. This can be either bug, or an opportunity to extend the feature in an meaningful way.
### BIND version used
* ~"Affects v9.16": d14a22b3...### Summary
Catalog zones grammar in named.conf does not enforce/require `default-primaries` key. This can be either bug, or an opportunity to extend the feature in an meaningful way.
### BIND version used
* ~"Affects v9.16": d14a22b3d9fa8e8bb21dfe3bb0bca216a5b93910
* ~"Affects v9.18": f5e7192691568d4c089fbdd4ed4e93c7af785bae
* ~"Affects v9.19": 0e489b9ed4ba7821c50038dade014bf2b706bd12
### Steps to reproduce
1. Define catalog zone **without** `default-primaries` key. E.g.
```
catalog-zones {
zone "catalog.invalid"
//default-masters { 127.0.0.2; }
in-memory no
zone-directory "catzones"
min-update-interval 1;
};
```
2a. Start **with** matching files on disk
2b. Start **without** matching files on disk
### What is the current *bug* behavior?
The config is accepted by parser but causes surprising behavior later on.
Variant 2A:
The zone is on disk under correct name, and it loads just fine when the file is available in `catzones` directory. `rndc zonestatus` then reports:
```
name: .
type: secondary
files: catzones/__catz___default_catalog.invalid_..db
serial: 2023010600
nodes: 8438
last loaded: Fri, 06 Jan 2023 16:03:08 GMT
next refresh: Fri, 06 Jan 2023 16:12:19 GMT
expires: Fri, 13 Jan 2023 16:03:08 GMT
secure: yes
inline signing: no
key maintenance: none
dynamic: no
reconfigurable via modzone: yes
```
Next time refresh timer hits it errors out with
```
zone ./IN: cannot refresh: no primaries
```
but continues serving the zone until it expires. Kind of works, but not so much because it can never refresh and is bound to expire eventually.
Variant 2B:
File is not on disk. It fails to load as expected, and logs
```
zone ./IN: cannot refresh: no primaries
```
immediately.
### Possible fixes
I can see two options:
a) Require the `default-primaries` and error out if it is not present. That would be the same as for regular secondary zones, I believe.
b) Make this behavior "supported", probably by switching zone type to "primary" in case there is no `default-primaries` defined for the respective catalog. (In that case `in-memory` must be configured as `no`.)
Personally I think it makes sense to do b) because it eliminates need to have two different per-zone config management procedures for primaries.
I mean - with "strict" variant adding a new primary zone always requires `rndc addzone` + catalog zone modification on the primary side.
With less strict variant `rndc addzone` is not necessary and the whole state is in the catalog zone, which is has to be maintained for secondaries anyway.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3776update-policy wildcard match limitations2023-01-09T11:30:12ZTimothe Littupdate-policy wildcard match limitations[The `wildcard` match documentation](https://bind9.readthedocs.io/en/v9_18_10/reference.html#dynamic-update-policies) reads
> The name field is subject to **DNS wildcard expansion**, and this rule matches when the name being updated is ...[The `wildcard` match documentation](https://bind9.readthedocs.io/en/v9_18_10/reference.html#dynamic-update-policies) reads
> The name field is subject to **DNS wildcard expansion**, and this rule matches when the name being updated is a valid expansion of the wildcard.
It would be useful to have a more flexible wildcard match for the update-policy's grant/deny wildcard names.
An example that would help many of us (who use Let's Encrypt) is
`_acme-challenge.*.example.net`, as in
```
grant "CERTIFICATE_ISSUE_BOT" name _acme-challenge.*.example.net. TXT ;
```
Since DNS wildcards only work for the leftmost label, this can't be expressed with the current syntax.
As a result, when a server is added, not only must the A/AAAA records be added (which can be done with UPDATE), but a `grant` clause must be added to the configuration (which can not).
Or allow the BOT to handle all TXT records in the domain. I'm pretty sure I don't want a bot to be able to mess up SPF, google console, and other TXT records...
There are other cases where a generic glob match would be helpful, but most of them can be worked-around by suitable naming and/or introducing a subdomain. Unfortunately, that's not the case for ACME, which requires this structure for the records it uses for `dns-01` validation.
This is NOT asking for changes to how queries are resolved. That ship sailed (to where there be dragons) long ago. Just how `update-policy` clauses are matched. `update-policy` is internal to bind, and the suggested change would be upward-compatible.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3698rndc can get very very slow if large number of requests is made over short pe...2023-01-12T11:25:12ZPetr Špačekpspacek@isc.orgrndc can get very very slow if large number of requests is made over short period of time### Summary
rndc can get very very slow if large number of requests is made over short period of time. Primary cause seems to be that packet deduplication goes O(n^2).
### BIND version used
- ~"Affects v9.19" : e2bbf38cdb42de70d504b2f...### Summary
rndc can get very very slow if large number of requests is made over short period of time. Primary cause seems to be that packet deduplication goes O(n^2).
### BIND version used
- ~"Affects v9.19" : e2bbf38cdb42de70d504b2ff281fb360cd0f27c0
- I assume that supported versions are affected
### Steps to reproduce
TL;DR call `rndc addzone` in a tight loop, and measure response time.
Helper scripts:
* [addconfprim.py](/uploads/129fa9ac79cd590c9172e6d61f28a59f/addconfprim.py) - run this
* [rndc.py](/uploads/23c2eba46244ac7decbe865d84a92052/rndc.py)
### What is the current *bug* behavior?
Adding zones slows down very quickly.
```
33000 zones present; adding last 1000 took 1.93 secs
...
65000 zones present; adding last 1000 took 4.42 secs
```
### What is the expected *correct* behavior?
No speed degradation.
### Relevant configuration files
```
key "key" {
algorithm hmac-sha256;
secret "ptCZS/77Xm2sIzCdO/oxEoer2BbDgCfvF0CrqrcdRWM=";
};
options {
max-cache-size 10M;
recursion no;
notify no;
allow-new-zones yes;
lmdb-mapsize 110M;
};
```
* [empty.db](/uploads/da7366d7d37edc16d43b7280f7cbaf6f/empty.db)
### Possible fixes
From a quick glance, the problem centers around `DUP_LIFETIME` defined in `lib/isccc/cc.c` and in the inefficiency of `isccc_cc_cleansymtab()` and it's use.https://gitlab.isc.org/isc-projects/bind9/-/issues/3669update-policy external is synchronous and blocking without timeouts2023-04-06T12:51:39ZPetr Špačekpspacek@isc.orgupdate-policy external is synchronous and blocking without timeouts### Summary
[update-policy](https://bind9.readthedocs.io/en/v9_19_6/reference.html#namedconf-statement-update-policy) `external` is using synchronous blocking I/O on a Unix socket.
### BIND version used
0744ebe2206fcb327ca0d33e0a72275...### Summary
[update-policy](https://bind9.readthedocs.io/en/v9_19_6/reference.html#namedconf-statement-update-policy) `external` is using synchronous blocking I/O on a Unix socket.
### BIND version used
0744ebe2206fcb327ca0d33e0a722757525e30f0, but as far as I can tell all versions after 9.8.0b1 are affected. (We did not have the `external` policy before that version.)
### Steps to reproduce
I've just looked at the code - function `dns_ssu_external_match()`.
### What is the current *bug* behavior?
Connect/write/read operations are done synchronously on an unix socket. If the external system takes non-zero time to process the query (say, because it's doing database lookups ... or because it just crashed) a named thread will be blocked while waiting for the answer.
### What is the expected *correct* behavior?
I would expect it to be asynchronous... Or that we don't have the policy :-0Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3658journal performance improvements - use asynchronous I/O2023-04-06T12:27:32ZPetr Špačekpspacek@isc.orgjournal performance improvements - use asynchronous I/OCurrently journal I/O is done synchronously, including fsync(). `fsync` is very slow (see #3556) and we probably cannot get rid of it completely, so I think we should use asynchronous I/O for journal processing. That would allow the serv...Currently journal I/O is done synchronously, including fsync(). `fsync` is very slow (see #3556) and we probably cannot get rid of it completely, so I think we should use asynchronous I/O for journal processing. That would allow the server to process normal queries while waiting for journal operations.
TODO: Test IXFR-in and querying the server in parallel.https://gitlab.isc.org/isc-projects/bind9/-/issues/3558Batched UPDATE processing2022-09-23T08:52:56ZTony FinchBatched UPDATE processingThere's a cool thing that can happen when you have a queue whose consumer can work in batches: as the load increases, the batch size increases, so the per-batch overhead is amortized over more queue entries and the system's overall effic...There's a cool thing that can happen when you have a queue whose consumer can work in batches: as the load increases, the batch size increases, so the per-batch overhead is amortized over more queue entries and the system's overall efficiency goes up.
This occurs in the DNS for UPDATE processing: UPDATEs are serialized, so new UPDATEs must be queued while an UPDATE is in progress. It then makes sense when an UPDATE is completed to process all pending UPDATEs in a single transaction, so the server has a chance of catching up with its backlog.Not plannedTony FinchTony Finchhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3556journal performance improvements - limit fsync()2023-04-06T17:09:34ZPetr Špačekpspacek@isc.orgjournal performance improvements - limit fsync()Version: 9.19.5-dev (Development Release) <id:b13d973>
Observation:
In a trivial test on a laptop the UPDATE performance on a single zone is about 1/300 of the query performance on the same zone. Using `tmpfs` for journal makes it as fa...Version: 9.19.5-dev (Development Release) <id:b13d973>
Observation:
In a trivial test on a laptop the UPDATE performance on a single zone is about 1/300 of the query performance on the same zone. Using `tmpfs` for journal makes it as fast as ~ 1/8 of the query performance on a 4 core machine, with multi-threading 8 virtual cores. (That kind of makes sense because of the serialization?)
From a quick look I guess it is because `fsync()` syscall is a real performance drag.
This issue is for discussing possibilities to improve UPDATE performance.
In the code I can see two relatively radical but simple opportunities for optimization:
- [ ] Make `fsync()` use for journal files configurable. IIUC `fsync()` guards only against hardware failure/kernel crash but it should not matter from perspective of a crashing process. Once the data are in kernel buffer after `write()` the process can crash but the filesystem will retain the content anyway. A fsync-knob would allow users to trade performance vs. journal resiliency against system crash (but again, not `named` crash).
- It might even make sense for for secondary zones which can be re-transferred at will.
- It is not unheard-of, see https://www.knot-dns.cz/docs/latest/singlehtml/#journal-db-mode.
- [ ] Even when `fsync()` is required/configured, I think that in `dns_journal_compact()` it should be good enough to call `fsync()` once at the very end. There should be zero risk until the new journal is renamed to the original name, so there is no need to `fsync()` it before that point. That should improve performance too.
Side-note about `fsync()`: It is a trap because on journaled filesystems it can force _all other_ transactions in filesystem journal to be flushed to disk before it even starts flushing the intended file, so it might be even slower than we would like.https://gitlab.isc.org/isc-projects/bind9/-/issues/3455Zone statistics, esp for tracking transfers, update status2023-03-27T14:30:40ZGreg ChoulesZone statistics, esp for tracking transfers, update statusIt is important to know how your server is performing! Complex and large authoritative server setups - many secondaries, zones and data records - have a lot of plates spinning, or balls in the air (tasks running) and understanding how ea...It is important to know how your server is performing! Complex and large authoritative server setups - many secondaries, zones and data records - have a lot of plates spinning, or balls in the air (tasks running) and understanding how each of these tasks is behaving will help operators to know what is 'normal' and what is not.
This issue is to request additional counters in BIND, to provide metrics on various objects and activities. Here are some initial thoughts on what those might be:
1. Total current no. of zones. This is the sum of numbers of zones of all types (see below).
2. Current no. of primary zones, added by zone statements or dynamically using 'addzone'.
3. Current no. of secondary zones..
4. Current no. of forward zones..
5. Current no. of stub zones..
6. Current no. of static-stub zones..
7. Current no. of catalog zones (catz)
8. Current no. of rpz zones
9. No. of SOA queries currently in progress - similar in concept to the current no. of recursive clients. (this might exist already?
10. Histogram of times to resolve SOA zone refresh queries - similar to the query RTT buckets in `named.stats`.
- 0-0.999ms
- 1-4.999ms
- 5-9.999ms
- 10-19.999ms
- 20-49.999ms
- 50-99.999ms
- 100-499.99ms
- 500ms-infinity
11. No. of AXFRs currently in progress
12. No. of IXFRs currently in progress
13. Histogram of times XFRs have been in progress (the bucket sizes are a guess, not based on empirical data)
- 0-0.999s
- 1-4.999s
- 5-9.999s
- 10-19.999s
- 20-49.999s
- 50-99.999s
- 100-499.99s
- 500s-infinityNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3431auth/DNSSEC: RRSIGs not removed when node becomes delegation point2022-06-30T23:27:56ZLibor Peltanauth/DNSSEC: RRSIGs not removed when node becomes delegation point### Summary
Bind operates as primary authoritative with DNSSEC signing enabled. A node (say `xyz.xyz.hahnekedar.`) already exists and has A+AAAA records signed. An incremental update adds a NS record to the node, making it a delegation ...### Summary
Bind operates as primary authoritative with DNSSEC signing enabled. A node (say `xyz.xyz.hahnekedar.`) already exists and has A+AAAA records signed. An incremental update adds a NS record to the node, making it a delegation point, making the previously authoritative A+AAAA records non-authoritative in this zone. As a result, their signatures should be removed.
### BIND version used
9.18.4 (also 9.18.1 and potentially others)
```
BIND 9.18.4-1+ubuntu20.04.1+isc+1-Ubuntu (Stable Release) <id:>
running on Linux x86_64 5.4.0-113-generic #127-Ubuntu SMP Wed May 18 14:30:56 UTC 2022
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=${prefix}/include' '--mandir=${prefix}/share/man' '--infodir=${prefix}/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=${prefix}/lib/x86_64-linux-gnu' '--libexecdir=${prefix}/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--disable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=yes' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-chX9Xr/bind9-9.18.4=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 9.4.0
compiled with OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
linked to OpenSSL version: OpenSSL 1.1.1f 31 Mar 2020
compiled with libuv version: 1.44.1
linked to libuv version: 1.44.1
compiled with libnghttp2 version: 1.40.0
linked to libnghttp2 version: 1.40.0
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.4.2
compiled with protobuf-c version: 1.3.3
linked to protobuf-c version: 1.3.3
threads support is enabled
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
See Summary.
### What is the current *bug* behavior?
The RRSIGs of the previously authoritative records are not removed from the zone.
### What is the expected *correct* behavior?
The RRSIGs should be no longer present in the zone.
### Relevant configuration files
```
options {
directory "/tmp/knottest-1656601404-kbfbxc3h/dnssec/validate_bind/bind1";
key-directory "/tmp/knottest-1656601404-kbfbxc3h/dnssec/validate_bind/bind1";
managed-keys-directory "/tmp/knottest-1656601404-kbfbxc3h/dnssec/validate_bind/bind1";
session-keyfile "/tmp/knottest-1656601404-kbfbxc3h/dnssec/validate_bind/bind1/session.key";
pid-file "/tmp/knottest-1656601404-kbfbxc3h/dnssec/validate_bind/bind1/bind.pid";
listen-on port 21461 { 127.0.0.1; };
listen-on-v6 { };
auth-nxdomain no;
recursion no;
masterfile-format text;
max-refresh-time 2;
max-retry-time 2;
transfers-in 30;
transfers-out 30;
minimal-responses true;
notify-delay 0;
notify-rate 1000;
max-journal-size unlimited;
max-ixfr-ratio unlimited;
startup-notify-rate 1000;
serial-query-rate 1000;
};
key "vsIj.JK2zpN69I9lrZ3M2wBOek8EjENtyvimIH0O8HpstVdWCI8yh96fLVGK88" {
algorithm hmac-md5;
secret "KkTQCVgZ54xSOtXoR0TwfA==";
};
controls {
inet 127.0.0.1 port 21462 allow { 127.0.0.1; } keys { vsIj.JK2zpN69I9lrZ3M2wBOek8EjENtyvimIH0O8HpstVdWCI8yh96fLVGK88; };
};
key "K8VMS.r8vKnF4I" {
# test
algorithm hmac-sha384;
secret "oIXitWx9sj66cCS4LzEjBBzjEQ7PxsR2WQVYbYSrFZIfdZ+CwpJTpo/qBjVTFCgh";
};
key "C8s0rGMAIWmKXmlE9g0Qc2YpKZMKeBqOxM6bzpqvTM50sAN7tPoNSKG6zkyPy.RRnMzzgsXaXv9pMsfpmdky.A61mVO33Stxh6PtW8Eenpdknt2.qhC6akpkb8aGw59RKAyIai60U4wvRWzNM57XMpcYdnPF.jnA3Jbq7QyTX64H924qywefBjXzhriUI7s8fLIYUrF4OtCA4I5UagQ" {
# local
algorithm hmac-sha256;
secret "ihC0Exd7Qq0q+s/mYsfVLq8KlBg1odYtuqsol5RB0d0=";
};
key "S8oUeWsERvzj4f6SlQu3aAucUhp.X5yMyeE287KUpVbXhl3ikdCIkQ59SFKTBS6yxd7qPEkaVIOA8PS4.sTIX7xW1qtyqxBpKqdSKP4hy5V2.Dub0zm5nVloE1KQrMSagYqJAKcW7gSu24U.gQuF3LQERY6cdRS4aEvEW101jPsBU1oqdMTsgEssVwIyE2445UEgV0vj8nw77J" {
# knot1
algorithm hmac-sha256;
secret "PCVor52MeoxlZ5nn3rp4MXqLXsPGft5SW0j4h2j55AE=";
};
# more configured zone ommited
zone "hahnekedar." {
file "/tmp/knottest-1656601404-kbfbxc3h/dnssec/validate_bind/bind1/master/hahnekedar.rndzone";
check-names warn;
type master;
notify explicit;
check-integrity no;
ixfr-from-differences yes;
also-notify { 127.0.0.1 port 21463 key C8s0rGMAIWmKXmlE9g0Qc2YpKZMKeBqOxM6bzpqvTM50sAN7tPoNSKG6zkyPy.RRnMzzgsXaXv9pMsfpmdky.A61mVO33Stxh6PtW8Eenpdknt2.qhC6akpkb8aGw59RKAyIai60U4wvRWzNM57XMpcYdnPF.jnA3Jbq7QyTX64H924qywefBjXzhriUI7s8fLIYUrF4OtCA4I5UagQ; };
allow-update { key K8VMS.r8vKnF4I; };
allow-transfer { key K8VMS.r8vKnF4I; key S8oUeWsERvzj4f6SlQu3aAucUhp.X5yMyeE287KUpVbXhl3ikdCIkQ59SFKTBS6yxd7qPEkaVIOA8PS4.sTIX7xW1qtyqxBpKqdSKP4hy5V2.Dub0zm5nVloE1KQrMSagYqJAKcW7gSu24U.gQuF3LQERY6cdRS4aEvEW101jPsBU1oqdMTsgEssVwIyE2445UEgV0vj8nw77J; };
inline-signing yes;
auto-dnssec maintain;
key-directory "/tmp/knottest-1656601404-kbfbxc3h/dnssec/validate_bind/bind1/keys";
};
```
### Relevant logs and/or screenshots
The issue is easily visible by `named-journalprint /tmp/knottest-1656601404-kbfbxc3h/dnssec/validate_bind/bind1/master/hahnekedar.rndzone.signed.jnl`
Please look for any changes to the node `xyz.xyz.hahnekedar.`. With serial `345896694`, it is interoduced first having an A record, and it becomes a RRSIG and NSEC+RRSIG appropriately. With serial `345896695` it becomes an AAAA record as well, and RRSIGs and NSECs are adjusted appropriately. With serial `345896696` it becomes a NS record as well, making it a delegation point. The RRSIGs for A and AAAA should disappear, but they don't.
```
add hahnekedar. 2648 IN SOA ns.hahnekedar. username.hahnekedar. 345896694 3600 1200 2419200 2648
add xyz.ns2.hahnekedar. 0 IN A 180.47.165.192
add xyz.xyz.hahnekedar. 0 IN A 56.101.241.32
add xyz.a7a.hahnekedar. 0 IN AAAA fd9c:20c0:91fc:cb36:2e9f:23c9:369e:1bfc
add xyz.bl7b907b61.hahnekedar. 0 IN AAAA fd9c:20c0:91fc:cb36:e87c:1f6b:3b46:cf28
add xyz.pub2a0.hahnekedar. 0 IN AAAA fd9c:20c0:91fc:cb36:2e76:b085:aeda:bdcb
add xyz._sip._udp.671A1.hahnekedar. 0 IN SRV 23 5 49681 intervention.hahnekedar.
add hahnekedar. 2648 IN RRSIG SOA 8 1 2648 20220730150351 20220630140351 54646 hahnekedar. IahqYdkP/6OFhyXEKWB13M2eCgMPWrSLonWVYIWE5GeWJuV2wKFp2xYd WbduWLj9jlchQbpCb1WvZZUiNdZLJqvpCx4YkWt0mFqW5PZyDq7Rz1VM j53d6JkpKlKw8gSgt0y9RoMJKXGaz4IpvzMBDulAr88uhU5vy4XLn/uD BfQ=
add xyz._sip._udp.671A1.hahnekedar. 0 IN RRSIG SRV 8 5 0 20220718231722 20220630140351 54646 hahnekedar. tXIeLqk3MXTbBAVk13y9PtO6u/oQunXUY40zrZLyhiqEbs3UtpejFRJq tLELYr2+7eCEYeFBEqdjkgzyahDuNKJwtICP6TFRlF9zXKacHJ+vQYm4 AUv466DMg3fficEj2VKr95aQA6v1ZoGPtth5AyY/NYvQ1g3wfKvG536o ZXM=
add xyz.a7a.hahnekedar. 0 IN RRSIG AAAA 8 3 0 20220718231722 20220630140351 54646 hahnekedar. hxkD0n2C+aHZnl5Ds5kRVO10pN5rY3VuKu6UqiRKvbbLG4x8uCp5vMpq xraRSYZpiXlRUtz6tMtLHfw2c/NAbhuVSZwtxsf1zk0kShqZVbJgUgdr 4SA4zPyow99SVkiEj9udter0HJmpnmUgWdwbExCaoLgMBqhrSP/Sb7fA 8oY=
add xyz.bl7b907b61.hahnekedar. 0 IN RRSIG AAAA 8 3 0 20220718231722 20220630140351 54646 hahnekedar. eAXsvnXqYd+AaS7KyiubuKuetx6fAOrqQtkQmIl41OH8Cop1Ui24u6OD pdT3Ii75CFJz3IFtHdScdlEAvhFkO9Jlpk5BAat4aooUZDXMRfvUNCoB K748aL2tSpEOkRCD84g/ETsnTA4iW+dFAuDBlgYOwgQAaMFvduoU4prV jqk=
add xyz.ns2.hahnekedar. 0 IN RRSIG A 8 3 0 20220718231722 20220630140351 54646 hahnekedar. dgrlg6VprM78tL3KQXHpZHWyMeRCEB2Onp9t00atg16LEt5b9XdI4ona WODfHCRLP9JUEZFd/Sa1EzI9yRrHQz/sLNsFwHkJ4aydm9yNW5gSmNsC Jn0zkiCBS1hifGnwcb7URAgN0M84h68TCD0Q808RrzpRbxDneceOCR85 N1A=
add xyz.pub2a0.hahnekedar. 0 IN RRSIG AAAA 8 3 0 20220718231722 20220630140351 54646 hahnekedar. N/gC4r/QlMfPBguDeMTc2VPmuC8vQom6XLAnkiUNZHCfAVwNSfSZwXdT 5SiB5p2Ys8m/u3KUGufEX7mACz0naQ0zbvwDr5vD+bUc7TjksmBrARoC RUzl3830KnulI/BwoLUh70g3pYuKzIgFTjOwx1i79wUCfZfimqJ2V8Av jK0=
add xyz.xyz.hahnekedar. 0 IN RRSIG A 8 3 0 20220718231722 20220630140351 54646 hahnekedar. W5ifYcm1UHBwx5j6FX0o5ms/1lmQX81IOA31KbIS4kKSFJ6X7nm3Fb7z Q4B7qZAmH6P631HouaUNyJHIZEt2F+ZOhCN3Edp3gU6xDVDtLrS1/PUs /bhAUD+oIMWNd/fEqMiU2SKKYrDpkj1ph336wWiI4yci6/emZ4tsmXyE ztQ=
add 0acC77eFAbbdc268.hahnekedar. 2648 IN RRSIG NSEC 8 2 2648 20220718231722 20220630140351 54646 hahnekedar. kQXr8PiNDG9IwnJG+d17dlHpJoZSMFO6AqJyS5R+9FuUgk8NX+tFqkOE 39lfDF8+xfavsiuR7luOYY9Y5fOM9/2qkCWP6dvdXw3HNrqD/aRrMW1K PERGgrqqdzAGaiGlNF9Kpc8erjAp1to+lbwVlok7n/4pxBxNUWlJmrXj F/E=
add xyz.2Ce98A477.hahnekedar. 2648 IN RRSIG NSEC 8 3 2648 20220718231722 20220630140351 54646 hahnekedar. C/akuQjWbn2GxlV0jbXLSJiDoTZoZMnuy+i7VGtuFjnjXogl097tjAME XUwhMOiqTDOcwJpcF4vdhQe+bWE+nXulZcrPXXtxP/DpuBdTQLrN8Z9k bCsqSW35Zyxvz1SLhah5xMw6iKR2l+cYYwyl4dqm7KuxEYgJF7riNp2t AlA=
add _sip._udp.671A1.hahnekedar. 2648 IN RRSIG NSEC 8 4 2648 20220718231722 20220630140351 54646 hahnekedar. ZUpBFwJdsbBf9QESGqLvSGpS0RpUnztyHsWpWlu2C7iZmoAjbwqqXERu mTJsxSPMfb17EaSBLhDF9FoyWH6ko0j5Jr2+Vd1a9M1EYGzKZh+h7Ook nPJp9Y8FfuBbURyKuQUUK20zoVSEaXeUcxISXS2k7b0InKdYlqz5uhsx 4M8=
add xyz._sip._udp.671A1.hahnekedar. 2648 IN RRSIG NSEC 8 5 2648 20220718231722 20220630140351 54646 hahnekedar. LYnDH3YWcuLN3l6Ew39HvjX4AEr4zSeP3kwxbwShcEWP0w/ofNH85kMW lAf02Qh45yxIOaOS9GpEeaVx6F8F+qpGnXbkzFCmAlIAZeZ6YG6EXxmt B4sFTYdKR2VwcqgMhAA8uaShZO0HwQwC7wjkaRG+GVdmKW/ZnRCi9zmI EeU=
add a7a.hahnekedar. 2648 IN RRSIG NSEC 8 2 2648 20220718231722 20220630140351 54646 hahnekedar. o4hzq3sirzZBjygVzAghzfOsgB5Cl0ty3d0Ecm8saylbUOKF39ZwDv94 +hSRjrA5Iz2ZgSNrUsHKNitRLCfrw9ChYVxEtlVaKVEw8DxmjfcirqWP nGnWTrIOh7g+F1R1RQmPdCsWNmT4HlYTMCk5iifxizUYE8RkEin9tR0q 37A=
add xyz.a7a.hahnekedar. 2648 IN RRSIG NSEC 8 3 2648 20220718231722 20220630140351 54646 hahnekedar. lTF4MPwG/vrRk+JT152fckLXUgW3LwcxnvThyMnGvY6KL//7nkHVlIFK JE9leplUDgoLI9Ps1l67Emmm0PVuur5mbfLMjP145S5isPM4LGNlNdnA Y4rOQztcvaPYSx0+IScvNJ1BRQM5VJ2S7/ngZG7aHEYmuU5Ql66RBwvu KMo=
add bl7b907b61.hahnekedar. 2648 IN RRSIG NSEC 8 2 2648 20220718231722 20220630140351 54646 hahnekedar. nAs4KftHJJ/vY7xpC+248ZXWn8l9f/hHzf53c7iq5RWvMkKkdW/JDFHh UurQpkcRCstpuoWqmSe5Oxrrt5xpVxk+Z+mEk1NX0aBgBQ1KJSeXuSL1 MHk5Uzsx1or4+Gk/XroIQkAzqjq7bPxuSsChObFHxWO5+Oeklkkgv+Le YcQ=
add xyz.bl7b907b61.hahnekedar. 2648 IN RRSIG NSEC 8 3 2648 20220718231722 20220630140351 54646 hahnekedar. cFmRZ1JTEwilLAhUzxUbHWkHxKbuaGIuHp8YEZzo1/h62JNAtfdlZAUJ o1i4asv9vwt6YoLkJvPzREaXkeSIjGu8bmtZTy60u+jsc9g4pU7K7P3Y c4ftzt4HeK2/SrS8PoHLdMPQsPNxGwvhbb80k+aoeITvMDJ2R6HHdbj5 hfA=
add ecFEC5.hahnekedar. 2648 IN RRSIG NSEC 8 2 2648 20220718231722 20220630140351 54646 hahnekedar. L6bNP7szNfC6Md0IbQvVS2vAmElKhRrdIJYwcGrTjAvpF3jjTOPtjVd6 TSsq9Z8KjNyoH/6fPsKWiExCHPMPXRF7PHN62+li/5axU9ObklqLit+z tq4ekP4hiNnsKDkBJRDw/4LtetGy3DreuI7PzFBFxHVSkxN63Zsws6EE KPw=
add fau69a83d99.hahnekedar. 2648 IN RRSIG NSEC 8 2 2648 20220718231722 20220630140351 54646 hahnekedar. Eyqb/OtO6F7xhmG6iPT268td64oglqfCsxA1qO5LCCup1G0uyObjB3Sp AUx2SY8vx1nNamEawLI/H+oEaUPjN6bhGZZbrhdCFjGvu3E4iUFC0xMp zaLeFXMwFH4KpdeFOuIq+h4wd+uPU8hS+dI6QKFJpgjUy4JlY82PU7e9 bfI=
add ns2.hahnekedar. 2648 IN RRSIG NSEC 8 2 2648 20220718231722 20220630140351 54646 hahnekedar. vX9Os5VqbgS8mMCzIqYoTnrKnhANAYxcu0/vJIYf2hlzqhKc6+WVUpjs Xf8Nmy1EwV5HAjZWkPkvfrAXfyAUEXyeXeVCPAHIbFSWE9GCg9DRaKxR Rwl7PjIADrxS8A3tRaEUc/VWNiSv2DBRPmJU0EeZq5fthhDP5i1telSC OPg=
add xyz.ns2.hahnekedar. 2648 IN RRSIG NSEC 8 3 2648 20220718231722 20220630140351 54646 hahnekedar. UkRBxDJNZ/oNt9f5uKqynzuGVF8S1GFHD54Gtb1AKFIrTXjcagOFPGRL nmGwzZQZ7Cn3TI+4iUUzRkA8gcGxrrgsp6uZyf0M1EJi6sqAVdZPoa8f qLW+RUDZNj34qTtJJF3AEcCJr9uLt2BXFof4dKkp9ggZxEtQz9IG4iqJ rhM=
add pub2a0.hahnekedar. 2648 IN RRSIG NSEC 8 2 2648 20220718231722 20220630140351 54646 hahnekedar. i4UA98/A9+ffiYVYBAmqZctmskhteBA8wj9gPuVooaAWMdtA8Fn7qLxb V4I/aYL96JbN/ht11f3NpkpWGzia+KKewHyQZ0GMwuFdrSiLxqPoCdxa JVd0hiNHvQKVLuuwNiqh2UBxXwBg3Z/bX6gPQDxkj5k+Of/WHuOuJB4C KWQ=
add xyz.pub2a0.hahnekedar. 2648 IN RRSIG NSEC 8 3 2648 20220718231722 20220630140351 54646 hahnekedar. eOg5aJ8O2Q+9XIL1b17JdnAmJJp3fm4y/XdfqnDHxtBek1vIt2PCERnR sLGc9+dTmn+XeJ8lPjbWzofG97Mtl2OS5cDxurbyPW5rST7svpiNDzEe N/rU3JsoWwbzJO3nEAbYYjIvMoKcMo/pF+0128yqpLLGEM9l1cEvZnW5 Xw4=
add xyz.xyz.hahnekedar. 2648 IN RRSIG NSEC 8 3 2648 20220718231722 20220630140351 54646 hahnekedar. ObP4lVTa8gghLfH4nQcUaaHiGRZlJbo490aySgcUuXsVrz1U2yitAXZ+ D7H2MYQlo0Ya/bNwz7xC105d9qZpexsvoFwNMzhhA9iUXLKK3SrRhxnP J0X2zLDyRhkltn3P4mF5yXwg3E7vQe7NeFe+Wpw2IVJqZsv5KB40AwGq dZ0=
add 0acC77eFAbbdc268.hahnekedar. 2648 IN NSEC xyz.2Ce98A477.hahnekedar. AAAA RRSIG NSEC
add xyz.2Ce98A477.hahnekedar. 2648 IN NSEC _sip._udp.671A1.hahnekedar. MX RRSIG NSEC
add _sip._udp.671A1.hahnekedar. 2648 IN NSEC xyz._sip._udp.671A1.hahnekedar. SRV RRSIG NSEC
add xyz._sip._udp.671A1.hahnekedar. 2648 IN NSEC 68Dbb6914Fc4e.hahnekedar. SRV RRSIG NSEC
add a7a.hahnekedar. 2648 IN NSEC xyz.a7a.hahnekedar. AAAA RRSIG NSEC
add xyz.a7a.hahnekedar. 2648 IN NSEC aEc7940DfdDEb.hahnekedar. AAAA RRSIG NSEC
add bl7b907b61.hahnekedar. 2648 IN NSEC xyz.bl7b907b61.hahnekedar. AAAA RRSIG NSEC
add xyz.bl7b907b61.hahnekedar. 2648 IN NSEC _sip._udp.protocol.CCb3.hahnekedar. AAAA RRSIG NSEC
add ecFEC5.hahnekedar. 2648 IN NSEC f30.hahnekedar. A RRSIG NSEC
add fau69a83d99.hahnekedar. 2648 IN NSEC _sip._udp.grid.hahnekedar. A RRSIG NSEC
add ns2.hahnekedar. 2648 IN NSEC xyz.ns2.hahnekedar. A RRSIG NSEC
add xyz.ns2.hahnekedar. 2648 IN NSEC pub2a0.hahnekedar. A RRSIG NSEC
add pub2a0.hahnekedar. 2648 IN NSEC xyz.pub2a0.hahnekedar. AAAA RRSIG NSEC
add xyz.pub2a0.hahnekedar. 2648 IN NSEC xyz.xyz.hahnekedar. AAAA RRSIG NSEC
add xyz.xyz.hahnekedar. 2648 IN NSEC hahnekedar. A RRSIG NSEC
del hahnekedar. 2648 IN SOA ns.hahnekedar. username.hahnekedar. 345896694 3600 1200 2419200 2648
del fau69a83d99.hahnekedar. 2648 IN A 84.195.165.254
del 623bC33D3B.normandy.hahnekedar. 2648 IN NS 0acC77eFAbbdc268.hahnekedar.
del hahnekedar. 2648 IN RRSIG SOA 8 1 2648 20220730150351 20220630140351 54646 hahnekedar. IahqYdkP/6OFhyXEKWB13M2eCgMPWrSLonWVYIWE5GeWJuV2wKFp2xYd WbduWLj9jlchQbpCb1WvZZUiNdZLJqvpCx4YkWt0mFqW5PZyDq7Rz1VM j53d6JkpKlKw8gSgt0y9RoMJKXGaz4IpvzMBDulAr88uhU5vy4XLn/uD BfQ=
del fau69a83d99.hahnekedar. 2648 IN RRSIG A 8 2 2648 20220720235742 20220630140325 54646 hahnekedar. BOTESc7VHASmQOWJ6R+x7Re1qC61AyuAljG8IsRdG9c+CivlZVFI3XFi AOzW63YZVfvf3mbtgED96Y8tnhQVz4a0Ny/mITS/5A0XO/GAfrP9DWbA aVkvILUWHmqHZUZZQZIE6WIMw7h/0a13IowwLkWJU19UimLG4A0L102u g7w=
del fau69a83d99.hahnekedar. 2648 IN RRSIG NSEC 8 2 2648 20220718231722 20220630140351 54646 hahnekedar. Eyqb/OtO6F7xhmG6iPT268td64oglqfCsxA1qO5LCCup1G0uyObjB3Sp AUx2SY8vx1nNamEawLI/H+oEaUPjN6bhGZZbrhdCFjGvu3E4iUFC0xMp zaLeFXMwFH4KpdeFOuIq+h4wd+uPU8hS+dI6QKFJpgjUy4JlY82PU7e9 bfI=
del 623bC33D3B.normandy.hahnekedar. 2648 IN RRSIG NSEC 8 3 2648 20220721114036 20220630140325 54646 hahnekedar. Ok+p2mXO/3fR1sveRxDiMgGDUXlW49edOW7w6DVAFipCNvX+mEsf/j6B /z3a52AU8b2kXmZHVkINapm11ZZOGWdZkqxfTU4mwCvGbqZFMm06nJmC B96IxlFmDcqfn6BOnUgpQjVy9CCz/sFFJTLVT/aRp5SQnxyeypbWQHz2 YU4=
del assuming-control.hahnekedar. 2648 IN RRSIG NSEC 8 2 2648 20220729153646 20220630140325 54646 hahnekedar. 0dGbtAuuCwKomF7plmLdL2nv6VD/idu8nbi8iteAsNVaJxsz0ZCYHPHv ApOdKcR7HPejJtBRa6MDdryPSmxU47qGkxKv5CaUDL2Gb7xJfx6aD4kl XKcCmnUZZEbnl9FFOA9AW9BQNrfiwKrENM3tlMTNnCl1LNeRhqUgyrOX 608=
del f75cd935ddEAee38.hahnekedar. 2648 IN RRSIG NSEC 8 2 2648 20220720235742 20220630140325 54646 hahnekedar. Yc0K6qKm731PfU8w+BbyDuDGUhAT/v39jfOeWl6nymwVZNbGNHNX+GoS djA4pXX4+IQJzxuBk5lONumJo2lmpHEd9zNijVKh7dwGDA7+C5RD6KHT 4kRBlNd7MFjxCXaPLlgpOWBNx08eL+Q6dbLdE5xXY948+d7Ma93FeC1i wwM=
del nexus5b2002b.hahnekedar. 2648 IN RRSIG NSEC 8 2 2648 20220716100219 20220630140325 54646 hahnekedar. JfVSZWSDL7iFs0SIUbkiovCkIUMP5HI3JNzUFDEk2J3UmVK+N3xoGfh1 XLbWGt39uWIOASnIk8TEC9c6G8E9khLpNnAL1QmTkQlkRJ+5UGvoa0cb MiUDClMPIXO6nUZnzIuM7EjbzFK0Nsq4d/mGhC6OuUnYitC7Zjda/H4V 6Dc=
del xyz.xyz.hahnekedar. 2648 IN RRSIG NSEC 8 3 2648 20220718231722 20220630140351 54646 hahnekedar. ObP4lVTa8gghLfH4nQcUaaHiGRZlJbo490aySgcUuXsVrz1U2yitAXZ+ D7H2MYQlo0Ya/bNwz7xC105d9qZpexsvoFwNMzhhA9iUXLKK3SrRhxnP J0X2zLDyRhkltn3P4mF5yXwg3E7vQe7NeFe+Wpw2IVJqZsv5KB40AwGq dZ0=
del fau69a83d99.hahnekedar. 2648 IN NSEC _sip._udp.grid.hahnekedar. A RRSIG NSEC
del 623bC33D3B.normandy.hahnekedar. 2648 IN NSEC ns.hahnekedar. NS RRSIG NSEC
del assuming-control.hahnekedar. 2648 IN NSEC bl7b907b61.hahnekedar. CNAME RRSIG NSEC
del f75cd935ddEAee38.hahnekedar. 2648 IN NSEC fau69a83d99.hahnekedar. LOC RRSIG NSEC
del nexus5b2002b.hahnekedar. 2648 IN NSEC 623bC33D3B.normandy.hahnekedar. NS RRSIG NSEC
del xyz.xyz.hahnekedar. 2648 IN NSEC hahnekedar. A RRSIG NSEC
add hahnekedar. 2648 IN SOA ns.hahnekedar. username.hahnekedar. 345896695 3600 1200 2419200 2648
add xyz.hahnekedar.hahnekedar. 0 IN NS elkoss.hahnekedar.
add xyz.assuming-control.hahnekedar. 0 IN CNAME fB10a30E6eF5dE40.hahnekedar.
add xyz.xyz.hahnekedar. 0 IN AAAA fd9c:20c0:91fc:cb36:e87c:1f6b:3b46:cf28
add hahnekedar. 2648 IN RRSIG SOA 8 1 2648 20220730150358 20220630140358 54646 hahnekedar. GCrdijPFrcpZG5PT/ot6iBSx45K+mdq79+wOSznTDeNsw6/v9wvrQgA6 x2Rn4TfeKQ7aq2ZImFpveiR4pZ7jxx6/8ZtwWH9BVaabNr3KapomkqaB iCFJtqJndtoHW/lwPeNl5wE+/PwysuWCVqkyudjfEozBToOdo7JNxO7r GlM=
add xyz.assuming-control.hahnekedar. 0 IN RRSIG CNAME 8 3 0 20220725200453 20220630140358 54646 hahnekedar. K38W9+66tRFYcgf9kyUmTbgHbYTuF3oF4IFVXtBpV4JjW34lq41a3ftP knAyjCfVFp4n5VLyqoseHwWiEcnddnnfwGcPfPniOlj9GZCiQ0ihcP8h PYe1+Olc7tZA7c+U4QsiosuxPSGiPC52wtR/wR4ARokt1FH8yCcoh+4z jog=
add xyz.xyz.hahnekedar. 0 IN RRSIG AAAA 8 3 0 20220725200453 20220630140358 54646 hahnekedar. seH/ntazJr3QWuDLcE+h28cQF62XrkPohioZ/wn6v9jfbIPJGKVMVzHf qfmmZC2HlNYV1+cTqQQ3g50/Z7HW5EWg6oi7TMHhgEq4xVJ/h3vrsHmc g8u7w//6Q8sI1AeMcLWBokGeCsmpiCqeHQoGS/FFah/yX+Ji9EbJv4if jIw=
add assuming-control.hahnekedar. 2648 IN RRSIG NSEC 8 2 2648 20220725200453 20220630140358 54646 hahnekedar. pcN/Sja1FzxShSsfKgni3GNi5axAnAXy4uR9MT4Ll6DpGD8zGcptzWyF CX/jHmWqUmGxjNRgWueOlix3Ki1u2Mjq5OdDWmhkDIt+hi9ObYH72yGz 4tOnrfvdC2mp6ochv2MkxqNfGzzzkA0LKzNV4rudlELlLaBrMKKVBjel 0Bs=
add xyz.assuming-control.hahnekedar. 2648 IN RRSIG NSEC 8 3 2648 20220725200453 20220630140358 54646 hahnekedar. DDibxXdK1ss2XWZsV+XX91DK3Kx/Hre2p2sDtKZSef5q6kwezxPy57sU RstEBEA+CZog6O5/t+EIEmDAA9Vj43bgxfM/y8SeJ1Ll4/PqKpZlyJYd LMWt/5cJk+GavNaSRZ5Qxw72T52kEvcaFR2T2iNPG6/MygGx/NaFFnvB kZw=
add f75cd935ddEAee38.hahnekedar. 2648 IN RRSIG NSEC 8 2 2648 20220725200453 20220630140358 54646 hahnekedar. pgfrrkMrp9Z+zB17gI0VtUuEY5HPSSbA//yEzkIzau4aFzQwT8iHA8Px 14YHac/bi7UQXjevM19FWRwpZHd8m+sPsTHIhEVhLTodNSm6HcgsxYmd kvfDjVybsg6Xjo2bJX9/2RmNeY3T31RB5ts4BgTpk8982zzqwIVFx0mo G8U=
add nexus5b2002b.hahnekedar. 2648 IN RRSIG NSEC 8 2 2648 20220725200453 20220630140358 54646 hahnekedar. gJxMggNCMdNZsZvQ7tI32COR9NopCRiHG0VUViBDzh9RbnUxbiqBLcJW X51wfLzLnRaOKp8/eEuZ5O8MxCAJycL9hJRDaGOztGykLcI3nMR6quFc qqvViMz3hPgJpNRIqClIr2L5NhLLoYDrR1L/yZo/RhuJ4+KFiSKfFhXd 2Hw=
add xyz.xyz.hahnekedar. 2648 IN RRSIG NSEC 8 3 2648 20220725200453 20220630140358 54646 hahnekedar. ykB150lyAJro6CvENSzlCVJ34VD2jxwpCoosqtB9N5sXqgnDmcy96NhO Up4Ng447q3tG2Oq7+LH0siwrZCFVJ3LjCUvF5HWwTrZTMiHAIgA+oH2i E4jlRqbB/8FyyJhRF2ZtKeXI+jo2Pe5DlAc65sCr/dw0yoqtLgl/R4kd +Nk=
add assuming-control.hahnekedar. 2648 IN NSEC xyz.assuming-control.hahnekedar. CNAME RRSIG NSEC
add xyz.assuming-control.hahnekedar. 2648 IN NSEC bl7b907b61.hahnekedar. CNAME RRSIG NSEC
add f75cd935ddEAee38.hahnekedar. 2648 IN NSEC _sip._udp.grid.hahnekedar. LOC RRSIG NSEC
add nexus5b2002b.hahnekedar. 2648 IN NSEC ns.hahnekedar. NS RRSIG NSEC
add xyz.xyz.hahnekedar. 2648 IN NSEC hahnekedar. A AAAA RRSIG NSEC
del hahnekedar. 2648 IN SOA ns.hahnekedar. username.hahnekedar. 345896695 3600 1200 2419200 2648
del nexus.hahnekedar. 2648 IN A 182.188.108.174
del hahnekedar. 2648 IN RRSIG SOA 8 1 2648 20220730150358 20220630140358 54646 hahnekedar. GCrdijPFrcpZG5PT/ot6iBSx45K+mdq79+wOSznTDeNsw6/v9wvrQgA6 x2Rn4TfeKQ7aq2ZImFpveiR4pZ7jxx6/8ZtwWH9BVaabNr3KapomkqaB iCFJtqJndtoHW/lwPeNl5wE+/PwysuWCVqkyudjfEozBToOdo7JNxO7r GlM=
del nexus.hahnekedar. 2648 IN RRSIG A 8 2 2648 20220716100219 20220630140325 54646 hahnekedar. z/cC3zcVlxVA1TPjbT7wKqfqX2TAhaMvpbjnZH0LxTkS9rRuGKMTQKXC R+wqsOtH1ga75TqVC7ZP2kF+donBESBcDA4fRAq6k98lYh40TJyKNLWA DeBHwW8PBgb9nPDzylC0XBwYS9/ghHjMg3sKD2A4M9xOR/YEy2EOWvzJ GP0=
del nexus.hahnekedar. 2648 IN RRSIG NSEC 8 2 2648 20220716100219 20220630140325 54646 hahnekedar. b9JCqITdbcKbjOaigxxu9brTnpkcwI8WmIJoMxLzkg+s9y/OVveVc1wg jYPCc4XjqJiXdPujX4gaokRsDU8UDyDmZ8BUNCdY/3LAjKVywwKwzTKP 9Q2WrGFq60fi/6ew+2bMFwdJlzgWXvDsSslGdMNn2/r2WM1dSf3QO5qv Y6g=
del 0acC77eFAbbdc268.hahnekedar. 2648 IN RRSIG NSEC 8 2 2648 20220718231722 20220630140351 54646 hahnekedar. kQXr8PiNDG9IwnJG+d17dlHpJoZSMFO6AqJyS5R+9FuUgk8NX+tFqkOE 39lfDF8+xfavsiuR7luOYY9Y5fOM9/2qkCWP6dvdXw3HNrqD/aRrMW1K PERGgrqqdzAGaiGlNF9Kpc8erjAp1to+lbwVlok7n/4pxBxNUWlJmrXj F/E=
del customer.hahnekedar. 2648 IN RRSIG NSEC 8 2 2648 20220719173022 20220630140325 54646 hahnekedar. R7jC+oTa3Dh48LZfB0ogmH3oJ8RsdVTzmvkjr76+Dfhd0+QOO6uW4AO5 j14U3n88C4cUK9VbMzDNKLr98hcB/CaCCITALR0Dvyyo3kC4D00cXjHZ FCsVofMP9gA4M8KEALgQdDrZ7RZ8/KyDooPyVPK2iqaayiNVnnVsMn6R SDs=
del ne05cc.hahnekedar. 2648 IN RRSIG NSEC 8 2 2648 20220716100219 20220630140325 54646 hahnekedar. sBHhFLoDr4ED3PVdSAlPoCX88y7BGgnfY+C0Ji9ynAl6ofqyfT5msfiW uSzB2lOAC1HA5zs8mHWJ91/DJupwvqLxEclkCDrJZjura8Oq1chB44I0 VPLT20gG8KujGijyMkjeR3o492S+63nCk0iQZJPJ8kVv94jQNSR9s0Ex 9fE=
del xyz.xyz.hahnekedar. 2648 IN RRSIG NSEC 8 3 2648 20220725200453 20220630140358 54646 hahnekedar. ykB150lyAJro6CvENSzlCVJ34VD2jxwpCoosqtB9N5sXqgnDmcy96NhO Up4Ng447q3tG2Oq7+LH0siwrZCFVJ3LjCUvF5HWwTrZTMiHAIgA+oH2i E4jlRqbB/8FyyJhRF2ZtKeXI+jo2Pe5DlAc65sCr/dw0yoqtLgl/R4kd +Nk=
del nexus.hahnekedar. 2648 IN NSEC nexus5b2002b.hahnekedar. A RRSIG NSEC
del 0acC77eFAbbdc268.hahnekedar. 2648 IN NSEC xyz.2Ce98A477.hahnekedar. AAAA RRSIG NSEC
del customer.hahnekedar. 2648 IN NSEC DCB285c85e6.hahnekedar. CNAME RRSIG NSEC
del ne05cc.hahnekedar. 2648 IN NSEC nexus.hahnekedar. A RRSIG NSEC
del xyz.xyz.hahnekedar. 2648 IN NSEC hahnekedar. A AAAA RRSIG NSEC
add hahnekedar. 2648 IN SOA ns.hahnekedar. username.hahnekedar. 345896696 3600 1200 2419200 2648
add xyz.xyz.hahnekedar. 0 IN NS elkoss.hahnekedar.
add xyz.customer.hahnekedar. 0 IN CNAME rosenkov.hahnekedar.
add xyz.0acC77eFAbbdc268.hahnekedar. 0 IN AAAA fd9c:20c0:91fc:cb36:aaed:e102:c5de:51a2
add hahnekedar. 2648 IN RRSIG SOA 8 1 2648 20220730150405 20220630140405 54646 hahnekedar. GLhH8KEDcajSr2gGrZGnKQyi2sbfLH0CcpcDIO1Li6k5ZqY/bi25OiXb ORJ1IKjJdQ4/bU22rCAxjsSOXYGF1CnJ2JkDkXpvZgl6yxWh6PdH7iXu M+M7z9+eaf4SpXvskTxotOhjBFaBpmh4S3AooFE7/hPV4R6FcOQGh1RQ Vlg=
add xyz.0acC77eFAbbdc268.hahnekedar. 0 IN RRSIG AAAA 8 3 0 20220714050033 20220630140405 54646 hahnekedar. gCYEiWyOyV6z4WY50yCFoYEBm33EbfHK+IPzl7tsosOrPq0SNZjdS/j8 u3BFS0L3zESl6QtnVUQu8pkMfSEcZz0sE94F8b086OXSAkTAIXMsvXxZ zf2wmCfQI1u+pRr1tWRieyAiebQ9NuDQ/3ZqT03MRQIJL8l9RthIvykO O3Q=
add xyz.customer.hahnekedar. 0 IN RRSIG CNAME 8 3 0 20220714050033 20220630140405 54646 hahnekedar. hS3RPH9ukbqqFpJJEr668yk8wUiX9OOCBaScavREQl468T6B5+gDLYsa fMdrj7E5HmAONznlih5c2utXmUSDH1SgHL0FEbP/eB4ir7LrmFEyhOjV ZWCuw1u2EiNp4fxGIw0bHE4273RisxLIpibxRuVQrvqrZtxpwUdEprHr 5k0=
add 0acC77eFAbbdc268.hahnekedar. 2648 IN RRSIG NSEC 8 2 2648 20220714050033 20220630140405 54646 hahnekedar. W4YDPjri0Vu9tJr11oDl13Gz1W+HjX0MbUiUZnDI5FALYxV9H3R/w+Rs w3p/nPCMgMsfhOj+2Zh3EubpvXp09QiPIFVXfXjvwcnW7bBA39Bx2F1t JAmlt65KPdLbix+veez32Et+CbZ3lkSLpoE2oEDBBXZZemkC1a/JPTdM GYI=
add xyz.0acC77eFAbbdc268.hahnekedar. 2648 IN RRSIG NSEC 8 3 2648 20220714050033 20220630140405 54646 hahnekedar. 0vaxSNYGS/Qzpt8rY4WDagnak3lVT9/ZO9Hgq+wP2pz6i0IAwUzU+3y8 v5jEWtcImbA9MA/htH1YvRAEOKAPtkBgfaMynQsoqy2+F8NiA4Nslee1 l4DqATmy1NqIcK0qr3TAMlECXHv59fB/aUlqJpFO7ZpZadh5wiV0bVKb 0qA=
add customer.hahnekedar. 2648 IN RRSIG NSEC 8 2 2648 20220714050033 20220630140405 54646 hahnekedar. bRq3GcqhB888x11nxdhywIaWcVwGpfpI0zDv5WqHgmHl5xM4iI3Np/Io vfsFqYqg5T1HaTy9h8sKDAV7tVOff30tjDOE3fqiADoHi/arSUG38oO4 KHdEjCzFMWSnxt6+nOxlaHhuiPFWV23HqRnLn3t5hWeHflmAVNpThcDD 9WQ=
add xyz.customer.hahnekedar. 2648 IN RRSIG NSEC 8 3 2648 20220714050033 20220630140405 54646 hahnekedar. kTV2b5iS5VOVt+tx27QxEzlOOEG+pLqkve1nmgcBqNA9tMlsSj/HUz8n iV+xIubbY/aIUbRskfCZPdbw0EA9oT+4P/DXZpv2fndXg90hviJvAFwL gCbQwLAknpMxQJ9YHQnuETXY8hhRfFj8MPBVMqUNK2ET+7jq3cQ15+9g 8+U=
add ne05cc.hahnekedar. 2648 IN RRSIG NSEC 8 2 2648 20220714050033 20220630140405 54646 hahnekedar. oeJyXlKBRNiB55mDfGnpb+2aoxjwTDxHX6+s89FTXx4+OthF7Q0W6TJD xiQZvVDGzAreoSccAP8FDELWbSCO2Gz9FjZWWJwkMCjZrueC+A1eBEZj w2rTUigKrVL7U6dY8dy90KunQMf50VzUQEZVM0ylPTydowkbmEk/mVVo W04=
add xyz.xyz.hahnekedar. 2648 IN RRSIG NSEC 8 3 2648 20220714050033 20220630140405 54646 hahnekedar. EQEXU9OBa17qQhpAbRvvsOeGAnIwg8hXdykY0UNCJ4XFpxk7Iv/UchSI nh2c2ZisCX8Ulq6eCXnj37U4XMQBSCXbXpHj1SFae/lJ59c0GMXpVn1b /DRM6g1VTJjM9JX6y7Wa+dpxyJziaqP8bVWwqWHGAhW1Hzeh63feaPsZ Yhg=
add 0acC77eFAbbdc268.hahnekedar. 2648 IN NSEC xyz.0acC77eFAbbdc268.hahnekedar. AAAA RRSIG NSEC
add xyz.0acC77eFAbbdc268.hahnekedar. 2648 IN NSEC xyz.2Ce98A477.hahnekedar. AAAA RRSIG NSEC
add customer.hahnekedar. 2648 IN NSEC xyz.customer.hahnekedar. CNAME RRSIG NSEC
add xyz.customer.hahnekedar. 2648 IN NSEC DCB285c85e6.hahnekedar. CNAME RRSIG NSEC
add ne05cc.hahnekedar. 2648 IN NSEC nexus5b2002b.hahnekedar. A RRSIG NSEC
add xyz.xyz.hahnekedar. 2648 IN NSEC hahnekedar. NS RRSIG NSEC
```
### Possible fixes
Good luck :)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2948DNSSEC signing statistics do not account for cross-algorithm key ID collisions2023-11-02T17:02:19ZMichał KępieńDNSSEC signing statistics do not account for cross-algorithm key ID collisionsIn https://gitlab.isc.org/isc-private/bind9/-/jobs/2033550, two signing
keys for different signing algorithms have the same key ID:
```
>>> 11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/RSASHA256/51742 (policy manykeys)
11-Oct-...In https://gitlab.isc.org/isc-private/bind9/-/jobs/2033550, two signing
keys for different signing algorithms have the same key ID:
```
>>> 11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/RSASHA256/51742 (policy manykeys)
11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/ECDSAP384SHA384/951 (policy manykeys)
11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/RSASHA256/37386 (policy manykeys)
>>> 11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/ECDSAP256SHA256/51742 (policy manykeys)
11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/ECDSAP256SHA256/23421 (policy manykeys)
11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/ECDSAP384SHA384/8256 (policy manykeys)
```
While this situation is not considered a key ID collision (because
different algorithms are involved), it messes up the XML/JSON statistics
because these are not keyed by the `<algorithm, ID>` tuple but rather
just by the key ID. In the `statschannel` system test, the
`zones-{json,xml}.pl` helper scripts only process *unique* key IDs,
leaving duplicate entries out of their output files. In this specific
example, this led to:
```diff
$ diff -u zones.expect.8 zones.out.x8
--- zones.expect.8 2021-10-11 23:30:21.000000000 +0200
+++ zones.out.x8 2021-10-11 23:30:23.000000000 +0200
@@ -1,12 +1,10 @@
dnssec-refresh operations 23421: 1
dnssec-refresh operations 37386: 10
dnssec-refresh operations 51742: 1
-dnssec-refresh operations 51742: 10
dnssec-refresh operations 8256: 1
dnssec-refresh operations 951: 10
dnssec-sign operations 23421: 1
dnssec-sign operations 37386: 10
dnssec-sign operations 51742: 1
-dnssec-sign operations 51742: 10
dnssec-sign operations 8256: 1
dnssec-sign operations 951: 10
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2527Confusing IXFR logging in BIND 9.17.7+2022-03-01T09:41:21ZMichał KępieńConfusing IXFR logging in BIND 9.17.7+A logging glitch slipped into !4246: ever since that MR got merged,
successful IXFRs started being accompanied by a "failed while receiving
responses: no more" log message. This problem was introduced by commit
934d6c6f92ff1761372c532ff...A logging glitch slipped into !4246: ever since that MR got merged,
successful IXFRs started being accompanied by a "failed while receiving
responses: no more" log message. This problem was introduced by commit
934d6c6f92ff1761372c532ff50b899ed4264d1d as it removed an early `return`
statement from `lib/dns/xfrin.c:xfrin_recv_done()`.
Here is what is logged for a successful IXFR in BIND 9.17.7+:
24-Feb-2021 22:17:23.280 zone nil/IN: transferred serial 2
24-Feb-2021 22:17:23.280 transfer of 'nil/IN' from 10.53.0.2#5300: failed while receiving responses: no more
24-Feb-2021 22:17:23.280 transfer of 'nil/IN' from 10.53.0.2#5300: Transfer status: IXFR failed
24-Feb-2021 22:17:23.280 transfer of 'nil/IN' from 10.53.0.2#5300: Transfer completed: 1 messages, 4 records, 179 bytes, 0.016 secs (11187 bytes/sec) (serial 2)
These messages are quite confusing because by the time the "failed while
receiving responses: no more" message is logged, the IXFR is already
journalled and applied to the zone.
The simplest solution seems to be to "promote" `ISC_R_NOMORE` to
`ISC_R_SUCCESS` [after going through the ANSWER section of the
transfer][1].
[1]: https://gitlab.isc.org/isc-projects/bind9/-/blob/965848a11a1032d66807811e2f7e15676760d67f/lib/dns/xfrin.c#L1342-1344Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2213Inline signing: AXFR before zone load on a secondary server prevents zone fro...2023-11-02T17:00:03ZMichał KępieńInline signing: AXFR before zone load on a secondary server prevents zone from being servedConsider an inline-signing secondary server ("bump-in-the-wire") that is
starting up with a previous version of a signed zone available locally.
The typical chain of events is that the server first loads the zone from
storage and then l...Consider an inline-signing secondary server ("bump-in-the-wire") that is
starting up with a previous version of a signed zone available locally.
The typical chain of events is that the server first loads the zone from
storage and then listens to any incoming NOTIFY messages indicating that
the unsigned zone has changed. When the unsigned zone gets updated, its
signed counterpart also gets updated accordingly and the process repeats
itself. This works as expected.
However, if the secondary server receives a NOTIFY for an inline-signed
zone and manages to transfer the unsigned zone in *before* attempting to
load the previous version of the signed zone from storage, things will
break in a way which prevents the inline-signed zone from being served:
```
13-Oct-2020 15:38:01.994 client @0x7f41ac0012f8 10.53.0.2#60440: received notify for zone 'bits'
13-Oct-2020 15:38:01.994 zone bits/IN (unsigned): notify from 10.53.0.2#60440: no serial
13-Oct-2020 15:38:01.994 queue_soa_query: zone bits/IN (unsigned): enter
13-Oct-2020 15:38:02.461 soa_query: zone bits/IN (unsigned): enter
13-Oct-2020 15:38:02.464 refresh_callback: zone bits/IN (unsigned): enter
13-Oct-2020 15:38:02.464 refresh_callback: zone bits/IN (unsigned): serial: new 2011072450, old not loaded
13-Oct-2020 15:38:02.464 queue_xfrin: zone bits/IN (unsigned): enter
13-Oct-2020 15:38:02.464 zone bits/IN (unsigned): Transfer started.
13-Oct-2020 15:38:02.464 zone bits/IN (unsigned): no database exists yet, requesting AXFR of initial version from 10.53.0.2#32589
13-Oct-2020 15:38:02.464 transfer of 'bits/IN (unsigned)' from 10.53.0.2#32589: connected using 10.53.0.3#43661
13-Oct-2020 15:38:02.464 transfer of 'bits/IN (unsigned)' from 10.53.0.2#32589: sent request data
13-Oct-2020 15:38:02.467 transfer of 'bits/IN (unsigned)' from 10.53.0.2#32589: received 168 bytes
;bits. IN AXFR
bits. 0 IN SOA ns2.bits. . 2011072450 20 20 1814400 3600
bits. 300 IN NS ns3.bits.
added.bits. 0 IN A 1.2.3.4
ns2.bits. 300 IN A 10.53.0.2
ns3.bits. 300 IN A 10.53.0.3
bits. 0 IN SOA ns2.bits. . 2011072450 20 20 1814400 3600
13-Oct-2020 15:38:02.467 transfer of 'bits/IN (unsigned)' from 10.53.0.2#32589: got nonincremental response
13-Oct-2020 15:38:02.467 dns_zone_verifydb: zone bits/IN (unsigned): enter
13-Oct-2020 15:38:02.467 zone bits/IN (unsigned): replacing zone database
13-Oct-2020 15:38:02.467 zone bits/IN (unsigned): zone transfer finished: success
13-Oct-2020 15:38:02.467 zone bits/IN (unsigned): transferred serial 2011072450
13-Oct-2020 15:38:02.467 zone_needdump: zone bits/IN (unsigned): enter
13-Oct-2020 15:38:02.467 zone_settimer: zone bits/IN (unsigned): enter
13-Oct-2020 15:38:02.467 zone_settimer: zone bits/IN (unsigned): enter
13-Oct-2020 15:38:02.467 transfer of 'bits/IN (unsigned)' from 10.53.0.2#32589: Transfer status: success
13-Oct-2020 15:38:02.467 transfer of 'bits/IN (unsigned)' from 10.53.0.2#32589: Transfer completed: 1 messages, 6 records, 168 bytes, 0.003 secs (56000 bytes/sec) (serial 2011072450)
13-Oct-2020 15:38:02.467 transfer of 'bits/IN (unsigned)' from 10.53.0.2#32589: freeing transfer context
13-Oct-2020 15:38:02.467 zone bits/IN (signed): number of nodes in database: 4
13-Oct-2020 15:38:02.467 zone bits/IN (signed): journal rollforward failed: journal out of sync with zone
13-Oct-2020 15:38:02.467 zone bits/IN (signed): not loaded due to errors.
13-Oct-2020 15:38:02.467 zone_postload: zone bits/IN (signed): done
13-Oct-2020 15:38:02.467 zone_needdump: zone bits/IN (signed): enter
13-Oct-2020 15:38:02.467 zone bits/IN (signed): receive_secure_db: out of range
```
The underlying cause is that in the broken case,
`lib/dns/journal.c:roll_forward()` retrieves the latest SOA serial
number for the zone from the AXFR rather than from the local copy of the
signed zone.
The time window during which this can happen is rather slim, so I do not
think it is a serious issue, but I decided to open a bug report anyway,
because things are certainly working suboptimally here - it seems to me
that `named` should be able to recover from such a sequence of events
just fine, serving the signed zone in the end.
This was found during [release testing for BIND 9.16.8][1]. I prepared
a crude patch which allows reliably triggering this issue in the
`inline` system test:
```diff
diff --git a/bin/tests/system/inline/tests.sh b/bin/tests/system/inline/tests.sh
index 7d7df7487f4..430f6fcbb77 100755
--- a/bin/tests/system/inline/tests.sh
+++ b/bin/tests/system/inline/tests.sh
@@ -475,7 +475,9 @@ status=`expr $status + $ret`
n=`expr $n + 1`
echo_i "restart bump in the wire signer server ($n)"
ret=0
+export SKIPLOAD="bits"
start_server --noclean --restart --port ${PORT} inline ns3 || ret=1
+unset SKIPLOAD
if [ $ret != 0 ]; then echo_i "failed"; fi
status=`expr $status + $ret`
diff --git a/lib/dns/zone.c b/lib/dns/zone.c
index b8cd90b129a..57bb239c9d5 100644
--- a/lib/dns/zone.c
+++ b/lib/dns/zone.c
@@ -1995,6 +1995,16 @@ zone_load(dns_zone_t *zone, unsigned int flags, bool locked) {
REQUIRE(DNS_ZONE_VALID(zone));
+ {
+ char origin[DNS_NAME_FORMATSIZE];
+ char *skipload = getenv("SKIPLOAD");
+
+ dns_name_format(&zone->origin, origin, sizeof(origin));
+ if (skipload != NULL && !strcmp(skipload, origin)) {
+ return (ISC_R_SUCCESS);
+ }
+ }
+
if (!locked) {
LOCK_ZONE(zone);
}
```
Applying the above patch should result in:
```
I:inline:stop bump in the wire signer server (29)
I:inline:restart bump in the wire signer server (30)
I:inline:checking YYYYMMDDVV (2011072450) serial on hidden primary (31)
I:inline:checking YYYYMMDDVV (2011072450) serial in signed zone (32)
I:inline:failed
I:inline:checking YYYYMMDDVV (2011072450) serial on hidden primary, noixfr (33)
I:inline:checking YYYYMMDDVV (2011072450) serial in signed zone, noixfr (34)
```
and log lines similar to the ones quoted above appearing in
`ns3/named.run`.
AFAICT, all maintained branches are affected.
[1]: https://wiki.isc.org/bin/view/QA/BindQaResults_9_11_24#9.16.8Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/953Problems signing a zone that already contains an NSEC3PARAM2024-02-14T14:39:55ZSara DickisnonProblems signing a zone that already contains an NSEC3PARAM### Summary
While testing zone signing using NSEC3, we used a method slightly different to that documented in the ARM - we added an NSEC3PARAM directly into an unsigned zone and got BIND to load it (with 'dnssec-auto maintain;' specifie...### Summary
While testing zone signing using NSEC3, we used a method slightly different to that documented in the ARM - we added an NSEC3PARAM directly into an unsigned zone and got BIND to load it (with 'dnssec-auto maintain;' specified in the config). BIND signed the zone, did not report an error but in some (not all) cases the resulting zone had invalid NSEC3 records.
We wanted to use the different method as it was simpler for our setup... we have subsequently used the documented method with no issues.
### BIND version used
Reproduced with several versions from 9.11.2 to 9.13.7
### Steps to reproduce
Zone file and named.conf attached
0) Create signing keys in the specified directory (/usr/local/bind/etc/dnssec_keys)
1) Use attached (trivial) zone file and named.conf and start BIND.
2) Inspect the logs - no errors shown
3) rndc sync -clean example.com
4) stop BIND
5) dnssec-verify -o example.com zones/example.com
6) result of 5) is:
dnssec-verify -o example.com etc/zones/example.com
Loading zone 'example.com' from file 'etc/zones/example.com'
Verifying the zone using the following algorithms: ECDSAP256SHA256.
No correct ECDSAP256SHA256 signature for 55165Q1V1UD5N19L8DF1LLRNKNJMTIS6.example.com NSEC3
The zone is not fully signed for the following algorithms: ECDSAP256SHA256.
dnssec-verify: fatal: DNSSEC completeness test failed.
Multiple other tests on the zone showed the same issue. Reproduced with other signing algorithms.
### What is the current *bug* behavior?
If this method is supported, then NSEC3 records are invalid
### What is the expected *correct* behavior?
If the method isn't supported then suggest to refuse to load the zone reporting the reason to the user.
### Relevant configuration files
Files attached:
[named.conf](/uploads/f9c2739e35dbe02c0a4daed637e3034e/named.conf)
[example.com](/uploads/5e8dfd80fd546906fd95cb772dd4ce05/example.com)
[example.com.signed](/uploads/35c648d3cdd85fe0af426647b07d21c8/example.com.signed)
### Relevant logs and/or screenshots
Part of BIND log:
```
21-Mar-2019 15:01:40.201 managed-keys-zone: loaded serial 0
21-Mar-2019 15:01:40.201 zone example.com/IN: loaded serial 2007120712
21-Mar-2019 15:01:40.201 all zones loaded
21-Mar-2019 15:01:40.201 running
21-Mar-2019 15:01:40.201 zone example.com/IN: reconfiguring zone keys
21-Mar-2019 15:01:40.204 zone example.com/IN: next key event: 21-Mar-2019 16:01:40.201
21-Mar-2019 15:01:50.393 received control channel command 'sync -clear example.com'
21-Mar-2019 15:01:50.394 sync: dumping zone 'example.com/IN', removing journal file: success
```
### Possible fixesMichał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/751[ISC-support #13775] Requested Feature: Add a way to define restrictions on w...2024-01-11T13:43:23ZMichael McNally[ISC-support #13775] Requested Feature: Add a way to define restrictions on which zones may be added via catalog zone### Description
Catalog zones provide a powerful mechanism to allow dynamic control over which zones are provisioned on an authoritative server but their initial implementation assumes that the party controlling the zone data for the ca...### Description
Catalog zones provide a powerful mechanism to allow dynamic control over which zones are provisioned on an authoritative server but their initial implementation assumes that the party controlling the zone data for the catalog zone is fully trusted. Numerous use cases exist where the operator of a server would like to delegate to a party permission to add and remove some zones but with restrictions on which such zones can be added (or removed.)
### Request
One of our BIND Support customers has asked that we consider adding mechanisms to allow an operator using catalog zones to restrict via configuration statements which zones will be allowed to be provisioned via the catalog zone.
### Links / references
The original customer request can be found in ISC Support ticket [#13775](https://support.isc.org/Ticket/Display.html?id=13775)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/704named fails to generate missing DNSSEC signatures for NSEC3 records generated...2023-11-02T16:25:43ZMichał Kępieńnamed fails to generate missing DNSSEC signatures for NSEC3 records generated by a previous instanceIf NSEC3 chain creation is requested when no signing keys are available, NSEC3 records will be created but not signed. If `named` is shutdown in the middle of such a chain creation process and subsequently restarted, NSEC3 records gener...If NSEC3 chain creation is requested when no signing keys are available, NSEC3 records will be created but not signed. If `named` is shutdown in the middle of such a chain creation process and subsequently restarted, NSEC3 records generated by the previous `named` instance will remain unsigned.
This is due to the fact that when `named` is restarted, NSEC3 chain creation is started from scratch (since database iterator state is not maintained between restarts) and if a pre-existing NSEC3 record is found by `dns_nsec3_addnsec3()`, it will [first remove the old record and then re-add an identical one][1]. This is not an issue in itself but the subsequent call to `do_one_tuple()` involves [invoking `dns_diff_appendminimal()`][2], which in turn removes changes which cancel each other out from the diff structure. In the case of `dns_nsec3_addnsec3()`, the diff structure in question is the one that is subsequently [passed to `dns__zone_updatesigs()`][3], which means that in order for any NSEC3 record to be (re)signed, it must be present in that diff structure; this will be the case for newly created NSEC3 records but not for these which were already present in the zone database; it will also not be an issue for records which were both pre-existing and signed before `named` was restarted since their signatures would simply be preserved.
(Related to [Support RT #13752][4])
[1]: https://gitlab.isc.org/isc-projects/bind9/blob/026817bd9c6c58c8ee98cccf12a9308b0ed8f25a/lib/dns/nsec3.c#L707-716
[2]: https://gitlab.isc.org/isc-projects/bind9/blob/026817bd9c6c58c8ee98cccf12a9308b0ed8f25a/lib/dns/nsec3.c#L318
[3]: https://gitlab.isc.org/isc-projects/bind9/blob/026817bd9c6c58c8ee98cccf12a9308b0ed8f25a/lib/dns/zone.c#L8080-8082
[4]: https://support.isc.org/Ticket/Display.html?id=13752Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/697Do not attempt to generate DNSSEC records when required keys are not present2022-03-01T09:36:55ZMichael McNallyDo not attempt to generate DNSSEC records when required keys are not present### Description
Recently a customer who is responsible for a very large zone accidentally initiated resigning when no ZSK was present (they keep it off-line and only mount it when required.) The results were not good.
### Request
If ...### Description
Recently a customer who is responsible for a very large zone accidentally initiated resigning when no ZSK was present (they keep it off-line and only mount it when required.) The results were not good.
### Request
If BIND cannot properly perform a signing action because required keys are not present it should fail (loudly) without altering the zone.
### Links / references
https://support.isc.org/Ticket/Display.html?id=13752Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/596Option to eliminate cross-zone glue in authoritative server responses2021-10-04T13:22:09ZCathy AlmondOption to eliminate cross-zone glue in authoritative server responses### Description
BIND in all currently-supported versions will return any cross-zone or out-of zone glue that it happens to have in its possession in its referral responses to clients.
There are three scenarios when it might do this:
...### Description
BIND in all currently-supported versions will return any cross-zone or out-of zone glue that it happens to have in its possession in its referral responses to clients.
There are three scenarios when it might do this:
a) The zone administrators added the out-of-zone glue to the zone when adding a delegation NS RRset and associated A/AAAA RRs. This out-of-zone glue is loaded by BIND anyway, isn't returned if queried-for directly (obviously - the server isn't auth for the zone), but it will be returned as glue in referrals to delegated zones whose out-of-zone RRs "need" it.
b) The authoritative server is serving multiple zones (e.g. Verisign serve both .com and .net) and thus quite often the cross-zone glue is available authoritatively.
c) The authoritative server is delegating e.g. bar.com and foo.com where some of foo.com's servers are in the bar.com domain and are also authoritative for bar.com, therefore are included (legitimately) as bar.com's glue.
There are situations where returning out-of-zone glue is undesirable (see references below).
The scenario a) can be mitigated by the zone administrator manually (remove the out-of-zone glue from the zone).
Scenarios b) and c) are currently unavoidable - named returns the out of zone glue regardless.
### Request
In its simplest form, just stop adding out-of-zone glue to referral query responses for delegated subdomains.
There is a more complex discussion however. The DNS RFCs currently don't forbid the following scenario:
```
foo.com.au. IN NS ns1.bar.com.
bar.com.au. IN NS ns1.foo.com.
ns1.foo.com. IN A 1.2.3.4
ns1.bar.com. IN A 1.2.3.5
```
Because each of the delegated subdomains is dependent on the other one, the glue is required. And that's just a very simple delegation dependency chain - it's possible to make more complicated ones.
So either we need a mechanism for signalling (on a per zone basis) that out-of-zone glue if available should be served. Or, we need to clarify whether or not this scenarios is permissible in the DNS (RFC update - feed the camel..?)
References:
https://support.isc.org/Ticket/Display.html?id=13434
https://indico.dns-oarc.net/event/29/contributions/660/attachments/630/1013/2018-10-OARC-Verisign-TLDs.pdf
### Links / referenceshttps://gitlab.isc.org/isc-projects/bind9/-/issues/595Exceeding transfers-per-ns quota aborts zone refresh2023-11-02T16:32:27ZGhost UserExceeding transfers-per-ns quota aborts zone refresh### Summary
A zone transfer abandoned because the selected master host's `transfers-per-ns` quota is reached cancels the whole refresh activity for the zone even when alternative master hosts are configured and below quota.
This causes...### Summary
A zone transfer abandoned because the selected master host's `transfers-per-ns` quota is reached cancels the whole refresh activity for the zone even when alternative master hosts are configured and below quota.
This causes updates to be unnecessarily delayed; another refresh will not occur until the zone's refresh timer expires or another NOTIFY message is received.
The effect of this is that just one slow master host effectively torpedoes overall zone-transfer latency even when lots of other master servers are available to use. A slow master which holds its zone transfer sessions open longer than usual causing it to reach its quota kills off the refresh activities for all zones that it's named's currently preferred master for.
### Steps to reproduce
Use the likes of `tc` on a slave host to slow TCP sessions to its first-listed master host to the point where the number of concurrent TCP transfer sessions exceeds the `transfers-per-ns` limit. Observe that slave hosts abort refresh activities for zones due to `transfers-per-ns` quota without trying the other master hosts.
### What is the current *bug* behavior?
Exceeding the `transfers-per-ns` quota for one master aborts the refresh activity for the zone, not just the transfer from the over-quota master.
### What is the expected *correct* behavior?
If there are other masters for the zone, they are below their own `transfers-per-ns` quota, and the global `transfers-in` quota is not exceeded, the alternative masters should be used.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/505experimental implementation of draft-ietf-dnsop-update-timeout2020-07-29T10:33:06ZMark Andrewsexperimental implementation of draft-ietf-dnsop-update-timeouthttps://tools.ietf.org/html/draft-ietf-dnsop-update-timeouthttps://tools.ietf.org/html/draft-ietf-dnsop-update-timeoutMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/459[RT 39964] logging of NXDOMAIN query-responses (response source and type)2024-03-13T13:46:50ZVicky Riskvicky@isc.org[RT 39964] logging of NXDOMAIN query-responses (response source and type)Edited/compressed from the original in classic bugs-RT
for analyzing queries resulting in NXDOMAIN responses...
Please add the following to normal query log:
a) what kind of answer was given (nxrrset, rrset (how many) or servfail)
b) w...Edited/compressed from the original in classic bugs-RT
for analyzing queries resulting in NXDOMAIN responses...
Please add the following to normal query log:
a) what kind of answer was given (nxrrset, rrset (how many) or servfail)
b) where did the answer came from (authorative, from cache or was it the result of a recursive search)
The actual content of the answer is not needed outside some very special debug-cases and for these cases you have to do a complete network trace anyway.
spawned from #39253: dnstap wish-list: Query log limited by zone/domain & Answer logging
Reference to https://support.isc.org/Ticket/Display.html?id=8385 added
----
* This is response, not query information
<from Ray>
NB: recording these either means two separate log entries (one for query, one for response) or if they're merged that the query log will now be in response order rather than request order.
------
This request is for 'normal' query logging, but many have asked for this via **dnstap** as well. We would love to get this in dnstap if that is possible, realizing there is a standards/schema issue with dnstap.
------
Tagging with 9.13.3 because we would really like to try for this in 9.14.0. This is a fairly long standing and frequently-heard request.Not planned