BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2018-03-18T10:25:34Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/123Support 64 RPZ zones by default from 9.13 onwards2018-03-18T10:25:34ZGhost UserSupport 64 RPZ zones by default from 9.13 onwardsSupport 64 RPZ zones by default from 9.13 onwards. Right now it's 32 or 64, and there doesn't seem to be any pressing need to have this choice going forward.Support 64 RPZ zones by default from 9.13 onwards. Right now it's 32 or 64, and there doesn't seem to be any pressing need to have this choice going forward.BIND-9.13.0https://gitlab.isc.org/isc-projects/bind9/-/issues/137Remove support for systems without ftello/fseeko2018-03-19T22:14:27ZOndřej SurýRemove support for systems without ftello/fseeko`fseeko` and `ftello` conforms to SUSv2, POSIX.1-2001. The `configure.in` says:
```
# BSDI doesn't have ftello fseeko
AC_CHECK_FUNCS(ftello fseeko)
```
The last version of BSD/OS was released in 2003, henceforth I believe it's safe to...`fseeko` and `ftello` conforms to SUSv2, POSIX.1-2001. The `configure.in` says:
```
# BSDI doesn't have ftello fseeko
AC_CHECK_FUNCS(ftello fseeko)
```
The last version of BSD/OS was released in 2003, henceforth I believe it's safe to remove this workaround.BIND-9.13.0Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/115clean up bin/tests, convert unit tests to ATF2018-03-19T22:15:47ZEvan Huntclean up bin/tests, convert unit tests to ATFThis is an old item on the TODO list whose time has come. Let's clean up bin/tests:
- remove bin/tests/master, it's been superfluous for a long time; it was turned into lib/isc/tests/master_test.c, but the original was never removed
- m...This is an old item on the TODO list whose time has come. Let's clean up bin/tests:
- remove bin/tests/master, it's been superfluous for a long time; it was turned into lib/isc/tests/master_test.c, but the original was never removed
- move dnssec-signzone tests into bin/tests/system/dnssec (if they aren't already there)
- rewrite atomic, db, dst, hashes, mem, names, net, rbt, resolver, sockaddr, tasks and timers as ATF tests (and ideally do something about how slow a few of them are)
- review the remaining tests in bin/tests/*_test.c and see if there are others that should be converted
- remove lib/tests and bin/tests/t_api.pl after all tests using them are convertedBIND-9.13.0Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/93Drop seccomp support [RT #46729]2018-03-19T22:18:59ZOndřej SurýDrop seccomp support [RT #46729]This ticket proposes complete removal of seccomp support from BIND
source code due to a number of issues with both seccomp itself and the
way it is implemented in BIND. Removal is planned to be announced in
BIND 9.12.0 release notes and ...This ticket proposes complete removal of seccomp support from BIND
source code due to a number of issues with both seccomp itself and the
way it is implemented in BIND. Removal is planned to be announced in
BIND 9.12.0 release notes and then performed in the next .0 release.
The reasons for suggesting removal of seccomp support from BIND are:
- Compiling an exhaustive list of system calls which should be
whitelisted is very tricky for a piece of software as complex as
BIND; while an application needs to declare a complete whitelist of
system calls which need to be allowed, it cannot assume anything
about what system calls libc is going to use in response to the
standard C library calls issued (see e.g. open() vs. openat(),
setrlimit() vs. prlimit()).
- Alternative mechanisms for achieving the same kind of protection
exist, e.g. SELinux or AppArmor. Fine-tuning policies enforced by
those mechanisms does not require any changes to be introduced into
BIND's source code.
- For threaded builds of BIND, seccomp is implemented in a way which
provides virtually no extra protection as the only thread which is
protected using seccomp is the main thread which waits for libisc to
exit its main loop; worker threads are not protected at all because
seccomp is initialized after worker threads are spawned. However,
this causes odd system test issues e.g. due to named getting killed
by SIGSYS after it logs an "exiting" message, but before it gets a
chance to clean up its lock file and PID file.
- For non-threaded builds of BIND, we are currently whitelisting over
60 systems calls, including open(), read(), write(), close(),
mmap(), chdir() and unlink(). These system calls alone are enough
for potential exploits to wreak havoc in the system, so such
protection arguably does not limit the attack surface significantly.
- Considering planned implementation of hooks and enabling external
hook modules to be loaded at runtime, either users will potentially
need to locally update the seccomp system call whitelist if their
module is going to use anything not currently on the list or we will
need to provide hook modules with a way of adding extra system calls
to the whitelist. Both of these options would further limit
seccomp's usefulness.
[NOTE: Not copying the other conversation from RT, it could be looked up there.]BIND-9.13.0Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/56Revise usage of getquad()2018-03-28T22:46:20ZOndřej SurýRevise usage of getquad()Copied from !5:
We want also revise `getquad()` usage whether this is really needed at all places to accept *almost-valid* IP addresses:
```
lib/dns/rdata/generic/ipseckey_45.c
lib/dns/rdata/generic/l32_105.c
lib/dns/rdata/hs_4/a_1.c
l...Copied from !5:
We want also revise `getquad()` usage whether this is really needed at all places to accept *almost-valid* IP addresses:
```
lib/dns/rdata/generic/ipseckey_45.c
lib/dns/rdata/generic/l32_105.c
lib/dns/rdata/hs_4/a_1.c
lib/dns/rdata/in_1/a_1.c
lib/dns/rdata/in_1/wks_11.c
```
Again deprecating the usage of obscure formats might be the right thing to do.BIND-9.13.0Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/183Add dns_fixedname_initname()2018-04-10T22:17:16ZGhost UserAdd dns_fixedname_initname()The following pattern is repeated in many places in BIND code:
```c
dns_fixedname_t fixed;
dns_name_t *name;
dns_fixedname_init(&fixed);
name = dns_fixedname_name(&name);
```
Let's add a helper function that does the equivalent:
```c...The following pattern is repeated in many places in BIND code:
```c
dns_fixedname_t fixed;
dns_name_t *name;
dns_fixedname_init(&fixed);
name = dns_fixedname_name(&name);
```
Let's add a helper function that does the equivalent:
```c
dns_fixedname_t fixed;
dns_name_t *name;
name = dns_fixedname_initname(&fixed);
```
Implementation would be:
```c
dns_name_t *
dns_fixedname_initname(dns_fixedname_t *fixed) {
dns_fixedname_init(fixed);
return (dns_fixedname_name(fixed));
}
```https://gitlab.isc.org/isc-projects/bind9/-/issues/191Remove OpenSSL < 1.0.0 support2018-05-03T20:32:48ZOndřej SurýRemove OpenSSL < 1.0.0 supportThe current code is #ifdef spaghetti supporting OpenSSL 1.1, OpenSSL 1.0/LibreSSL and OpenSSL 0.9.6/0.9.8. Let's remove OpenSSL 0.9.x support to simplify the code.The current code is #ifdef spaghetti supporting OpenSSL 1.1, OpenSSL 1.0/LibreSSL and OpenSSL 0.9.6/0.9.8. Let's remove OpenSSL 0.9.x support to simplify the code.BIND-9.13.0Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/221Unify the random number provider2018-05-16T08:05:33ZOndřej SurýUnify the random number providerWhile looking at the crypto routines, I found that we have:
- `isc_random_get()`
- `isc_rng_randombytes()`
- `isc_entropy_getdata()`
and the usage isn't really consistent throughout the source code.
This issue aims to unify the random...While looking at the crypto routines, I found that we have:
- `isc_random_get()`
- `isc_rng_randombytes()`
- `isc_entropy_getdata()`
and the usage isn't really consistent throughout the source code.
This issue aims to unify the random data providers inside libisc to use (in this order):
1. `getrandom()` glibc call if available
2. `SYS_getrandom` syscall if available
3. `arc4random()` if available
4. crypto library provider call (`RAND_bytes()` in case of OpenSSL) if available
These are all good (and reasonable fast) providers of random data.Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/269Refactor zone logging functions2018-06-15T09:34:17ZMichał KępieńRefactor zone logging functions`lib/dns/zone.c` contains a set of logging functions:
* `dns_zone_log()`
* `dns_zone_logc()`
* `notify_log()`
* `zone_debuglog()`
Implementations of all these functions are similar enough that the common bits can be extracted to a sepa...`lib/dns/zone.c` contains a set of logging functions:
* `dns_zone_log()`
* `dns_zone_logc()`
* `notify_log()`
* `zone_debuglog()`
Implementations of all these functions are similar enough that the common bits can be extracted to a separate function, which would improve clarity and decrease code duplication.BIND-9.13.2Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/266Convert verifyzone() to a libdns function2018-06-15T09:41:01ZMichał KępieńConvert verifyzone() to a libdns functionIn preparation for [implementing mirror zones](#33), the `verifyzone()` function from `bin/dnssec/dnssectool.c` should first be converted to a libdns routine which does not call `exit()` under any circumstances. The reworked function wi...In preparation for [implementing mirror zones](#33), the `verifyzone()` function from `bin/dnssec/dnssectool.c` should first be converted to a libdns routine which does not call `exit()` under any circumstances. The reworked function will later be employed for verifying mirror zones. `dnssec-signzone` and `dnssec-verifyzone` should also use the reworked function to prevent code duplication.BIND-9.13.2Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/384Rework IDN support in dig2018-07-13T06:37:51ZMichał KępieńRework IDN support in digIDN support in `dig` currently suffers from a number of issues:
* IDNA2003 fallbacks [are still present](https://gitlab.isc.org/isc-projects/bind9/blob/4f6ef2f3e5bacd74da2cf2e4f8e51f3d7682b9a1/bin/dig/dighost.c#L4291-4293), despite our...IDN support in `dig` currently suffers from a number of issues:
* IDNA2003 fallbacks [are still present](https://gitlab.isc.org/isc-projects/bind9/blob/4f6ef2f3e5bacd74da2cf2e4f8e51f3d7682b9a1/bin/dig/dighost.c#L4291-4293), despite our test comments claiming that BIND made a hard transition to IDNA2008 non-transitional processing,
* confusing ([passing flags which are ignored by the callee](https://gitlab.isc.org/isc-projects/bind9/blob/4f6ef2f3e5bacd74da2cf2e4f8e51f3d7682b9a1/bin/dig/dighost.c#L4335)) and fragile ([locale-dependent](https://gitlab.com/libidn/libidn2/blob/6a5fce9848bf76102cb62a314b69d422125a14e1/lib/decode.c#L365-376)) libidn2 calls are used when decoding Punycode found in upstream DNS responses,
* leftover Autoconf macros from previous IDN implementations are still present,
* redundant code is present.BIND-9.13.3Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/478Remove support for unthreaded BIND2018-08-16T19:09:45ZWitold KrecickiRemove support for unthreaded BINDThreads are supported virtually anywhere, removing support for unthreaded version of BIND cleans up code and it's a sane thing to do.Threads are supported virtually anywhere, removing support for unthreaded version of BIND cleans up code and it's a sane thing to do.Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/62consider removal of --disable-threads2018-08-24T20:19:22ZEvan Huntconsider removal of --disable-threadsMukund noted that this would simplify the refactoring of the task/thread/socket code. It will break support for some very old legacy platforms, but possibly that's okay?
The list of platforms that currently build with threads disabled b...Mukund noted that this would simplify the refactoring of the task/thread/socket code. It will break support for some very old legacy platforms, but possibly that's okay?
The list of platforms that currently build with threads disabled by default is:
* solaris 2.[0-6]
* hpux 10
* sco unix & unixware
* netbsd [1-4]
* openbsd
* freebsd [1-7]
* bsdi [2-4]
* all versions of MacOS prior to snow leopard.
(Some of these *can* use threads, though; I'm not sure why the defaults are set the way they are in all cases.)https://gitlab.isc.org/isc-projects/bind9/-/issues/192Make IPv6 support in the system mandatory2018-08-28T08:51:39ZOndřej SurýMake IPv6 support in the system mandatory...and cleanup related code....and cleanup related code.Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/452isc_refcount_init() return value is checked inconsistently2018-08-30T19:31:39ZOndřej Surýisc_refcount_init() return value is checked inconsistently`isc_refcount_init()` should be changed to never fail and the places where result is checked should be cleaned up.`isc_refcount_init()` should be changed to never fail and the places where result is checked should be cleaned up.BIND-9.13.3Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/572Improve accuracy of query error logging2018-10-08T11:01:44ZMichał KępieńImprove accuracy of query error loggingThere are two issues related to query error logging that bug me:
1. Until BIND 9.11 (inclusive), when something goes wrong while recursing for an answer to a query, [the `default:` branch of a `switch` statement in `query_gotanswer()`]...There are two issues related to query error logging that bug me:
1. Until BIND 9.11 (inclusive), when something goes wrong while recursing for an answer to a query, [the `default:` branch of a `switch` statement in `query_gotanswer()`][1] generates a SERVFAIL response. When serve-stale was implemented in BIND 9.12, it was done in a way which causes that `default:` branch to only [set a flag (`want_stale`) in the query context][2] for such queries, effectively moving the `QUERY_ERROR()` call for such queries [to `query_done()`][3] (and making `query_done()` call itself recursively, which hinders readability). This may be a source of confusion[^1] as the "query failed" log messages now point at a line in `query_done()` which appears to have something to do with serve-stale (`if (qctx->want_stale)`) even if the latter is not enabled.
2. Apparently we are setting `qctx->result` to `DNS_R_SERVFAIL` for a lot of different failure modes:
```sh
$ sed -n 's|.*\(QUERY_ERROR([^)]*);\)$|\1|p;' lib/ns/query.c | sort | uniq -c | sort
2 QUERY_ERROR(qctx, DNS_R_DROP);
2 QUERY_ERROR(qctx, DNS_R_REFUSED);
4 QUERY_ERROR(qctx, result);
19 QUERY_ERROR(qctx, DNS_R_SERVFAIL);
```
In some situations, this really is the only sensible thing to do (e.g. when the root key sentinel mechanism overrides the RCODE or when the SERVFAIL cache is hit) but in most others, doing this feels like replacing potentially useful diagnostic information with a rather less useful "oops, something went wrong" type of message:
```
client @0x7fa62c0403b0 ::1#52563 (servfail.nl): query failed (SERVFAIL) for servfail.nl/IN/A at query.c:10681
```
While in some cases the root cause of failed queries is indicated by the preceding log messages, troubleshooting others requires recompiling BIND with `--enable-querytrace`, which is not always a viable option for the user.
I think we can improve `named`'s behavior in this regard. Note that the response message's RCODE is derived from `qctx->result` using `dns_result_torcode()`, which handles a number of possible `isc_result_t` values and returns SERVFAIL for anything not explicitly listed. If we used `QUERY_ERROR(qctx, result);` instead of `QUERY_ERROR(qctx, DNS_R_SERVFAIL);` where possible, the specific error could be logged by `query_error()` and the response's RCODE would still be SERVFAIL. The win here would be that some light could be shed on the less obvious query errors just by bumping the debug level using `rndc trace` (or enabling query logging) rather than recompiling with `--enable-querytrace`.
[^1]: see e.g. https://lists.isc.org/pipermail/bind-users/2018-September/100868.html, though the issue caught me by surprise a couple of times as well while debugging
[1]: https://gitlab.isc.org/isc-projects/bind9/blob/c635b3175620ea085a8d2402afd446dfd95422bd/bin/named/query.c#L8571-8580
[2]: https://gitlab.isc.org/isc-projects/bind9/blob/7b49de3a79e6597d42f8c3a69e55c8b01e47324d/lib/ns/query.c#L6675-6679
[3]: https://gitlab.isc.org/isc-projects/bind9/blob/7b49de3a79e6597d42f8c3a69e55c8b01e47324d/lib/ns/query.c#L10644BIND-9.13.4Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/479Remove isc_bind9 from (almost) everywhere2018-10-18T10:39:43ZWitold KrecickiRemove isc_bind9 from (almost) everywhereSince dhcpd will not be using libisc we can get rid of this stuff...Since dhcpd will not be using libisc we can get rid of this stuff...Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/564Mirror zone configuration tweaks and cleanups2018-10-24T18:51:39ZMichał KępieńMirror zone configuration tweaks and cleanupsVarious discussions around mirror zones which happened after they were initially implemented (see #342, #375/!475, [Twitter poll](https://twitter.com/ISCdotORG/status/1007711763121356800)) indicate that certain aspects of mirror zone con...Various discussions around mirror zones which happened after they were initially implemented (see #342, #375/!475, [Twitter poll](https://twitter.com/ISCdotORG/status/1007711763121356800)) indicate that certain aspects of mirror zone configuration could use some tweaks:
* `type secondary; mirror yes;` should be replaced with `type mirror;`
* it should be clearly documented that:
* mirror zones are supposed to *replace* the configuration example provided by [RFC 7706](https://tools.ietf.org/html/rfc7706#appendix-B.1) rather than *augment* it,
* mirror zones only work the intended way if recursion is available in the view they are configured in,
* by default, outgoing transfers of mirror zones are disabled.
Furthermore:
* the list of valid mirror zone options should be trimmed down,
* NOTIFY configuration for mirror zones is a bit too hacky and could use some love,
* we currently do not test whether mirror zones can be added and removed dynamically (using `rndc`).
The above concerns need to be addressed before we release BIND 9.14 and since configuration changes are involved, BIND 9.13.4 would be the more appropriate target.BIND-9.13.4Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/645Get rid of vector socket functions2018-11-05T20:05:49ZWitold KrecickiGet rid of vector socket functionsisc_socket_recvv, isc_socket_sendv, isc_socket_sendtov, isc_socket_sendtov2 are used only by httpd and dig, we can get rid of them and simplify socket code.isc_socket_recvv, isc_socket_sendv, isc_socket_sendtov, isc_socket_sendtov2 are used only by httpd and dig, we can get rid of them and simplify socket code.Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/604Get rid of isc_socket_{recv,sendto}v{,2} functions from dig2018-11-08T16:42:11ZWitold KrecickiGet rid of isc_socket_{recv,sendto}v{,2} functions from digDig (dighost.c) is the only place we're using iovec-like versions of socket_recv/send functions, we should get rid of those as that'd simplify the codebase.Dig (dighost.c) is the only place we're using iovec-like versions of socket_recv/send functions, we should get rid of those as that'd simplify the codebase.