BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-11-02T16:58:16Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1900Runtime system test fails badly when run as root on non-linux systems.2023-11-02T16:58:16ZMark AndrewsRuntime system test fails badly when run as root on non-linux systems.Lots of the sub tests depend on capabilities being enabled to get "permission denied" when run as root.
```
% sudo sh run.sh runtime
Making check in dyndb/driver
make[1]: Nothing to be done for `check'.
Making check in dlzexternal/drive...Lots of the sub tests depend on capabilities being enabled to get "permission denied" when run as root.
```
% sudo sh run.sh runtime
Making check in dyndb/driver
make[1]: Nothing to be done for `check'.
Making check in dlzexternal/driver
make[1]: Nothing to be done for `check'.
/Applications/Xcode.app/Contents/Developer/usr/bin/make feature-test makejournal pipelined/pipequeries rndc/gencheck rpz/dnsrps tkey/keycreate tkey/keydelete
make[2]: `feature-test' is up to date.
make[2]: `makejournal' is up to date.
make[2]: `pipelined/pipequeries' is up to date.
make[2]: `rndc/gencheck' is up to date.
make[2]: `rpz/dnsrps' is up to date.
make[2]: `tkey/keycreate' is up to date.
make[2]: `tkey/keydelete' is up to date.
/Applications/Xcode.app/Contents/Developer/usr/bin/make check-TESTS
S:runtime:2020-06-01T09:18:45+1000
T:runtime:1:A
A:runtime:System test runtime
I:runtime:PORTS:5330,5331,5332,5333,5334,5335,5336,5337,5338,5339
I:runtime:starting servers
I:runtime:verifying that named started normally (1)
I:runtime:verifying that named checks for conflicting named processes (2)
I:runtime:verifying that 'lock-file none' disables process check (3)
I:runtime:checking that named refuses to reconfigure if working directory is not writable (4)
I:runtime:failed
I:runtime:checking that named refuses to reconfigure if managed-keys-directory is not writable (5)
I:runtime:failed
I:runtime:checking that named refuses to reconfigure if new-zones-directory is not writable (6)
I:runtime:failed
I:runtime:checking that named recovers when configuration file is valid again (7)
I:runtime:failed
I:runtime:checking that named refuses to start if working directory is not writable (8)
I:runtime:failed
I:runtime:checking that named refuses to start if managed-keys-directory is not writable (9)
I:runtime:failed
I:runtime:checking that named refuses to start if new-zones-directory is not writable (10)
I:runtime:failed
I:runtime:checking that named logs control characters in octal notation (11)
I:runtime:checking that named escapes special characters in the logs (12)
I:runtime:checking that named logs an ellipsis when the command line is larger than 8k bytes (13)
I:runtime:verifying that named switches UID (14)
I:runtime:failed
I:runtime:exit status: 8
I:runtime:stopping servers
R:runtime:FAIL
E:runtime:2020-06-01T09:19:22+1000
FAIL: runtime
============================================================================
Testsuite summary for BIND 9.17.1-dev
============================================================================
# TOTAL: 1
# PASS: 0
# SKIP: 0
# XFAIL: 0
# FAIL: 1
# XPASS: 0
# ERROR: 0
============================================================================
See bin/tests/system/run.log
Please report to info@isc.org
============================================================================
make[3]: *** [run.log] Error 1
make[2]: *** [check-TESTS] Error 2
make[1]: *** [check-am] Error 2
make: *** [check-recursive] Error 1
%
```
Additionally it appears that the following also fails on centos8 (from bind-users) which is what prompted me to check.
```
I:runtime:verifying that named switches UID (14)
I:runtime:failed
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1866dumpdb take 12+ seconds to complete.2021-10-05T12:18:21ZMark Andrewsdumpdb take 12+ seconds to complete.Job [#896675](https://gitlab.isc.org/isc-projects/bind9/-/jobs/896675) failed for 4df013f0ea61d927abf4f67d5c6ab04478b53d28:
cacheclean system test failed because dumpdb took excessive time to complete.
```
I:cacheclean:check the number...Job [#896675](https://gitlab.isc.org/isc-projects/bind9/-/jobs/896675) failed for 4df013f0ea61d927abf4f67d5c6ab04478b53d28:
cacheclean system test failed because dumpdb took excessive time to complete.
```
I:cacheclean:check the number of cached records remaining (13)
I:cacheclean:timed out waiting for 'rndc dumpdb' to finish
Can't open ns2/named_dump.db.test13: No such file or directory.
I:cacheclean:found 0 records expected 1
I:cacheclean:failed
```
```
21-May-2020 04:21:38.807 received control channel command 'dumpdb -cache _default'
21-May-2020 04:21:38.807 dumpdb started: -cache
21-May-2020 04:21:38.807 delete_node(): 0x7febb871ad68 second1.top1.flushtest.example (bucket 94)
21-May-2020 04:21:38.807 delete_node(): 0x7febb871fc20 top2.flushtest.example (bucket 0)
21-May-2020 04:21:38.807 delete_node(): 0x7feb4fe51bd0 second1.top3.flushtest.example (bucket 36)
21-May-2020 04:21:38.807 delete_node(): 0x7febb871aa38 second2.top3.flushtest.example (bucket 0)
21-May-2020 04:21:48.887 socket 0x7febb8801600: internal_accept called, locked socket
21-May-2020 04:21:48.887 socket 0x7febb8801600 10.53.0.1#38867: accepted connection, new socket 0x7febb83e8310
21-May-2020 04:21:50.555 expiring v4 for name 0x7febb858f270
21-May-2020 04:21:50.675 killing name 0x7febb858f270
21-May-2020 04:21:50.675 ENTER clean_finds_at_name, name 0x7febb858f270, evtype 0004000d, addrs 00000003
21-May-2020 04:21:50.675 EXIT clean_finds_at_name, name 0x7febb858f270
21-May-2020 04:21:50.687 dumpdb complete
```https://gitlab.isc.org/isc-projects/bind9/-/issues/1864Commit 54fe75b9b76eba92efd0fc1cded4a0ac0adc0ba9 introduced a regression in 9.112021-10-05T12:17:40ZBrian ConryCommit 54fe75b9b76eba92efd0fc1cded4a0ac0adc0ba9 introduced a regression in 9.11This commit causes a problem in 9.11 when using `query-source` with `port 53`.
After a reconfig or reload the server will stop receiving data.
I've confirmed that 9.14 and later versions are not affected.
I've also confirmed that both ...This commit causes a problem in 9.11 when using `query-source` with `port 53`.
After a reconfig or reload the server will stop receiving data.
I've confirmed that 9.14 and later versions are not affected.
I've also confirmed that both 9.11 and 9.11-S are affected.
This was discovered from a customer ticket, though the customer has since removed the query source port configuration.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1863dnssec-verify specify a current time2024-02-14T14:44:27ZPeter Daviesdnssec-verify specify a current time### Description
dnssec-verify specify a current time:
If we generate a signed zone via dnssec-signzone with an inception time in the future, then we have a way to fully verify it (including signature validity time checks) with dnssec-ve...### Description
dnssec-verify specify a current time:
If we generate a signed zone via dnssec-signzone with an inception time in the future, then we have a way to fully verify it (including signature validity time checks) with dnssec-verify before hand.
### Request
A command line parameter that allowed you to specify a current time to be used by dnssec-verify.
### Links / references
[GL #743 ](https://gitlab.isc.org/isc-projects/bind9/-/issues/743)
[RT #16466](https://support.isc.org/Ticket/Display.html?id=16466)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1814isc_rwlocks tuning - get rid of {down,up}grades, adaptivity2021-10-05T12:13:21ZWitold Krecickiisc_rwlocks tuning - get rid of {down,up}grades, adaptivityOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1754edns-udp-size in server statement2021-06-23T15:48:52ZDavid Zychedns-udp-size in server statementhttps://ftp.isc.org/isc/bind9/9.16.1/doc/arm/Bv9ARM.ch05.html#server_statement_definition_and_usage points out that `edns-udp-size` in a server statement, which sets a single UDP size for all packets sent to the server, differs from the ...https://ftp.isc.org/isc/bind9/9.16.1/doc/arm/Bv9ARM.ch05.html#server_statement_definition_and_usage points out that `edns-udp-size` in a server statement, which sets a single UDP size for all packets sent to the server, differs from the behavior of `edns-udp-size` in options or view statements, where it specifies a *maximum* value. It goes on to warn that **"The server statement behavior may be brought into conformance with the options/view behavior in future releases."**
I'm writing to share what I believe to be a valid real-world use case for the current behavior, and therefore a reason to preserve it.
As of this writing, I have discovered that a certain set of authoritative nameservers neglects to set the TC flag when they truncate a response to the following query:
```
$ dig +norec +dnssec +bufsize=512 +ignore +qr @a.gov-servers.net rh202ns2.355.dhhs.gov a
; <<>> DiG 9.11.17 <<>> +norec +dnssec +bufsize=512 +ignore +qr @a.gov-servers.net rh202ns2.355.dhhs.gov a
; (2 servers found)
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30828
;; flags: ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
; COOKIE: cd7bdc7c0652450f
;; QUESTION SECTION:
;rh202ns2.355.dhhs.gov. IN A
;; QUERY SIZE: 62
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30828
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;rh202ns2.355.dhhs.gov. IN A
;; AUTHORITY SECTION:
dhhs.gov. 86400 IN NS rh120ns2.368.dhhs.gov.
dhhs.gov. 86400 IN NS rh202ns2.355.dhhs.gov.
dhhs.gov. 86400 IN NS rh120ns1.368.dhhs.gov.
dhhs.gov. 86400 IN NS rh202ns1.355.dhhs.gov.
dhhs.gov. 3600 IN DS 51937 8 1 5B557959E1E4CB05FE667CD0EE98D0C5D243D71A
dhhs.gov. 3600 IN DS 635 8 2 3DA74CE6083E79B5FCA8BD5516CE7201774BAEBDE7D1314A32A113A7 74635410
dhhs.gov. 3600 IN DS 51937 8 2 8CDF39C362FD8A982E141B25DEBA8D6957419A7C025A40CC493255BD 6D5352D7
dhhs.gov. 3600 IN DS 635 8 1 CC30699D55C70F38F9653E71B6A8553803ED67D9
dhhs.gov. 3600 IN RRSIG DS 8 2 3600 20200421161007 20200414161007 36558 gov. m1OXbWkv/Rvkb+y6Ytnvtde6pdJXBVOYG6ha0llcV+43bf9o0pHVa7xX J23MSpLzBytY0m61XO8hVUPmln7Rkz+gX5HuIjweMiqoT2MbVC5LjMu7 Z38kG2cV3xkjMs2MCM3Cl5MdnLmt9swdhu+Weue5NsOixr0dTDmrhaXs 3jRDJk1Nd7Wav/MgYvz1/LyMT5AmDlSwQO+W+QQwBnbd+A==
;; Query time: 12 msec
;; SERVER: 69.36.157.30#53(69.36.157.30)
;; WHEN: Tue Apr 14 19:36:25 UTC 2020
;; MSG SIZE rcvd: 500
```
This is one of the authoritative nameservers for `gov.` providing a referral response for `dhhs.gov.`. Since the nameservers in the referral are themselves underneath `dhhs.gov.`, it is absolutely essential that this response include glue A records; without them, it is impossible for a recursive resolver to follow the delegation. But in this case the glue A records have been omitted in order for the response to fit within 512 bytes, and **no TC flag is set** to tell the resolver it should retry over TCP. Which is not our fault, of course, but that doesn't mean it's not our problem.
Now consider a freshly-initialized BIND recursive resolver. Because BIND always advertises a UDP buffer size of 512 the first time it queries any given remote server, if the first recursive query we attempt to handle after startup is for `rh202ns2.355.dhhs.gov a` then we will receive the above problematic answer (TC=0, no glue A records) from one of the gov servers, conclude that no glue records *exist* (i.e. the delegation is hopelessly broken), and return SERVFAIL to our recursive client.
Interestingly this SERVFAIL condition will not persist indefinitely; since our first query against 69.36.157.30 with buffer size 512 was "successful" (in the sense that we didn't get a timeout or a NOTIMPL / FORMERR / SERVFAIL), our next subsequent attempt to query 69.36.157.30 will advertise a larger buffer size which does in fact happen to be large enough to hold all the glue records, allowing us to follow the delegation and retrieve the desired answer. But each time we restart named (and maybe for other reasons too, I'm not sure) we'll try 512 again and end up back at SERVFAIL.
Which brings us to `edns-udp-size`: configuring
```
options {
edns-udp-size 1232;
};
```
is no help at all in this scenario because BIND will still try 512 first. But
```
# a.gov-servers.net
server 69.36.157.30 {
edns-udp-size 1232;
};
# b.gov-servers.net
server 209.112.123.30 {
edns-udp-size 1232;
};
# c.gov-servers.net
server 69.36.153.30 {
edns-udp-size 1232;
};
# d.gov-servers.net
server 81.19.194.30 {
edns-udp-size 1232;
};
```
is an effective workaround that we can implement on the BIND recursive resolver, until such time as we can convince someone to fix the authoritative nameservers (which are not under our control).
Of course we could also use `tcp-only yes;` as a workaround, but it's nice to have both alternatives available.
For the record:
* I did my proof-of-concept testing with BIND 9.11.17, but the ARM statement warning that this behavior might be removed someday is still present in 9.16.1.
* What matters to me is that the behavior still be available; I would be perfectly happy to configure it using a different option name in order to reduce confusion.
Thanks for reading!Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1746Clarifications in ARM about catalog zones2023-11-02T17:00:02ZDan MahoneyClarifications in ARM about catalog zonesAt the bottom of the catalog zones syntax in the 9.14 ARM, the following example is listed for a catalog zone:
```
masters.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN A 192.0.2.2
label.masters.5960775ba382e7a4e092...At the bottom of the catalog zones syntax in the 9.14 ARM, the following example is listed for a catalog zone:
```
masters.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN A 192.0.2.2
label.masters.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN AAAA 2001:db8::2
label.masters.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN TXT "tsig_key"
allow-query.5960775ba382e7a4e09263fc06e7c00569b6a05c.zones.catalog.example. IN APL 1:10.0.0.0/24
```
This is a sort of uncommon usage which is basically like:
```
zone "hash" {
masters { 192.0.2.2; 2001:db8::2 key tsig_key; };
allow-query 10.0.0.0/24;
}
```
It's odd that a zone would be configured with one master with a TSIG key, and one without. I think the intent was to show the flexibility here, but if you want to show this it would be better to specify a second zone example that includes the TSIG key.
For the various examples given in this file, it would also be helpful to show the equivalent named.conf clause, to help understanding of a new concept.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1659Test that in tree and oot installs install the same set of files.2023-11-02T16:51:54ZMark AndrewsTest that in tree and oot installs install the same set of files.In the past we have had different files installed with in tree to oot builds. We should make sure we catch this in the CI.In the past we have had different files installed with in tree to oot builds. We should make sure we catch this in the CI.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1603Masterformat test failed2021-10-05T08:42:57ZMark AndrewsMasterformat test failedJob [#646262](https://gitlab.isc.org/isc-projects/bind9/-/jobs/646262) failed for e8bf82efc6dfffa7f17117617c6dfe32ce7ac96d:
```
S:masterfile:Fri Feb 7 09:08:49 UTC 2020
T:masterfile:1:A
A:masterfile:System test masterfile
I:masterfile:P...Job [#646262](https://gitlab.isc.org/isc-projects/bind9/-/jobs/646262) failed for e8bf82efc6dfffa7f17117617c6dfe32ce7ac96d:
```
S:masterfile:Fri Feb 7 09:08:49 UTC 2020
T:masterfile:1:A
A:masterfile:System test masterfile
I:masterfile:PORTRANGE:9300 - 9399
I:masterfile:test master file $INCLUDE semantics (1)
I:masterfile:test master file BIND 8 compatibility TTL and $TTL semantics (1)
I:masterfile:test of master file RFC1035 TTL and $TTL semantics (1)
I:masterfile:test that the nameserver is running with a missing master file (2)
I:masterfile:test that the nameserver returns SERVFAIL for a missing master file (3)
I:masterfile:test owner inheritence after $INCLUDE (4)
I:masterfile:exit status: 0
R:masterfile:PASS
E:masterfile:Fri Feb 7 09:08:55 UTC 2020
S:masterformat:Fri Feb 7 09:08:55 UTC 2020
T:masterformat:1:A
A:masterformat:System test masterformat
I:masterformat:PORTRANGE:9400 - 9499
I:masterformat:checking that master files in raw format loaded (1)
I:masterformat:checking raw format versions (2)
I:masterformat:checking source serial numbers (3)
I:masterformat:waiting for transfers to complete
I:masterformat:checking that slave was saved in raw format by default (4)
I:masterformat:checking that slave was saved in text format when configured (5)
I:masterformat:checking that slave was saved in 'full' style when configured (6)
I:masterformat:checking that slave formerly in text format is now raw (7)
I:masterformat:checking that large rdatasets loaded (8)
I:masterformat:checking format transitions: text->raw->map->text (9)
I:masterformat:checking format transitions: text->map->raw->text (10)
I:masterformat:checking map format loading with journal file rollforward (11)
I:masterformat:checking map format file dumps correctly (12)
I:masterformat:no response from ns3
I:masterformat:failed
No test directory: "/builds/isc-projects/bind9/bin/tests/masterformat"
I:masterformat:failed
I:masterformat:checking corrupt map files fail to load (bad file header) (13)
I:masterformat:checking corrupt map files fail to load (bad node header) (14)
I:masterformat:checking corrupt map files fail to load (bad node data) (15)
I:masterformat:checking map format zone is scheduled for resigning (compilezone) (16)
I:masterformat:checking map format zone is scheduled for resigning (signzone) (17)
I:masterformat:ns1 zone reload queued
I:masterformat:exit status: 1
R:masterformat:FAIL
E:masterformat:Fri Feb 7 09:10:11 UTC 2020
```https://gitlab.isc.org/isc-projects/bind9/-/issues/1602rpz system test failed because protoype responses timed out.2020-02-12T08:48:18ZMark Andrewsrpz system test failed because protoype responses timed out.Job [#646278](https://gitlab.isc.org/isc-projects/bind9/-/jobs/646278) failed for e8bf82efc6dfffa7f17117617c6dfe32ce7ac96d:
```
S:rpz:Fri Feb 7 09:09:39 UTC 2020
T:rpz:1:A
A:rpz:System test rpz
I:rpz:PORTRANGE:11200 - 11299
I:rpz:runni...Job [#646278](https://gitlab.isc.org/isc-projects/bind9/-/jobs/646278) failed for e8bf82efc6dfffa7f17117617c6dfe32ce7ac96d:
```
S:rpz:Fri Feb 7 09:09:39 UTC 2020
T:rpz:1:A
A:rpz:System test rpz
I:rpz:PORTRANGE:11200 - 11299
I:rpz:running native RPZ sub-test
I:rpz:checking QNAME rewrites (1)
I:rpz:'dig a0-1.tld2' wrong; diff dig.out-test1-2 proto.nxdomain
I:rpz:'dig a4-2.tld2' wrong; diff dig.out-test1-6 proto.nxdomain
I:rpz:'dig a4-2-cname.tld2' wrong; diff dig.out-test1-7 proto.nxdomain
I:rpz:'dig c1.crash2.tld3' wrong; diff dig.out-test1-24 proto.nxdomain
I:rpz:'dig a0-1.tld2 +dnssec' wrong; diff dig.out-test1-25 proto.nxdomain
I:rpz:'dig a0-1.tld2s +nodnssec' wrong; diff dig.out-test1-26 proto.nxdomain
I:rpz:'dig a0-1s-cname.tld2s +dnssec' wrong; diff dig.out-test1-28 proto.nxdomain
I:rpz:'dig a0-1.tld2s srv +nodnssec' wrong; diff dig.out-test1-31 proto.nxdomain
I:rpz:checking NXDOMAIN/NODATA action on QNAME trigger (2)
I:rpz:'dig a0-1.tld2 @10.53.0.6' wrong; diff dig.out-test1-1 proto.nxdomain
I:rpz:'dig a4-2.tld2 @10.53.0.6' wrong; diff dig.out-test1-4 proto.nxdomain
I:rpz:'dig a4-2-cname.tld2 @10.53.0.6' wrong; diff dig.out-test1-5 proto.nxdomain
I:rpz:'dig c1.crash2.tld3 @10.53.0.6' wrong; diff dig.out-test1-17 proto.nxdomain
I:rpz:'dig a0-1.tld2 +dnssec @10.53.0.6' wrong; diff dig.out-test1-18 proto.nxdomain
I:rpz:'dig a0-1s-cname.tld2s +dnssec @10.53.0.6' wrong; diff dig.out-test1-19 proto.nxdomain
I:rpz:checking IP rewrites (3)
I:rpz:'dig a4-2.tld2' wrong; diff dig.out-test2-4 proto.nxdomain
I:rpz:'dig a4-2.tld2 -tany' wrong; diff dig.out-test2-7 proto.nxdomain
I:rpz:'dig a3-1.tld2 -taaaa' wrong; diff dig.out-test2-9 proto.nxdomain
I:rpz:'dig c2.crash2.tld3' wrong; diff dig.out-test2-16 proto.nxdomain
I:rpz:'dig a7-1.tld2' wrong; diff dig.out-test2-18 proto.nxdomain
I:rpz:ns2 zone reload queued
I:rpz:ns2 zone reload queued
I:rpz:'dig a7-1.tld2' wrong; diff dig.out-test2-20 proto.nxdomain
I:rpz:checking radix tree deletions (4)
I:rpz:checking NSDNAME rewrites (5)
I:rpz:'dig a3-1.sub1.tld2' wrong; diff dig.out-test3-3 proto.nxdomain
I:rpz:'dig a3-1.subsub.sub1.tld2' wrong; diff dig.out-test3-4 proto.nxdomain
I:rpz:'dig a3-1.subsub.sub1.tld2 -tany' wrong; diff dig.out-test3-5 proto.nxdomain
I:rpz:'dig xxx.crash1.tld2' wrong; diff dig.out-test3-12 proto.nxdomain
I:rpz:checking NSIP rewrites (6)
I:rpz:'dig a3-1.tld2' wrong; diff dig.out-test4-1 proto.nxdomain
I:rpz:checking walled garden NSIP rewrites (7)
I:rpz:checking policy overrides (8)
```
```
[beetle:tests/system/rpz] marka% more proto.nxdomain
; <<>> DiG 9.15.8 <<>> +noauth +nocookie +noadd +time +tries -p 11200 nonexistent @10.53.0.2 -b10.53.0.2
;; global options: +cmd
;; connection timed out; no servers could be reached
[beetle:tests/system/rpz] marka%
```https://gitlab.isc.org/isc-projects/bind9/-/issues/1598Improve dnssec-policy documentation2020-03-09T08:22:58ZMatthijs Mekkingmatthijs@isc.orgImprove dnssec-policy documentation* [x] I don't see a mention of default or none in the ARM
* [x] Document that multiple rollovers at the same time is not supported (roll a key that has not yet been made active).
* [x] Key rollovers and timings around submitting the DS
*...* [x] I don't see a mention of default or none in the ARM
* [x] Document that multiple rollovers at the same time is not supported (roll a key that has not yet been made active).
* [x] Key rollovers and timings around submitting the DS
* [x] minor typo: should be "of" not "or"
Like <command>max-zone-ttl</command>, specifies the
maximum permissible TTL value in seconds. When loading a
zone file using a <option>masterfile-format</option> or
<constant>text</constant> or <constant>raw</constant>,
* [x] Document that PT0S (duration of 0 seconds) is infinite key lifetime
I'm trying to make it do insane things and I'm not sure why it isn't? I gave it a zsk lifetime of 6 hours,
and publish-safety 1 week. shouldn't it be prepublishing about 28 keys? but it's only created two zsk's and
only published one
You are pushing it to its limits and basically says: "I am afraid I can't let you do that Dave" - It follows
the policy and does one ZSK at a time. The lifetime for the first key will be 6 hours extended with a week. It
is not according to policy but as close as it safely can be
* [x] We probably need some warning logs when detecting such insanity.
* [x] ...and documentation of what to expect.
Some other suggestions:
* [x] Consider making the 'lifetime' keyword optional, with default zero if unspecified. consider adding 'unlimited' as a synonym for '0'.
* [x] Also suggest making the key-directory keyword optional
* [x] Add algorithm menmonic support so you could say "ksk algorithm ecdsa256;"
* [x] Forbid, or at least warn, if someone specifies a key length with an algorithm where that's predefined. it accepted "algorithm 13 2048" which I believe to be a silly value.
* [x] We need a way, via rndc zonestatus or some other command, to see what the current state of the keys are and when they're going to be changing to a new state (e.g. rumored to omnipresent). the log file says "wait 7500 seconds" or something if you run in debug mode but I haven't found any other way to figure it out
* [x] We need a way, via rndc or some other command, to signal that we have submitted the DS.
* [x] incidentally, why is zone-max-ttl not called max-zone-ttl? it's identical to the zone option and confusing for them to have two different nameshttps://gitlab.isc.org/isc-projects/bind9/-/issues/1595mkeys filesnames should not contain colons2020-03-04T02:08:52ZEvan Huntmkeys filesnames should not contain colons':' is a special character on windows, so if a view name contains one, then we should not use `<viewname>.mkeys` for a fileanme. It should be added to the `DISALLOW` string in `file.c` along with slash, backslash, and capital letters.':' is a special character on windows, so if a view name contains one, then we should not use `<viewname>.mkeys` for a fileanme. It should be added to the `DISALLOW` string in `file.c` along with slash, backslash, and capital letters.Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1594wait for netmgr to complete before starting systemd service2023-09-22T14:00:22Zkalfeherwait for netmgr to complete before starting systemd service### Description
I noticed that on some of my test servers, BIND fails to listen to some network interfaces on boot up because they are not yet available.
I'm using the COPR package (9.15.8)
This appears to be due to the following line ...### Description
I noticed that on some of my test servers, BIND fails to listen to some network interfaces on boot up because they are not yet available.
I'm using the COPR package (9.15.8)
This appears to be due to the following line in the file: isc-bind-named.service
```
After=network.target
```
### Request
The following might result in a more reliable start up
```
After=network-online.target
Wants=network-online.target
```
### Links / referencesMichał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1587Intermittent test failure in reclimit system test2023-11-02T16:51:52ZMatthijs Mekkingmatthijs@isc.orgIntermittent test failure in reclimit system testhttps://gitlab.isc.org/isc-projects/bind9/-/jobs/605399
```
...
--- test-reclimit ---
I:reclimit:count 51 (actual) != 50 (expected)
I:reclimit:failed
...
```https://gitlab.isc.org/isc-projects/bind9/-/jobs/605399
```
...
--- test-reclimit ---
I:reclimit:count 51 (actual) != 50 (expected)
I:reclimit:failed
...
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1573Rewrite qmin ans.py services2021-10-05T07:43:44ZWitold KrecickiRewrite qmin ans.py servicesLong-termWitold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1558libuv doesn't support pktinfo - we need to bind to all IPv6 interfaces explic...2023-11-02T16:44:01ZWitold Krecickilibuv doesn't support pktinfo - we need to bind to all IPv6 interfaces explicitlyIn 'old' code we only bound to all ipv6 interfaces on Windows - on Unices that supported it we bound to :: and then used pktinfo to determine which destination the packet was sent to. This doesn't work in libuv as there's no portable way...In 'old' code we only bound to all ipv6 interfaces on Windows - on Unices that supported it we bound to :: and then used pktinfo to determine which destination the packet was sent to. This doesn't work in libuv as there's no portable way - we need to bind to all interfaces.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1532'rndc nta -d' ought to report 'validate-except'2020-03-04T09:09:55ZEvan Hunt'rndc nta -d' ought to report 'validate-except'We can use 'rndc secroots' to list the trust anchors and 'rndc nta -d' to list the negative trust anchors, but there seems to be no way to view the permanent NTA's that are set up by `validate-except`. This seems potentially misleading.We can use 'rndc secroots' to list the trust anchors and 'rndc nta -d' to list the negative trust anchors, but there seems to be no way to view the permanent NTA's that are set up by `validate-except`. This seems potentially misleading.Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1450named-checkzone could use the filename for zone name if there's only one argu...2021-10-05T07:09:00ZEvan Huntnamed-checkzone could use the filename for zone name if there's only one argumentThis was a suggestion on twitter from Paul Wouters. `dnssec-signzone` does this, but `named-checkzone` doesn't.This was a suggestion on twitter from Paul Wouters. `dnssec-signzone` does this, but `named-checkzone` doesn't.Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1285Teeny tiny documentation update to Sortlist feature [BUGS 42615]2019-11-06T10:08:35ZCathy AlmondTeeny tiny documentation update to Sortlist feature [BUGS 42615]From [BUG ticket #42615](https://bugs.isc.org/Ticket/Display.html?id=42615) and [Support ticket #10120](https://support.isc.org/Ticket/Display.html?id=10120)
(This one is trivial to do by the way)
---
The sortlist statement can have m...From [BUG ticket #42615](https://bugs.isc.org/Ticket/Display.html?id=42615) and [Support ticket #10120](https://support.isc.org/Ticket/Display.html?id=10120)
(This one is trivial to do by the way)
---
The sortlist statement can have multiple matching address match lists with corresponding sorts defined for them.
The question arose - what if the address match lists are not mutually exclusive but overlap - which sort definition is used - first, or last, or are they merged in some fashion?
For example:
```
acl acl_netlist_1 { 10.1/16; 10.2.2.2; };
acl acl_netlist_2 { 10.2/16; 10.1.1.1; };
```
```
sortlist {
{ acl_netlist_1; { acl_sort1; }; };
{ acl_netlist_2; { acl_sort2; }; };
};
```
What happens to queries from clients and 10.2.2.2, since they match both acl_netlist_1 and acl_netlist_2?
The answer is that 'first match wins' so they will both get acl_sort_1 - but this is not clear from the ARM. Please can we add a sentence just to make this clear.https://gitlab.isc.org/isc-projects/bind9/-/issues/1279named-compilezone should be able to take input from STDIN2021-11-26T13:53:57ZPaul Hoffmannamed-compilezone should be able to take input from STDIN### Description
named-compilezone is a useful tool in scripts. Some of those scripts may have the zone that needs to be processed in memory instead of in a file.
### Request
Make the last argument of named-compilezone optional if anot...### Description
named-compilezone is a useful tool in scripts. Some of those scripts may have the zone that needs to be processed in memory instead of in a file.
### Request
Make the last argument of named-compilezone optional if another argument indicates that the input is from STDIN.Diego dos Santos FronzaDiego dos Santos Fronza