BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-11-02T17:02:20Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2992Replace "tcp-only" with a more generic option2023-11-02T17:02:20ZArtem BoldarievReplace "tcp-only" with a more generic optionBind has a `tcp-only` option to force interaction with a server using TCP only.
```
server <address> {
...
tcp-only yes;
...
};
```
This option was enough when DNS was using UDP and TCP only (Do53), however as it becomes po...Bind has a `tcp-only` option to force interaction with a server using TCP only.
```
server <address> {
...
tcp-only yes;
...
};
```
This option was enough when DNS was using UDP and TCP only (Do53), however as it becomes possible to carry DNS traffic with more transports, we might need to replace this option with a more generic one which could specify the desired transport explicitly, e.g.:
```
server <address> {
...
transport tcp; # or "tls", or "quic" (in the future), etc
...
};
```
When the option is omitted, it means use the default (Do53 - the current behaviour).
This issue, in a way, mirrors #2776.Not plannedArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2984ECS-IP not visible in the "rpz.log"2023-04-12T12:34:45ZThomas AmgartenECS-IP not visible in the "rpz.log"<!--
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
If an RPZ-enabled BIND is behind a proxy/loadbalancer (for example dnsdist), which injects the ECS-IP, there's actually no way to have/see the client ip address (ECS-IP) in the "rpz.log". Instead, one can correctly see only the ip address from the proxy/dnsdist itself and not the address from the effective source.
### BIND version used
Tested with BIND-9.16.21
### Steps to reproduce
- Place a proxy/dnsdist in front of BIND and inject the ECS-IP.
```
Domain Name System (response)
Transaction ID: 0x5d00
Flags: 0x8183 Standard query response, No such name
1... .... .... .... = Response: Message is a response
.000 0... .... .... = Opcode: Standard query (0)
.... .0.. .... .... = Authoritative: Server is not an authority for domain
.... ..0. .... .... = Truncated: Message is not truncated
.... ...1 .... .... = Recursion desired: Do query recursively
.... .... 1... .... = Recursion available: Server can do recursive queries
.... .... .0.. .... = Z: reserved (0)
.... .... ..0. .... = Answer authenticated: Answer/authority portion was not authenticated by the server
.... .... ...0 .... = Non-authenticated data: Unacceptable
.... .... .... 0011 = Reply code: No such name (3)
Questions: 1
Answer RRs: 0
Authority RRs: 0
Additional RRs: 1
Queries
example.ch: type A, class IN
Name: example.ch
[Name Length: 8]
[Label Count: 2]
Type: A (Host Address) (1)
Class: IN (0x0001)
Additional records
<Root>: type OPT
Name: <Root>
Type: OPT (41)
UDP payload size: 1232
Higher bits in extended RCODE: 0x00
EDNS0 version: 0
Z: 0x0000
0... .... .... .... = DO bit: Cannot handle DNSSEC security RRs
.000 0000 0000 0000 = Reserved: 0x0000
Data length: 40
Option: COOKIE
Option Code: COOKIE (10)
Option Length: 24
Option Data: faf2434380c56c3d01000000617a1b9c7be4e739ff1b30de
Client Cookie: faf2434380c56c3d
Server Cookie: 01000000617a1b9c7be4e739ff1b30de
Option: CSUBNET - Client subnet
Option Code: CSUBNET - Client subnet (8)
Option Length: 8
Option Data: 00012000c0a8ec02
Family: IPv4 (1)
Source Netmask: 32
Scope Netmask: 0
Client Subnet: 172.16.16.33 <------------------
[Request In: 13]
[Time: 0.000221000 seconds]
```
- Then query a domain via proxy, which triggers RPZ
### What is the current *bug* behavior?
- Verify the "rpz.log", which only shows the proxy-ip
```
27-Oct-2021 15:41:27.940 rpz: info: client @0x7f3db81aa0f8 127.0.0.1#44353 (example.ch): rpz QNAME NXDOMAIN rewrite example.ch/A/IN via example.ch.blacklist-rpz.test.local
```
### What is the expected *correct* behavior?
A way to see the ECS-IP, the effective client ip address, like this is already implemented, when enabling the builtin "rndc querylog on":
```
27-Oct-2021 15:41:27.940 queries: info: client @0x7f3db81aa0f8 127.0.0.1#44353 (example.ch): query: example.ch IN A +E(0)K (127.0.0.1) [ECS 172.16.16.33/32/0]
```
### Relevant configuration files
(Paste any relevant configuration files - please use code blocks (```)
to format console output. If submitting the contents of your
configuration file in a non-confidential Issue, it is advisable to
obscure key secrets: this can be done automatically by using
`named-checkconf -px`.)
### Relevant logs and/or screenshots
### Possible fixesNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2980QNAME minimisation and check-names response fail; interact2021-10-27T08:31:37ZMark AndrewsQNAME minimisation and check-names response fail; interactI noticed `check-names failure _.clients6.google.com/A/IN` in the logs with check-names response fail set.I noticed `check-names failure _.clients6.google.com/A/IN` in the logs with check-names response fail set.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2965RPZ and /0 prefixes2021-11-09T17:33:50ZMark AndrewsRPZ and /0 prefixesOn quick examination of lib/dns/rpz.c it looks just removing the check for zero length prefixes is not enough to have them work.On quick examination of lib/dns/rpz.c it looks just removing the check for zero length prefixes is not enough to have them work.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2964Templates in the configuration2024-01-15T07:00:03ZOndřej SurýTemplates in the configurationThe zone should contain reusable chunks (something like yaml: `<< *foo`).The zone should contain reusable chunks (something like yaml: `<< *foo`).Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2959Remove support for signed 32-bit time_t2023-11-02T17:02:20ZOndřej SurýRemove support for signed 32-bit time_tNow there are couple of requirements:
* All user space must be compiled with a 64-bit time_t, which are supported in the musl-1.2 and glibc-2.32 releases, along with installed kernel headers from linux-5.6 or higher.
See for details: h...Now there are couple of requirements:
* All user space must be compiled with a 64-bit time_t, which are supported in the musl-1.2 and glibc-2.32 releases, along with installed kernel headers from linux-5.6 or higher.
See for details: https://lkml.org/lkml/2020/1/29/355?anz=webNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2955Bad html generated for 9.11 doc on web site2022-03-01T09:46:14ZMark AndrewsBad html generated for 9.11 doc on web siteSee https://bind.isc.org/doc/arm/9.11/man.named.conf.html for example. White space is incorrect.See https://bind.isc.org/doc/arm/9.11/man.named.conf.html for example. White space is incorrect.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2953Resolver issues with refactored dispatch code2023-11-02T17:02:19ZMichał KępieńResolver issues with refactored dispatch codeThis issue attempts to describe various issues with resolver behavior
found after merging !4601 (#2401). Most of these issues are
intermittent, so it is important to keep track of them somewhere in
order to not forget that they exist. ...This issue attempts to describe various issues with resolver behavior
found after merging !4601 (#2401). Most of these issues are
intermittent, so it is important to keep track of them somewhere in
order to not forget that they exist. We should get to the bottom of all
of these issues before we release BIND 9.18.0.
1. [x] **Recursive Perflab tests cause the resolver to stop responding.**
This issue might be the simplest to start with because the behavior
observed seems to be consistent rather than intermittent. Namely,
all Perflab jobs which test a resolver seem to crank out a response
rate of some 70-120 kQPS at the beginning of the test and then...
the resolver stops responding indefinitely. While Perflab was not
designed with recursive tests in mind and therefore we can treat its
recursive results with a grain of salt, it certainly should not be
reporting zeros all over the place.
- https://perflab.isc.org/#/config/run/5bf195dd83ba91a870b2976f/
- https://perflab.isc.org/#/config/run/5cd6a166643076f6c1f6c26f/
- https://perflab.isc.org/#/config/run/5db74b6264458967f762143a/
- https://perflab.isc.org/#/config/run/5db74b7264458967f762143b/
- https://perflab.isc.org/#/config/run/5db74c2764458967f7621440/
- https://perflab.isc.org/#/config/run/5db74c3464458967f7621441/
(Resolved by !5500.)
2. [x] **`respdiff` tests are *sometimes* slow.**
Ever since we merged the dispatch branch, the `respdiff` tests
started failing *intermittently* for `main` (and only `main`)
because of timeouts.
- [job 2016337][1]: pass, ~2m30s per each 10,000 queries
- [job 2016622][2]: pass, ~2m45s per each 10,000 queries
- [job 2017990][3]: pass, ~2m30s per each 10,000 queries
- [job 2020093][4]: fail, 7+ minutes per each 10,000 queries
- [job 2023057][5]: fail, 16+ minutes per each 10,000 queries
- [job 2023490][6]: pass, ~2m40s per each 10,000 queries
I do not think varying CI runner stress can be blamed for this, not
for discrepancies this large. It also never happened before merging
!4601, AFAIK.
3. [x] **A lot of "stress" test graph indicate growing memory use.** #3002
While testing October BIND 9 releases, one of the 1-hour "stress"
tests ran in recursive mode for BIND 9.17.19 yielded a graph which
indicates that memory use growth over time might be an issue.
https://wiki.isc.org/bin/viewfile/QA/BindQaResults_9_11_36?filename=bind-9.17.19-linux-amd64-recursive-1h.png;rev=1
However, that phenomenon was not observable for other OS/arch
combinations this specific code revision was tested with.
It was also not observable on the *same* OS/arch combination for a
very similar code revision (the code differences should not have any
effect on memory use patterns):
https://wiki.isc.org/bin/viewfile/QA/BindQaResults_9_11_36?filename=bind-9.17.19-linux-amd64-recursive-1h.png;rev=2
Pre-release tests run for BIND 9.17.20 confirmed that memory leaks
are a common thing when `named` is used as a recursive resolver.
More details are available in #3002.
The "stress" tests are run on isolated VMs and despite being pretty
synthetic (fixed traffic pattern, everything happens on one machine,
etc.), they have a history of being very stable, so typical issues
like test host load varying over time etc. are not a factor here.
4. [x] **Lame servers with IPv6 unreachable cause hang on shutdown.** #2927
5. [x] **resolver test fails intermittently** #3013
See https://gitlab.isc.org/isc-projects/bind9/-/jobs/2054296
```
I:resolver:query count error: 6 NS records: expected queries 10, actual 11
I:resolver:failed
```
6. [x] **Assertion failed in `dns_resolver_logfetch()`** #2962
7. [x] **Assertion failed in `dns_dispatch_gettcp()`** #2963
8. [x] **Assertion failed in `dns_resolver_destroyfetch()`** #2969
9. [x] **ThreadSanitizer issues with adb** #2978 #2979
10. [x] **fctx_cancelquery() attempts to process a query which has already been freed** #3018
11. [x] **premature TCP connection closure leaks fetch contexts (hang on shutdown)** #3026
12. [ ] **validator loops can cause shutdown hang** #3033
13. [ ] **ADB finds for a broken zone may cause fetch contexts to hang** #3037
14. [ ] **ASAN error in fctx_cancelquery()** #3102
I decided to open a single issue for all of the above problems because I
sense they are somehow related and I hope that fixing the root cause of
one of them will eliminate the other ones as well.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/2016337
[2]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/2016622
[3]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/2017990
[4]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/2020093
[5]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/2023057
[6]: https://gitlab.isc.org/isc-projects/bind9/-/jobs/2023490Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2948DNSSEC signing statistics do not account for cross-algorithm key ID collisions2023-11-02T17:02:19ZMichał KępieńDNSSEC signing statistics do not account for cross-algorithm key ID collisionsIn https://gitlab.isc.org/isc-private/bind9/-/jobs/2033550, two signing
keys for different signing algorithms have the same key ID:
```
>>> 11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/RSASHA256/51742 (policy manykeys)
11-Oct-...In https://gitlab.isc.org/isc-private/bind9/-/jobs/2033550, two signing
keys for different signing algorithms have the same key ID:
```
>>> 11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/RSASHA256/51742 (policy manykeys)
11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/ECDSAP384SHA384/951 (policy manykeys)
11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/RSASHA256/37386 (policy manykeys)
>>> 11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/ECDSAP256SHA256/51742 (policy manykeys)
11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/ECDSAP256SHA256/23421 (policy manykeys)
11-Oct-2021 21:30:08.790 keymgr: keyring: manykeys/ECDSAP384SHA384/8256 (policy manykeys)
```
While this situation is not considered a key ID collision (because
different algorithms are involved), it messes up the XML/JSON statistics
because these are not keyed by the `<algorithm, ID>` tuple but rather
just by the key ID. In the `statschannel` system test, the
`zones-{json,xml}.pl` helper scripts only process *unique* key IDs,
leaving duplicate entries out of their output files. In this specific
example, this led to:
```diff
$ diff -u zones.expect.8 zones.out.x8
--- zones.expect.8 2021-10-11 23:30:21.000000000 +0200
+++ zones.out.x8 2021-10-11 23:30:23.000000000 +0200
@@ -1,12 +1,10 @@
dnssec-refresh operations 23421: 1
dnssec-refresh operations 37386: 10
dnssec-refresh operations 51742: 1
-dnssec-refresh operations 51742: 10
dnssec-refresh operations 8256: 1
dnssec-refresh operations 951: 10
dnssec-sign operations 23421: 1
dnssec-sign operations 37386: 10
dnssec-sign operations 51742: 1
-dnssec-sign operations 51742: 10
dnssec-sign operations 8256: 1
dnssec-sign operations 951: 10
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2938CID 339072 (#1 of 1): Unchecked return value (CHECKED_RETURN)2023-01-09T11:11:24ZMark AndrewsCID 339072 (#1 of 1): Unchecked return value (CHECKED_RETURN)lib/dns/rpz.c:
```
2246
CID 339072 (#1 of 1): Unchecked return value (CHECKED_RETURN)
25. check_return: Calling isc_timer_reset without checking return value (as is done elsewhere 9 out of 10 times).
2247 isc_timer_...lib/dns/rpz.c:
```
2246
CID 339072 (#1 of 1): Unchecked return value (CHECKED_RETURN)
25. check_return: Calling isc_timer_reset without checking return value (as is done elsewhere 9 out of 10 times).
2247 isc_timer_reset(rpz->updatetimer, isc_timertype_inactive, NULL,
2248 NULL, true);
```Not plannedMark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2936dispatch_test failed2023-11-02T17:02:19ZOndřej Surýdispatch_test failedhttps://gitlab.isc.org/isc-projects/bind9/-/jobs/2023742https://gitlab.isc.org/isc-projects/bind9/-/jobs/2023742Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2915False positive with CVE-2020-8622 regression test2022-04-07T13:14:12ZMark AndrewsFalse positive with CVE-2020-8622 regression testIf the timeout for between successive queries has been shortened for
```
I:tsig:check that a malformed truncated response to a TSIG query is handled
```
the test can fail. The default is +time=5, if it is set to 1 (e.g. via .digrc)
na...If the timeout for between successive queries has been shortened for
```
I:tsig:check that a malformed truncated response to a TSIG query is handled
```
the test can fail. The default is +time=5, if it is set to 1 (e.g. via .digrc)
named is still performing lookups when dig times out.Not plannedMark AndrewsMark Andrewshttps://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/2883Let name of inline-signed zone file be configured2023-11-02T16:26:08ZMagnus HolmgrenLet name of inline-signed zone file be configured### Description
The names of journal files can be overridden (with `journal`), but not the names of the signed zone files created when `inline-signing=yes`. They are always named like the original file with `.signed` appended. https://g...### Description
The names of journal files can be overridden (with `journal`), but not the names of the signed zone files created when `inline-signing=yes`. They are always named like the original file with `.signed` appended. https://gitlab.isc.org/isc-projects/bind9/-/blob/2872d6a12efe578360a641c1ba90884ea9a7dd01/bin/named/zoneconf.c#L1116
It's not a huge deal, but I'd like to separate manually edited configuration from software managed data per the FHS, and thus keep non-dynamic master zones in /etc (which is also what the Debian package recommends) but the inline-signed zone data in /var/lib. (It appears that the Debian BIND maintainers didn't consider inline signing, because the included AppArmor profile prevents `named` from writing to /etc/bind.)
### Request
Define a new option `signed-file` or similar. Could something like [signed-file.patch](/uploads/ec5f66b98f5c986d867ea76ccc4a89d9/signed-file.patch) work?Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2879Add --disable-doh to a CI build?2023-11-02T16:26:08ZMark AndrewsAdd --disable-doh to a CI build?The following discussion from !5353 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5353#note_231504): (+1 comment)
> One remaining question is "do we add yet ano...The following discussion from !5353 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5353#note_231504): (+1 comment)
> One remaining question is "do we add yet another system with --disable-doh to CI?"
- [ ] Also should we have a CI build that does not have libnghttp2 installed.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/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/2862Persistent mode doesn't work with `named` AFL fuzzing2022-04-02T07:50:35ZSiva Kesava R KakarlaPersistent mode doesn't work with `named` AFL fuzzing### Summary
When the code is compiled with `afl-clang-fast` to enable fuzzing of `named` in persistent mode, it either results in a compilation error with an older version (2.52b) or goes through with the latest version (3.14c), but the...### Summary
When the code is compiled with `afl-clang-fast` to enable fuzzing of `named` in persistent mode, it either results in a compilation error with an older version (2.52b) or goes through with the latest version (3.14c), but the persistent mode is not detected.
### BIND version used
Older version:
- BIND 9.17.5 (Development Release) <id:dbcf683>
- afl-clang-fast 2.52b
- clang version 4.0.1-10 (tags/RELEASE_401/final)
- Ubuntu:bionic container; afl-clang-fast installed with `apt install afl++`
Latest Version:
- BIND 9.17.16 (Development Release) <id:502f48a>
- afl-cc ++3.14c, mode: LLVM-PCGUARD [(afl-clang-fast symlinks to afl-cc and uses the mode variable to detect LLVM or gcc)](https://github.com/AFLplusplus/AFLplusplus#a-selecting-the-best-afl-compiler-for-instrumenting-the-target)
- Ubuntu clang version 12.0.1-++20210630032618+fed41342a82f-1~exp1~20210630133332.127
- Using aflplusplus/aflplusplus:latest container
### Steps to reproduce
Older version:
- cd bind9; `autoreconf -fi`
- `CXX=afl-clang-fast++ CC=afl-clang-fast ./configure --enable-fuzzing=afl --disable-linux-caps --disable-shared --enable-static --enable-developer --without-cmocka --without-zlib`
- `make -j`
The above `make` results in the following error:
```
make[4]: Entering directory '/bind9/bin/named'
CC fuzz.o
afl-clang-fast 2.52b by <lszekeres@google.com>
fuzz.c:585:2: error: cast from 'const char *' to 'char *' drops const qualifier [-Werror,-Wcast-qual]
__AFL_LOOP(0);
^
<command line>:11:88: note: expanded from here
#define __AFL_LOOP(_A) ({ static volatile char *_B __attribute__((used)); _B = (char*)"##SIG_AFL_PERS...
^
1 error generated.
```
Commenting out that [line from `fuzz.c`](https://gitlab.isc.org/isc-projects/bind9/-/blob/dbcf683c1a57f49876e329fca183cb39d20ca3a4/bin/named/fuzz.c#L577) makes without any issue, but AFL doesn’t recognize it to be in persistent mode (expected as this line was used to signal that).
The build goes through if `afl-clang` is used instead of the `afl-clang-fast`. The problem is that `named` has to be fuzzed in persistent mode only: there is a check for if the environment variable [`AFL_Persistent` is set in fuzz.c](https://gitlab.isc.org/isc-projects/bind9/-/blob/dbcf683c1a57f49876e329fca183cb39d20ca3a4/bin/named/fuzz.c#L752 ) and then it spawns a new fuzz thread.
Latest Version:
Everything gets built using the same above commands, but the new thread is not spawned when run as the above check fails. Running `named -A client:127.0.0.1:53 -g` actually results in a segmentation fault (printing `...found 8 CPUs, using 8 worker threads; using 8 UDP listeners per interface; segmentation fault`) when compiled with the latest version of afl++.
----------------
What version combination (Bind version + clang version) works well for fuzzing the `named` binary using the `-A client:127.0.0.1:53` argument? Are there some flags that have to be set to allow the detection of the persistent mode and allows fuzz thread spawning in the `named_fuzz_setup` function?Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2849Dig: Add option to change default record type2022-04-26T13:36:02ZSören KleinDig: Add option to change default record type### Description
It would be great to have the option to change the default record type from e.g. `A` to `AAAA`.
It would also be very helpful if multiple default record types are supported, e.g. `A, AAAA`.
### Request
I would like t...### Description
It would be great to have the option to change the default record type from e.g. `A` to `AAAA`.
It would also be very helpful if multiple default record types are supported, e.g. `A, AAAA`.
### Request
I would like to set the default records either with an option, e.g. `dig --set-default-records "A, AAAA"` or as part of an system environment variable.
If multiple record types are defined, then the command `dig example.com` with the types `A, AAAA` should be extended to `dig example.com A example.com AAAA`.
### Links / referencesNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2828Compile fail on musl/arm32 since 9.16.82022-03-01T09:45:06ZEd WildgooseCompile fail on musl/arm32 since 9.16.8Hi, I'm building a gentoo based system on arm v7 32bit, using musl as my libc. I am hitting a compile error, that I have determined happens on 9.16.9 onwards, yet I can build fine with 9.16.8 and earlier
The specific error snippet I se...Hi, I'm building a gentoo based system on arm v7 32bit, using musl as my libc. I am hitting a compile error, that I have determined happens on 9.16.9 onwards, yet I can build fine with 9.16.8 and earlier
The specific error snippet I see is:
armv7a-unknown-linux-musleabihf-gcc -O2 -pipe -march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard -mno-unaligned-access -DDIG_SIGCHASE -pthread -fPIC -Wl,-O1 -Wl,--as-needed -L/usr/lib -Wl,--export-dynamic -o sample-async \
sample-async.o ../dns/libdns.a ../isccfg/libisccfg.a ../isc/libisc.a -lcrypto -luv -ldl
/usr/lib/gcc/armv7a-unknown-linux-musleabihf/10.3.0/../../../../armv7a-unknown-linux-musleabihf/bin/ld: ../isc/libisc.a(backtrace.o): in function `btcallback':
backtrace.c:(.text+0x50): undefined reference to `_Unwind_GetIP'
armv7a-unknown-linux-musleabihf-gcc -O2 -pipe -march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard -mno-unaligned-access -DDIG_SIGCHASE -pthread -fPIC -Wl,-O1 -Wl,--as-needed -L/usr/lib -Wl,--export-dynamic -o resolve \
resolve.o ../irs/libirs.a ../dns/libdns.a ../isccfg/libisccfg.a ../isc/libisc.a -lcrypto -luv -ldl
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:494: sample-gai] Error 1
make[1]: *** Waiting for unfinished jobs....
/usr/lib/gcc/armv7a-unknown-linux-musleabihf/10.3.0/../../../../armv7a-unknown-linux-musleabihf/bin/ld: ../isc/libisc.a(backtrace.o): in function `btcallback':
backtrace.c:(.text+0x50): undefined reference to `_Unwind_GetIP'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:502: sample-request] Error 1
/usr/lib/gcc/armv7a-unknown-linux-musleabihf/10.3.0/../../../../armv7a-unknown-linux-musleabihf/bin/ld: ../isc/libisc.a(backtrace.o): in function `btcallback':
backtrace.c:(.text+0x50): undefined reference to `_Unwind_GetIP'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:490: sample-async] Error 1
/usr/lib/gcc/armv7a-unknown-linux-musleabihf/10.3.0/../../../../armv7a-unknown-linux-musleabihf/bin/ld: ../isc/libisc.a(backtrace.o): in function `btcallback':
backtrace.c:(.text+0x50): undefined reference to `_Unwind_GetIP'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:486: resolve] Error 1
I think this is related to this change here:
--- /var/tmp/portage/net-dns/bind-tools-9.16.9/work/bind-9.16.9/lib/isc/backtrace.c 2020-11-16 14:44:37.000000000 +0000
+++ /var/tmp/portage/net-dns/bind-tools-9.16.8/work/bind-9.16.8/lib/isc/backtrace.c 2020-10-13 08:41:40.000000000 +0000
@@ -40,7 +40,7 @@
*/
#ifdef HAVE_LIBCTRACE
#define BACKTRACE_LIBC
-#elif defined(HAVE_UNWIND_BACKTRACE)
+#elif defined(__GNUC__) && (defined(__x86_64__) || defined(__ia64__))
#define BACKTRACE_GCC
#elif defined(WIN32)
#define BACKTRACE_WIN32
If I revert this change then my compile succeeds (although it may not be correct?)
I'm not really skilled enough to understand the details of gcc backtrace implementation on arm. I'm using gcc 10.3.0 to compile this, and I can see that I have a header:
/usr/lib/gcc/armv7a-unknown-linux-musleabihf/10.3.0/include/unwind.h
So I'm assuming that I have gcc compiled with some kind of unwind implementation?
I use a very similar profile to compile near identical code base for both amd64 and x86 architectures and both of those have no issues compiling latest bind-tools (and previous). Also, near as I can see I have my gcc configured identically across all three systems...
Now I *can* compile bind-tools ok if I install the libunwind library, however, that then breaks (re)compiling my gcc compiler, so I'm really thinking that's the wrong route to go down?
Temporarily I'm reverting the above change locally, but I wonder if you could either guide me to a correct solution, or if someone more knowledgeable can revert or write some correct #if test for this situation please?
I'm sure I have failed to provide enough details at this stage. Please be gentle...Not planned