BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2021-04-06T16:27:07Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2585filter-a plugin2021-04-06T16:27:07ZMatthijs Mekkingmatthijs@isc.orgfilter-a pluginReverse the functionality of the 'filter-aaaa' plugin to omit A records instead of AAAA records.
This is useful especially in some IPv6-only environments. Sometimes, client software ignores system preferences and choses A over AAAA (e.g...Reverse the functionality of the 'filter-aaaa' plugin to omit A records instead of AAAA records.
This is useful especially in some IPv6-only environments. Sometimes, client software ignores system preferences and choses A over AAAA (e.g. 'NodeJS' does or used to do this). On an IPv6-only system, this will result in a failed connection attempt. If no 'happy eyeballs' is used, this will at least defer connection till after timeout, or worse it will make the connection impossible.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2485DNS protocol cleanup: require correct AA bit2023-08-16T16:51:42ZPetr Špačekpspacek@isc.orgDNS protocol cleanup: require correct AA bit### Description
Allegedly different resolvers treat AA bit in responses differently, and this is causing different operational problems for each implementation. PowerDNS and Knot Resolver have had issues with that.
Proposal by Peter va...### Description
Allegedly different resolvers treat AA bit in responses differently, and this is causing different operational problems for each implementation. PowerDNS and Knot Resolver have had issues with that.
Proposal by Peter van Dijk is to be strict on AA bit and punish non-compliance. Main motivation seems to be code simplification when it comes various combinations of NXDOMAIN/NOERROR without SOA RR and/or "extra" NS records in authority which are sometimes added as "good measure" but do not actually mean a referral.
Anecdotes from the field:
a) Ralf Weber from Akamai has some reservations:
> Given that a lot of people use resolvers in front of their authoritative servers who don't send AA I fail to envision what resolvers should do. If we drop non AA answers I expect huge portion of the Internet to go dark, though I don't have hard numbers on that.
b) Recent versions of PowerDNS switched to stricter mode and insist on AA bit being correct. A person from Deutsche Telecom claims this:
> To give a sense of possible impact, we have tens of millions of subscribers and only 5-10 cases per year estimated. So I guess nothing would "go dark" :slightly_smiling_face:
### Links / references
Thread https://chat.dns-oarc.net/community/pl/57pcpenfkf86tr8onmhn1q5a4a
Personally I argue this is
a) not significant enough
b) not widespread enough
to warrant full fledged flag day, but we can start being stricter on AA bit if we decide to do so. PowerDNS already went in that direction so first-mover disadvantage is already paid :-)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2478Consider making the build-time dependency on nghttp2 optional2021-07-14T18:34:16ZMichał KępieńConsider making the build-time dependency on nghttp2 optionalRight now, the `main` branch needs nghttp2 to be available in order for
BIND 9 to build at all. Since nghttp2 is only required for
DNS-over-HTTPS (DoH) support - which we promised to backport to BIND
9.16 at some point - it looks slight...Right now, the `main` branch needs nghttp2 to be available in order for
BIND 9 to build at all. Since nghttp2 is only required for
DNS-over-HTTPS (DoH) support - which we promised to backport to BIND
9.16 at some point - it looks slightly harsh to have a new, hard
requirement on another library (even if it is a rather ubiquitous and
not version-picky one), especially in light of a future BIND 9.16
backport.
We should probably discuss whether nghttp2 should be considered
mandatory for:
- BIND 9.17+
- ~~BIND 9.16~~[^1]
Any changes in this area should be "announced" in:
- `README.md`
- `PLATFORMS.md`
- release notes.
[^1]: Not a possibility any more as it has been decided that DoH support
will not be backported to BIND 9.16.August 2021 (9.11.35, 9.11.35-S1, 9.16.20, 9.16.20-S1, 9.17.17)https://gitlab.isc.org/isc-projects/bind9/-/issues/2394dig +short for MX when the record is broken gives confusing answer2022-04-26T13:36:40ZPaul Hoffmandig +short for MX when the record is broken gives confusing answerA confused user said that dig +short for an MX record did not report the preference level. The example he gave was:
```
# dig +short cyclonit.com MX
HDRedirect-LB7-5a03e1c2772e1c9c.elb.us-east-1.amazonaws.com.
```
When given without +sho...A confused user said that dig +short for an MX record did not report the preference level. The example he gave was:
```
# dig +short cyclonit.com MX
HDRedirect-LB7-5a03e1c2772e1c9c.elb.us-east-1.amazonaws.com.
```
When given without +short, the reason becomes clear:
```
# dig cyclonit.com MX
; <<>> DiG 9.16.10 <<>> cyclonit.com MX
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65526
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: b0e8599a68ce3729dc85d51e6003a03d038d9864e7c2e63c (good)
;; QUESTION SECTION:
;cyclonit.com. IN MX
;; ANSWER SECTION:
cyclonit.com. 10544 IN CNAME HDRedirect-LB7-5a03e1c2772e1c9c.elb.us-east-1.amazonaws.com.
;; AUTHORITY SECTION:
elb.us-east-1.amazonaws.com. 53 IN SOA ns-1826.awsdns-36.co.uk. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 60
```
Yep, it's the dreaded "CNAME and MX at the same level" issue. However, +short hides that in a confusing way.
Proposal: dig +short for broken names such as this should instead reply "CNAME target", or possibly "Bad CNAME target".Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2377Allow A records below an '_spf' label as a check-names exception2021-02-04T11:43:35ZMark AndrewsAllow A records below an '_spf' label as a check-names exceptionSPF uses A records for existence testing (exists rule). When "_spf" is used as a separating label this results in A records with non LDH owners.SPF uses A records for existence testing (exists rule). When "_spf" is used as a separating label this results in A records with non LDH owners.February 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2375dnssec-policy key rollover bug when more than two keys are involved2023-07-06T09:26:15ZMatthijs Mekkingmatthijs@isc.orgdnssec-policy key rollover bug when more than two keys are involved### Summary
When using `dnssec-policy`, key rollovers are scheduled automatically. If a key rollover is halted (because for example the DS was never uploaded), and a new key is introduced to replace the previous successor, at some point...### Summary
When using `dnssec-policy`, key rollovers are scheduled automatically. If a key rollover is halted (because for example the DS was never uploaded), and a new key is introduced to replace the previous successor, at some point `dnssec-policy` decides that having only the new key is a valid state, removing the two previous keys. This moves the zone into a bogus state, where the DS
in the parent mismatches the DNSKEY RRset in the child zone.
### BIND version used
9.16.9
### Steps to reproduce
Create a `dnssec-policy` with quick rollovers, wait until the third key is introduced, and then some more. At some point the keymgr decides to remove the first two keys.
### What is the current *bug* behavior?
The first two keys are removed from the zone too soon.
### What is the expected *correct* behavior?
All three keys should stay in the zone, until a valid `rndc dnssec -checkds` command is issued.
### Relevant configuration files
```
///
/// 20201209 DST, BIND 9.16 dnssec policy test
///
dnssec-policy "test" {
// Keys
keys {
csk key-directory lifetime 7d algorithm 13;
};
// Key timings
dnskey-ttl 3600;
publish-safety 1h;
retire-safety 1h;
// Zone parameters
max-zone-ttl 3600;
zone-propagation-delay 300;
// Parent parameters
parent-ds-ttl 1h;
parent-propagation-delay 1h;
};
zone "badware.ch" {
type master;
dnssec-policy test;
key-directory "/etc/bind/inline-signing-keys";
file "dynamic/badware.ch";
};
```
### Relevant logs and/or screenshots
https://dnsviz.net/d/badware.ch/X-MRAg/dnssec/
### Possible fixesFebruary 2021 (9.11.28, 9.11.28-S1, 9.16.12, 9.16.12-S1, 9.17.10)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2360dnstap-read: please modify to print query/response timestamps with milliseconds2023-05-05T10:34:18Zssbertilsondnstap-read: please modify to print query/response timestamps with milliseconds### Description
Desire to be able to use dnstap-read to track latency - milliseconds not just by seconds. Simple function call change in print_yaml from using existing libisc function isc_time_formatISO8601 to existing isc_time_formatI...### Description
Desire to be able to use dnstap-read to track latency - milliseconds not just by seconds. Simple function call change in print_yaml from using existing libisc function isc_time_formatISO8601 to existing isc_time_formatISO8601ms in 2 places. Am using this in a version modified from 9.16.6.
### Request
```
diff --git a/bin/tools/dnstap-read.c b/bin/tools/dnstap-read.c
index 5b15fa8153..2663668c08 100644
--- a/bin/tools/dnstap-read.c
+++ b/bin/tools/dnstap-read.c
@@ -230,13 +230,13 @@ print_yaml(dns_dtdata_t *dt) {
if (!isc_time_isepoch(&dt->qtime)) {
char buf[100];
- isc_time_formatISO8601(&dt->qtime, buf, sizeof(buf));
+ isc_time_formatISO8601ms(&dt->qtime, buf, sizeof(buf));
printf(" query_time: !!timestamp %s\n", buf);
}
if (!isc_time_isepoch(&dt->rtime)) {
char buf[100];
- isc_time_formatISO8601(&dt->rtime, buf, sizeof(buf));
+ isc_time_formatISO8601ms(&dt->rtime, buf, sizeof(buf));
printf(" response_time: !!timestamp %s\n", buf);
}
```
### Links / referencesMay 2023 (9.16.41, 9.16.41-S1, 9.18.15, 9.18.15-S1, 9.19.13)https://gitlab.isc.org/isc-projects/bind9/-/issues/2268RFC 8914 - Extended error for No Reachable Authority2023-07-11T10:01:59ZVicky Riskvicky@isc.orgRFC 8914 - Extended error for No Reachable AuthorityAnother error message support would like to see sooner is
22 - No Reachable AuthorityAnother error message support would like to see sooner is
22 - No Reachable Authorityhttps://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/2225named-checkconf: Validate that A records contain valid IP address (e.g. not a...2020-10-22T03:50:17ZElijah Lynnnamed-checkconf: Validate that A records contain valid IP address (e.g. not a CNAME)### Description
Recently ran into an issue with `named` failing to start on a deployment which appears to be due to the following type of entry:
`example IN A example.com` (no trailing period either)
We discussed adding some val...### Description
Recently ran into an issue with `named` failing to start on a deployment which appears to be due to the following type of entry:
`example IN A example.com` (no trailing period either)
We discussed adding some validation which led us to the `named-checkconf` tool, as referenced in https://www.cyberciti.biz/tips/howto-linux-unix-check-dns-file-errors.html. The tool doesn't appear to check for valid IPs and I think it could be a good place to put this logic. I tested locally and it doesn't appear to catch an invalid IP for an A record.
### Request
Can we consider adding validation support for valid IP addresses for A records in `named-checkconf`?
### Links / referenceshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2153Rebuild RBTDB while rehashing2021-10-05T15:35:42ZBrian ConryRebuild RBTDB while rehashing@ondrej had an idea related to rebuilding the RBTDB while rehashing as a means of clearing out empty interior nodes.
This issue is a reminder.
Description to be updated and amended.@ondrej had an idea related to rebuilding the RBTDB while rehashing as a means of clearing out empty interior nodes.
This issue is a reminder.
Description to be updated and amended.BIND 9.19.xOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2096isc_refcount_decrement needs acquire release memory ordering.2020-09-02T10:19:49ZMark Andrewsisc_refcount_decrement needs acquire release memory ordering.September 2020 (9.11.23, 9.11.23-S1, 9.16.7, 9.17.5)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2088Listen explicitly on exact addresses without checking their presence2023-11-02T17:00:02ZPetr MenšíkListen explicitly on exact addresses without checking their presence### Description
Listen explicitly on exact addresses without checking their presence
### Request
Currently, listening on addresses listen in options are handled in [interfacemgr](https://gitlab.isc.org/isc-projects/bind9/-/blob/main/l...### Description
Listen explicitly on exact addresses without checking their presence
### Request
Currently, listening on addresses listen in options are handled in [interfacemgr](https://gitlab.isc.org/isc-projects/bind9/-/blob/main/lib/ns/interfacemgr.c#L992). Because of the way it is used, it requires working enumeration of existing addresses to listen on them.
There are some cases when enumerating would not work, but binding for listening would anyway.
For example, Linux kernel allows listening on address 127.0.0.2 without configuration of anything special. Just have 127.0.0.1/8 network configured on lo interface.
```
options {
listen-on { 127.0.0.2; };
};
```
Above configuration would not work. Also, some special quirks useful for testing cannot work, unless they provide also interface enumeration abstraction. This breaks [socker_wrapper](https://cwrap.org/socket_wrapper.html). Similar requirement is also for [deckard](https://gitlab.nic.cz/knot/deckard).
My request is to allow explicit IPv4 and IPv6 address to listen and bind without requirement to find it in interface list. It iterates over interfaces now and applies dns_acl_match to each interface address. It seems it is hard to extract exact address in ACL list in easy way. Either API for examination of ACL networks or additional list for addresses would be required.
I would like listening for UDP queries would try listening on address (no network range, but single unicast address). It it fails, retry on interface scan. But if it succeeds, allow listeners on it.
It is interesting control channel can listen quite nice this way on (alternative) localhost.
```
controls {
inet 127.0.0.2 port 2953
allow { 127.0.0.2; } keys { "rndc-key"; };
};
```
```
# test-named.conf
include "/etc/rndc.key";
options {
listen-on port 2053 { 127.0.0.2; };
};
statistics-channels {
inet 127.0.0.3 port 8080 allow { localhost; };
};
controls {
inet 127.0.0.4 port 2953
allow { localhost; } keys { "rndc-key"; };
};
```
named running this configuration listens only on control and statistics channel.
```
$ ss -lntp | grep named
LISTEN 0 4096 127.0.0.4:2953 0.0.0.0:* users:(("named",pid=1290435,fd=37))
LISTEN 0 4096 127.0.0.3:8080 0.0.0.0:* users:(("named",pid=1290435,fd=36))
```
### Links / references
1. https://cwrap.org/socket_wrapper.html
2. https://gitlab.nic.cz/knot/deckardNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1976LMDB 0.9.26 will break "rndc reconfig" (+ other LMDB issues)2020-08-20T19:36:01ZMichał KępieńLMDB 0.9.26 will break "rndc reconfig" (+ other LMDB issues)The way BIND uses LMDB is at odds with what the authors of that library
expect and intend. ~~While I cannot find any mention of that
recommendation in the [docs][1], the LMDB author himself [says][2] that
"you should only ever open an e...The way BIND uses LMDB is at odds with what the authors of that library
expect and intend. ~~While I cannot find any mention of that
recommendation in the [docs][1], the LMDB author himself [says][2] that
"you should only ever open an environment once in any particular
process".~~[^1] BIND calls `mdb_env_open()` and `mdb_env_close()`
[multiple][3] [times][4] within the lifetime of a single process, but
AFAICT, doing that in an "open → close → open → close → ..." type of
sequence works just fine. Unfortunately, BIND does something worse and
it is related to what happens during an `rndc reconfig`: new views are
configured first and only after that happens, the old views get torn
down. For LMDB, this means that we call `mdb_env_open()` for a
previously `mdb_env_open()`ed LMDB environment *from the same process*
and then close the old "instance" of the environment. I am not sure we
ever cared about this a lot because it seemed to Just Work™. It did
[bite us][5] once (see 40a90fbf89738c1aa867a5f09ef7243ef3ae52e4), but we
worked around the problem and moved on.
Still, the [docs][6] clearly state:
> Do not have open an LMDB database twice in the same process at the
> same time.
We are not getting away with it as easily this time around.
In December 2019, the FreeBSD port for LMDB [started using robust
mutexes][7], which FreeBSD started supporting in the 11.0 release. This
broke LMDB-related BIND system tests on FreeBSD. I investigated it and
my conclusion was that the problem was likely caused by some low-level
FreeBSD issue that was over my head. I [reported it][8] and it was
ultimately determined to be an [undefined-behavior-type issue][9] with
what the FreeBSD threading library does when a mutex is unmapped from
memory without being destroyed first. This prompted LMDB maintainers to
merge a [fix][10] which causes LMDB to destroy locktable mutexes when
`mdb_env_close()` is called and the process calling that function is the
only remaining user of the LMDB environment. This change has been
already [applied][11] as a patch to the FreeBSD port of LMDB 0.9.24 and
I fully expect it to be a part of the next LMDB release, i.e. version
0.9.26, as it has also been [merged][12] into the LMDB 0.9 release
branch.
The problem is that the aforementioned fix breaks `rndc reconfig` on
*all* platforms we test on because it breaks the kludge we have been
effectively relying on so far. This is what we do (note that all calls
are for the same LMDB environment on disk, even though the pointers used
below - `envA` and `envB` - are different!):
1. `mdb_env_open(envA)`
2. (`rndc reconfig` is invoked)
3. `mdb_env_open(envB)`
4. `mdb_env_close(envA)`
Since all of this happens within a single process, the `mdb_env_close()`
call from step 4 destroys the locktable mutexes (because it correctly
observes that the current process is the only remaining user of the LMDB
environment at hand), which prevents any subsequent `mdb_txn_begin()`
calls from succeeding. Here is an example system test job which
triggers the problem:
https://gitlab.isc.org/isc-projects/bind9/-/jobs/975003
This problem affects all maintained BIND branches.
The only way I can see to work around the problem yet again without
redesigning the whole thing from the ground up is to employ `MDB_NOLOCK`
and use a mutex for controlling concurrent access to the LMDB database
ourselves. What saves us here is that we already [have][13] a mutex
handy and we can just broaden its scope without bumping the API versions
for our libraries in 9.11. I will submit a merge request implementing
this workaround shortly.
Honestly, though, I am afraid that this will just be another bandaid.
Call me an Eastern European grumbler, but I am not happy with the way
LMDB support has been implemented in BIND. We seem to have [chosen][14]
LMDB because it was apparently performing slightly better than SQLite 3.
The thing is, I do not think our use case needs fast *concurrent* access
to the database; we need something that allows us to add, remove, and
query zone configuration *faster than scanning a flat file sequentially*
(which is what pretty much any sane database should be capable of).
LMDB lives up to its promises about speed, but it comes with a set of
caveats that we need to cater for, which complicates our code given how
BIND works. To make things worse, our implementation of LMDB uses
`#ifdef` guards, which means it shares *some* of the code with the
non-LMDB variant (NZF, a text file), but not *all* of it, which makes
the code harder to follow than it has to be.
Here are some ideas for what we can do in the future to improve the
state of things:
- Rework the LMDB implementation in BIND so that it matches the
intended use of that library. This could be achieved by keeping a
global list of reference-counted LMDB environment objects, each of
which would be associated with a specific view name (not view
instance!). This approach should allow `rndc reconfig` to do
without calling `mdb_env_open()` or `mdb_env_close()`. I think such
a change would be too severe to go into 9.16, though.
- Use a different database that will likely be slower than LMDB, but
might be simpler to use.
- Move LMDB support to a module (easier said than done).
- Drop LMDB support altogether :-)
[1]: http://www.lmdb.tech/doc/group__mdb.html
[2]: https://bugs.openldap.org/show_bug.cgi?id=9278#c4
[3]: https://gitlab.isc.org/isc-projects/bind9/-/blob/bcbc7e2b10f85451466a3cc098f15cddd019ae0f/bin/named/server.c#L12796
[4]: https://gitlab.isc.org/isc-projects/bind9/-/blob/bcbc7e2b10f85451466a3cc098f15cddd019ae0f/lib/dns/view.c#L2135
[5]: https://bugs.isc.org/Ticket/Display.html?id=46556#txn-508940
[6]: http://www.lmdb.tech/doc/index.html
[7]: https://svnweb.freebsd.org/ports?view=revision&revision=519246
[8]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244493
[9]: https://bugs.openldap.org/show_bug.cgi?id=9278#c3
[10]: https://git.openldap.org/openldap/openldap/-/commit/2fd44e325195ae81664eb5dc36e7d265927c5ebc
[11]: https://svnweb.freebsd.org/ports?view=revision&revision=539380
[12]: https://git.openldap.org/openldap/openldap/-/commit/f683ffdc81d0edb20437cb7d655cf15a60e31249
[13]: https://gitlab.isc.org/isc-projects/bind9/-/blob/d35101e4338c3254113b8f51d178ac44170d412f/lib/dns/include/dns/view.h#L227
[14]: https://bugs.isc.org/Ticket/Display.html?id=39837#txn-430786
[^1]: The docs *do* in fact state the same thing, see below.
August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)https://gitlab.isc.org/isc-projects/bind9/-/issues/1939kasp system test intermittent test failures for "rumoured.kasp" zone2020-07-03T16:24:36ZMichał Kępieńkasp system test intermittent test failures for "rumoured.kasp" zoneSome checks recently added to the `kasp` system test fail very often as
they do not tolerate certain events taking more than 1 second to happen:
```
I:kasp:check key timing metadata for key KEY1 id 49258 zone rumoured.kasp (110)
I:kasp:...Some checks recently added to the `kasp` system test fail very often as
they do not tolerate certain events taking more than 1 second to happen:
```
I:kasp:check key timing metadata for key KEY1 id 49258 zone rumoured.kasp (110)
I:kasp:check key timing metadata for key KEY2 id 10506 zone rumoured.kasp (111)
I:kasp:check key timing metadata for key KEY3 id 25185 zone rumoured.kasp (112)
I:kasp:error: mismatch publish comment in ns3/Krumoured.kasp.+005+25185.key (expected 20200615091205)
I:kasp:error: mismatch publish in ns3/Krumoured.kasp.+005+25185.private (expected 20200615091205)
I:kasp:error: mismatch publish in ns3/Krumoured.kasp.+005+25185.state (expected 20200615091205)
I:kasp:error: mismatch active comment in ns3/Krumoured.kasp.+005+25185.key (expected 20200616091205)
I:kasp:error: mismatch active in ns3/Krumoured.kasp.+005+25185.private (expected 20200616091205)
I:kasp:error: mismatch active in ns3/Krumoured.kasp.+005+25185.state (expected 20200616091205)
I:kasp:error: mismatch retired comment in ns3/Krumoured.kasp.+005+25185.key (expected 20210616091205)
I:kasp:error: mismatch retired in ns3/Krumoured.kasp.+005+25185.private (expected 20210616091205)
I:kasp:error: mismatch retired in ns3/Krumoured.kasp.+005+25185.state (expected 20210616091205)
I:kasp:error: mismatch removed comment in ns3/Krumoured.kasp.+005+25185.key (expected 20210626101705)
I:kasp:error: mismatch removed in ns3/Krumoured.kasp.+005+25185.private (expected 20210626101705)
I:kasp:error: mismatch removed in ns3/Krumoured.kasp.+005+25185.state (expected 20210626101705)
I:kasp:failed
```
Meanwhile, in the artifacts:
```
$ cat bin/tests/system/kasp/ns3/Krumoured.kasp.+005+25185.key
; This is a zone-signing key, keyid 25185, for rumoured.kasp.
; Created: 20200615091204 (Mon Jun 15 09:12:04 2020)
; Publish: 20200615091204 (Mon Jun 15 09:12:04 2020)
; Activate: 20200616091204 (Tue Jun 16 09:12:04 2020)
; Inactive: 20210616091204 (Wed Jun 16 09:12:04 2021)
; Delete: 20210626101704 (Sat Jun 26 10:17:04 2021)
rumoured.kasp. 1234 IN DNSKEY 256 3 5 AwEAAbmPnkXcnAF0iTlpP57eQnoDD05ldTahTcUkOUVaeRqF1gSpYYU6 zp9mQrmYty57kLYe7EuG6xbPHIK2DT+7sAQxGM+J+oFLxFKkxCQE+Cm6 ubhaZZ5sbBpwQMy06iuZFJ3pNFT2Q1FzIz4zCjqbnupySShsC34SsvGT zgExa/73Jy9f7k8/8JT12mbcNYByamiSnvHzMTdyqGA/jiruRPRApgYG +Gh+nS0inf5r9pX/rzu54XrZ/n8CNYAYvp2wWgIO6uWJvDgj2oszgKn4 HUTsS/x6hu+CHiFeSOZPAyW2fXVRUTqARnDzLedyupO3WNgRVipBtE/X iwE=
```
Example instances of this failure mode taken from just one pipeline:
- https://gitlab.isc.org/isc-private/bind9/-/jobs/953093
- https://gitlab.isc.org/isc-private/bind9/-/jobs/953097
- https://gitlab.isc.org/isc-private/bind9/-/jobs/953103July 2020 (9.11.21, 9.11.21-S1, 9.16.5, 9.17.3)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1890automation of DS Record submit to registrar/parent, integrated with 'new' ka...2021-10-05T14:46:01Zpgndautomation of DS Record submit to registrar/parent, integrated with 'new' kasp/dnssec-policy support in bind### Description
i'm migrating/implementing the new `dnssec-policy` usage & KASP workflow in my bind 9.16.3.
the new policy does a nice job of streamlining the signing/key mgmt.
after key generation/rotation, the 'last step' is subm...### Description
i'm migrating/implementing the new `dnssec-policy` usage & KASP workflow in my bind 9.16.3.
the new policy does a nice job of streamlining the signing/key mgmt.
after key generation/rotation, the 'last step' is submitting new/changed DS Records to the relevant registrar
i'd like to automate the process of submitting generated DS Records to the registrar/parent using a capable registrar's DNSSEC API.
as i understand, there is neither any mechanism in Bind for automating the DS Record submit, nor is there
an external hook mechanism to external scripts that can handle the task.
offline, it's been suggested to me that with the current version of bind, a 'best' approach would be to write a simple script that checks for the existence of the CDS/CDNSKEY RRset in each signed zone.
then, when a new record is added, trigger a submission of the DS to the parent. and, similarly, when a record is removed, trigger a withdrawal of the DS.
rather than re-inventing the wheel ... i'm guessing i'm not the only one who'd like to automate this.
### Request
an additional response on ML
> This is where we need to get the registrars to follow standards. They are written
> so everyone doesn’t have to cobble together ad-hoc solutions. Hourly scans of all
> the DNSSEC delegations by the registrars would do.
>
> Personally I prefer push solutions but I couldn’t get the IETF to agree.
> https://tools.ietf.org/html/draft-andrews-dnsop-update-parent-zones-04
sounds reasonable. at very least, better than nothing.
in the absence of a standards-based solution, integrated in bind's dnssec-policy/kasp feature set, an option for script/execution hooks in bind to external scripts, would be a good 1st step, even if ad-hoc
e.g., "if when change in DS Record in local bind, then fire this external script which will manage the DS submit/withdraw via API to registrar"
failing any/all of that^, a well documented example of a completely de-coupled solution, independent of bind itself, ideally registrar/API agnostic, but demonstrated to work, would be useful.
that's of course doable -- but again, ad-hoc, and seems a step backwards given the nice progress with dnssec-policy/kasp simplifications in recent versions.
### Links / referencesBIND 9.19.xMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/1885checking for libuv... checking for libuv >= 1.0.0... no configure: error: lib...2020-05-27T13:49:16ZJim DeCarochecking for libuv... checking for libuv >= 1.0.0... no configure: error: libuv not foundSystem=Solaris 11.4 x86 64 bit virtual machine on VMware. Upgrading BIND from 9.14.9 to 9.16.3. New dependency libuv--has additional dependencies: pkg-config, automake, m4, libtool, autoconf. Installed dependencies + libuv-v1.38.0. ....System=Solaris 11.4 x86 64 bit virtual machine on VMware. Upgrading BIND from 9.14.9 to 9.16.3. New dependency libuv--has additional dependencies: pkg-config, automake, m4, libtool, autoconf. Installed dependencies + libuv-v1.38.0. ./configure phase of BIND install throws the above error message. ran "find / -name libuv* -print":
/usr/local/lib/libuv.so
/usr/local/lib/libuv.la
/usr/local/lib/libuv.so.1
/usr/local/lib/libuv.a
/usr/local/lib/libuv.so.1.0.0
/usr/local/lib/pkgconfig/libuv.pc
/usr/include/sys/libuvfs_ki.h
/usr/include/libuvfs.h
/usr/lib/amd64/libuvfs.so
/usr/lib/amd64/libuvfs.so.1
I am fairly new to this so I am unsure what the issue is. It does not look like libuv binaries were installed, but I am not sure. Any help would be appreciated.https://gitlab.isc.org/isc-projects/bind9/-/issues/1879ARM and named man page incorrect regarding -U and number of listeners2024-02-14T14:48:26ZCathy AlmondARM and named man page incorrect regarding -U and number of listenersAs verified in 9.16.3 ARM. From [Support ticket #16280](https://support.isc.org/Ticket/Display.html?id=16280)
The ARM still says (about the options for starting named):
```
-U #listeners
Use #listeners worker threads to listen for inc...As verified in 9.16.3 ARM. From [Support ticket #16280](https://support.isc.org/Ticket/Display.html?id=16280)
The ARM still says (about the options for starting named):
```
-U #listeners
Use #listeners worker threads to listen for incoming UDP packets on each address. If
not specified, named will calculate a default value based on the number of detected CPUs:
1 for 1 CPU, and the number of detected CPUs minus one for machines with more than 1
CPU. This cannot be increased to a value higher than the number of CPUs. If -n has been
set to a higher value than the number of detected CPUs, then -U may be increased as high
as that value, but no higher. On Windows, the number of UDP listeners is hardwired to 1
and this option has no effect.
```
This is in fact untrue - we're using '-n' throughout (apart from Windows), as of 9.12 and up.
E.g. from named starting up:
> ...
> 16-Apr-2020 05:51:48.172 found 24 CPUs, using 24 worker threads
> 16-Apr-2020 05:51:48.172 using 24 UDP listeners per interface
> 16-Apr-2020 05:51:48.201 using up to 21000 sockets
> ...
I expect this changed post-9.11 at some point when we changed how the legacy server sockets code works.
Please fix the ARM and man page appropriately (maybe in the next maintenance releases?)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1801Launchpad PPA for Ubuntu 20.04 LTS (Focal Fossa)2021-05-14T07:57:09ZTobias GüntherLaunchpad PPA for Ubuntu 20.04 LTS (Focal Fossa)Similar to https://gitlab.isc.org/isc-projects/bind9/-/issues/1294 I would like to request the release in the repository for the now released Ubuintu 20.04 codenamed: "focal fossa"
Thanks for the great work!Similar to https://gitlab.isc.org/isc-projects/bind9/-/issues/1294 I would like to request the release in the repository for the now released Ubuintu 20.04 codenamed: "focal fossa"
Thanks for the great work!https://gitlab.isc.org/isc-projects/bind9/-/issues/1761BIND fails to run with new libuv 1.362022-06-09T09:35:18ZKlemen MihevcBIND fails to run with new libuv 1.36<!--
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 ...<!--
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
If i upgrade libuv to 1.36, released today bind failes to start and crashes. Recompile of bind does not help.
### BIND version used
```
BIND 9.16.1 (Stable Release) <id:d497c32>
running on Linux x86_64 5.6.4-gentoo #1 SMP Mon Apr 13 17:04:45 CEST 2020
built by make with '--build=x86_64-pc-linux-gnu' '--host=x86_64-pc-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--docdir=/usr/share/doc/bind-9.16.1' '--htmldir=/usr/share/doc/bind-9.16.1/html' '--with-sysroot=/' '--libdir=/usr/lib64' '--prefix=/usr' '--sysconfdir=/etc/bind' '--localstatedir=/var' '--with-libtool' '--enable-full-report' '--without-readline' '--with-openssl=/usr' '--enable-linux-caps' '--disable-dnsrps' '--disable-dnstap' '--disable-fixed-rrset' '--with-dlz-bdb' '--with-dlopen' '--with-dlz-filesystem' '--with-dlz-stub' '--with-gssapi' '--without-json-c' '--without-dlz-ldap' '--with-dlz-mysql' '--without-dlz-odbc' '--without-dlz-postgres' '--without-lmdb' '--with-python' '--with-libxml2' '--with-zlib' 'build_alias=x86_64-pc-linux-gnu' 'host_alias=x86_64-pc-linux-gnu' 'CFLAGS=-march=native -pipe -O3 -fomit-frame-pointer -I/usr/include/db6.0' 'LDFLAGS=-Wl,-O3 -Wl,--as-needed -Wl,--sort-common -Wl,--hash-style=gnu -L/usr/lib64 -ldl' 'PKG_CONFIG_PATH=/usr/lib64/pkgconfig'
compiled by GCC 9.3.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 libxml2 version: 2.9.9
linked to libxml2 version: 20909
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
threads support is enabled
```
### Steps to reproduce
Upgrade to new libuv 1.36, restart bind.
### What is the current *bug* behavior?
Crash with following error:
```
15-Apr-2020 23:05:57.838 general: critical: netmgr.c:1000: REQUIRE(worker->recvbuf_inuse) failed, back trace
15-Apr-2020 23:05:57.838 general: critical: #0 0x5629318abbaf in ??
15-Apr-2020 23:05:57.838 general: critical: #1 0x7fc037259d0c in ??
15-Apr-2020 23:05:57.838 general: critical: #2 0x7fc037271eda in ??
15-Apr-2020 23:05:57.838 general: critical: #3 0x7fc0372768fb in ??
15-Apr-2020 23:05:57.838 general: critical: #4 0x7fc03615beea in ??
15-Apr-2020 23:05:57.838 general: critical: #5 0x7fc03615c4eb in ??
15-Apr-2020 23:05:57.838 general: critical: #6 0x7fc03615edd0 in ??
15-Apr-2020 23:05:57.838 general: critical: #7 0x7fc03614e0ca in ??
15-Apr-2020 23:05:57.838 general: critical: #8 0x7fc0372740e9 in ??
15-Apr-2020 23:05:57.838 general: critical: #9 0x7fc03646cea7 in ??
15-Apr-2020 23:05:57.838 general: critical: #10 0x7fc03639ee8f in ??
15-Apr-2020 23:05:57.838 general: critical: exiting (due to assertion failure)
```
### Possible fixes
Reverting libuv back to 1.35 helps :)May 2020 (9.11.19, 9.11.19-S1, 9.14.12, 9.16.3)