ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2022-11-25T17:02:36Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3608[question] 9.18.4 fails processing certain query reply with: 'end of file'2022-11-25T17:02:36ZBenoît Panizzon[question] 9.18.4 fails processing certain query reply with: 'end of file'### Summary
Working for an ISP which recently updated it's caching and recursive NS to bind 9.18.4 we got a report from a customer which could not resolve a specific resource: fd19g0409.drive.pro.io
### BIND version used
9.18.4
### S...### Summary
Working for an ISP which recently updated it's caching and recursive NS to bind 9.18.4 we got a report from a customer which could not resolve a specific resource: fd19g0409.drive.pro.io
### BIND version used
9.18.4
### Steps to reproduce
$ dig +noedns +nocookie +nodnssec +noednsnegotiation A fd19g0409.drive.pro.io @{BIND-9.18.4-NS}
Setting various options likely to pin down causes of similar issues. No success.
Consult Syslog on Bind DNS and find error:
named[3156696]: end of file resolving '_.drive.pro.io/A/IN': 80.74.143.169#53
Analyzing traffic with Wireshark shows the authoritative server in question is answering the query and the reply IMHO is correct.
### What is the current *bug* behavior?
Bind 9.18.4 most probably fails parsing the reply with 'End of File' Error thus ignoring the reply. They query is repeated a couple of times, then a timeout 'SERVERFAIL' is returned to the client.
### What is the expected *correct* behavior?
Using Bind 9.11.36 with the same query works flawlessly.
Using other DNS resolves works flawlessly.
=> A record of: fd19g0409.drive.pro.io is returned.
### Relevant configuration files
I don't think this is relevant. It could be reproduced by others.
### Relevant logs and/or screenshots
named[3156696]: end of file resolving '_.drive.pro.io/A/IN': 80.74.143.169#53
Asked on SWINOG Mailinglist if colleagues at other ISP could reproduce the issue or could spot the cause.
Result: Got report from a colleague: Bind 9.18.7 fails the same way.
Got several reports that nobody can spot an issue with the reply in question which would cause bind to fail to parse this reply.
Got a hint, that it might be related to issue: #3474
Others suspect this looks like a Bug in Bind 9.18.Xhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3605empty-zones-enable should implicitly specify "forwarders {};" on empty zones2022-10-20T22:26:16Zelmaimboempty-zones-enable should implicitly specify "forwarders {};" on empty zones### Summary
The purpose of the "empty-zones-enable" option, when set to "yes" (default setting), is to prevent reverse DNS look-ups of private IP addresses leaking out to the Internet. However when the "forwarders" option has been speci...### Summary
The purpose of the "empty-zones-enable" option, when set to "yes" (default setting), is to prevent reverse DNS look-ups of private IP addresses leaking out to the Internet. However when the "forwarders" option has been specified with a non-blank value (at the options or view level), the observed behaviour is that these queries are sent to the forwarders. These queries should be answered locally instead of being forwarded.
### BIND version used
BIND 9.18.1
### Steps to reproduce
Specify the following configuration for BIND:
```
options {
forwarders {
1.1.1.1;
};
# empty-zones-enable is set to yes by default
};
```
(edit: this was log copy&pasted from [a different configuration](https://gitlab.isc.org/isc-projects/bind9/-/issues/3605#note_322409))
~~Note that when BIND starts up it logs something like this:~~
> ~~zoneload: automatic empty zone: view XXX: 168.192.IN-ADDR.ARPA~~
Then use dig to perform reverse look-up of a private IP address - e.g.: `dig -x 192.168.1.1`
### What is the current *bug* behavior?
BIND logs show that the request was sent to the forwarders specified in the options:
```
16-Oct-2022 14:23:17.568 queries: info: client @0x7fdd7c036758 ::1#34016 (1.1.168.192.in-addr.arpa): view XXX: query: 1.1.168.192.in-addr.arpa IN PTR +E(0)K (::1)
16-Oct-2022 14:23:17.604 lame-servers: info: no valid RRSIG resolving '168.192.in-addr.arpa/DS/IN': 1.1.1.1#53
16-Oct-2022 14:23:17.604 lame-servers: info: broken trust chain resolving '1.1.168.192.in-addr.arpa/PTR/IN': 1.1.1.1#53
16-Oct-2022 14:23:17.604 query-errors: info: client @0x7fdd7c036758 ::1#34016 (1.1.168.192.in-addr.arpa): view XXX: query failed (broken trust chain) for 1.1.168.192.in-addr.arpa/IN/PTR at query.c:7649
```
### What is the expected *correct* behavior?
The queries relating to the zones created by the empty-zones-enable option should be answered locally.
### Relevant configuration files
See above.
### Relevant logs and/or screenshots
See above.
### Possible fixes
The zones created by the empty-zones-enable option should contain an implicit "forwarders {};" setting which would stop these queries from being forwarded.
If the administrator actually does want these requests to be forwarded, they should specify "empty-zones-enable no;" or "disable-empty-zone ...".https://gitlab.isc.org/isc-projects/kea/-/issues/2592partner-down state transition when max-unacked-clients reached2022-11-24T14:45:22ZMarcin Siodelskipartner-down state transition when max-unacked-clients reachedSuppose the server lost the connection with its partner. The server begins the failover procedure by checking whether or not the partner responds to the DHCP queries. The `max-unacked-clients` setting controls how many different clients ...Suppose the server lost the connection with its partner. The server begins the failover procedure by checking whether or not the partner responds to the DHCP queries. The `max-unacked-clients` setting controls how many different clients should retry getting the lease with the increased value of the `secs` field before the server considers partner dead. One would expect the server to make `partner-down` transition as soon as the number of unacked clients reaches the configured number. In fact, the state transitions are generally performed when the server completes a heartbeat or a lease update. It is possible that under heavy traffic there will be much larger number of unacked clients and the server still sits in the normal state (e.g. hot-standby), waiting for the heartbeat trigger. Assuming the heartbeat interval is reasonable, it should probably be fine. However, we may consider starting the transition as soon as the number of unacked clients reaches the configured maximum.backloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3604bind9 package in Ubuntu 18.04 PPA can't be installed2022-10-16T07:34:01ZTom Krizekbind9 package in Ubuntu 18.04 PPA can't be installed### Summary
When attempting to install a bind9 package from [ISC's PPA](https://launchpad.net/~isc/+archive/ubuntu/bind/+packages) on Ubuntu 18.04, the installation fails due to a dependency issue.
(reported by a user to info@isc.org)
...### Summary
When attempting to install a bind9 package from [ISC's PPA](https://launchpad.net/~isc/+archive/ubuntu/bind/+packages) on Ubuntu 18.04, the installation fails due to a dependency issue.
(reported by a user to info@isc.org)
### BIND version used
bind9 - 1:9.18.7-1+ubuntu18.04.1+isc+1
### Steps to reproduce
```
# add-apt-repository ppa:isc/bind
# apt install bind9
```
### What is the current *bug* behavior?
```
# apt install bind9
Reading package lists... Done
Building dependency tree
Reading state information... Done
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:
The following packages have unmet dependencies:
bind9 : PreDepends: init-system-helpers (>= 1.54~) but 1.51 is to be installed
E: Unable to correct problems, you have held broken packages.
```
### What is the expected *correct* behavior?
bind9 package is installedhttps://gitlab.isc.org/isc-projects/stork/-/issues/880Empty search results should clear the result list2022-11-08T14:49:35ZSlawek FigielEmpty search results should clear the result listThe issue was found during 1.8.0 sanity checks by @slawek. [Source](https://gitlab.isc.org/isc-projects/stork/-/issues/875#note_320878).
![image](https://gitlab.isc.org/isc-projects/stork/uploads/b97638c6dd045b23ae3f942baa09cce7/image.p...The issue was found during 1.8.0 sanity checks by @slawek. [Source](https://gitlab.isc.org/isc-projects/stork/-/issues/875#note_320878).
![image](https://gitlab.isc.org/isc-projects/stork/uploads/b97638c6dd045b23ae3f942baa09cce7/image.png)
An empty search result should cause to clear the list and display an empty placeholder.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/879Out-of-pool utilization bar2023-12-05T13:25:01ZSlawek FigielOut-of-pool utilization barThe issue was found during 1.8.0 sanity checks by @slawek. [Source](https://gitlab.isc.org/isc-projects/stork/-/issues/875#note_320877).
![image](https://gitlab.isc.org/isc-projects/stork/uploads/35031faddfcd6e1aa1abdd3b9d5cd643/image.p...The issue was found during 1.8.0 sanity checks by @slawek. [Source](https://gitlab.isc.org/isc-projects/stork/-/issues/875#note_320877).
![image](https://gitlab.isc.org/isc-projects/stork/uploads/35031faddfcd6e1aa1abdd3b9d5cd643/image.png)
We can add a dedicated bar for the utilization of out-of-pool reservations. It looks weird when the total addresses count exceeds 0, but no bar is presented.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/877Sanity checks for Stork 1.7.0 rc22022-10-13T08:53:19ZWlodzimierz WencelSanity checks for Stork 1.7.0 rc2We are now at step SANITY CHECKS of Stork 1.7.0 rc2.
Please do sanity checks according to the steps below:
1. Get the tarball and check it, run tests with `rake unittest:backend` or `rake unittest:backend_db`.
2. Get the apk, deb & rpm...We are now at step SANITY CHECKS of Stork 1.7.0 rc2.
Please do sanity checks according to the steps below:
1. Get the tarball and check it, run tests with `rake unittest:backend` or `rake unittest:backend_db`.
2. Get the apk, deb & rpm packages, place them in the tarball location, run tests with `rake system_tests` and `rake system_tests_ui`.
3. Start demo locally with `rake demo:up` and follow the steps from the demo wiki: https://gitlab.isc.org/isc-projects/stork/-/wikis/Demo
4. Install server and agent locally e.g. in VMs from apk, deb & rpm packages
Before starting, please state what you are checking in a thread/discussion (not as comment).
When you finish a check, state in the same thread/discussion what the result is.
This way we know what is covered upfront and we can avoid repeating ourselves.
* tarball: https://gitlab.isc.org/isc-projects/stork/-/jobs/2822777/artifacts/browse
* apk, deb & rpm packages: https://gitlab.isc.org/isc-projects/stork/-/jobs/2822781/artifacts/browse1.7https://gitlab.isc.org/isc-projects/bind9/-/issues/3597tls_test gets stuck in tls_timeout_recovery2022-12-14T18:26:43ZOndřej Surýtls_test gets stuck in tls_timeout_recoveryThis happens quite often:
```
rr: Saving execution to trace directory `/home/ondrej/.local/share/rr/tls_test-0'.
[==========] Running 11 test(s).
[ RUN ] tls_noop
[ OK ] tls_noop
[ RUN ] tls_noresponse
[ OK ] tls_n...This happens quite often:
```
rr: Saving execution to trace directory `/home/ondrej/.local/share/rr/tls_test-0'.
[==========] Running 11 test(s).
[ RUN ] tls_noop
[ OK ] tls_noop
[ RUN ] tls_noresponse
[ OK ] tls_noresponse
[ RUN ] tls_timeout_recovery
```
and it gets stuck.Artem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/stork/-/issues/8751.7.0 sanity checks2022-10-13T08:50:02ZWlodzimierz Wencel1.7.0 sanity checkshttps://gitlab.isc.org/isc-projects/stork/-/jobs/2820242/artifacts/browse
https://gitlab.isc.org/isc-projects/stork/-/jobs/2820238/artifacts/browse
Please do sanity checks according to the steps below:
1. Get the tarball and check it...https://gitlab.isc.org/isc-projects/stork/-/jobs/2820242/artifacts/browse
https://gitlab.isc.org/isc-projects/stork/-/jobs/2820238/artifacts/browse
Please do sanity checks according to the steps below:
1. Get the tarball and check it, run tests with `rake unittest:backend` or `rake unittest:backend_db`.
2. Get the deb & rpm packages, place them in the tarball location, run tests with `rake system_tests` and `rake system_tests_ui`.
3. Start demo locally with `rake demo:up` and follow the steps from the demo wiki: https://gitlab.isc.org/isc-projects/stork/-/wikis/Demo
4. Install server and agent locally e.g. in VMs from deb & rpm packages1.7https://gitlab.isc.org/isc-projects/bind9/-/issues/3593"manykeys" zone gets resigned twice during a single "statschannel" system tes...2022-10-10T21:34:43ZMichał Kępień"manykeys" zone gets resigned twice during a single "statschannel" system test runhttps://gitlab.isc.org/isc-private/bind9/-/jobs/2819986
<details>
<summary>Click to expand/collapse test output</summary>
```
S:statschannel:2022-10-10T10:13:28+0000
T:statschannel:1:A
A:statschannel:System test statschannel
I:statscha...https://gitlab.isc.org/isc-private/bind9/-/jobs/2819986
<details>
<summary>Click to expand/collapse test output</summary>
```
S:statschannel:2022-10-10T10:13:28+0000
T:statschannel:1:A
A:statschannel:System test statschannel
I:statschannel:PORTS:10363,10364,10365,10366,10367,10368,10369,10370,10371,10372,10373,10374,10375
I:statschannel:starting servers
I:statschannel:checking consistency between named.stats and xml/json (1)
I:statschannel:checking malloced memory statistics xml/json (2)
I:statschannel:checking consistency between regular and compressed output (3)
I:statschannel:checking if compressed output is really compressed (4)
I:statschannel:fetching zone 'dnssec' stats data after zone maintenance at startup (5)
I:statschannel:... using xml
I:statschannel:... using json
I:statschannel:fetching zone 'dnssec' stats data after dynamic update (6)
I:statschannel:... using xml
I:statschannel:... using json
I:statschannel:fetch zone 'dnssec' stats data after updating DNSKEY RRset (7)
I:statschannel:... using xml
I:statschannel:... using json
I:statschannel:fetching zone 'manykeys' stats data after zone maintenance at startup (8)
I:statschannel:... using xml
zones.out.x8 zones.expect.8 differ: char 37, line 1
I:statschannel:... using json
zones.out.j8 zones.expect.8 differ: char 37, line 1
I:statschannel:failed
I:statschannel:fetching zone 'manykeys' stats data after dynamic update (9)
I:statschannel:... using xml
zones.out.x9 zones.expect.9 differ: char 37, line 1
I:statschannel:... using json
zones.out.j9 zones.expect.9 differ: char 37, line 1
I:statschannel:failed
I:ns2 server reload successful
I:statschannel:fetching zone 'manykeys' stats data after dnssec-policy change (10)
I:statschannel:... using xml
zones.out.x10 zones.expect.10 differ: char 34, line 1
I:statschannel:... using json
zones.out.j10 zones.expect.10 differ: char 34, line 1
I:statschannel:failed
I:statschannel:Check HTTP/1.1 pipelined requests are handled (GET) (11)
I:statschannel:Check HTTP/1.1 pipelined requests are handled (POST) (12)
I:statschannel:Check HTTP/1.1 pipelined with truncated stream (13)
I:statschannel:exit status: 3
I:statschannel:stopping servers
R:statschannel:FAIL
E:statschannel:2022-10-10T10:13:48+0000
FAIL statschannel (exit status: 1)
```
</details>
```diff
$ diff -u zones.expect.8 zones.out.j8
--- zones.expect.8 2022-10-10 12:13:39.000000000 +0200
+++ zones.out.x8 2022-10-10 12:13:40.000000000 +0200
@@ -1,12 +1,12 @@
-dnssec-refresh operations 13+13146: 10
-dnssec-refresh operations 13+35376: 1
-dnssec-refresh operations 14+13156: 10
-dnssec-refresh operations 14+65001: 1
-dnssec-refresh operations 8+498: 10
-dnssec-refresh operations 8+5755: 1
-dnssec-sign operations 13+13146: 10
-dnssec-sign operations 13+35376: 1
-dnssec-sign operations 14+13156: 10
-dnssec-sign operations 14+65001: 1
-dnssec-sign operations 8+498: 10
-dnssec-sign operations 8+5755: 1
+dnssec-refresh operations 13+13146: 20
+dnssec-refresh operations 13+35376: 2
+dnssec-refresh operations 14+13156: 20
+dnssec-refresh operations 14+65001: 2
+dnssec-refresh operations 8+498: 20
+dnssec-refresh operations 8+5755: 2
+dnssec-sign operations 13+13146: 20
+dnssec-sign operations 13+35376: 2
+dnssec-sign operations 14+13156: 20
+dnssec-sign operations 14+65001: 2
+dnssec-sign operations 8+498: 20
+dnssec-sign operations 8+5755: 2
```
Looking at `ns2/named.run`, it looks like the signatures were
unexpectedly refreshed twice: first at 10:13:30 and then again, ten
seconds later (at 10:13:40). Sample log excerpts for a single RRset:
```
$ grep -E '(add|del) re-sign mail\.manykeys\..*A 13.*13146' ns2/named.run
10-Oct-2022 10:13:30.523 del re-sign mail.manykeys. 300 IN RRSIG A 13 2 300 20221010101330 20221010091329 13146 manykeys. d3FRyKl8rOtAf/X760MtA34ekLMhPkK4kwXWu16bnHDXP+CFv3bHmIUo 3GlOU64YOY0sd1zdw1byjqD7uz84Gw==
10-Oct-2022 10:13:30.523 add re-sign mail.manykeys. 300 IN RRSIG A 13 2 300 20221015101340 20221010091330 13146 manykeys. 1nY6w6eOfvFvKQtkznuuB2sUPXy0Y8OCudY3bHl3+j4Atxbzwwp8hNRE bMOkm6b68Z9x9a82Xii3n5EE0vwDXA==
10-Oct-2022 10:13:40.079 del re-sign mail.manykeys. 300 IN RRSIG A 13 2 300 20221015101340 20221010091330 13146 manykeys. 1nY6w6eOfvFvKQtkznuuB2sUPXy0Y8OCudY3bHl3+j4Atxbzwwp8hNRE bMOkm6b68Z9x9a82Xii3n5EE0vwDXA==
10-Oct-2022 10:13:40.079 add re-sign mail.manykeys. 300 IN RRSIG A 13 2 300 20221024092343 20221010091340 13146 manykeys. 1oAQSc/D2yrMPekGrtLwFoMCGJj0UkF7XnWmPPV7o+snZij5dZCdrIjA cZlhzdOGA4VZvloE5a+p6EY1Mw/M3g==
10-Oct-2022 10:13:44.407 del re-sign mail.manykeys. 300 IN RRSIG A 13 2 300 20221024092343 20221010091340 13146 manykeys. 1oAQSc/D2yrMPekGrtLwFoMCGJj0UkF7XnWmPPV7o+snZij5dZCdrIjA cZlhzdOGA4VZvloE5a+p6EY1Mw/M3g==
```
This is what the same command outputs when the test passes:
```
$ grep -E '(add|del) re-sign mail\.manykeys\..*A 13.*15554' ns2/named.run
10-Oct-2022 15:41:21.833 del re-sign mail.manykeys. 300 IN RRSIG A 13 2 300 20221010134122 20221010124121 15554 manykeys. FQQc1UmPh0TVCJSBfb64Mw7btRfTpAr7CyFku52KUyJPmkCXBATY3tVg ksPoFHRs8YTp5dC6+jwmhEznH6JULg==
10-Oct-2022 15:41:21.833 add re-sign mail.manykeys. 300 IN RRSIG A 13 2 300 20221017201301 20221010124121 15554 manykeys. JIg+WRo5qf7a4A0J7bJ7Ug4BZIbUkDzG38ohjfNlG2JuDTYGlr92/gU+ uThPRYFN65ki7nChpV7TlwdojT1M4A==
10-Oct-2022 15:41:54.516 del re-sign mail.manykeys. 300 IN RRSIG A 13 2 300 20221017201301 20221010124121 15554 manykeys. JIg+WRo5qf7a4A0J7bJ7Ug4BZIbUkDzG38ohjfNlG2JuDTYGlr92/gU+ uThPRYFN65ki7nChpV7TlwdojT1M4A==
```
Seems to me like something made `zone_resigninc()` believe that
signatures generated 10 seconds earlier are outdated and need to be
refreshed.Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/265dhcp server function doesn't work after interface status changes from DOWN to UP2022-10-10T07:17:51Zpoe luodhcp server function doesn't work after interface status changes from DOWN to UPafter configured /etc/default/isc-dhcp-server and /etc/dhcp/dhcpd.conf, i started isc-dhcp-server via systemctl restart isc-dhcp-server (interface is DOWN currently).
checking process status with systemctl status isc-dhcp-server, it sho...after configured /etc/default/isc-dhcp-server and /etc/dhcp/dhcpd.conf, i started isc-dhcp-server via systemctl restart isc-dhcp-server (interface is DOWN currently).
checking process status with systemctl status isc-dhcp-server, it showed like below:
No subnet declaration for eno6 (no IPv4 addresses).
** Ignoring requests on eno6. If this is not what
you want, please write a subnet declaration
in your dhcpd.conf file for the network segment
to which interface eno6 is attached. **
then i plugged in a cable into eno6, it turned to UP status, but dhcp server function seems not working, because the client didn't get any ip address.
however, if i plugged in a cable first, then start isc-dhcp-server, it worked well if i unplugged the cable and re-plugged back.
what i want to know is that can isc-dhcp-server auto detect the listed interfaces status, when interfaces turn to UP status, it will always assign ip address to client successfully without restarting process manually.
my env is Ubuntu 18.04.
thanks.https://gitlab.isc.org/isc-projects/bind9/-/issues/3590[question] strange dig with IDN2022-11-25T17:03:10ZAndrey Blokhintsev[question] strange dig with IDN<!--
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
dig output to terminal is different from output to file/pipe for idn queries
### BIND version used
(Paste the output of `named -V`.)
BIND 9.18.7 (Stable Release) <id:85a6eb1>
running on Darwin x86_64 21.6.0 Darwin Kernel Version 21.6.0: Mon Aug 22 20:17:10 PDT 2022; root:xnu-8020.140.49~2/RELEASE_X86_64
built by make with '--prefix=/opt/local' '--disable-silent-rules' '--mandir=/opt/local/share/man' '--with-openssl=/opt/local' '--with-libidn2=/opt/local' '--enable-doh' 'CC=/usr/bin/clang' 'CFLAGS=-pipe -Os -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -arch x86_64' 'LDFLAGS=-L/opt/local/lib -Wl,-headerpad_max_install_names -Wl,-syslibroot,/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -arch x86_64' 'CPPFLAGS=-I/opt/local/include -isysroot/Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk'
compiled by CLANG Apple LLVM 14.0.0 (clang-1400.0.29.102)
compiled with OpenSSL version: OpenSSL 3.0.5 5 Jul 2022
linked to OpenSSL version: OpenSSL 3.0.5 5 Jul 2022
compiled with libuv version: 1.44.2
linked to libuv version: 1.44.2
compiled with libnghttp2 version: 1.50.0
linked to libnghttp2 version: 1.50.0
compiled with libxml2 version: 2.10.2
linked to libxml2 version: 21002
compiled with json-c version: 0.16
linked to json-c version: 0.16
compiled with zlib version: 1.2.12
linked to zlib version: 1.2.12
threads support is enabled
default paths:
named configuration: /opt/local/etc/named.conf
rndc configuration: /opt/local/etc/rndc.conf
DNSSEC root key: /opt/local/etc/bind.keys
nsupdate session key: /opt/local/var/run/named/session.key
named PID file: /opt/local/var/run/named/named.pid
named lock file: /opt/local/var/run/named/named.lock
dig -v
DiG 9.18.7
### Steps to reproduce
export LANG=uk_UA.UTF-8
export LANGUAGE=uk_UA.UTF-8
echo укр. > /tmp/f
dig ns -f /tmp/f
dig ns -f /tmp/f | cat
Queried domain from file to be sure that shell don't damage args
Checked at FreeBSD 13.1, macOS 12.6, Ubuntu 22.04, Debian 11.5
(How one can reproduce the issue - this is very important.)
### What is the current *bug* behavior?
different queries to resolver
tcpdump from "dig ns -f /tmp/f":
14:37:03.156768 IP 10.11.14.5.53545 > 10.11.12.1.53: 63892+ [1au] NS? xn--j1amh. (50)
14:37:03.158987 IP 10.11.12.1.53 > 10.11.14.5.53545: 63892 6/0/1 NS dns2.u-registry.net., NS ukr.ns.ua., NS tier1.num.net.ua., NS dns.tci.net.ua., NS dns1.u-registry.com., NS dns3.dotukr.com. (242)
tcpdumo from "dig ns -f /tmp/f | cat"
14:37:09.436218 IP 10.11.14.5.56868 > 10.11.12.1.53: 49469+ [1au] NS? M-QM-^CM-PM-:M-QM-^@. (47)
14:37:09.445445 IP 10.11.12.1.53 > 10.11.14.5.56868: 49469 NXDomain* 0/1/1 (138)
Queried domain from file to be sure that shell don't damage args
Checked at FreeBSD 13.1, macOS 12.6, Ubuntu 22.04, Debian 11.5
(What actually happens.)
### What is the expected *correct* behavior?
Expected the same output from "dig ns укр." and from "dig ns укр. | cat"
(What you should see instead.)
### 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
(Paste any relevant logs - please use code blocks (```) to format console
output, logs, and code, as it's very hard to read otherwise.)
### Possible fixes
(If you can, link to the line of code that might be responsible for the
problem.)https://gitlab.isc.org/isc-projects/stork/-/issues/873System tests for top-level server functionalities2022-10-25T13:58:00ZSlawek FigielSystem tests for top-level server functionalitiesDue to technical details, we cannot actually write unit tests for top-level Stork Server functionalities as:
* Interpreting CLI commands
* Running server
* Remembering DB password for reload
* Handling reloading
* Handling shutdown
We ...Due to technical details, we cannot actually write unit tests for top-level Stork Server functionalities as:
* Interpreting CLI commands
* Running server
* Remembering DB password for reload
* Handling reloading
* Handling shutdown
We should split the main server function according to the Single Responsibility Principle to make it testable.
After that, we should cover the individual features with unit tests.backloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3581Build state bind9 - 1:9.18.7-1+ubuntu18.04.1+isc+12022-10-20T22:34:17ZIvo FrassBuild state bind9 - 1:9.18.7-1+ubuntu18.04.1+isc+1As to be seen on the page https://launchpad.net/~isc/+archive/ubuntu/bind/+packages the build state of the package **bind9 - 1:9.18.7-1+ubuntu18.04.1+isc+1** is still **failed** since 2022-09-21.
Is there a schedule when the package will...As to be seen on the page https://launchpad.net/~isc/+archive/ubuntu/bind/+packages the build state of the package **bind9 - 1:9.18.7-1+ubuntu18.04.1+isc+1** is still **failed** since 2022-09-21.
Is there a schedule when the package will be built and ready for usage?
Thanks in advanceOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/stork/-/issues/872Improve the look of the Stork login form2023-08-10T12:48:24ZMarcin SiodelskiImprove the look of the Stork login formThe user name and password inputs seems small comparing to the size of the page. I suggest we increase their size, so the login page doesn't look empty. It is a minor issue though.The user name and password inputs seems small comparing to the size of the page. I suggest we increase their size, so the login page doesn't look empty. It is a minor issue though.backlogMarcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/871Unsupported stat info messages should be a lower log level2023-03-07T13:44:37Zvps-ericUnsupported stat info messages should be a lower log levelThese log statements are, in my opinion, not relevant enough to warrant being INFO level:
```
INFO[2022-09-26 21:45:51] promkeaexporter.go:683 Encountered unsupported stat: v4-allocation-fail-no-pools
INFO[2022-09-26 21:45:51] prom...These log statements are, in my opinion, not relevant enough to warrant being INFO level:
```
INFO[2022-09-26 21:45:51] promkeaexporter.go:683 Encountered unsupported stat: v4-allocation-fail-no-pools
INFO[2022-09-26 21:45:51] promkeaexporter.go:683 Encountered unsupported stat: v4-allocation-fail-subnet
INFO[2022-09-26 21:45:51] promkeaexporter.go:680 Encountered unsupported stat: v4-reservation-conflicts
INFO[2022-09-26 21:45:51] promkeaexporter.go:683 Encountered unsupported stat: declined-addresses
INFO[2022-09-26 21:45:51] promkeaexporter.go:683 Encountered unsupported stat: reclaimed-leases
INFO[2022-09-26 21:45:51] promkeaexporter.go:683 Encountered unsupported stat: reclaimed-declined-addresses
INFO[2022-09-26 21:45:51] promkeaexporter.go:683 Encountered unsupported stat: v4-allocation-fail
INFO[2022-09-26 21:45:51] promkeaexporter.go:683 Encountered unsupported stat: v4-reservation-conflicts
INFO[2022-09-26 21:45:51] promkeaexporter.go:683 Encountered unsupported stat: v4-allocation-fail-shared-network
INFO[2022-09-26 21:45:51] promkeaexporter.go:683 Encountered unsupported stat: v4-allocation-fail-classes
INFO[2022-09-26 21:45:51] promkeaexporter.go:683 Encountered unsupported stat: cumulative-assigned-addresses
INFO[2022-09-26 21:45:51] promkeaexporter.go:680 Encountered unsupported stat: v4-reservation-conflicts
...
```
I propose that they be moved to DEBUG log level. Adding support for an unsupported stat is not something expected of a normal system administrator.
See #839.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/869Avoid removing Stork user on update2022-10-12T10:42:30ZSlawek FigielAvoid removing Stork user on updateThe issue was reported on the mailing list by Bertrand Buclin on 2022-09-21.
> Another annoying thing with the current installation scripts is that it removes the stork-agent (and stork-server for the server) username at every upgrade. ...The issue was reported on the mailing list by Bertrand Buclin on 2022-09-21.
> Another annoying thing with the current installation scripts is that it removes the stork-agent (and stork-server for the server) username at every upgrade. For the agent, the post installation scripts has logic to add the re-created stork-agent user to the bind group so that I can access the Bind files, but it does not do the same for the _kea group, and one has to always add the stork-agent user manually after the upgrade. Delete and adding also has the undesired side effect that the UID and GID may change at each release.
>
> Would it be possible:
> 1) not to delete the stork-agent (or stork-server) user if this is an upgrade: it is already in place, so no need to change things, nor cause a change in UID and GID
> 2) enhance the install script to also add stork-agent to the _kea group (after testing of course that Kea is also installed on the system)1.7https://gitlab.isc.org/isc-projects/stork/-/issues/868Improve HA pair state presentation when both machines are down2022-10-04T13:49:37ZMarcin SiodelskiImprove HA pair state presentation when both machines are downWhen two HA machines are down, Stork is unable to fetch information about their states. In that case, Stork presents the last known state. For example:
![Zrzut_ekranu_2022-09-29_o_17.06.54](/uploads/f6c59f7c714c03232129df5193eb1501/Zrzu...When two HA machines are down, Stork is unable to fetch information about their states. In that case, Stork presents the last known state. For example:
![Zrzut_ekranu_2022-09-29_o_17.06.54](/uploads/f6c59f7c714c03232129df5193eb1501/Zrzut_ekranu_2022-09-29_o_17.06.54.png)
It is a little misleading. The only sign that the information is outdated is the `Status checked` far in the past. However, it would be better to show that the communication is broken, possibly meaning that both machines are down.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2582ISC DHCP sub classes2022-10-18T12:11:49ZFrancis DupontISC DHCP sub classesISC DHCP support sub classes:
```
In addition to classes, it is possible to declare subclasses. A subclass
is a class with the same name as a regular class, but with a specific
submatch expression which is hashed fo...ISC DHCP support sub classes:
```
In addition to classes, it is possible to declare subclasses. A subclass
is a class with the same name as a regular class, but with a specific
submatch expression which is hashed for quick matching. This is
essentially a speed hack - the main difference between five classes with
match expressions and one class with five subclasses is that it will be
quicker to find the subclasses. Subclasses work as follows:
class "allocation-class-1" {
match pick-first-value (option dhcp-client-identifier, hardware);
}
class "allocation-class-2" {
match pick-first-value (option dhcp-client-identifier, hardware);
}
subclass "allocation-class-1" 1:8:0:2b:4c:39:ad;
subclass "allocation-class-2" 1:8:0:2b:a9:cc:e3;
subclass "allocation-class-1" 1:0:0:c4:aa:29:44;
subnet 10.0.0.0 netmask 255.255.255.0 {
pool {
allow members of "allocation-class-1";
range 10.0.0.11 10.0.0.50;
}
pool {
allow members of "allocation-class-2";
range 10.0.0.51 10.0.0.100;
}
}
The data following the class name in the subclass declaration is a
constant value to use in matching the match expression for the class.
When class matching is done, the server will evaluate the match
expression and then look the result up in the hash table. If it finds a
match, the client is considered a member of both the class and the
subclass.
Subclasses can be declared with or without scope. In the above example,
the sole purpose of the subclass is to allow some clients access to one
address pool, while other clients are given access to the other pool, so
these subclasses are declared without scopes. If part of the purpose of
the subclass were to define different parameter values for some clients,
you might want to declare some subclasses with scopes.
In the above example, if you had a single client that needed some
configuration parameters, while most didn't, you might write the
following subclass declaration for that client:
subclass "allocation-class-2" 1:08:00:2b:a1:11:31 {
option root-path "samsara:/var/diskless/alphapc";
filename "/tftpboot/netbsd.alphapc-diskless";
}
In this example, we've used subclassing as a way to control address
allocation on a per-client basis. However, it's also possible to use
subclassing in ways that are not specific to clients - for example, to
use the value of the vendor-class-identifier option to determine what
values to send in the vendor-encapsulated-options option. An example of
this is shown under the VENDOR ENCAPSULATED OPTIONS head in the
dhcp-options(5) manual page.
```
Sub-classes are essentially an improvement in both the evaluation process (match expression is evaluated once and its value is compared with a hash table) and configuration (less things to repeat and exposed relationship). The same idea can be used in Kea: currently Keama just recombines match expression and value in regular classes, losing the fact the parent depends on a matching sub class...ISC DHCP Migrationhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3568[question] Bind 9.16.28 upgrade: high memory utilization and OOM2022-11-25T17:03:51ZShailendra Gautam[question] Bind 9.16.28 upgrade: high memory utilization and OOMWe had recently upgraded our bind nameservers from 9.14.10 to 9.16.28. This led to the hosts gradually using up a lot of memory and eventually named was OOM killed as it consumed nearly 7GB out of total 8GB server memory. (This package w...We had recently upgraded our bind nameservers from 9.14.10 to 9.16.28. This led to the hosts gradually using up a lot of memory and eventually named was OOM killed as it consumed nearly 7GB out of total 8GB server memory. (This package was built from source for centos 7)
I’ve been looking into this and tested the performance of both 9.14 and 9.16 under the traffic of 600 queries per sec for 12 hours, which is the average qps our servers get. It was found that while 9.14 had a surge of around 2GB, 9.16 had a surge of 5.2GB during this time. I wanted to know whether this difference in memory consumption is expected while migrating from 9.14.10 to 9.16.28, or if this could be a memory leak that would keep building over time; it would really help if I can get some insights on what might be causing this, or if there’s any way to avoid this other than bumping up the RAM.
I’d be glad to provide more info if needed. Would really appreciate your inputs and suggestions on this.
Its running on 3.10.0-957.10.1.el7.x86_64, named is running as a systemd service, I'll attach configuration data and stats soon, compile time options below:
```
# named -V
BIND 9.16.28 (Extended Support Version) <id:7aea13f>
running on Linux x86_64 3.10.0-957.10.1.el7.x86_64 #1 SMP Mon Mar 18 15:06:45 UTC 2019
built by make with '--build=x86_64-redhat-linux-gnu' '--host=x86_64-redhat-linux-gnu' '--program-prefix=' '--disable-dependency-tracking' '--prefix=/usr' '--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin' '--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include' '--libdir=/usr/lib64' '--libexecdir=/usr/libexec' '--sharedstatedir=/var/lib' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--with-python=/usr/bin/python2' '--with-libtool' '--localstatedir=/var' '--with-pic' '--disable-static' '--includedir=/usr/include/bind9' '--with-tuning=large' '--with-libidn2' '--disable-lock-free-queue' '--with-maxminddb' '--with-dlopen=yes' '--with-gssapi=yes' '--with-lmdb=yes' '--without-libjson' '--with-json-c' '--enable-dnstap' '--enable-fixed-rrset' '--enable-full-report' 'build_alias=x86_64-redhat-linux-gnu' 'host_alias=x86_64-redhat-linux-gnu' 'CFLAGS= -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic' 'LDFLAGS=-Wl,-z,relro ' 'PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-44)
compiled with OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2p.6.2.312-fips
compiled with libuv version: 1.44.1
linked to libuv version: 1.44.1
compiled with libxml2 version: 2.9.1
linked to libxml2 version: 20901
compiled with json-c version: 0.11
linked to json-c version: 0.11
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
linked to maxminddb version: 1.2.0
compiled with protobuf-c version: 1.0.2
linked to protobuf-c version: 1.0.2
threads support is enabled
default paths:
named configuration: /etc/named.conf
rndc configuration: /etc/rndc.conf
DNSSEC root key: /etc/bind.keys
nsupdate session key: /var/run/named/session.key
named PID file: /var/run/named/named.pid
named lock file: /var/run/named/named.lock
geoip-directory: /usr/share/GeoIP
```