BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2018-11-22T10:30:00Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/723Use thread annotations2018-11-22T10:30:00ZOndřej SurýUse thread annotationsClang 8 (and maybe earlier) has support for Thread Safety Analysis:
https://clang.llvm.org/docs/ThreadSafetyAnalysis.html
that allows thread annotations like `GUARDED_BY`, `REQUIRES(...)` and others to annotate variables, pointers and ...Clang 8 (and maybe earlier) has support for Thread Safety Analysis:
https://clang.llvm.org/docs/ThreadSafetyAnalysis.html
that allows thread annotations like `GUARDED_BY`, `REQUIRES(...)` and others to annotate variables, pointers and functions with hints for the analysis engine.Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/722Refactor RBT2023-10-31T11:31:45ZOndřej SurýRefactor RBT(This is just a placeholder for future ideas for refactoring some RBT...)
Since RBT was invented in seventies, there has been some improvements to the algorithm since, namely:
* Lock-Free Red-Black Trees Using CAS
* https://www.cs.um...(This is just a placeholder for future ideas for refactoring some RBT...)
Since RBT was invented in seventies, there has been some improvements to the algorithm since, namely:
* Lock-Free Red-Black Trees Using CAS
* https://www.cs.umanitoba.ca/~hacamero/Research/RBTreesKim.pdf
* http://swapnil-pimpale.github.io/lock-free-BST/
* Left-leaning Red-Black Trees:
* http://www.cs.princeton.edu/~rs/talks/LLRB/RedBlack.pdf
* http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.139.282
* http://www.cs.princeton.edu/~rs/talks/LLRB/LLRB.pdf
* http://www.mew.org/~kazu/proj/red-black-tree/
* http://25thandclement.com/~william/projects/llrb.h.html
* OpenBSD's `<sys/tree.h>`:
* https://ftp.netbsd.org/pub/NetBSD/NetBSD-current/src/sys/sys/tree.hBIND 9.19.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/721Performance impact of various features2022-06-03T10:15:20ZVicky Riskvicky@isc.orgPerformance impact of various features### Description
ISC support gets a lot of questions about how to improve BIND server performance, and whether enabling a specific feature will improve or degrade performance.
Users considering enabling various features, including thos...### Description
ISC support gets a lot of questions about how to improve BIND server performance, and whether enabling a specific feature will improve or degrade performance.
Users considering enabling various features, including those intended to improve performance, have no guidelines about what to expect. Today, all they can do is enable the feature and wait and see if performance goes up or down. Operators of highly available systems can't be expected to experiment on production servers when there is a performance problem.
Features that do or could be expected to impact performance include: RRL, fetches per server, minimal responses, prefetch, with-tuning-large, dnstap, query logging, logging level settings, DNSSEC validation(?), RPZ (?), <add others>
### Request
Realizing that local traffic and platform will affect the results, can we profile these features in a lab setting and provide some rules of thumb on the likely impact such as:
* enabling this feature is likely to cost you 8 - 12% QPS performance?
* enabling this feature is likely to improve performance 2 - 5% if you have, eg. a large number of zones with few records in each
* enabling this feature is likely to chew up another x% of your memory (in the XYZ scenario)
It would be very helpful to figure out a way to profile resolvers as well as authoritative servers. I realize this is a hard problem and would require getting a query sample from some operator(s), possibly via OARC (to ensure anonymity).
the interesting metrics include:
- queries per second that can be successfully responded to
- memory utilization (platform statistic)
- cache hit rateNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/713Use atomics instead of locks in isc_mem2019-05-10T21:20:28ZOndřej SurýUse atomics instead of locks in isc_memBIND 9.15.xOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/704named fails to generate missing DNSSEC signatures for NSEC3 records generated...2023-11-02T16:25:43ZMichał Kępieńnamed fails to generate missing DNSSEC signatures for NSEC3 records generated by a previous instanceIf NSEC3 chain creation is requested when no signing keys are available, NSEC3 records will be created but not signed. If `named` is shutdown in the middle of such a chain creation process and subsequently restarted, NSEC3 records gener...If NSEC3 chain creation is requested when no signing keys are available, NSEC3 records will be created but not signed. If `named` is shutdown in the middle of such a chain creation process and subsequently restarted, NSEC3 records generated by the previous `named` instance will remain unsigned.
This is due to the fact that when `named` is restarted, NSEC3 chain creation is started from scratch (since database iterator state is not maintained between restarts) and if a pre-existing NSEC3 record is found by `dns_nsec3_addnsec3()`, it will [first remove the old record and then re-add an identical one][1]. This is not an issue in itself but the subsequent call to `do_one_tuple()` involves [invoking `dns_diff_appendminimal()`][2], which in turn removes changes which cancel each other out from the diff structure. In the case of `dns_nsec3_addnsec3()`, the diff structure in question is the one that is subsequently [passed to `dns__zone_updatesigs()`][3], which means that in order for any NSEC3 record to be (re)signed, it must be present in that diff structure; this will be the case for newly created NSEC3 records but not for these which were already present in the zone database; it will also not be an issue for records which were both pre-existing and signed before `named` was restarted since their signatures would simply be preserved.
(Related to [Support RT #13752][4])
[1]: https://gitlab.isc.org/isc-projects/bind9/blob/026817bd9c6c58c8ee98cccf12a9308b0ed8f25a/lib/dns/nsec3.c#L707-716
[2]: https://gitlab.isc.org/isc-projects/bind9/blob/026817bd9c6c58c8ee98cccf12a9308b0ed8f25a/lib/dns/nsec3.c#L318
[3]: https://gitlab.isc.org/isc-projects/bind9/blob/026817bd9c6c58c8ee98cccf12a9308b0ed8f25a/lib/dns/zone.c#L8080-8082
[4]: https://support.isc.org/Ticket/Display.html?id=13752Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/697Do not attempt to generate DNSSEC records when required keys are not present2022-03-01T09:36:55ZMichael McNallyDo not attempt to generate DNSSEC records when required keys are not present### Description
Recently a customer who is responsible for a very large zone accidentally initiated resigning when no ZSK was present (they keep it off-line and only mount it when required.) The results were not good.
### Request
If ...### Description
Recently a customer who is responsible for a very large zone accidentally initiated resigning when no ZSK was present (they keep it off-line and only mount it when required.) The results were not good.
### Request
If BIND cannot properly perform a signing action because required keys are not present it should fail (loudly) without altering the zone.
### Links / references
https://support.isc.org/Ticket/Display.html?id=13752Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/696Suppress duplicate NSEC3 chain generation requests via rndc.2023-11-02T16:32:28ZMark AndrewsSuppress duplicate NSEC3 chain generation requests via rndc.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/695dnssec-verify needs to better handle incomplete NSEC3 chains without a NSEC3P...2023-11-02T16:32:28ZMark Andrewsdnssec-verify needs to better handle incomplete NSEC3 chains without a NSEC3PARAMThese sort chains should just be a notice. They could be in the process of being added or removed.
Additionally dnssec-verify should report the chain's parameters when reporting a error or notice.These sort chains should just be a notice. They could be in the process of being added or removed.
Additionally dnssec-verify should report the chain's parameters when reporting a error or notice.Not plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/691Add thread safety testing in the CI2021-03-04T15:27:01ZOndřej SurýAdd thread safety testing in the CIWe should expand our testing in our CI to test for thread safety.
* It will need some annotation for parts that are not synchronized, but safe
* Both Helgrind and ThreadSanitizer should be used
Let's start by doing comparative tests on...We should expand our testing in our CI to test for thread safety.
* It will need some annotation for parts that are not synchronized, but safe
* Both Helgrind and ThreadSanitizer should be used
Let's start by doing comparative tests on the release branches in the Jenkins CI, and build the tools to compare the TS and Helgrind results, and use those tools to have a GitLab CI job that would not allow regressions.Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/690Systematic concurrency testing of named and other BIND 9 tools2023-11-02T16:32:28ZOndřej SurýSystematic concurrency testing of named and other BIND 9 toolsWe should add systematic concurrency testing to our CI, here are some links to get us started:
https://dl.acm.org/citation.cfm?id=1985824
https://www.faculty.ece.vt.edu/chaowang/pubDOC/Wang11HaPSet.pdf
https://insights.sei.cmu.edu/sei...We should add systematic concurrency testing to our CI, here are some links to get us started:
https://dl.acm.org/citation.cfm?id=1985824
https://www.faculty.ece.vt.edu/chaowang/pubDOC/Wang11HaPSet.pdf
https://insights.sei.cmu.edu/sei_blog/2014/10/thread-safety-analysis-in-c-and-c.html
http://diy.inria.fr + http://diy.inria.fr/linux/
http://www.1024cores.net/home/relacy-race-detector
And on Windows:
https://archive.codeplex.com/?p=chesstool
https://pdfs.semanticscholar.org/186e/82657c803bf9f5f58be4d6ff17d1420dbbeb.pdfNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/689dig: fix behavior for -6 used with IPv4-mapped IPv6 addresses2023-11-02T16:32:27ZMichał Kępieńdig: fix behavior for -6 used with IPv4-mapped IPv6 addressesThis is a spin-off from !755. Over there, @each [said][1]:
> If "dig -6" is used but only v4 addresses are in resolv.conf, I would have expected it to use v4-mapped addresses instead of giving up -- that's what it does if an ipv4 addre...This is a spin-off from !755. Over there, @each [said][1]:
> If "dig -6" is used but only v4 addresses are in resolv.conf, I would have expected it to use v4-mapped addresses instead of giving up -- that's what it does if an ipv4 address is specified on the command line with the -6 flag.
To which I [replied][2]:
> What does _not_ make sense to me, though (...), is why we attempt using IPv4-mapped IPv6 addresses when `-6` was specified. Apparently we have been doing this for the past 17 years (since da5795a32a5b28fc8afd59e4887e19ec1252d0d0). I personally find this very confusing. The man page for `dig` says:
>
> ```
> -6
> Use IPv6 only.
> ```
> To me, this means: "`dig` will only communicate using IPv6". But if you use `-6` in conjunction with an IPv4 address, it **will** use IPv4 to send the query. After all, IPv4-mapped IPv6 addresses are not some kind of an IPv6 transition mechanism but merely a way of storing an IPv4 address in an `AF_INET6` socket structure. To me, this looks as if `dig` fails to deliver on its promise not to use IPv4. What is the use case for doing this?
The way I read it, @ondrej [agreed][3] with me:
> I think this is wrong. If -6 is specified I would expect dig to use only IPv6 to communicate with the outside.
Given the above, I propose to, at minimum, change the default in `dig` from `+mapped` to `+nomapped`, the rationale being that `dig` should not implicitly use IPv4 if `-6` was explicitly specified, but it is okay to allow the user to keep using this quirk if it is explicitly requested by passing `+mapped` on the command line.
The somewhat more extreme version of this change would treat command lines in the likes of `dig -6 @192.0.2.1` (or, correspondingly, `dig -6 @::ffff:192.0.2.1`) as errors, i.e. we would completely remove the `+[no]mapped` option, causing `-6` to become a more strict limit.
Any thoughts on this are welcome.
[1]: https://gitlab.isc.org/isc-projects/bind9/merge_requests/755#note_21896
[2]: https://gitlab.isc.org/isc-projects/bind9/merge_requests/755#note_21997
[3]: https://gitlab.isc.org/isc-projects/bind9/merge_requests/755#note_22998Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/669Intermittent TCP test failure2019-11-28T12:25:32ZOndřej SurýIntermittent TCP test failureJob [#86348](https://gitlab.isc.org/isc-projects/bind9/-/jobs/86348) failed for 68ca9877921892968c718865363e9115ba5095bf:Job [#86348](https://gitlab.isc.org/isc-projects/bind9/-/jobs/86348) failed for 68ca9877921892968c718865363e9115ba5095bf:BIND 9.15.xWitold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/661rich configuration API2023-11-02T16:32:27ZPetr Špačekpspacek@isc.orgrich configuration API### Description
BIND is hard to configure from outside using APIs, especially when it comes to reading configuration back. It is of course possible to always generate full config file from scratch and restart named process but it has so...### Description
BIND is hard to configure from outside using APIs, especially when it comes to reading configuration back. It is of course possible to always generate full config file from scratch and restart named process but it has some drawbacks:
- previous configuration which requires modification must be stored elsewhere (because named.conf is hard to parse from outside)
- it makes combining manual tweaking in config with automation becomes harder than necessary
### Request
In general I suggest to provide an configuration API which allows user to tweak running instance, and very importantly, also obtain configuration from the running instance. It would make life much easier for people who want to manage BIND using external tools.
### Links / referencesNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/658$sysconfdir is silently overridden with /etc when "--prefix" is not used2020-01-14T21:16:05ZMichał Kępień$sysconfdir is silently overridden with /etc when "--prefix" is not used@pspacek pointed out to me that when you use `./configure` without `--prefix`, `make install` puts everything under `/usr/local`... except the configuration files. I ran `./configure --help`, which yielded:
```
...
Installation directo...@pspacek pointed out to me that when you use `./configure` without `--prefix`, `make install` puts everything under `/usr/local`... except the configuration files. I ran `./configure --help`, which yielded:
```
...
Installation directories:
--prefix=PREFIX install architecture-independent files in PREFIX
[/usr/local]
...
--sysconfdir=DIR read-only single-machine data [PREFIX/etc]
...
...
```
So far so good. Then I checked `configure.ac` and found [this][1]:
```sh
#
# Special processing of paths depending on whether --prefix,
# --sysconfdir or --localstatedir arguments were given. What's
# desired is some compatibility with the way previous versions
# of BIND built; they defaulted to /usr/local for most parts of
# the installation, but named.boot/named.conf was in /etc
# and named.pid was in /var/run.
#
# So ... if none of --prefix, --sysconfdir or --localstatedir are
# specified, set things up that way. If --prefix is given, use
# it for sysconfdir and localstatedir the way configure normally
# would. To change the prefix for everything but leave named.conf
# in /etc or named.pid in /var/run, then do this the usual configure way:
# ./configure --prefix=/somewhere --sysconfdir=/etc
# ./configure --prefix=/somewhere --localstatedir=/var
#
# To put named.conf and named.pid in /usr/local with everything else,
# set the prefix explicitly to /usr/local even though that's the default:
# ./configure --prefix=/usr/local
#
case "$prefix" in
NONE)
case "$sysconfdir" in
'${prefix}/etc')
sysconfdir=/etc
;;
esac
case "$localstatedir" in
'${prefix}/var')
localstatedir=/var
;;
esac
;;
esac
```
`git blame` indicates that this bit was added in 2000. I think that in 2018 this is wrong and confusing, especially given that `./configure --help` claims that the default value for `$sysconfdir` is `PREFIX/etc`. IMHO we should at least address this in *master*.
[1]: https://gitlab.isc.org/isc-projects/bind9/blob/d88efa7e40cbf244ca7886d8ddf0f0361ce8a518/configure.ac#L334-367BIND 9.15.xMichał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/657Add a seatbelt to IDN2023-11-02T16:32:27ZOndřej SurýAdd a seatbelt to IDNFrom paf on dns-operations:
> Please please please do check what happens when you have bidirectional strings before you decide that having U-LABEL output be the default.
>
> I am the conservative kind that am so nervous over these kind...From paf on dns-operations:
> Please please please do check what happens when you have bidirectional strings before you decide that having U-LABEL output be the default.
>
> I am the conservative kind that am so nervous over these kind of things that I would say "let the user turn on IDN output if the user know what the user is doing".
>
> You might require LOCALE processing, and get different result depending on the shell you use, so "just" look at whether the output is a TTY is something that I think is not enough.
>
> So be careful, and do proper QA, by at least reaching out to people having different directionality by default.
> For bidi issues, please look for example on these old blog posts of mine:
>
> https://stupid.domain.name/node/681
> https://stupid.domain.name/node/682
> https://stupid.domain.name/node/683
>
> You might at least make your code more stable. Add a seatbelt...Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/651Add an option to disable qname minimization for selected domains2021-10-04T13:33:45ZWitold KrecickiAdd an option to disable qname minimization for selected domainsNot plannedWitold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/622BIND should accept trust anchors / keys in DS format too, not just DNSKEY2021-05-11T13:17:24ZRay BellisBIND should accept trust anchors / keys in DS format too, not just DNSKEYper title.
This would simplify use for those registries that would prefer to only receive DS records from their delegated children.
Also, the ICANN root trust anchor is mostly only distributed in DS format.per title.
This would simplify use for those registries that would prefer to only receive DS records from their delegated children.
Also, the ICANN root trust anchor is mostly only distributed in DS format.BIND 9.15.xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/605Add SipHash24 and synchronize the Cookie algorithm with other vendors2019-07-22T12:15:37ZOndřej SurýAdd SipHash24 and synchronize the Cookie algorithm with other vendorsBIND 9.15.xOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/599assertion error in isc__timer_create(): task != ((void *)0)2018-11-13T13:25:12ZAndreas Hasenackandreas@canonical.comassertion error in isc__timer_create(): task != ((void *)0)<!--
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
The command `host -t soa local.` crashed with an assertion error:
`#2 0x00007fe590c645ef in isc_assertion_failed (file=file@entry=0x7fe590cb769c "../../../lib/isc/timer.c", line=line@entry=392, type=type@entry=isc_assertiontype_require, cond=cond@entry=0x7fe590cb0103 "task != ((void *)0)") at ../../../lib/isc/assertions.c:52`
Ubuntu bug: https://bugs.launchpad.net/ubuntu/+source/bind9/+bug/1797926
### BIND version used
1:9.11.4+dfsg-3ubuntu5 in Ubuntu Cosmic 18.10 (https://launchpad.net/ubuntu/+source/bind9/1:9.11.4+dfsg-3ubuntu5)
### Steps to reproduce
Unknown, but reporter indicated it was after his computer came back from sleep.
### What is the current *bug* behavior?
The `host` command failed with an assertion error.
### What is the expected *correct* behavior?
The `host` command should produce a result, or timeout and fail gracefully.
### Relevant logs and/or screenshots
Backtrace:
```
#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
[Error: raise.c was not found in source tree]
#1 0x00007fe590a44535 in __GI_abort () at abort.c:79
[Error: abort.c was not found in source tree]
#2 0x00007fe590c645ef in isc_assertion_failed (file=file@entry=0x7fe590cb769c "../../../lib/isc/timer.c", line=line@entry=392, type=type@entry=isc_assertiontype_require, cond=cond@entry=0x7fe590cb0103 "task != ((void *)0)") at ../../../lib/isc/assertions.c:52
47: void
48: isc_assertion_failed(const char *file, int line, isc_assertiontype_t type,
49: const char *cond)
50: {
51: isc_assertion_failed_cb(file, line, type, cond);
52: abort();
53: /* NOTREACHED */
54: }
55:
56: /*% Set callback. */
57: void
#3 0x00007fe590c9245a in isc__timer_create (manager0=0x7fe58d741010, type=<optimized out>, expires=<optimized out>, interval=<optimized out>, task=0x0, action=0x55bcf1af75c0 <connect_timeout>, arg=0x7fe58d74e018, timerp=0x7fe58d74e288) at ../../../lib/isc/timer.c:457
452: timer->index = 0;
453: result = isc_mutex_init(&timer->lock);
454: if (result != ISC_R_SUCCESS) {
455: isc_task_detach(&timer->task);
456: isc_mem_put(manager->mctx, timer, sizeof(*timer));
457: return (result);
458: }
459: ISC_LINK_INIT(timer, link);
460: timer->common.impmagic = TIMER_MAGIC;
461: timer->common.magic = ISCAPI_TIMER_MAGIC;
462: timer->common.methods = (isc_timermethods_t *)&timermethods;
#4 0x000055bcf1aef75a in bringup_timer (query=0x7fe58d74e018, default_timeout=<optimized out>) at ../../../bin/dig/dighost.c:2949
2944: }
2945: debug("have local timeout of %d", local_timeout);
2946: isc_interval_set(&l->interval, local_timeout, 0);
2947: if (query->timer != NULL)
2948: isc_timer_detach(&query->timer);
2949: result = isc_timer_create(timermgr, isc_timertype_once, NULL,
2950: &l->interval, global_task, connect_timeout,
2951: query, &query->timer);
2952: check_result(result, "isc_timer_create");
2953: }
2954:
#5 0x000055bcf1af6e22 in send_udp (query=0x7fe58d74e018) at ../../../bin/dig/dighost.c:3135
3130: dig_query_t *next;
3131:
3132: debug("send_udp(%p)", query);
3133:
3134: l = query->lookup;
3135: bringup_timer(query, UDP_TIMEOUT);
3136: l->current_query = query;
3137: debug("working on lookup %p, query %p", query->lookup, query);
3138: if (!query->recv_made) {
3139: /* XXX Check the sense of this, need assertion? */
3140: query->waiting_connect = ISC_FALSE;
#6 0x000055bcf1af76c5 in connect_timeout (task=<optimized out>, event=<optimized out>) at ../../../bin/dig/dighost.c:3265
3260:
3261: if (l->retries > 1) {
3262: if (!l->tcp_mode) {
3263: l->retries--;
3264: debug("resending UDP request to first server");
3265: send_udp(ISC_LIST_HEAD(l->q));
3266: } else {
3267: debug("making new TCP request, %d tries left",
3268: l->retries);
3269: l->retries--;
3270: requeue_lookup(l, ISC_TRUE);
#7 0x00007fe590c8c439 in dispatch (manager=0x7fe58d73f010) at ../../../lib/isc/task.c:1141
1136: ISC_MSGSET_TASK,
1137: ISC_MSG_EXECUTE,
1138: "execute action"));
1139: if (event->ev_action != NULL) {
1140: UNLOCK(&task->lock);
1141: (event->ev_action)(
1142: (isc_task_t *)task,
1143: event);
1144: LOCK(&task->lock);
1145: }
1146: dispatch_count++;
#8 run (uap=0x7fe58d73f010) at ../../../lib/isc/task.c:1313
1308: isc__taskmgr_t *manager = uap;
1309:
1310: XTHREADTRACE(isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL,
1311: ISC_MSG_STARTING, "starting"));
1312:
1313: dispatch(manager);
1314:
1315: XTHREADTRACE(isc_msgcat_get(isc_msgcat, ISC_MSGSET_GENERAL,
1316: ISC_MSG_EXITING, "exiting"));
1317:
1318: #ifdef OPENSSL_LEAKS
#9 0x00007fe590c14164 in start_thread (arg=<optimized out>) at pthread_create.c:486
[Error: pthread_create.c was not found in source tree]
#10 0x00007fe590b3cdef in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
[Error: clone.S was not found in source tree]
```
The `host` call that triggered the assertion was most likely the same one from issue https://gitlab.isc.org/isc-projects/bind9/issues/520BIND 9.13.xMichał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/598Wishlist: statistics for DNS-over-TCP and TLS2024-02-29T16:01:45ZTony FinchWishlist: statistics for DNS-over-TCP and TLSA couple of suggestions:
1. For DNS-over-TLS using a proxy, it would be nice to have separate statistics counters from queries that came from the proxy. When the TLS proxy is running on the same server, it would be enough to have sepa...A couple of suggestions:
1. For DNS-over-TLS using a proxy, it would be nice to have separate statistics counters from queries that came from the proxy. When the TLS proxy is running on the same server, it would be enough to have separate counters when the client address is in the interface list that BIND keeps track of. Is this generally useful enough to be worthwhile?
2. For DNS-over-TCP (and by implication, DNS-over-TLS) it would be helpful to have some guide to setting TCP idle timeouts. Two things would help:
* include the connection age in the query log - useful for later analysis, but no good if query logging needs to be left off
* keep an overall histogram of connection age - I don't know of any smaller summary statistics that would be useful, because the distribution of queries is very skewedBIND 9.19.xAydın MercanAydın Mercan