BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2021-10-15T12:32:03Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/536Add a MacOS instance to CI2021-10-15T12:32:03ZMark AndrewsAdd a MacOS instance to CIWe had a build failure on MacOS committed due to MacOS not being part of CI.We had a build failure on MacOS committed due to MacOS not being part of CI.https://gitlab.isc.org/isc-projects/bind9/-/issues/1614IDN and dig2021-10-15T21:46:56ZMark AndrewsIDN and digExtend dig to selectively validate input against
* IDNA2008 `IDN2_NO_TR46`
* TR46 `IDN2_TRANSITIONAL`
* NON-TR46 `IDN2_NONTRANSITIONAL` [current behaviour, default]
`+idnin=<rule>` may be one way to signal thisExtend dig to selectively validate input against
* IDNA2008 `IDN2_NO_TR46`
* TR46 `IDN2_TRANSITIONAL`
* NON-TR46 `IDN2_NONTRANSITIONAL` [current behaviour, default]
`+idnin=<rule>` may be one way to signal thishttps://gitlab.isc.org/isc-projects/bind9/-/issues/421Add support-status command to rndc2021-10-15T22:01:55ZOndřej SurýAdd support-status command to rndcWhile reading https://www.ubuntu.com/info/release-end-of-life I came to an idea that it would be a good to have a `rndc support-status` command that would print the support status of the current version and the current release branch.
A...While reading https://www.ubuntu.com/info/release-end-of-life I came to an idea that it would be a good to have a `rndc support-status` command that would print the support status of the current version and the current release branch.
As it doesn't get automatically executed, it could easily just call home to ask.
@vicky @cathya What do you think?Not plannedOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1630Requested feature: Label construct for configuration file.2021-10-15T22:01:56ZPeter DaviesRequested feature: Label construct for configuration file.The other day while test different configurations, I came upon an old idea that it might be useful if one could define a label in the configuration file.
This would give a simple method to track configuration versions and to verify the r...The other day while test different configurations, I came upon an old idea that it might be useful if one could define a label in the configuration file.
This would give a simple method to track configuration versions and to verify the running config.
This either by consulting the startup messages and/or by using the "rndc status" command.
I realise it is not foolproof and is entirely dependent on the creator updating the label.
Neither would this be usable on included files labels, although using other structures than string may.
Related to :
GL #421 "Add support-status command to rndc"
GL #993 "Provide a way to print out whole configuration as it would be used on startup"
GL #1075 "Print entire running configuration to a file for troubleshooting, diagnostics, updating"
/Peterhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2967Consider adding back resolver timers2021-10-21T08:10:52ZMatthijs Mekkingmatthijs@isc.orgConsider adding back resolver timers#2927 unveiled a cycle that would result in a hang, that previously was a timeout. Consider adding back timers, either with `isc_timers` or with the new network manager timers.#2927 unveiled a cycle that would result in a hang, that previously was a timeout. Consider adding back timers, either with `isc_timers` or with the new network manager timers.https://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/2981Add EDNS option to report raw zone's serial with SOA query for inline zones2021-10-27T20:45:10ZMark AndrewsAdd EDNS option to report raw zone's serial with SOA query for inline zonesThis would be useful when monitoring that the raw contents are up-to-date.This would be useful when monitoring that the raw contents are up-to-date.https://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/3036clang-format-13 leads to weird layout formatting of function parameters2021-12-01T08:52:54ZMatthijs Mekkingmatthijs@isc.orgclang-format-13 leads to weird layout formatting of function parametersThe following discussion from !5602 should be addressed:
- [ ] @matthijs started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5602#note_251399): (+1 comment)
> Off topic, but is this really the preferr...The following discussion from !5602 should be addressed:
- [ ] @matthijs started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5602#note_251399): (+1 comment)
> Off topic, but is this really the preferred format? Maybe we want to adjust the `clang-format`? @ondrejhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3038refactor peer.c to reduce copy-and-paste needed for new options.2021-12-02T02:05:21ZMark Andrewsrefactor peer.c to reduce copy-and-paste needed for new options.This should reduce copy-paste-replace errors.This should reduce copy-paste-replace errors.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3044'recursing clients' counter in stats is still underflowing on BIND 9.16.23-S12021-12-07T11:47:20ZCathy Almond'recursing clients' counter in stats is still underflowing on BIND 9.16.23-S1As reported in [Support ticket #19917](https://support.isc.org/Ticket/Display.html?id=19917)
For example:
```
4294445023 recursing clients
```
We seem to have addressed some causes of this anomaly in earlier versions of BIND ...As reported in [Support ticket #19917](https://support.isc.org/Ticket/Display.html?id=19917)
For example:
```
4294445023 recursing clients
```
We seem to have addressed some causes of this anomaly in earlier versions of BIND (#1078, #1719), but it is definitely still a problem.
There was one hypothesis that this might be related to DNS64 - however, no sign of DNS64 in this named.conf.
I would like to suggest that it might be due to one (or all) of:
- prefetch (it'd be easy to turn this off to confirm?)
- RPZ (yes, they have all of `nsip-wait-recurse no` and `qname-wait-recurse no` but whether or not additional recursion takes place is determined also by the actual policies in the policy zones themselves)
- Something awry with TCP socket handling?
- Something whacky with the interaction with serve-stale? (Although this is a default config., so `stale-cache-enable yes;`, `stale-answer-enable no;`.
No fetch-limits in this configuration, but if it was purely fetch-limits related, I think we'd have found and fixed it by now.https://gitlab.isc.org/isc-projects/bind9/-/issues/637Proxy-mode secondary zones "lazy-secondary"2021-12-15T15:20:06ZCathy AlmondProxy-mode secondary zones "lazy-secondary"### Description
As suggested in https://support.isc.org/Ticket/Display.html?id=13653 along with one tactic explicitly requested in https://gitlab.isc.org/isc-projects/bind9/issues/636.
This could be another way to look at meeting the u...### Description
As suggested in https://support.isc.org/Ticket/Display.html?id=13653 along with one tactic explicitly requested in https://gitlab.isc.org/isc-projects/bind9/issues/636.
This could be another way to look at meeting the underlying need by means of a proxy or lazy-secondary service?
### Request
The end goal is being able to maintain a 'proxy' or 'boundary' authoritative DNS server set for an organization, without needing to explicitly provision the servers as secondaries for all internal domains and subdomains thereof, but instead make use of recursive resolution and cached answers to fulfill (non-recursive) queries from Internet resolvers.
The needs are:
- Respond authoritatively for everything within the internal domain space
- Use recursion to obtain answers for zones that have been configured as covered by 'proxy-mode' or 'lazy-secondary', even if client requests do not have 'RD' set, and would not otherwise be permitted to access recursive services
- Don't break DNSSEC (so no synthesizing of RRsets)
- Stop chasing CNAMEs where they point outside of the internal domain space
- Don't recurse at all, outside of the 'proxy-mode' domains and subdomains
Limitations and provisos:
- The DNS administrator will need be to be responsible for configuring an internal root that enables recursion within the organisation's namespace, but not to beyond that.
- This set-up is inevitably going to deliver some query responses to the clients that provide other NS RRsets within the organisation that should be unreachable (assuming that the boundary routing is correctly configured).
- It will not be possible to 'hide' these nameserver names/addresses without breaking DNSSEC.
- The organisation's boundary routers must deliver queries addressed to the internal routers to the server providing proxy services, and it must accept them, with their original addresses (providing that those addresses are within its managed address space)
- Query responses should be sent from the address they were originally addressed to - effectively the zones being proxied are also having their servers 'spoofed'
- Since cache is being used to 'lazy-secondary' authoritative responses, the TTLs would ordinarily vary due to counting down - is there any mechanism to still count down and refresh as normal, but when responding authoritatively, to use the original TTL as obtained from the internal authoritative server?
... and anything else I didn't yet think of
### Links / referenceshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3059Follow-up from "Draft: Resolve #3055 by examining RTM_NEWADDR, RTM_DELADDR me...2021-12-20T11:58:16ZEvan HuntFollow-up from "Draft: Resolve #3055 by examining RTM_NEWADDR, RTM_DELADDR messages contents"The following discussion from !5638 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5638#note_254568): (+3 comments)
> We could also just take the RTM_NEWADDR and...The following discussion from !5638 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5638#note_254568): (+3 comments)
> We could also just take the RTM_NEWADDR and RTM_DELADDR content and add/delete the interfaces individually rather than scanning at all. Leave scanning for startup / reconfiguration. Queue up events while scanning then process any queued events at the end.
Also, see #3064.https://gitlab.isc.org/isc-projects/bind9/-/issues/2999remove duplicate code between DLZ example & dlzexternal test2022-01-07T09:40:28ZPetr Špačekpspacek@isc.orgremove duplicate code between DLZ example & dlzexternal testVersion: main branch, 4bebcd45033400a6b1a3057c60c3a2cfd5fd4029
These two files are substantially the same:
- contrib/dlz/example/dlz_example.c
- bin/tests/system/dlzexternal/driver/driver.c
I think we should remove one of them and use ...Version: main branch, 4bebcd45033400a6b1a3057c60c3a2cfd5fd4029
These two files are substantially the same:
- contrib/dlz/example/dlz_example.c
- bin/tests/system/dlzexternal/driver/driver.c
I think we should remove one of them and use symlink instead of copy. Updating two files is ... suboptimal.Long-termhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3085checkds test is unstable on OpenBSD2022-01-10T14:50:34ZMichal Nowakcheckds test is unstable on OpenBSDJob [#2213656](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2213656) failed for 5d677c1b3642a33a1c855fc44b2fb65b7a36f512 on OpenBSD:
`wait_for_log()` fails to find `zone multiple-dspublished.checkds/IN (signed): checkds: DS response...Job [#2213656](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2213656) failed for 5d677c1b3642a33a1c855fc44b2fb65b7a36f512 on OpenBSD:
`wait_for_log()` fails to find `zone multiple-dspublished.checkds/IN (signed): checkds: DS response from 10.53.0.4` line in `ns9/named.run` which supposedly appears in the log at `07-Jan-2022 09:21:12.195` but it was able to find `zone multiple-dspublished.checkds/IN (signed): checkds: DS response from 10.53.0.2`, which in the log appears at `07-Jan-2022 09:21:11.688` - just 507 ms before. But this should not happen because `wait_for_log()` is polling 10 seconds for the line.
```
...
D:checkds:# DS correctly published in all parents.
D:checkds:zone_check(server, "multiple-dspublished.checkds.")
D:checkds:wait_for_log("ns9/named.run",
D:checkds:"zone multiple-dspublished.checkds/IN (signed): checkds: "
D:checkds:"DS response from 10.53.0.2")
D:checkds:> wait_for_log("ns9/named.run",
D:checkds:"zone multiple-dspublished.checkds/IN (signed): checkds: "
D:checkds:"DS response from 10.53.0.4")
D:checkds:
D:checkds:tests-checkds.py:269:
D:checkds:_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
D:checkds:
D:checkds:filename = 'ns9/named.run'
D:checkds:log = 'zone multiple-dspublished.checkds/IN (signed): checkds: DS response from 10.53.0.4'
D:checkds:
D:checkds:def wait_for_log(filename, log):
D:checkds:found = False
D:checkds:
D:checkds:for _ in range(10):
D:checkds:print("read log file {}".format(filename))
D:checkds:
D:checkds:try:
D:checkds:with open(filename, 'r', encoding='utf-8') as file:
D:checkds:s = mmap.mmap(file.fileno(), 0, access=mmap.ACCESS_READ)
D:checkds:if s.find(bytes(log, "ascii")) != -1:
D:checkds:found = True
D:checkds:except FileNotFoundError:
D:checkds:print("file not found {}".format(filename))
D:checkds:
D:checkds:if found:
D:checkds:break
D:checkds:
D:checkds:print("sleep")
D:checkds:time.sleep(1)
D:checkds:
D:checkds:> assert found
D:checkds:E assert False
D:checkds:
D:checkds:tests-checkds.py:219: AssertionError
D:checkds:----------------------------- Captured stdout call -----------------------------
D:checkds:read log file ns9/named.run
D:checkds:read state file ns9/Kdspublished.checkds.+013+46589.state
D:checkds:read log file ns9/named.run
D:checkds:read state file ns9/Kreference.checkds.+013+33843.state
D:checkds:read log file ns9/named.run
D:checkds:read state file ns9/Kmissing-dspublished.checkds.+013+18135.state
D:checkds:read log file ns9/named.run
D:checkds:read state file ns9/Kbad-dspublished.checkds.+013+20215.state
D:checkds:read log file ns9/named.run
D:checkds:read log file ns9/named.run
D:checkds:sleep
D:checkds:read log file ns9/named.run
D:checkds:sleep
D:checkds:read log file ns9/named.run
D:checkds:sleep
D:checkds:read log file ns9/named.run
D:checkds:sleep
D:checkds:read log file ns9/named.run
D:checkds:sleep
D:checkds:read log file ns9/named.run
D:checkds:sleep
D:checkds:read log file ns9/named.run
D:checkds:sleep
D:checkds:read log file ns9/named.run
D:checkds:sleep
D:checkds:read log file ns9/named.run
D:checkds:sleep
D:checkds:read log file ns9/named.run
D:checkds:sleep
D:checkds:===================== 1 failed, 1 passed in 11.14 seconds ======================
```
`named.run`: [named.run](/uploads/ced46b015192dfd435fd28988c35d7d5/named.run)Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3094doth: RNDC reconfiguration too slow on OpenIndiana2022-01-14T11:18:06ZMichal Nowakdoth: RNDC reconfiguration too slow on OpenIndianaEven with 2e5f9a0df5e0a8a15c1cdf69f2aae55fd7a0aca3 RNDC reconfiguration in `doth` system test takes 30-60 second and `dig` invocations fail with "connection refused" on OpenIndiana (but not on Solaris 11.4). Affects `doth` tests "checkin...Even with 2e5f9a0df5e0a8a15c1cdf69f2aae55fd7a0aca3 RNDC reconfiguration in `doth` system test takes 30-60 second and `dig` invocations fail with "connection refused" on OpenIndiana (but not on Solaris 11.4). Affects `doth` tests "checking DoT query after a reconfiguration" and "checking DoH query (POST) after a reconfiguration".
Keep `named`s from `doth` system test running and issue `../../../bin/rndc/rndc -c common/rndc.conf -p 5312 -s 10.53.0.4 reconfig` command:
```
...
11-Jan-2022 16:43:49.938 calling free_rbtdb(.)
11-Jan-2022 16:43:49.938 done free_rbtdb(.)
```
Only after 30 seconds (sometimes close to 60 seconds) `named` is ready:
```
11-Jan-2022 16:44:19.082 listening on IPv4 interface lo0, 10.53.0.4#5301
11-Jan-2022 16:44:19.083 listening on IPv4 interface lo0, 10.53.0.4#5303
```
Otherwise, `../../../bin/dig/dig +tls +noadd +nosea +nostat +noquest +nocmd -p 5301 @10.53.0.4 example SOA` fails with:
```
;; Connection to 10.53.0.4#5301(10.53.0.4) for example failed: connection refused.
;; Connection to 10.53.0.4#5301(10.53.0.4) for example failed: connection refused.
;; Connection to 10.53.0.4#5301(10.53.0.4) for example failed: connection refused.
```
CPU utilization of `named` looks sub 1% during the reconfiguration.Not plannedArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3098Intermittent mkeys test failure2022-01-14T13:53:30ZOndřej SurýIntermittent mkeys test failurehttps://gitlab.isc.org/isc-projects/bind9/-/jobs/2231254
```
I:mkeys:reset the root server with no keys, check for minimal update (23)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:ns2 refreshing managed keys for '_default'
...https://gitlab.isc.org/isc-projects/bind9/-/jobs/2231254
```
I:mkeys:reset the root server with no keys, check for minimal update (23)
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:ns2 refreshing managed keys for '_default'
I:mkeys:failed
I:mkeys:reset the root server with no signatures, check for minimal update (24)
```
I am guessing this is timing related again.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3136dnstap-read: add incremental packet number to the output2022-02-10T15:06:10Zmartinvonwittichdnstap-read: add incremental packet number to the output### Description
Currently, `dnstap-read` doesn't print any kind of unique identifier per packet. E.g. if I'm using it without any options to get the short summary format:
```
09-Feb-2022 02:33:36.294 CQ 127.0.0.1:41718 -> 127.0.0.1:0 U...### Description
Currently, `dnstap-read` doesn't print any kind of unique identifier per packet. E.g. if I'm using it without any options to get the short summary format:
```
09-Feb-2022 02:33:36.294 CQ 127.0.0.1:41718 -> 127.0.0.1:0 UDP 33b example.com/IN/MX
09-Feb-2022 02:33:36.334 RR 192.168.1.2:55163 <- 192.168.1.1:53 UDP 71b example.com/IN/MX
09-Feb-2022 02:33:36.294 RQ 192.168.1.2:55163 -> 192.168.1.1:53 UDP 33b example.com/IN/MX
09-Feb-2022 02:33:36.334 CR 127.0.0.1:41718 <- 127.0.0.1:0 UDP 102b example.com/IN/MX
09-Feb-2022 02:33:38.453 CQ 127.0.0.1:57293 -> 127.0.0.1:0 UDP 33b example.com/IN/MX
09-Feb-2022 02:33:38.453 CR 127.0.0.1:57293 <- 127.0.0.1:0 UDP 102b example.com/IN/MX
```
and then I want to lookup the details of one of these packets in the `-p` format, I have to search for the whole line to find it.
It's even worse in the `-y` format because contrary to the `-p` format, the YAML representation doesn't contain the original summary line, and while the summary and `-p` will print timestamps in the local timezone, `-y` will print UTC timestamps.
### Request
I would like `dnstap-read` to prefix each packet with an incremental number in the summary and in the `-p` output, so that the details for a packet can easily be searched. The YAML representation should contain the number in an additional YAML field.
### Links / references
I like the way it works in `tshark` - each line in the summary is prefixed with an incremental packet number:
```
server ~ # tshark -i ens3 -w test.pcap
Running as user "root" and group "root". This could be dangerous.
Capturing on 'ens3'
4 ^C
server ~ # tshark -r test.pcap
Running as user "root" and group "root". This could be dangerous.
1 2022-02-09 17:43:01,528756106 02:00:62:3e:71:f5 → 02:00:62:3e:71:f9 ARP 42 Who has 172.16.56.10? Tell 172.16.0.1
2 2022-02-09 17:43:01,528792938 02:00:62:3e:71:f9 → 02:00:62:3e:71:f5 ARP 42 172.16.56.10 is at 02:00:62:3e:71:f9
3 2022-02-09 17:43:02,068971390 172.16.56.10 → 172.21.0.10 SSH 102 Server: Encrypted packet (len=36)
4 2022-02-09 17:43:02,170798836 172.21.0.10 → 172.16.56.10 TCP 66 55798 → 22 [ACK] Seq=1 Ack=37 Win=990 Len=0 TSval=1691964300 TSecr=1370499909
```
When printing the capture file with the `-V` option, the first line of each frame is prefixed with `Frame n`, which makes it easy to search in a pager:
```
server ~ # tshark -r test.pcap -V | head -n 5
Running as user "root" and group "root". This could be dangerous.
Frame 1: 42 bytes on wire (336 bits), 42 bytes captured (336 bits) on interface 0
Interface id: 0 (ens3)
Interface name: ens3
Encapsulation type: Ethernet (1)
Arrival Time: Feb 9, 2022 17:43:01.528756106 CET
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3148Consider changing the "shut down hung fetch" log message2022-02-11T15:02:19ZMichał KępieńConsider changing the "shut down hung fetch" log message!5612 reintroduced the global recursive query handling timer, to enable
netmgr-based dispatch code to deal with some pathological resolution
scenarios relatively cleanly (i.e. without indefinitely holding on to
resources). A new log mes...!5612 reintroduced the global recursive query handling timer, to enable
netmgr-based dispatch code to deal with some pathological resolution
scenarios relatively cleanly (i.e. without indefinitely holding on to
resources). A new log message was introduced, too:
```c
4612 static void
4613 fctx_expired(isc_task_t *task, isc_event_t *event) {
4614 fetchctx_t *fctx = event->ev_arg;
4615
4616 REQUIRE(VALID_FCTX(fctx));
4617
4618 UNUSED(task);
4619
4620 isc_log_write(dns_lctx, DNS_LOGCATEGORY_RESOLVER,
4621 DNS_LOGMODULE_RESOLVER, ISC_LOG_INFO,
4622 "shut down hung fetch while resolving '%s'", fctx->info);
4623 fctx_shutdown(fctx);
4624 isc_event_free(&event);
4625 }
```
Empirical evidence from a small resolver with often-flaky connectivity
suggests that this log message may be confusing because no *detection*
of hung fetches actually takes place - rather, `fctx_expired()` is
simply the timer callback. In other words, the "shut down hung fetch"
message may be logged e.g. due to query timeouts (caused by intermittent
network issues) preventing the resolution from succeeding. The log
message in question should therefore arguably be revised as it cannot be
used to reliably discern between the resolver code itself having issues
with a given query and e.g. network connectivity failing for a few
seconds.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3131test case timeout when the number of CPUs is 1282022-02-21T11:59:29Zjin ggtest case timeout when the number of CPUs is 128test case timeout when the number of CPUs is 128 :
![image](/uploads/c53b15deba7467dd5e2d82cf56c92288/image.png)
I see some test cases will create manager wokers with the same number of CPUs on machine. This is the root cause of the tes...test case timeout when the number of CPUs is 128 :
![image](/uploads/c53b15deba7467dd5e2d82cf56c92288/image.png)
I see some test cases will create manager wokers with the same number of CPUs on machine. This is the root cause of the test case timeout. The more workers threads, the worse the performance seems.
![image](/uploads/00c9a46063873de9cfd1f78d3ca782a3/image.png)
At the same time, I see that named's main program also uses the number of CPUs on the macine to create manager worker threads, So I wonder if this affects named's performance when the number of CPUs is high?
![image](/uploads/1d7157ba9cafb358f80ea2fd3005fa25/image.png)Not planned