BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-03-08T05:42:15Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4531Improvements to the parental-agents definition in the arm2024-03-08T05:42:15ZDan MahoneyImprovements to the parental-agents definition in the armHi and thanks for filing an issue! It will be read with care by human beings.
It would be a tremendous help if you could follow these steps first:
- [X] Search the existing issues in GitLab (both open and closed) to see if your report m...Hi and thanks for filing an issue! It will be read with care by human beings.
It would be a tremendous help if you could follow these steps first:
- [X] Search the existing issues in GitLab (both open and closed) to see if your report might be a duplicate. We have a large database here and many issues have already been fixed in the latest versions!
- [X] Make sure this is **not** a support question. If you have specific trouble configuring or debugging your setup, please use the bind-users mailing list: https://lists.isc.org/mailman/listinfo/bind-users
- [X] You have read and understood the "out in the open" support policy: https://blog.powerdns.com/2016/01/18/open-source-support-out-in-the-open/ . Even though it was written by the PowerDNS folks, we follow it as well!
Before continuing, **please select the appropriate issue template in the drop-down menu above, under the heading _Description_**.
(There is no "doc" template. Maybe there should be.)
The current doc for parental-agents laid out in the 9.18 arm is, some formatting tweaks for gitlab aside:
> Grammar zone (primary, secondary): `parental-agents [ port <integer> ] { ( <remote-servers> | <ipv4_address> [ port <integer> ] | <ipv6_address> [ port <integer> ] ) [ key <string> ] [ tls <string> ]; ... };`
>
> Grammar topmost: `parental-agents <string> [ port <integer> ] { ( <remote-servers> | <ipv4_address> [ port <integer> ] | <ipv6_address> [ port <integer> ] ) [ key <string> ] [ tls <string> ]; ... }; // may occur multiple times`
>
> Blocks: topmost, zone (primary, secondary)
>
> Tags: zone
>
> Defines a list of delegation agents to be used by primary and secondary zones.
>
> 8.2.10. `parental-agents` Block Definition and Usage
>
> `parental-agents` lists allow for a common set of parental agents to be easily used by multiple primary and secondary zones. A parental agent is the entity that is allowed to change a zone’s delegation information (defined in RFC 7344).
What is not apparent from the above:
* If you define a "topmost" parental agent, you must still define it in a zone for it to be used. There is no way to configure a default parental agent, nor to have it apply to zones without stating it for each. The example cited in the 9.18 migration article in the KB only mentions the pure-zone-based version, and doesn't give a good example of how to do it with a globally-defined one.
* The "usage" statement for the zone does not make it apparent how to specify an agent defined topmost -- this implies either two "zone" usage statements (Grammar zone with no defined topmost agent, grammar zone with the agent defined only in the zone statement), or a more complex definition of the "Grammar Zone" statement where it's either "parental-agents { "string"; } followed by the rest of the possible options. (I guess it's possible to use a topmost-defined parental agent but ALSO add others? -- I'm not sure how to properly bracket those options, depending on if that's the case.)
* **"A parental agent is the entity that is allowed to change a zone's delegation information"** is untrue in this case. While that is one possible usage (for example, specifying "a0.org.afilias-nst.info." for an agent for example.org), The a0.org.afilias-nst.info. is not allowed to change the delegation information -- some hidden SRS server and a stealth master are, as part of the DNSSEC process. A parental-agent may also be set to 8.8.8.8 or any other TSIG-relationship-defined validating resolver, none of which are allowed to change anything about the delegation.
* Also, the "allowed to change" wording implies that there is some nsupdate-like relationship required between our zone and it, that's to be configured, especially because things like TSIG keys are offered as options.
* It isn't immediately clear that the only thing BIND does is send DS queries.
A better phrasing here might be:
"A parental agent is a trusted DNS server that can confirm that a zone's delegation information has been updated in the parent zone of the one being configured, as defined in (rfc foo section bar). [An optional statement about what is implied by "trusted" (TSIG/DNSSEC/ACLs on the parental-agent server) could go here.]"March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4551dnssec-keygen man page contradictory on whether TSIG keys can be generated2024-03-08T05:39:15ZChristopher Headdnssec-keygen man page contradictory on whether TSIG keys can be generated### Summary
At the top of the `dnssec-keygen` man page appears this text:
> It can also generate keys for use with TSIG (Transaction Signatures) as defined in RFC 2845, or TKEY (Transaction Key) as defined in RFC 2930.
Under the secti...### Summary
At the top of the `dnssec-keygen` man page appears this text:
> It can also generate keys for use with TSIG (Transaction Signatures) as defined in RFC 2845, or TKEY (Transaction Key) as defined in RFC 2930.
Under the section for the `-a` option:
> In prior releases, HMAC algorithms could be generated for use as TSIG keys, but that feature was removed in BIND 9.13.0. Use tsig-keygen to generate TSIG keys.
It looks like the top matter probably wasn’t updated when TSIG was spun out into `tsig-keygen`.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4541values of ruletype field for update-policy statement2024-03-08T05:30:58Zperlangvalues of ruletype field for update-policy statementOne document typo, version 9.18.21, doc/arm/reference.rst, line 7492,
It is only 18 values from the list.
```
The ruletype field has 20 values: ``name``, ``subdomain``, ``zonesub``,
``wildcard``, ``self``, ``selfsub``, ``selfwild``...One document typo, version 9.18.21, doc/arm/reference.rst, line 7492,
It is only 18 values from the list.
```
The ruletype field has 20 values: ``name``, ``subdomain``, ``zonesub``,
``wildcard``, ``self``, ``selfsub``, ``selfwild``, ``ms-self``,
``ms-selfsub``, ``ms-subdomain``, ``ms-subdomain-self-rhs``, ``krb5-self``,
``krb5-selfsub``, ``krb5-subdomain``, ``krb5-subdomain-self-rhs``,
``tcp-self``, ``6to4-self``, and ``external``.
```March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/issues/4510Wrongly considering signatures-validity in "key lifetime is shorter than the ...2024-03-07T22:43:37ZLibor PeltanWrongly considering signatures-validity in "key lifetime is shorter than the time it takes to do a rollover"### Summary
For testing purposes, I tried to configure as short ZSK lifetime as possible (like 10 seconds). I kept failing with the error `key lifetime is shorter than the time it takes to do a rollover` until I discovered (by trial and...### Summary
For testing purposes, I tried to configure as short ZSK lifetime as possible (like 10 seconds). I kept failing with the error `key lifetime is shorter than the time it takes to do a rollover` until I discovered (by trial and error!) that this error wrongly considers `signatures-validity` and `signatures-refresh`.
This is in contrary to the documentation https://bind9.readthedocs.io/en/v9.18.18/reference.html#namedconf-statement-dnskey-ttl which claims that the ZSK lifetime minimum depends only on `dnskey-ttl`, `publish-safety`, `max-zone-ttl`, `retire-safety`, and `zone-propagation-delay`. See also #3416 .
It would be possible to fix this by adjusting the documentation, but I'd prefer to adjust the behaviour: there is no reason why ZSK lifetime should depend on RRSIG validity, only TTLs matter.
### BIND version affected
`BIND 9.18.18-0ubuntu0.22.04.1-Ubuntu (Extended Support Version)`
### Steps to reproduce
```
dnssec-policy "triumph." {
keys {
zsk lifetime 18 algorithm ecdsa256;
ksk lifetime unlimited algorithm ecdsa256;
};
dnskey-ttl 3;
max-zone-ttl 4;
zone-propagation-delay 2;
publish-safety 1;
retire-safety 1;
};
```
(signatures-validity defaults to 14d and signatures-refresh to 5d, the difference is 9d and the zsk lifetime is denied unless I set it to more than 9d)
### What is the current *bug* behavior?
The configuration load fails with the aforementioned error whenever I set the ZSK lifetime to less than `signatures-validity - signatures-refresh`, which is contrary to the documentation https://bind9.readthedocs.io/en/v9.18.18/reference.html#namedconf-statement-dnskey-ttl
### What is the expected *correct* behavior?
Either the documentation should be aligned with the observed behavior, or the behavior (appearance of the error and failure to load conf) should be adjusted to not consider signatures-validity.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4156Document that 'rndc reconfig' will regenerate ephemeral TLS keys (whilst not ...2024-03-07T22:42:10ZCathy AlmondDocument that 'rndc reconfig' will regenerate ephemeral TLS keys (whilst not recreating sockets and listeners entirely)### Summary
There's nowhere in the 9.18 ARM where it is documented what happens to TLS listening sockets when `rndc reconfig` is applied to a running server. Per engineering, a reconfig does recreate TLS contexts (as the certs/keys cou...### Summary
There's nowhere in the 9.18 ARM where it is documented what happens to TLS listening sockets when `rndc reconfig` is applied to a running server. Per engineering, a reconfig does recreate TLS contexts (as the certs/keys could have changed on disk). Thus, all ephemeral data provided for us by OpenSSL is changed.
### BIND version used
BIND 9.18+
### Steps to reproduce
N/A (just search the ARM...)
### What is the current *bug* behavior?
What happens is not documented anywhere.
### What is the expected *correct* behavior?
Please document this. I would suggest as an addendum here to this paragraph:
> There are two built-in TLS connection configurations: ephemeral, uses a temporary key and certificate created for the
> current named session only, and none, which can be used when setting up an HTTP listener with no encryption.
### Relevant configuration files
N/A
### Relevant logs and/or screenshots
N/A
### Possible fixes
See aboveMarch 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/5Revise coding style and documentation requirements2024-01-03T14:09:50ZOndřej SurýRevise coding style and documentation requirementsThis is unsorted list:
* [ ] opening curly braces on new line when the outside construct is multiline, e.g.
```
for (foo;
bar;
baz) {
```
vs current
```
for (foo;
bar;
baz)
{
```
* [ ] Using parentheses to e...This is unsorted list:
* [ ] opening curly braces on new line when the outside construct is multiline, e.g.
```
for (foo;
bar;
baz) {
```
vs current
```
for (foo;
bar;
baz)
{
```
* [ ] Using parentheses to explicitly set priority in conditions, e.g.
```
((foo == TRUE) || (bar == FALSE))
```
vs current
```
(foo == TRUE || bar == FALSE)
```
* [ ] Explicit `NULL` or `FALSE` comparison
```
(foo == FALSE && bar == NULL)
```
vs current
```
(!foo && !bar)
```November 2019 (9.11.13, 9.14.8, 9.15.6)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3416ZSK rollover dnssec-policy: key lifetime is shorter than the time it takes to...2023-12-28T12:16:42ZTom ShawZSK rollover dnssec-policy: key lifetime is shorter than the time it takes to do a rollover<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
Setting up DNSSec using a dnssec policy a previously working configuration now fails due to the Key duration and roll over periods being too "short".
### BIND version used
```
BIND 9.19.2-1+ubuntu22.04.1+isc+1-Ubuntu (Development Release) <id:>
running on Linux x86_64 5.15.0-39-generic #42-Ubuntu SMP Thu Jun 9 23:42:32 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-option-checking' '--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 -ffile-prefix-map=/build/bind9-YovKit/bind9-9.19.2=. -flto=auto -ffat-lto-objects -flto=auto -ffat-lto-objects -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-Bsymbolic-functions -flto=auto -ffat-lto-objects -flto=auto -Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 11.2.0
compiled with OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
linked to OpenSSL version: OpenSSL 3.0.2 15 Mar 2022
compiled with libuv version: 1.44.1
linked to libuv version: 1.44.1
compiled with libnghttp2 version: 1.43.0
linked to libnghttp2 version: 1.43.0
compiled with libxml2 version: 2.9.13
linked to libxml2 version: 20913
compiled with json-c version: 0.15
linked to json-c version: 0.15
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.5.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
Use the policy provided below and apply this to a zone.
### What is the current *bug* behavior?
Service fails to start.
### What is the expected *correct* behavior?
I should expect the dnssec-policy set to honour the configuration. A warning at best, would be appropriate here. This configuration worked in the previous development release.
The duration of the keys is a security consideration and not something BIND should enforce. If I want my keys to roll over every hour, I should be able to allow this.
The warning provides a 30day message when in fact the security policy (provided below) allows BIND to start. It would be useful to see some sort of timeline view in the docs relating to the config values for a dnssec policy as the values are unexplained and best guess values have been used.
### Relevant configuration files
none working config
```
dnssec-policy "standard" {
keys {
ksk lifetime PT120M algorithm ECDSAP384SHA384;
zsk lifetime PT40M algorithm ECDSAP384SHA384;
};
//
dnskey-ttl PT3M;
publish-safety PT3M;
retire-safety PT5M;
purge-keys PT1M;
// Signature timings
signatures-refresh PT5M;
signatures-validity PT60M;
signatures-validity-dnskey PT60M;
//
max-zone-ttl PT5M;
parent-ds-ttl PT3M;
parent-propagation-delay PT3M;
nsec3param iterations 10 optout no salt-length 16;
};
```
working modified config (less than 30d)
```
dnssec-policy "standard" {
keys {
ksk lifetime PT120M algorithm ECDSAP384SHA384;
zsk lifetime PT55M algorithm ECDSAP384SHA384;
};
//
dnskey-ttl PT3M;
publish-safety PT3M;
retire-safety PT5M;
purge-keys PT1M;
// Signature timings
signatures-refresh PT5M;
signatures-validity PT40M;
signatures-validity-dnskey PT40M;
//
max-zone-ttl PT5M;
parent-ds-ttl PT3M;
parent-propagation-delay PT3M;
nsec3param iterations 10 optout no salt-length 16;
};
```
### Relevant logs and/or screenshots
```
Jun 17 16:22:02 ninja.flipkick.media named[2161]: /etc/bind/named.options.conf:43: dnssec-policy: key lifetime is shorter than 30 days
Jun 17 16:22:02 ninja.flipkick.media named[2161]: /etc/bind/named.options.conf:66: dnssec-policy: key lifetime is shorter than 30 days
Jun 17 16:22:02 ninja.flipkick.media named[2161]: /etc/bind/named.options.conf:67: dnssec-policy: key lifetime is shorter than 30 days
Jun 17 16:22:02 ninja.flipkick.media named[2161]: /etc/bind/named.options.conf:67: dnssec-policy: key lifetime is shorter than the time it takes to do a ro>
Jun 17 16:22:02 ninja.flipkick.media named[2161]: loading configuration: failure
Jun 17 16:22:02 ninja.flipkick.media named[2161]: exiting (due to fatal error)
Jun 17 16:22:02 ninja.flipkick.media systemd[1]: named.service: Main process exited, code=exited, status=1/FAILURE
```
### Possible fixes
Allow any period for key duration. 30 days is a poor security policy when working with an Edge computing system and I have resolved the CDS/DS key updates https://github.com/flipkickmedia/cme-dnssec-service - I can get a fully working dnssec system up and running in seconds. With this new update, I have to wait 30d to see if the system works.
I would expect a warning at best, and my TLD providers update the DS keys when I update them (<3H)July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4417Stale hyperlinks in the ARM2023-12-04T10:02:12ZMatthijs Mekkingmatthijs@isc.orgStale hyperlinks in the ARMFrom bind-users:
https://bind9.readthedocs.io/en/v9.18.19/dnssec-guide.html
there's a link to
https://stats.research.icann.org/dns/tld_report/
which is no longer valid. New data seems to be here:
https://ithi.research.icann.or...From bind-users:
https://bind9.readthedocs.io/en/v9.18.19/dnssec-guide.html
there's a link to
https://stats.research.icann.org/dns/tld_report/
which is no longer valid. New data seems to be here:
https://ithi.research.icann.org/
ITHI == idenitifier technologies health indicators
how many TLDs support DNSSEC ?
https://ithi.research.icann.org/graph-m7.htmlDecember 2023 (9.18.21, 9.18.21-S1, 9.19.19)Petr Špačekpspacek@isc.orgPetr Špačekpspacek@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4316dynamic update refused shortly after zone was thawed2023-11-07T10:52:35ZTom Krizekdynamic update refused shortly after zone was thawedThe `rndc` system test failed in `system:gcc:buster:amd64` in [job#3653879](https://gitlab.isc.org/isc-private/bind9/-/jobs/3653879):
```
2023-09-13 04:19:50 INFO:rndc I:rndc_tmp_vgoajfpy:checking zone now writable (5)
2023-09-13 04...The `rndc` system test failed in `system:gcc:buster:amd64` in [job#3653879](https://gitlab.isc.org/isc-private/bind9/-/jobs/3653879):
```
2023-09-13 04:19:50 INFO:rndc I:rndc_tmp_vgoajfpy:checking zone now writable (5)
2023-09-13 04:19:51 INFO:rndc I:rndc_tmp_vgoajfpy:failed
2023-09-13 04:19:51 INFO:rndc I:rndc_tmp_vgoajfpy:rndc sync
2023-09-13 04:19:51 INFO:rndc I:rndc_tmp_vgoajfpy:checking zone was dumped (6)
2023-09-13 04:20:01 INFO:rndc I:rndc_tmp_vgoajfpy:failed
```
The test first issues an `rndc freeze` command. Afterwards, `rndc thaw` is called and then a dynamic zone update is performed. According to [`ns2/named.run`](https://gitlab.isc.org/isc-private/bind9/-/jobs/3653879/artifacts/file/bin/tests/system/rndc_tmp_vgoajfpy/ns2/named.run), the sequence of events seems correct. However, the dynamic update is refused and the message indicates the zone was still frozen - which happens _after_ the zone has been reported as thawed:
```
13-Sep-2023 04:19:50.883 received control channel command 'freeze'
13-Sep-2023 04:19:50.887 freezing zone 'nil/IN': success
13-Sep-2023 04:19:50.887 freezing all zones: success
13-Sep-2023 04:19:50.959 received control channel command 'thaw'
13-Sep-2023 04:19:50.959 thawing zone 'nil/IN': success
13-Sep-2023 04:19:50.959 thawing all zones: success
13-Sep-2023 04:19:50.959 freeing control connection
13-Sep-2023 04:19:50.987 clientmgr @0x7f01f8e00280 attach: 2
13-Sep-2023 04:19:50.987 query client=0x7f01e3441168 thread=0x7f01fa3fc700(<unknown-query>): query_reset
13-Sep-2023 04:19:50.987 client @0x7f01e3441168 (no-peer): allocate new client
13-Sep-2023 04:19:50.987 client @0x7f01e3441168 10.53.0.1#58541: UDP request
13-Sep-2023 04:19:50.987 received client packet from 10.53.0.1#58541
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 53284
;; flags:; ZONE: 1, PREREQ: 0, UPDATE: 1, ADDITIONAL: 1
;; ZONE SECTION:
;nil. IN SOA
;; UPDATE SECTION:
;text3.nil. 600 IN TXT "addition 3"
;; TSIG PSEUDOSECTION:
;local-ddns. 0 ANY TSIG hmac-sha256. 1694578790 300 32 (
; nQa3VUoXEpPfl0juk40ALpyujNrs
; XztiFcMzLq8/9/0= ) 53284 NOERROR 0
13-Sep-2023 04:19:50.987 client @0x7f01e3441168 10.53.0.1#58541: using view '_default'
13-Sep-2023 04:19:50.987 client @0x7f01e3441168 10.53.0.1#58541: request has valid signature: local-ddns
13-Sep-2023 04:19:50.987 client @0x7f01e3441168 10.53.0.1#58541/key local-ddns: recursion not available (recursion not enabled for view)
13-Sep-2023 04:19:50.987 client @0x7f01e3441168 10.53.0.1#58541/key local-ddns: updating zone 'nil/IN': update failed: dynamic update temporarily disabled because the zone is frozen. Use 'rndc thaw' to re-enable updates. (REFUSED)
13-Sep-2023 04:19:50.987 client @0x7f01e3441168 10.53.0.1#58541/key local-ddns: reset client
```November 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4349Document the complex defaults of inline-signing2023-11-07T09:29:45ZBjörn PerssonDocument the complex defaults of inline-signingThe reference manual needs to explain how inline-signing and dnssec-policy will interact in BIND 9.20. This patch describes how it works in the development branch, to the best of my understanding.
[0001-Document-the-complex-defaults-of-...The reference manual needs to explain how inline-signing and dnssec-policy will interact in BIND 9.20. This patch describes how it works in the development branch, to the best of my understanding.
[0001-Document-the-complex-defaults-of-inline-signing.patch](/uploads/15d6ee902fba86b2ec85ff0a54a3dc32/0001-Document-the-complex-defaults-of-inline-signing.patch)November 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2588Fixup the copyright texts2023-11-01T07:38:48ZOndřej SurýFixup the copyright textsThe following discussion from !4807 should be addressed:
- [ ] @sgoldlust started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4807#note_200295): (+2 comments)
> I know this is not what you asked for m...The following discussion from !4807 should be addressed:
- [ ] @sgoldlust started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4807#note_200295): (+2 comments)
> I know this is not what you asked for my review on, but there's no reason for the word "you" to be capitalized in these messages.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2475ARM documentation for no-case-compress ACL seems inconsistent2023-11-01T07:35:08ZBrian ConryARM documentation for no-case-compress ACL seems inconsistent <para>
Specifies a list of addresses which require responses
to use case-insensitive compression. This ACL can be
used when <command>named</command> needs to work wit... <para>
Specifies a list of addresses which require responses
to use case-insensitive compression. This ACL can be
used when <command>named</command> needs to work with
clients that do not comply with the requirement in RFC
1034 to use case-insensitive name comparisons when
checking for matching domain names.
</para>
<para>
If left undefined, the ACL defaults to
<command>none</command>: case-insensitive compression
will be used for all clients. If the ACL is defined and
matches a client, then case will be ignored when
compressing domain names in DNS responses sent to that
client.
</para>
The first paragraph says that it "Specifies a list of addresses which require responses to use case-insensitive compression." while the second paragraph says the opposite, that when the ACL has a value of "none" (meaning that no addresses match) that "case-insensitive compression will be used for all clients."
Based on a code analysis by @pspacek, I believe that the extent of the inconsistency may be the phrase "If left undefined, the ACL defaults to `none`: **case-insensitive** compression will be used for all clients.", which seems like it should read instead "If left undefined, the ACL defaults to `none`: **case-sensitive** compression will be used for all clients."
Testing is recommended to validate behavior before making changes.https://gitlab.isc.org/isc-projects/bind9/-/issues/2254named.conf man page formatting2023-11-01T07:33:03ZTom Marcoennamed.conf man page formattingThe ''named.conf'' man page displays the comment styles in the DESCRIPTION as:
```
C style: /* */
C++ style: // to end of line
Unix style: # to end of line
```
is this weird spacing intentional? I would expect it to be:
```
C style...The ''named.conf'' man page displays the comment styles in the DESCRIPTION as:
```
C style: /* */
C++ style: // to end of line
Unix style: # to end of line
```
is this weird spacing intentional? I would expect it to be:
```
C style: /* */
C++ style: // to end of line
Unix style: # to end of line
```
The code in the man page is:
```
.sp
C style: /* */
.INDENT 0.0
.INDENT 3.5
C++ style: // to end of line
.UNINDENT
.UNINDENT
.sp
Unix style: # to end of line
```
Perhaps it can be changed to:
```
.sp
C style: /* */
.INDENT 0.0
C++ style: // to end of line
.UNINDENT
.INDENT 0.0
Unix style: # to end of line
.UNINDENT
```
PS: This man page appears to be missing from the appendix of the ARM (v9.16.8).https://gitlab.isc.org/isc-projects/bind9/-/issues/1687It's not clear in the ARM what options resolver-nonbackoff-tries and resolver...2023-10-31T14:23:16ZCathy AlmondIt's not clear in the ARM what options resolver-nonbackoff-tries and resolver-retry-interval actually doThey've been added to the descriptions (but not the grammar) in BIND 9.11 ARM, then they're added to the grammar in newer versions of BIND.
I understand that they're now knobs that allow you to changed the default settings for these val...They've been added to the descriptions (but not the grammar) in BIND 9.11 ARM, then they're added to the grammar in newer versions of BIND.
I understand that they're now knobs that allow you to changed the default settings for these values (that have been around in BIND9 for a long time).
But the definition of them in the ARM is just the names of them expanded into words - there's no explanation of how they're used by resolvers in context. For example, I know that named will deal with multiple nameservers for a domain and will have to decide which one to query first (shortest SRTT), how long to wait for that one to respond, how soon to retry if it doesn't, and when to start querying the next server in the list...
An explanation of how this all works would be very helpful - in the ARM or in the KB. And then alongside that:
- why did we make it possible now to tweak these values?
- what could be the costs/benefits to changing the defaults?
- why specifically were these knobs added as part of the work done to introduce Serve Stale?
If it would be generally not useful and potentially detrimental to BIND performance to change the values, then perhaps we should have left these options as undocumented (or unavailable unless named was built with specific non-default options).
Question arose from Support Ticket [RT16171](https://support.isc.org/Ticket/Display.html?id=16171)BIND 9.19.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3143Local addresses are missing from dnstap captures of resolver traffic2023-09-28T15:01:51ZMichał KępieńLocal addresses are missing from dnstap captures of resolver trafficSince !4601 was merged, the following dnstap output is produced by
`named` in the default configuration when a resolver is queried for
`pl/DNSKEY` (only resolver traffic was included for clarity):
<details>
<summary>named -6</summary>
...Since !4601 was merged, the following dnstap output is produced by
`named` in the default configuration when a resolver is queried for
`pl/DNSKEY` (only resolver traffic was included for clarity):
<details>
<summary>named -6</summary>
```
10-Feb-2022 17:55:08.521 RQ :::36241 -> 2001:503:c27::2:30:53 UDP 40b ./IN/DNSKEY
10-Feb-2022 17:55:08.521 RQ :::53541 -> 2001:503:c27::2:30:53 UDP 40b ./IN/NS
10-Feb-2022 17:55:08.601 RR :::36241 <- 2001:503:c27::2:30:53 UDP 864b ./IN/DNSKEY
10-Feb-2022 17:55:09.317 RQ :::34801 -> 2001:503:c27::2:30:53 UDP 40b ./IN/NS
10-Feb-2022 17:55:09.404 RR :::34801 <- 2001:503:c27::2:30:53 UDP 845b ./IN/NS
10-Feb-2022 17:55:12.617 RQ :::41106 -> 2001:503:ba3e::2:30:53 UDP 40b ./IN/NS
10-Feb-2022 17:55:12.617 RQ :::51237 -> 2001:503:ba3e::2:30:53 UDP 43b pl/IN/DNSKEY
10-Feb-2022 17:55:12.640 RR :::41106 <- 2001:503:ba3e::2:30:53 UDP 1097b ./IN/NS
10-Feb-2022 17:55:12.640 RR :::51237 <- 2001:503:ba3e::2:30:53 UDP 914b pl/IN/DNSKEY
10-Feb-2022 17:55:12.640 RQ :::37509 -> 2620:10a:80aa::48:53 UDP 43b pl/IN/DNSKEY
10-Feb-2022 17:55:12.640 RQ :::47186 -> 2001:500:2d::d:53 UDP 49b e-dns.pl/IN/AAAA
10-Feb-2022 17:55:12.640 RR :::47186 <- 2001:500:2d::d:53 UDP 914b e-dns.pl/IN/AAAA
10-Feb-2022 17:55:12.644 RQ :::43215 -> 2620:10a:80aa::48:53 UDP 49b e-dns.pl/IN/AAAA
10-Feb-2022 17:55:12.667 RR :::37509 <- 2620:10a:80aa::48:53 UDP 31b pl/IN/DNSKEY
10-Feb-2022 17:55:12.674 RR :::43215 <- 2620:10a:80aa::48:53 UDP 761b e-dns.pl/IN/AAAA
10-Feb-2022 17:55:12.667 RQ :::0 -> 2620:10a:80aa::48:53 TCP 43b pl/IN/DNSKEY
10-Feb-2022 17:55:12.720 RR :::0 <- 2620:10a:80aa::48:53 TCP 1385b pl/IN/DNSKEY
```
</details>
<details>
<summary>named -4</summary>
```
10-Feb-2022 17:55:42.617 RQ 0.0.0.0:52361 -> 202.12.27.33:53 UDP 40b ./IN/DNSKEY
10-Feb-2022 17:55:42.617 RQ 0.0.0.0:37000 -> 202.12.27.33:53 UDP 40b ./IN/NS
10-Feb-2022 17:55:42.647 RR 0.0.0.0:52361 <- 202.12.27.33:53 UDP 864b ./IN/DNSKEY
10-Feb-2022 17:55:42.664 RR 0.0.0.0:37000 <- 202.12.27.33:53 UDP 1097b ./IN/NS
10-Feb-2022 17:55:45.890 RQ 0.0.0.0:58104 -> 193.0.14.129:53 UDP 43b pl/IN/DNSKEY
10-Feb-2022 17:55:45.894 RR 0.0.0.0:58104 <- 193.0.14.129:53 UDP 914b pl/IN/DNSKEY
10-Feb-2022 17:55:45.894 RQ 0.0.0.0:53854 -> 93.190.128.146:53 UDP 43b pl/IN/DNSKEY
10-Feb-2022 17:55:45.914 RR 0.0.0.0:53854 <- 93.190.128.146:53 UDP 59b pl/IN/DNSKEY
10-Feb-2022 17:55:45.914 RQ 0.0.0.0:0 -> 93.190.128.146:53 TCP 59b pl/IN/DNSKEY
10-Feb-2022 17:55:45.954 RR 0.0.0.0:0 <- 93.190.128.146:53 TCP 1413b pl/IN/DNSKEY
```
</details>
Meanwhile, the expected output (as produced by BIND 9.16 and older
versions) looks more like this:
<details>
<summary>named -6</summary>
```
10-Feb-2022 17:57:44.523 RQ 2001:470:64df:111::e02:52125 -> 2001:500:200::b:53 UDP 40b ./IN/DNSKEY
10-Feb-2022 17:57:44.523 RQ 2001:470:64df:111::e02:48774 -> 2001:500:200::b:53 UDP 40b ./IN/NS
10-Feb-2022 17:57:44.583 RR 2001:470:64df:111::e02:52125 <- 2001:500:200::b:53 UDP 56b ./IN/DNSKEY
10-Feb-2022 17:57:44.583 RR 2001:470:64df:111::e02:48774 <- 2001:500:200::b:53 UDP 56b ./IN/NS
10-Feb-2022 17:57:44.583 RQ 2001:470:64df:111::e02:39731 -> 2001:500:200::b:53 UDP 56b ./IN/DNSKEY
10-Feb-2022 17:57:44.583 RQ 2001:470:64df:111::e02:60246 -> 2001:500:200::b:53 UDP 56b ./IN/NS
10-Feb-2022 17:57:44.639 RR 2001:470:64df:111::e02:39731 <- 2001:500:200::b:53 UDP 892b ./IN/DNSKEY
10-Feb-2022 17:57:44.639 RR 2001:470:64df:111::e02:60246 <- 2001:500:200::b:53 UDP 1229b ./IN/NS
10-Feb-2022 17:57:47.643 RQ 2001:470:64df:111::e02:55999 -> 2001:500:2::c:53 UDP 40b ./IN/NS
10-Feb-2022 17:57:47.643 RQ 2001:470:64df:111::e02:47594 -> 2001:500:2::c:53 UDP 43b pl/IN/DNSKEY
10-Feb-2022 17:57:48.446 RQ 2001:470:64df:111::e02:41403 -> 2001:500:2::c:53 UDP 40b ./IN/NS
10-Feb-2022 17:57:48.446 RQ 2001:470:64df:111::e02:49003 -> 2001:500:2::c:53 UDP 43b pl/IN/DNSKEY
10-Feb-2022 17:57:49.246 RQ 2001:470:64df:111::e02:49059 -> 2001:500:2::c:53 UDP 40b ./IN/NS
10-Feb-2022 17:57:49.246 RQ 2001:470:64df:111::e02:51667 -> 2001:500:2::c:53 UDP 43b pl/IN/DNSKEY
10-Feb-2022 17:57:51.513 RQ 2001:470:64df:111::e02:54552 -> 2001:dc3::35:53 UDP 40b ./IN/NS
10-Feb-2022 17:57:51.513 RQ 2001:470:64df:111::e02:47949 -> 2001:dc3::35:53 UDP 43b pl/IN/DNSKEY
10-Feb-2022 17:57:51.579 RR 2001:470:64df:111::e02:54552 <- 2001:dc3::35:53 UDP 1097b ./IN/NS
10-Feb-2022 17:57:51.583 RQ 2001:470:64df:111::e02:49651 -> 2001:7fe::53:53 UDP 49b e-dns.pl/IN/AAAA
10-Feb-2022 17:57:51.579 RR 2001:470:64df:111::e02:47949 <- 2001:dc3::35:53 UDP 914b pl/IN/DNSKEY
10-Feb-2022 17:57:51.643 RR 2001:470:64df:111::e02:49651 <- 2001:7fe::53:53 UDP 942b e-dns.pl/IN/AAAA
10-Feb-2022 17:57:51.583 RQ 2001:470:64df:111::e02:44144 -> 2001:a10:121:1::156:53 UDP 43b pl/IN/DNSKEY
10-Feb-2022 17:57:51.643 RQ 2001:470:64df:111::e02:56067 -> 2620:10a:80aa::48:53 UDP 49b e-dns.pl/IN/AAAA
10-Feb-2022 17:57:51.633 RR 2001:470:64df:111::e02:44144 <- 2001:a10:121:1::156:53 UDP 59b pl/IN/DNSKEY
10-Feb-2022 17:57:51.709 RR 2001:470:64df:111::e02:56067 <- 2620:10a:80aa::48:53 UDP 761b e-dns.pl/IN/AAAA
10-Feb-2022 17:57:51.633 RQ 2001:470:64df:111::e02:34815 -> 2001:a10:121:1::156:53 TCP 59b pl/IN/DNSKEY
10-Feb-2022 17:57:51.713 RR 2001:470:64df:111::e02:34815 <- 2001:a10:121:1::156:53 TCP 1413b pl/IN/DNSKEY
```
</details>
<details>
<summary>named -4</summary>
```
10-Feb-2022 17:58:17.419 RQ 192.168.111.245:60076 -> 202.12.27.33:53 UDP 40b ./IN/DNSKEY
10-Feb-2022 17:58:17.419 RQ 192.168.111.245:35292 -> 202.12.27.33:53 UDP 40b ./IN/NS
10-Feb-2022 17:58:17.452 RR 192.168.111.245:35292 <- 202.12.27.33:53 UDP 1097b ./IN/NS
10-Feb-2022 17:58:17.452 RR 192.168.111.245:60076 <- 202.12.27.33:53 UDP 864b ./IN/DNSKEY
10-Feb-2022 17:58:18.749 RQ 192.168.111.245:37632 -> 199.7.83.42:53 UDP 43b pl/IN/DNSKEY
10-Feb-2022 17:58:18.769 RR 192.168.111.245:37632 <- 199.7.83.42:53 UDP 914b pl/IN/DNSKEY
10-Feb-2022 17:58:18.769 RQ 192.168.111.245:44178 -> 185.159.198.48:53 UDP 43b pl/IN/DNSKEY
10-Feb-2022 17:58:18.789 RR 192.168.111.245:44178 <- 185.159.198.48:53 UDP 31b pl/IN/DNSKEY
10-Feb-2022 17:58:18.789 RQ 192.168.111.245:45483 -> 185.159.198.48:53 TCP 43b pl/IN/DNSKEY
10-Feb-2022 17:58:18.832 RR 192.168.111.245:45483 <- 185.159.198.48:53 TCP 1385b pl/IN/DNSKEY
```
</details>
See also #4344July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3422Documentation clarifications on dnssec-policy and dynamic zones2023-09-19T09:22:12ZMatthijs Mekkingmatthijs@isc.orgDocumentation clarifications on dnssec-policy and dynamic zonesSection 4.2.28 (dnssec-policy Statement Definition and Usage) should probably mention that inline-signing is implicitly enabled unless the zone is a dynamic zone, and should also reference (i.e. link to) section 4.2.36.4?
Section 4.2.36....Section 4.2.28 (dnssec-policy Statement Definition and Usage) should probably mention that inline-signing is implicitly enabled unless the zone is a dynamic zone, and should also reference (i.e. link to) section 4.2.36.4?
Section 4.2.36.4 (Dynamic Update Policies) should outline the consequences (of using dynamic zones) on zone file management, including:
The zone file can no longer be manually updated while named is running, without first performing rndc freeze and then after editing performing rndc thaw.
Comments and formatting in the zone file will be lost when dynamic updates (including DNSSEC signing) occur?July 2022 (9.16.31, 9.16.31-S1, 9.18.5, 9.19.3)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4266Documentation: Please document the "lifetime" options for dnssec policy keys ...2023-09-01T09:16:46ZDan MahoneyDocumentation: Please document the "lifetime" options for dnssec policy keys statements.Looking through the ARM, see timing options for the key lifetimes such as:
```
keys {
ksk key-directory lifetime unlimited algorithm rsasha256 2048;
zsk lifetime P30D algorithm 8;
csk lifetime P6MT12H3M15S algorithm ecdsa25...Looking through the ARM, see timing options for the key lifetimes such as:
```
keys {
ksk key-directory lifetime unlimited algorithm rsasha256 2048;
zsk lifetime P30D algorithm 8;
csk lifetime P6MT12H3M15S algorithm ecdsa256;
};
```
And while the ARM spells out what that last (weird) key argument does, there's no link to what the actual format of the lifetime statement is -- what the P and T stand for (also, nothing in our KB's.)
named-checkconf also does not emit warnings if you just say "lifetime 30d" so I cannot tell if this behavior is somehow different.
In fact, I cannot at all find a syntax for the "keys" sub-statement for dnssec-policy in the ARM.
Finally, in the rendered version of the ARM, there's a statement that says:
"Here is an example (for illustration purposes only) of some possible entries in a [keys] list:", and that links to the
wrong "keys" statement. (It links to https://bind9.readthedocs.io/en/v9.18.18/reference.html#namedconf-statement-keys
where it specifically says "these are NOT the dnssec-policy keys")September 2023 (9.16.44, 9.16.44-S1, 9.18.19, 9.18.19-S1, 9.19.17)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4184Minor documentation error in query log format2023-08-04T10:19:17ZVicky Riskvicky@isc.orgMinor documentation error in query log formatDocs bug.
Greg verified that this appears to be a correct report
----
> I'm trying to understand the Bind 9 query log format, and came across a potential mistake in the admin manual:
>
> https://bind9.readthedocs.io/en/latest/refere...Docs bug.
Greg verified that this appears to be a correct report
----
> I'm trying to understand the Bind 9 query log format, and came across a potential mistake in the admin manual:
>
> https://bind9.readthedocs.io/en/latest/reference.html#the-category-phrase
>
> under "queries", the manual states (emphasis mine);
>
> > The query log entry first reports a **client object identifier in @0x<hexadecimal-number> format**. Next, it reports the client’s IP address and port number, and the query name, class, and type.
>
> However, the example query log entry listed after this paragraph is missing this object identifier:
>
> > client 127.0.0.1#62536 (www.example.com): query: www.example.com IN AAAA +SE client ::1#62537 (www.example.net): query: www.example.net IN AAAA -SE
>
> Meanwhile, in my own Bind 9 query log, I *can* see this client object identifier. Therefore, I believe you are mistakenly using an old query log entry as an example. Can you please confirm if this is the case?July 2023 (9.18.17, 9.18.17-S1, 9.19.15)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4226dig help message https-plain-get vs http-plain-get2023-08-02T08:24:45ZOli Schacherdig help message https-plain-get vs http-plain-get### Summary
`dig -h` says:
```
+[no]https-plain-get (Use GET instead of default POST method while using plain HTTP)
```
but the option is actually called `+[no]http-plain-get`, without the s
### BIND version used
`DiG 9.18.17`...### Summary
`dig -h` says:
```
+[no]https-plain-get (Use GET instead of default POST method while using plain HTTP)
```
but the option is actually called `+[no]http-plain-get`, without the s
### BIND version used
`DiG 9.18.17`
### Steps to reproduce
run `dig -h`
or for the more adventurous:
```
dig @dns.switch.ch isc.org +https-plain-get
Invalid option: +https-plain-get
[....]
```
### What is the current *bug* behavior?
dig -h claims the option name is `+[no]https-plain-get`
### What is the expected *correct* behavior?
`dig -h` should say the option name is `+[no]http-plain-get`
### Relevant configuration files
n/a
### Relevant logs and/or screenshots
n/a
### Possible fixes
change https://gitlab.isc.org/isc-projects/bind9/-/blob/6a6f2e58e9e4a2e5d30ebb6113e429712dc09b34/bin/dig/dig.c#L228August 2023 (9.16.43, 9.16.43-S1, 9.18.18, 9.18.18-S1, 9.19.16)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4151Add warning to BIND relnotes/documentation for 9.19.6 and 9.18.8 and newer - ...2023-07-04T12:51:42ZCathy AlmondAdd warning to BIND relnotes/documentation for 9.19.6 and 9.18.8 and newer - incompatible key files using HMAC-MD5 when upgrading### Summary
There is a surprise problem with old key files when upgrading to a version of BIND that includes feature #3541. That is, from something older to 9.18.8 or 9.16.34 or newer. Full details of the problem can be found in #3668...### Summary
There is a surprise problem with old key files when upgrading to a version of BIND that includes feature #3541. That is, from something older to 9.18.8 or 9.16.34 or newer. Full details of the problem can be found in #3668. This is a request to add an appropriate warning, somewhere ...
### BIND version used
N/AJuly 2023 (9.18.17, 9.18.17-S1, 9.19.15)