BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2021-02-24T20:45:03Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2526Example configuration for authoritative DNS server for docker container is mi...2021-02-24T20:45:03ZMalte BögershausenExample configuration for authoritative DNS server for docker container is misleadingThe example for the basic configuration for an authoritative DNS server given on https://hub.docker.com/r/internetsystemsconsortium/bind9 is misleading.
The lines:
```
listen-on { 127.0.0.1; };
listen-on-v6 { ::1; };
```...The example for the basic configuration for an authoritative DNS server given on https://hub.docker.com/r/internetsystemsconsortium/bind9 is misleading.
The lines:
```
listen-on { 127.0.0.1; };
listen-on-v6 { ::1; };
```
mean that the DNS server is not accessible from outside the container (and there is no reason to access it from inside the container).
Additionally there is no filename suggested for the config file. If `named.conf` is used the default structure for config files is overridden.https://gitlab.isc.org/isc-projects/bind9/-/issues/2214forward zones aren't zones and shouldn't be configured as if they were2021-03-04T10:08:09ZBrian Conryforward zones aren't zones and shouldn't be configured as if they were"zones" of type `forward` aren't zones and aren't treated like zones internally, but because they are called "zones" and configured with a `zone` statement many people are confused when they can't use them with features like catalog zone..."zones" of type `forward` aren't zones and aren't treated like zones internally, but because they are called "zones" and configured with a `zone` statement many people are confused when they can't use them with features like catalog zones or `rndc addzone`.
The configuration block declaring them should be renamed to `forward` or something else unambiguous.
Alternatively, all of the things that operates on zones and can't handle a forward "zone" should be fixed so that they can.https://gitlab.isc.org/isc-projects/bind9/-/issues/2576[ISC-support #18100] FORMERR when EDNS is disabled and spurious DS record is ...2021-03-14T23:43:28ZEverett Fulton[ISC-support #18100] FORMERR when EDNS is disabled and spurious DS record is received### Summary
Support ticket: https://support.isc.org/Ticket/Display.html?id=18100
A customer's resolver has EDNS0 disabled globally, and is logging FORMERR in a case where an authoritative server is returning an unrequested DS record (w...### Summary
Support ticket: https://support.isc.org/Ticket/Display.html?id=18100
A customer's resolver has EDNS0 disabled globally, and is logging FORMERR in a case where an authoritative server is returning an unrequested DS record (with no corresponding RRSIG) in a referral, even without DO bit being set.
### BIND version used
9.11.22-S1
### Steps to reproduce
1. Configure resolver with:
`server 0.0.0.0/0 { edns no; };`
in global context. This has been confirmed as the minimal reproducer in Support testing.
2. `dig @RESOLVER_IP mg13.so.kpn.com`
### What is the current *bug* behavior?
SERVFAIL response
### What is the expected *correct* behavior?
NOERROR, with A record returned.
### Relevant configuration files
Provided in ISC-support ticket #18100, contains potentially sensitve ACLs.
Simplified resolver configuration with EDNS0 disabled globally is sufficient, as follows:
`server 0.0.0.0/0 { edns no; };`
### Relevant logs and/or screenshots
```
12-Mar-2021 17:44:08.075 info: FORMERR resolving 'mg13.so.kpn.com/A/IN': 194.151.228.10#53
12-Mar-2021 17:44:08.088 info: FORMERR resolving 'mg13.so.kpn.com/A/IN': 213.75.63.33#53
12-Mar-2021 17:44:08.088 client @0x7f5a2c1c8940 127.0.0.1#40330 (mg13.so.kpn.com): view internet: query failed (SERVFAIL) for mg13.so.kpn.com/ IN/A at query.c:9601
```https://gitlab.isc.org/isc-projects/bind9/-/issues/2577Support for RFC 5424 structured syslog data2021-03-15T23:00:42ZCarsten StrotmannSupport for RFC 5424 structured syslog data### Description
The current BIND 9 log data send to syslog is unstructured RFC 3164 style data.
### Request
The newer RFC 5424 defines an optional structure for syslog messages. However applications such as BIND 9 must provide this ad...### Description
The current BIND 9 log data send to syslog is unstructured RFC 3164 style data.
### Request
The newer RFC 5424 defines an optional structure for syslog messages. However applications such as BIND 9 must provide this additional syslog format.
The RFC 5424 format allows easy and robust parsing and filtering of syslog messages.
### Links / references
https://tools.ietf.org/html/rfc5424Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2571-E pkcs11 default documented but not implemented, crashing dnssec.2021-04-20T12:09:50ZHarry G. Coin-E pkcs11 default documented but not implemented, crashing dnssec.A documented command line default is unimplemented, generating failures/crashes in dnssec related activity.
man named includes "... -E engine-name ...When BIND is built with OpenSSL PKCS#11 support, this defaults to the string "pkcs11"...A documented command line default is unimplemented, generating failures/crashes in dnssec related activity.
man named includes "... -E engine-name ...When BIND is built with OpenSSL PKCS#11 support, this defaults to the string "pkcs11". However, the default is Null (0x0) leading to, for example:
Mar 08 20:26:07 registry1.1.quietfountain.com named[1388]: dns_dnssec_findmatchingkeys: error reading key file K11.quietfountain.com.+008+37760.private: no engine
In bind compiled as:
```
Mar 09 10:56:32 registry1.1.quietfountain.com named[59594]: starting BIND 9.11.28-RedHat-9.11.28-1.fc33 (Extended Support Version) <id:60f9417>
Mar 09 10:56:32 registry1.1.quietfountain.com named[59594]: running on Linux x86_64 5.10.19-200.fc33.x86_64 #1 SMP Fri Feb 26 16:21:30 UTC 2021
Mar 09 10:56:32 registry1.1.quietfountain.com named[59594]: built with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-python=/usr/bin/python3' '--with-libtool' '--localstatedir=/var' '--enable-threads' '--enable-ipv6' '--enable-filter-aaaa' '--with-pic' '--disable-static' '--includedir=/usr/include/bind9' '--with-tuning=large' '--with-libidn2' '--enable-openssl-hash' '--with-geoip2' '--enable-native-pkcs11' '--with-pkcs11=/usr/lib64/pkcs11/libsofthsm2.so' '--with-dlopen=yes' '--with-dlz-ldap=yes' '--with-dlz-postgres=yes' '--with-dlz-mysql=yes' '--with-dlz-filesystem=yes' '--with-gssapi=yes' '--disable-isc-spnego' '--with-lmdb=yes' '--with-libjson' '--enable-dnstap' '--with-cmocka' '--enable-fixed-rrset' '--with-docbook-xsl=/usr/share/sgml/docbook/xsl-ns-stylesheets' '--enable-full-report' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CC=gcc' 'CFLAGS= -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection' 'LDFLAGS=-Wl,-z,relro -Wl,--as-needed -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld ' 'CPPFLAGS= -DDIG_SIGCHASE' 'LT_SYS_LIBRARY_PATH=/usr/lib64:' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
```
in gdb we have:
```
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
[New Thread 0x7ffff5d48640 (LWP 59595)]
[New Thread 0x7ffff5547640 (LWP 59596)]
[New Thread 0x7ffff4d46640 (LWP 59597)]
[New Thread 0x7ffff4545640 (LWP 59598)]
[New Thread 0x7ffff3d44640 (LWP 59599)]
[New Thread 0x7ffff3519640 (LWP 59600)]
Thread 1 "named" hit Breakpoint 5, dst__openssl_init (engine=0x0) at ../../../lib/dns/openssl_link.c:196
196 dst__openssl_init(const char *engine) {
(gdb) bt
#0 dst__openssl_init (engine=0x0) at ../../../lib/dns/openssl_link.c:196
#1 0x00007ffff7f00de7 in dst_lib_init2 (mctx=<optimized out>, ectx=0x7ffff5d52010, engine=0x0, eflags=eflags@entry=1) at ../../../lib/dns/dst_api.c:198
#2 0x00005555555c1c56 in ns_server_create (mctx=0x55555562e730, serverp=0x555555627e60 <ns_g_server>) at ../../../bin/named/server.c:9157
#3 0x0000555555579332 in setup () at ../../../bin/named/main.c:1337
#4 main (argc=<optimized out>, argv=0x7fffffffe2c8) at ../../../bin/named/main.c:1556
(gdb) n
209 CRYPTO_set_mem_functions(mem_alloc, mem_realloc, mem_free);
(gdb) n
250 OPENSSL_load_builtin_modules();
(gdb) n
251 ENGINE_load_builtin_engines();
(gdb) n
252 ERR_clear_error();
(gdb) n
253 CONF_modules_load_file(NULL, NULL,
(gdb) n
258 if (engine != NULL && *engine == '\0')
(gdb) p engine
$32 = 0x0
(gdb) info args
engine = 0x0
```
A 'workaround' is, in /etc/sysconfig/named, to include
OPTIONS="-E pkcs11"
But it would be better if either the docs changed, the error message was more helpful, or the code changed to implement the documented default.
Other detail at: https://bugzilla.redhat.com/show_bug.cgi?id=1937207Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/26409.16.13 Windows 64-bit - Error 109: The pipe has been ended (when stopped/re...2021-04-20T13:37:09ZRvdH9.16.13 Windows 64-bit - Error 109: The pipe has been ended (when stopped/restarted via Windows Services)<!--
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
Error 109: The pipe has been ended (when stopped/restarted via Windows Services)
### BIND version used
9.16.13 Windows 64-Bit
**named -V**
```
BIND 9.16.13 (Stable Release) <id:072e758>
running on Windows 10 0 build 17763 475 for x64
built by Visual Studio with 'with-tools-version=15.0 with-platform-toolset=v141 with-platform-version=10.0.17763.0 with-vcredist=C:/Program\ Files\ (x86)/Microsoft\ Visual\ Studio/2017/BuildTools/VC/Redist/MSVC/14.16.27012/vcredist_x64.exe with-openssl=C:/OpenSSL with-libxml2=C:/libxml2 with-libuv=C:/libuv without-python with-system-tests x64'
compiled by MSVC 1916
compiled with OpenSSL version: OpenSSL 1.1.1j 16 Feb 2021
linked to OpenSSL version: OpenSSL 1.1.1j 16 Feb 2021
compiled with libuv version: 1.41.0
linked to libuv version: 1.41.0
compiled with libxml2 version: 2.9.10
linked to libxml2 version: 20910
threads support is enabled
default paths:
named configuration: C:\Program Files\ISC BIND 9\etc\named.conf
rndc configuration: C:\Program Files\ISC BIND 9\etc\rndc.conf
DNSSEC root key: C:\Program Files\ISC BIND 9\etc\bind.keys
nsupdate session key: C:\Program Files\ISC BIND 9\etc\session.key
named PID file: C:\Program Files\ISC BIND 9\etc\named.pid
named lock file: C:\Program Files\ISC BIND 9\etc\named.lock
```
### Steps to reproduce
This behavior already is noticeable with a default install
### What is the current *bug* behavior?
Error 109: The pipe has been ended
### What is the expected *correct* behavior?
Nothinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2641BIND Version checker/reporter2021-04-28T16:16:24ZVicky Riskvicky@isc.orgBIND Version checker/reporter**Background**
ISC needs some general idea how many instances of BIND are running which software versions. We frequently have to guesstimate this in order to assess the relative impact of a bug or vulnerability on our user base. We do ...**Background**
ISC needs some general idea how many instances of BIND are running which software versions. We frequently have to guesstimate this in order to assess the relative impact of a bug or vulnerability on our user base. We do not have any useful information from downloads, because our open source is published on so many sites, including many we do not control. Having this information would enable us to make better decisions about how many installations might be impacted and about what sort of fix is appropriate.
At the same time, we also need some mechanism to alert users who are running software that is EOL or subject to a known, published CVE. We should be able to provide unobtrusive but visible feedback to the operator when that is detected.
Users are wary of any feature that reports software information that could be used to identify and target them, or that carries any potential for side-channel data leakage. We must make it very transparent exactly what information is sent and what information we retain. Some users will wish to disable whatever version checker we implement, and we should make it easy to do so. However, if we do not enable this feature by default, it is unlikely that we will get enough data to be useful.
**Requirements**
1. We need a utility that will periodically (define) contact some system at ISC and report what BIND version it is running and check to see if that is a supported version clear of published CVEs.
1. The message or lookup from the version checker should consume a *very modest* amount of bandwidth. UDP should be adequate, retries and failure messages are not indicated if the lookup fails or is blocked. We want to be careful not to create a DDOS on the server.
1. The version checker does not need to check frequently - a period of daily might be ok and might be easiest to implement, weekly is adequate however.
1. The version checker should be enabled by default.
1. We might have one check that happens on startup and an identifiably different check that happens say, weekly after that. This is to address the issue of test systems, ephemeral dockers biasing the statistics.
1. **TBD.** It might be useful to initiate the 'ongoing' checker only when some level of regular query traffic is reached, to eliminate systems that are unused or 'toy' systems, again to reduce those systems biasing the statistics. The problem is that some of these systems we might regard as 'toy' systems could still be important to their users and we would be denying them the benefit of the alerts that their system is compromised. Also, some systems with a lot of query traffic could simply be, e.g. unmanaged open resolvers that are pounded with abuse traffic.
1. It must be relatively easy to disable the version checker. It should be possible to disable it without rebuilding the image and without restarting the daemon.
1. Some operating system packagers are going to want to disable the version checker, or possibly to 'redirect' it to check some facility of their own. This should not be unnecessarily difficult for them to do.
1. This feature should be added to the development branch of BIND.
1. **It is TBD** whether we should backport it to the most recent stable branch.
**Local logging**
The version checker should insert a log message in the configured default bind logging facility if the running version is EOL or if it is subject to a known published CVE.
1. The log message should state the CVE status (clear, vulnerable, EOL, unrecognized version)
1. **TBD. **If there is adequate room, this message could provide any of the following
- the date of the planned EOL for this version
- a link to get more information
- a link to download a new version
- a link to the vulnerability report
- a link to the CVE matrix
depending on what is feasible and reasonable given the space available.
1. **TBD** whether the log message should be at the Warning level or the Informational level
1. **TBD** whether the version checker should log that it ran, and checked the version and the response is ok. Some users might want this, but since it is not very useful and adds more chaff to the log, if it is logged it should be at a low level, info or debug.
**Version Status Responder**
1. ISC should stand up a system that the version checker can check
1. The responder should be identified by a FQDN. We will have to maintain this facility for a long time, and using a FQDN will make it easier for packagers to substitute their own responder if they choose.
1. The responder should have information on known BIND versions with support status and CVE status.
1. It should be possible for anyone who can publish a BIND CVE or post a BIND release to add or edit the known versions, CVE status and support status so we can easily keep this up to date, given we are releasing multiple new versions monthly.
1. The responder should log the time and version number the checker looks up, but it should not log the IP address the requests comes from or.... anything else.
1. **TBD.** How can we effectively identify package versions where the BIND version does not map to the ISC releases, such as when a packager backports CVE fixes?
1. **TBD** Should we make the census information public?https://gitlab.isc.org/isc-projects/bind9/-/issues/2699RNDC - how feasible is it to have it report when a change needs a daemon rest...2021-05-17T12:58:50ZChuck StearnsRNDC - how feasible is it to have it report when a change needs a daemon restart?### Description
Changes made with rndc affect the running config, but some changes still require a daemon restart in order to take effect, but there is no reporting of that in rndc's output.
### Request
Perhaps a stderr or part of `rn...### Description
Changes made with rndc affect the running config, but some changes still require a daemon restart in order to take effect, but there is no reporting of that in rndc's output.
### Request
Perhaps a stderr or part of `rndc status` suggesting that the running and static configs are in sync and/or whether or not a daemon restart is necessary.
### Links / referenceshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2761Excessive interval between zone transfer retries after failure2021-06-09T18:02:44ZEverett FultonExcessive interval between zone transfer retries after failureFrom https://support.isc.org/Ticket/Display.html?id=18577
A customer using 9.11.30-S1 reports intermittent zone transfers with "failed setting up socket: address in use" being logged. This would not be a serious issue, except that more...From https://support.isc.org/Ticket/Display.html?id=18577
A customer using 9.11.30-S1 reports intermittent zone transfers with "failed setting up socket: address in use" being logged. This would not be a serious issue, except that more than 10 minutes can pass before a retry.https://gitlab.isc.org/isc-projects/bind9/-/issues/795rndc dumpdb output may be larger than expected - documentation update request2021-06-16T11:35:52ZCathy Almondrndc dumpdb output may be larger than expected - documentation update requestOrdinarily it should be anticipated by operators that dumping cache via rndc dumpdb is going to create a large file in the dump location. However there are some RRs whose presentation form can be significantly larger than their wire/mem...Ordinarily it should be anticipated by operators that dumping cache via rndc dumpdb is going to create a large file in the dump location. However there are some RRs whose presentation form can be significantly larger than their wire/memory format.
For example, the NSEC record format contains a bitmap which, when expanded can consume significantly more bytes.
This is a request for the ARM to be updated to warn operators that dumpdb output files can be significantly large - sometimes bigger than the operator would expect if there are many NSEC/NSEC3 RRsets currently cached.https://gitlab.isc.org/isc-projects/bind9/-/issues/2803Add missing zone locks in dns_zone_get_.* functions2021-06-28T12:32:08ZMatthijs Mekkingmatthijs@isc.orgAdd missing zone locks in dns_zone_get_.* functionsSee https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5234#note_223073See https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5234#note_223073https://gitlab.isc.org/isc-projects/bind9/-/issues/2655Assertion failure in rdataset.c:2642021-08-05T14:18:00ZGiedrius TuminauskasAssertion failure in rdataset.c:264During weekly logrotate cron job (on Sunday), when named-pkcs11 is reloaded - stops working
Affected versions:
```
bind-9.11.4-26.P2.el7_9.4.x86_64
bind-9.11.20-5.el8.x86_64
```
```
25-Apr-2021 06:45:07.219 reloading configuration succ...During weekly logrotate cron job (on Sunday), when named-pkcs11 is reloaded - stops working
Affected versions:
```
bind-9.11.4-26.P2.el7_9.4.x86_64
bind-9.11.20-5.el8.x86_64
```
```
25-Apr-2021 06:45:07.219 reloading configuration succeeded
25-Apr-2021 06:45:07.219 reloading zones succeeded
25-Apr-2021 06:45:07.219 shutting down automatic empty zones to enable forwarding for domain '.'
25-Apr-2021 06:45:07.347 ../../../lib/dns-pkcs11/rdataset.c:264: REQUIRE(rdataset->methods != ((void *)0)) failed, back trace
25-Apr-2021 06:45:07.347 #0 0x556d08b4c744 in ??
25-Apr-2021 06:45:07.347 #1 0x7fe0e582bb10 in ??
25-Apr-2021 06:45:07.347 #2 0x7fe0e5bb812a in ??
25-Apr-2021 06:45:07.347 #3 0x7fe0e5bce008 in ??
25-Apr-2021 06:45:07.347 #4 0x7fe0e5bd0b49 in ??
25-Apr-2021 06:45:07.347 #5 0x7fe0e5bd19a0 in ??
25-Apr-2021 06:45:07.347 #6 0x7fe0e58522bf in ??
25-Apr-2021 06:45:07.347 #7 0x7fe0e327b14a in ??
25-Apr-2021 06:45:07.347 #8 0x7fe0e2c44f23 in ??
25-Apr-2021 06:45:07.347 exiting (due to assertion failure)
```https://gitlab.isc.org/isc-projects/bind9/-/issues/2865Follow-up from "Test migrating CSK to dnssec-policy"2021-08-17T14:52:13ZMatthijs Mekkingmatthijs@isc.orgFollow-up from "Test migrating CSK to dnssec-policy"The following discussion from !5328 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5328#note_230211): (+2 comments)
> I would test migrating 2 SEP keys. I would...The following discussion from !5328 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5328#note_230211): (+2 comments)
> I would test migrating 2 SEP keys. I would also test migrating 2 non-SEP keys.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/85Automatic database filename generation2021-08-25T15:37:12ZRay BellisAutomatic database filename generationNSD has the ability to automatically generate a zone's filename based on a template string, instead of requiring them to be specified within each zone's configuration:
```
%s is replaced with the zone name.
...NSD has the ability to automatically generate a zone's filename based on a template string, instead of requiring them to be specified within each zone's configuration:
```
%s is replaced with the zone name.
%1 is replaced with the first character of the zone name.
%2 is replaced with the second character of the zone name.
%3 is replaced with the third character of the zone name.
%z is replaced with the toplevel domain name of the zone.
%y is replaced with the next label under the toplevel domain.
%x is replaced with the next-next label under the toplevel
domain.
```
It would be useful if BIND has a similar feature. This would also work well with Catalog Zones, where it is not expected that the Catalog Zone itself would hold the filename, but where the secondary server would synthesise a filename for itself.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2876upgrade tests for persistent data are missing2021-08-26T20:32:47ZPetr Špačekpspacek@isc.orgupgrade tests for persistent data are missingWe need tests to cover compatibility of persistent files between versions. List of formats which come to mind:
- [ ] zone journal
- [ ] zone in raw format
- [ ] zone in map format
- [ ] new-zone database (NZD) in our custom format
- [ ] ...We need tests to cover compatibility of persistent files between versions. List of formats which come to mind:
- [ ] zone journal
- [ ] zone in raw format
- [ ] zone in map format
- [ ] new-zone database (NZD) in our custom format
- [ ] new-zone database (NZD) in LMDB
- [ ] managed-keys
This list might not be exhaustive.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2411Gracefully shutdown the TLS connections in TLSDNS using SSL_shutdown2021-09-02T12:42:57ZOndřej SurýGracefully shutdown the TLS connections in TLSDNS using SSL_shutdownThe SSL_shutdown needs bit back and forth on the networking channel, so right now we are doing ungraceful shutdown by tearing down the underlying TCP connection. This should be fixed to behave like a good netizen.The SSL_shutdown needs bit back and forth on the networking channel, so right now we are doing ungraceful shutdown by tearing down the underlying TCP connection. This should be fixed to behave like a good netizen.Not plannedOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2892The Umbrella EDNS option has been published by IANA2021-09-13T20:37:12ZMark AndrewsThe Umbrella EDNS option has been published by IANA```
20292 Umbrella Ident Optional [https://developer.cisco.com/docs/cloud-security/#!integrating-network-devices/rdata-description][Cisco_CIE_DNS_team]
```
- Add the ability to check and display the option contents
- Add support to +edn...```
20292 Umbrella Ident Optional [https://developer.cisco.com/docs/cloud-security/#!integrating-network-devices/rdata-description][Cisco_CIE_DNS_team]
```
- Add the ability to check and display the option contents
- Add support to +ednsopt in dig.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2302DOT scalability, performance testing2021-09-13T20:52:00ZVicky Riskvicky@isc.orgDOT scalability, performance testingWe need to find a way to test with a large number of DOT connections for scalability. I understand our current perflab set up cannot do this.
The goals of this might include:
- checking that DOT scaling is equivalent to TCP scaling (if...We need to find a way to test with a large number of DOT connections for scalability. I understand our current perflab set up cannot do this.
The goals of this might include:
- checking that DOT scaling is equivalent to TCP scaling (if it is much worse we might consider that a bug)
- providing some guidance to users about throughput (e.g. as a % of UDP performance)
- verifying (functionally) that rate limits work as expected for DOThttps://gitlab.isc.org/isc-projects/bind9/-/issues/155add version flag to all tools2021-10-04T12:35:42ZCarsten Strotmannadd version flag to all tools### Description
some BIND 9 tools (such as arpaname, named-checkconf, named-checkzone, named-rrchecker, maybe more) don't have a version information that can be printed out.
That makes it harder to identify old versions in the path (i...### Description
some BIND 9 tools (such as arpaname, named-checkconf, named-checkzone, named-rrchecker, maybe more) don't have a version information that can be printed out.
That makes it harder to identify old versions in the path (it would have helped me to identify the problem in issue #151 faster).
### Request
Give all BIND 9 tools / commandline commands a "-V" switch that prints out the BIND 9 release version the binary originated from.
### Links / referenceshttps://gitlab.isc.org/isc-projects/bind9/-/issues/352Refactored RPZ has a scalability design problem2021-10-04T12:50:35ZGhost UserRefactored RPZ has a scalability design problem(Don't let that title sound discouraging - IMO it is still better than the old RPZ code, but more work is necessary.)
Last week I heard from a provider of feed data that they need resolvers to react quickly and the current 60s default u...(Don't let that title sound discouraging - IMO it is still better than the old RPZ code, but more work is necessary.)
Last week I heard from a provider of feed data that they need resolvers to react quickly and the current 60s default update rate plus the fact that RPZ does a full iteration of the DB will not work for them as their data is not latency tolerant and their policy zones are large.
There was a separate bug ticket by a popular reporter from another ISC customer in the last 1-2 months that asked whether this 60s update time could be improved to match the old RPZ behavior.
I feel this can be addressed. BIND RPZ would need to hook not just into `dns_db_updatenotify_register()`, but also into a `newdbversion` signal and every `add` and `del` update to the DB. Note that the RPZ view summary datastructure is still not versioned, so RPZ code would have to separately batch and keep aside a copy of the update diffs until the DB version commit passes, and then apply just the diffs to the RPZ view summary data structure instead of iterating the zone. I think versioning the view summary datastructure would be too much work and complicate the structure.. as long as the diff is applied to it after the DB version commit passes, there should be no problem of inconsistent data.Long-term