BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-03-29T09:53:07Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4630CID 487883: Null pointer dereference in lib/dns/qpzone.c2024-03-29T09:53:07ZMichal NowakCID 487883: Null pointer dereference in lib/dns/qpzone.cCoverity Scan claims null pointer dereference in `lib/dns/qpzone.c`.
```c
/lib/dns/qpzone.c: 4935 in addrdataset()
4929
4930 /*
4931 * Update the zone's secure status. If version is non-NULL
4932 * this is deferre...Coverity Scan claims null pointer dereference in `lib/dns/qpzone.c`.
```c
/lib/dns/qpzone.c: 4935 in addrdataset()
4929
4930 /*
4931 * Update the zone's secure status. If version is non-NULL
4932 * this is deferred until closeversion() is called.
4933 */
4934 if (result == ISC_R_SUCCESS && version == NULL) {
>>> CID 487883: Null pointer dereferences (FORWARD_NULL)
>>> Passing null pointer "version" to "setsecure", which dereferences it.
4935 setsecure(db, version, qpdb->origin);
4936 }
4937
4938 return (result);
4939 }
4940
```April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)https://gitlab.isc.org/isc-projects/bind9/-/issues/4421Remove support for AES-based DNS cookies and AES implementation2023-12-06T18:12:06ZEric SesterhennRemove support for AES-based DNS cookies and AES implementationThe legacy support for AES-based DNS cookies should go, which will resolve following:
> The functions `isc_aes256_crypt()` and `isc_aes192_crypt()` in `lib/isc/aes.c` have no callers besides test code and should be removed.
as we are g...The legacy support for AES-based DNS cookies should go, which will resolve following:
> The functions `isc_aes256_crypt()` and `isc_aes192_crypt()` in `lib/isc/aes.c` have no callers besides test code and should be removed.
as we are going to remove the AES implementation in libisc completely.December 2023 (9.18.21, 9.18.21-S1, 9.19.19)https://gitlab.isc.org/isc-projects/bind9/-/issues/4406cleanup 'b' in dnstap-read main2023-11-07T10:27:34ZMark Andrewscleanup 'b' in dnstap-read main'b' is unused.'b' is unused.November 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4405deprecate/remove resolver-nonbackoff-tries, resolver-retry-interval2023-12-08T12:18:01ZEvan Huntdeprecate/remove resolver-nonbackoff-tries, resolver-retry-intervalThese options were added to `named` at the same time as serve-stale support. I suspect they were meant to be used for testing, but they weren't documented as test-only options (or, really, as anything else either - see #1687).
They are ...These options were added to `named` at the same time as serve-stale support. I suspect they were meant to be used for testing, but they weren't documented as test-only options (or, really, as anything else either - see #1687).
They are not, in fact, used in any of the system tests, and I can't think of a reason one would want to modify them in production. I suggest we remove them as of 9.20.December 2023 (9.18.21, 9.18.21-S1, 9.19.19)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/4263Deprecate the "dnssec-must-be-secure" feature2023-12-07T10:23:40ZOndřej SurýDeprecate the "dnssec-must-be-secure" featureThe `dnssec-must-be-secure` feature was added in the early days of BIND 9 and DNSSEC and it makes sense only as a debugging feature. Remove it to simplify the code.
See #4482 for the removal issue.The `dnssec-must-be-secure` feature was added in the early days of BIND 9 and DNSSEC and it makes sense only as a debugging feature. Remove it to simplify the code.
See #4482 for the removal issue.September 2023 (9.16.44, 9.16.44-S1, 9.18.19, 9.18.19-S1, 9.19.17)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4098Compiling options --enable-epoll and --disable-epoll are not working.2023-06-14T09:28:53ZXuesong BaiCompiling options --enable-epoll and --disable-epoll are not working.I'm working on a project in which I need to run BIND 9 in an environment where `SYS_epoll_create1` call is not supported. But I cannot compile directly in that environment. So I'm compiling BIND 9 on a supported machine.
From the [sourc...I'm working on a project in which I need to run BIND 9 in an environment where `SYS_epoll_create1` call is not supported. But I cannot compile directly in that environment. So I'm compiling BIND 9 on a supported machine.
From the [source code](https://gitlab.isc.org/isc-projects/bind9/-/blob/main/configure.ac#L525), there are two options, `--enable-epoll`, `--disable-epoll`,that I can use to disable epoll.
But when I compiled the software with these options separately and tested them on the target environment, `SYS_epoll_create1` call is still used.
So I wonder if anyone can help me solve this problem. Many thanks!June 2023 (9.16.42, 9.16.42-S1, 9.18.16, 9.18.16-S1, 9.19.14)https://gitlab.isc.org/isc-projects/bind9/-/issues/3982Remove the isc_fsaccess API2023-04-11T20:16:41ZOndřej SurýRemove the isc_fsaccess APISince Windows is gone, we can remove `isc_fsaccess` API and use the `mkstemp()` to safely create non-truncated files.Since Windows is gone, we can remove `isc_fsaccess` API and use the `mkstemp()` to safely create non-truncated files.April 2023 (9.16.40, 9.16.40-S1, 9.18.14, 9.18.14-S1, 9.19.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/3953Deprecate and remove (root-)delegation-only2023-04-11T17:19:54ZOndřej SurýDeprecate and remove (root-)delegation-onlyThe `delegation-only` and `root-delegation-only` options were introduced as a response to the "SiteFinder" incident, as it can be seen [here](https://circleid.com/posts/the_name_domain_disrupted_by_site_finder_patch) and [here](https://w...The `delegation-only` and `root-delegation-only` options were introduced as a response to the "SiteFinder" incident, as it can be seen [here](https://circleid.com/posts/the_name_domain_disrupted_by_site_finder_patch) and [here](https://www.afnic.fr/en/observatory-and-resources/news/warning-for-bind-and-delegation-only-users/) this created more problems than it solved and the options should be deprecated and removed; possibly in the expedited way.April 2023 (9.16.40, 9.16.40-S1, 9.18.14, 9.18.14-S1, 9.19.12)https://gitlab.isc.org/isc-projects/bind9/-/issues/3905Remove TKEY Diffie-Hellman authentication2023-05-30T08:11:18ZOndřej SurýRemove TKEY Diffie-Hellman authenticationAlthough [draft-eastlake-dnsop-rfc2930bis-tkey](https://datatracker.ietf.org/doc/draft-eastlake-dnsop-rfc2930bis-tkey/) hasn't been finished, I would suggest that we go with the recommendation in the draft:
```
4.2 Diffie-Hellman Exchan...Although [draft-eastlake-dnsop-rfc2930bis-tkey](https://datatracker.ietf.org/doc/draft-eastlake-dnsop-rfc2930bis-tkey/) hasn't been finished, I would suggest that we go with the recommendation in the draft:
```
4.2 Diffie-Hellman Exchanged Keying (Deprecated)
The use of this mode (#2) is NOT RECOMMENDED for the following two
reasons but the specification is still included in Appendix A in case
an implementation is needed for compatibility with old TKEY
implementations. See Section 4.6 on ECDH Exchanged Keying.
The mixing function used does not meet current cryptographic
standards because it uses MD5 [RFC6151].
RSA keys must be excessively long to achieve levels of security
required by current standards.
```June 2023 (9.16.42, 9.16.42-S1, 9.18.16, 9.18.16-S1, 9.19.14)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3781Deprecate source port configuration2023-12-07T13:15:14ZEvan HuntDeprecate source port configurationDeprecate the definition of the source ports and rely on the operating system to provide reasonable ephemeral port range for outgoing UDP and TCP connections.
Specifying outgoing ports is a bad practice, it's already discouraged, it's ...Deprecate the definition of the source ports and rely on the operating system to provide reasonable ephemeral port range for outgoing UDP and TCP connections.
Specifying outgoing ports is a bad practice, it's already discouraged, it's prone to errors (it's not only specifying single port, but specifying not enough ports removes a layer of protection) and is already full of caveats like:
```
.. note:: The address specified in the :any:`query-source` option is used for both
UDP and TCP queries, but the port applies only to UDP queries. TCP
queries always use a random unprivileged port.
.. warning:: Specifying a single port is discouraged, as it removes a layer of
protection against spoofing errors.
.. warning:: The configured :term:`port` must not be the same as the listening port.
```
The deprecation will include:
* specifying **port** in the following statements:
- `query-source`
- `query-source-v6`
- `transfer-source`
- `transfer-source-v6`
- `notify-source`
- `notify-source-v6`
- `parental-source`
- `parental-source-v6`
-
* the following statements as a whole:
- `use-v4-udp-ports`
- `use-v6-udp-ports`
- `avoid-v4-udp-ports`
- `avoid-v6-udp-ports`
See #3843 for the corresponding option removal issue.February 2023 (9.16.38, 9.16.38-S1, 9.18.12, 9.18.12-S1, 9.19.10)https://gitlab.isc.org/isc-projects/bind9/-/issues/3773Deprecate DSCP options in 9.18 and remove it in 9.202023-01-11T12:01:05ZOndřej SurýDeprecate DSCP options in 9.18 and remove it in 9.20January 2023 (9.16.37, 9.16.37-S1, 9.18.11, 9.18.11-S1, 9.19.9)https://gitlab.isc.org/isc-projects/bind9/-/issues/3737fix initialisation of local. in isdotlocal in dig2023-01-11T14:00:27ZMark Andrewsfix initialisation of local. in isdotlocal in digRemove the trailing '\0' as it shouldn't be there. The trailing `\0` in the definition just happens to work with dns_name_issubdomain so there is no operational impact.Remove the trailing '\0' as it shouldn't be there. The trailing `\0` in the definition just happens to work with dns_name_issubdomain so there is no operational impact.January 2023 (9.16.37, 9.16.37-S1, 9.18.11, 9.18.11-S1, 9.19.9)https://gitlab.isc.org/isc-projects/bind9/-/issues/3700consider deprecating "dialup" option2023-08-04T09:42:20ZPetr Špačekpspacek@isc.orgconsider deprecating "dialup" optionIt is unclear if [dialup](https://bind9.readthedocs.io/en/v9_19_7/reference.html#namedconf-statement-dialup) statement is useful in practice, and at the same time it adds fair amount of logic to zone refresh/notify handling.
Consider th...It is unclear if [dialup](https://bind9.readthedocs.io/en/v9_19_7/reference.html#namedconf-statement-dialup) statement is useful in practice, and at the same time it adds fair amount of logic to zone refresh/notify handling.
Consider the fun of finding out how following flags interact:
`lib/dns/zone.c`:
```c
19964 void
19965 dns_zone_setdialup(dns_zone_t *zone, dns_dialuptype_t dialup) {
19966 REQUIRE(DNS_ZONE_VALID(zone));
19967
19968 LOCK_ZONE(zone);
19969 DNS_ZONE_CLRFLAG(zone, DNS_ZONEFLG_DIALNOTIFY |
19970 DNS_ZONEFLG_DIALREFRESH |
19971 DNS_ZONEFLG_NOREFRESH);
19972 switch (dialup) {
19973 case dns_dialuptype_no:
19974 break;
19975 case dns_dialuptype_yes:
19976 DNS_ZONE_SETFLAG(zone, (DNS_ZONEFLG_DIALNOTIFY |
19977 DNS_ZONEFLG_DIALREFRESH |
19978 DNS_ZONEFLG_NOREFRESH));
19979 break;
19980 case dns_dialuptype_notify:
19981 DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_DIALNOTIFY);
19982 break;
19983 case dns_dialuptype_notifypassive:
19984 DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_DIALNOTIFY);
19985 DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_NOREFRESH);
19986 break;
19987 case dns_dialuptype_refresh:
19988 DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_DIALREFRESH);
19989 DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_NOREFRESH);
19990 break;
19991 case dns_dialuptype_passive:
19992 DNS_ZONE_SETFLAG(zone, DNS_ZONEFLG_NOREFRESH);
19993 break;
19994 default:
19995 UNREACHABLE();
19996 }
19997 UNLOCK_ZONE(zone);
19998 }
```August 2023 (9.16.43, 9.16.43-S1, 9.18.18, 9.18.18-S1, 9.19.16)https://gitlab.isc.org/isc-projects/bind9/-/issues/3694Deprecate setting alternate transfer source2022-12-02T12:56:00ZMatthijs Mekkingmatthijs@isc.orgDeprecate setting alternate transfer sourceThis was an undocumented BIND 8 feature that was ported to BIND 9 in the early days. But there is no good use case for it.
See #3714 for the corresponding option removal issue.This was an undocumented BIND 8 feature that was ported to BIND 9 in the early days. But there is no good use case for it.
See #3714 for the corresponding option removal issue.December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3676Deprecate and remove "Operating System Resource Limits"2022-12-07T18:50:32ZOndřej SurýDeprecate and remove "Operating System Resource Limits"From ARM:
```
Operating System Resource Limits
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The server's usage of many system resources can be limited. Scaled
values are allowed when specifying resource limits. For example, ``1G``
can be used inst...From ARM:
```
Operating System Resource Limits
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The server's usage of many system resources can be limited. Scaled
values are allowed when specifying resource limits. For example, ``1G``
can be used instead of ``1073741824`` to specify a limit of one
gigabyte. ``unlimited`` requests unlimited use, or the maximum available
amount. ``default`` uses the limit that was in force when the server was
started. See the description of ``size_spec`` in :ref:`configuration_file_elements`.
The following options set operating system resource limits for the name
server process. Some operating systems do not support some or any of the
limits; on such systems, a warning is issued if an unsupported
limit is used.
``coresize``
This sets the maximum size of a core dump. The default is ``default``.
``datasize``
This sets the maximum amount of data memory the server may use. The default is
``default``. This is a hard limit on server memory usage; if the
server attempts to allocate memory in excess of this limit, the
allocation will fail, which may in turn leave the server unable to
perform DNS service. Therefore, this option is rarely useful as a way
to limit the amount of memory used by the server, but it can be
used to raise an operating system data size limit that is too small
by default. To limit the amount of memory used by the
server, use the ``max-cache-size`` and ``recursive-clients`` options
instead.
``files``
This sets the maximum number of files the server may have open concurrently.
The default is ``unlimited``.
``stacksize``
This sets the maximum amount of stack memory the server may use. The default is
``default``.
```
These are options that are better left to be managed by the environment, and not from within the `named`, just deprecate these options in 9.18 and remove the options from 9.19+.December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)https://gitlab.isc.org/isc-projects/bind9/-/issues/3667deprecate auto-dnssec feature in favor of dnssec-policy2023-02-18T03:56:51ZPetr Špačekpspacek@isc.orgdeprecate auto-dnssec feature in favor of dnssec-policyAs discussed in person in Porto, I think it's high time to deprecate [auto-dnssec](https://bind9.readthedocs.io/en/latest/dnssec-guide.html#semi-automatic-signing) in ~"v9.18" branch. Doing so _now_ would give users 3 years of warning be...As discussed in person in Porto, I think it's high time to deprecate [auto-dnssec](https://bind9.readthedocs.io/en/latest/dnssec-guide.html#semi-automatic-signing) in ~"v9.18" branch. Doing so _now_ would give users 3 years of warning before ~"v9.18" is out of support.
IMHO in ~"v9.19" we should remove it altogether ASAP.
There is a question what to do with zones which use `auto-dnssec` on upgrade. I think it would be wrong to just skip over the config statement and pretend it is not configured because it would be major break in user's expectation. I think in this case it should be hard error (from ~"v9.19" onwards, of course.)December 2022 (9.16.36, 9.16.36-S1, 9.18.10, 9.19.8)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3553followups from #34932022-09-27T12:59:11ZEvan Huntfollowups from #3493Now that the minimal fix for the statistics channel overread issue has been merged to the public repository, related code that was written while fixing it can be made public as well:
- further cleaning up httpd.c
- adding assertions to ...Now that the minimal fix for the statistics channel overread issue has been merged to the public repository, related code that was written while fixing it can be made public as well:
- further cleaning up httpd.c
- adding assertions to the `ISC__BUFFER` macros
- changing `ISC__BUFFER` macros to static inline functions in 9.19 and 9.18October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3443Documentation and behavior of memory-related options are inconsistent2022-07-15T09:02:32ZMichał KępieńDocumentation and behavior of memory-related options are inconsistentWith all the recent work around memory use in BIND 9, the documentation
and behavior of various memory-related options (both build-time and
run-time) has become a bit of a mess in various branches:
- `main`, `v9_18`:
- the man ...With all the recent work around memory use in BIND 9, the documentation
and behavior of various memory-related options (both build-time and
run-time) has become a bit of a mess in various branches:
- `main`, `v9_18`:
- the man page for `named` still mentions `external` as a legal
value for `-M`, even though the internal allocator does not
exist in those branches any more (and therefore `external` does
not work),
- `v9_16`:
- the `-M` command-line option accepts an `internal` value, but
the latter is neither mentioned in the man page for `named` nor
included in `named -h` output,
- the documentation claims that memory filling is disabled by
default unless `--enable-developer` is used; however, that
latter point is only true if the internal allocator is used,
which is not the default; as a result, memory filling is not
performed by default, even if `--enable-developer` is used -
unless `-DISC_MEM_USE_INTERNAL_MALLOC=1` is set at build-time,
- commit c96b6eb5ece1d44fdfbce45da2364e3764956822 missed a spot,
which results in every BIND 9 build with
`-DISC_MEM_USE_INTERNAL_MALLOC=1` set to consistently fail an
assertion upon shutdown.
The minimum amount of work to do here is to update the documentation in
all branches so that it matches the code.
The question of whether we should fix the code for ~"v9.16" is
debatable:
- The "missed spot" thing is easy to fix and it is a clear bug, though
definitely not a critical one.
- As for the confusing memory filling behavior, I think of it as a
bug, too - IMHO memory filling should be enabled by default in
developer mode even if the system allocator is used. (If that was
the case, I would have been able to reproduce #3441 much more
quickly - it is the reason I started this work.)August 2022 (9.16.32, 9.16.32-S1, 9.18.6, 9.19.4)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3399Remove unused random-device statement from named.conf2022-09-20T13:48:07ZPetr Špačekpspacek@isc.orgRemove unused random-device statement from named.confAs far as I can tell, `random-device` statement in named.conf grammar does not do anything since !269 (9.13.0). At the same time it is not marked as deprecated or obsolete in the config.
Proposal:
- Mark it as obsolete but still accepte...As far as I can tell, `random-device` statement in named.conf grammar does not do anything since !269 (9.13.0). At the same time it is not marked as deprecated or obsolete in the config.
Proposal:
- Mark it as obsolete but still accepted by the parser in ~"v9.16" and ~"v9.18"
- Remove in ~"v9.19"October 2022 (9.16.34, 9.16.34-S1, 9.18.8, 9.19.6)https://gitlab.isc.org/isc-projects/bind9/-/issues/3324clean up fctx_minimize_qname2022-06-02T11:15:31ZMark Andrewsclean up fctx_minimize_qnameThere are redundant variables and multiple initialisations of the same variable when constructing the next qminname.There are redundant variables and multiple initialisations of the same variable when constructing the next qminname.Not planned