ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2022-03-01T09:43:31Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3027Move setting of @SO@ to copy_setports2022-03-01T09:43:31ZMark AndrewsMove setting of @SO@ to copy_setportsSetting @SO@ in conf files is currently done by configure. copy_setports should be capable of doing this.Setting @SO@ in conf files is currently done by configure. copy_setports should be capable of doing this.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3015QNAME minimization test fails as non-minimized request is served from cache2022-03-01T09:38:59ZWil KnollQNAME minimization test fails as non-minimized request is served from cache### Summary
When using default configuration for BIND the QNAME minimization test hosted at internet.nl would fail randomly after four or more iterations. It appears that the fourth request in a row is served the proper minimized reques...### Summary
When using default configuration for BIND the QNAME minimization test hosted at internet.nl would fail randomly after four or more iterations. It appears that the fourth request in a row is served the proper minimized request cached previously, but triggers a fetch at the same time which is not minimized. The response to that request is then served to the following fifth request and beyond.
```
17-Nov-2021 06:17:13.568 client @0x7fef808ae838 127.0.0.1#35491 (qnamemintest.internet.nl): query: qnamemintest.internet.nl IN TXT + (127.0.0.1)
17-Nov-2021 06:17:13.568 client @0x7fef808ae838 127.0.0.1#35491 (qnamemintest.internet.nl): query (cache) 'qnamemintest.internet.nl/TXT/IN' approved
17-Nov-2021 06:17:13.568 fetch: a.b.qnamemin-test.internet.nl/TXT
17-Nov-2021 06:17:13.568 log_ns_ttl: fctx 0x7fef80044e60: fctx_create: a.b.qnamemin-test.internet.nl (in 'internet.nl'?): 1 3587
17-Nov-2021 06:17:13.568 QNAME minimization - not minimized, qmintype 16 qminname a.b.qnamemin-test.internet.nl
```
### BIND version used
BIND 9.16.22-Ubuntu (Extended Support Version) <id:59bfaba>
### Steps to reproduce
We ran the following bash commands and this behaviour would occur sometimes after four of five iterations, other times after a dozen or more. We echo'ed the `date` command into the log as well to line up events.
```
for i in {1..30};
do date +"%T.%6N";
echo "Test Number " $i;
echo "========== Before test" $i >> /var/log/named/default.log;
kdig +nodnssec +short @127.0.0.1 qnamemintest.internet.nl TXT;
date +"%T.%6N";
echo "======== done test" $i >> /var/log/named/default.log;
echo "Test Number " $i "done, sleeping.";
sleep 3;
done
```
### What is the current *bug* behavior?
Here the test fails on the fifth iteration
```
06:16:57.072993
Test Number 1
;; WARNING: response timeout for 127.0.0.1@53(UDP)
a.b.qnamemin-test.internet.nl.
"HOORAY - QNAME minimisation is enabled on your resolver :)!"
06:17:04.540956
Test Number 1 done, sleeping.
06:17:07.545660
Test Number 2
a.b.qnamemin-test.internet.nl.
"HOORAY - QNAME minimisation is enabled on your resolver :)!"
06:17:07.551628
Test Number 2 done, sleeping.
06:17:10.556281
Test Number 3
a.b.qnamemin-test.internet.nl.
"HOORAY - QNAME minimisation is enabled on your resolver :)!"
06:17:10.562749
Test Number 3 done, sleeping.
06:17:13.567638
Test Number 4
a.b.qnamemin-test.internet.nl.
"HOORAY - QNAME minimisation is enabled on your resolver :)!"
06:17:13.574423
Test Number 4 done, sleeping.
06:17:16.578864
Test Number 5
a.b.qnamemin-test.internet.nl.
"NO - QNAME minimisation is NOT enabled on your resolver :("
06:17:16.584539
Test Number 5 done, sleeping.
06:17:19.588370
Test Number 6
a.b.qnamemin-test.internet.nl.
"NO - QNAME minimisation is NOT enabled on your resolver :("
06:17:19.594741
Test Number 6 done, sleeping.
```
Part of the internet.nl test is to serve a different TXT record based on the delegation path for their records. If you do not follow QNAME minimization to spec, you will miss a delegation and be served a different record than if you had walked the whole way down from the top. In this case, we are served the failure message.
In the debug below, we see that the fourth test is served from cache while a new fetch of the TXT is started and not minimized. That response arrives after the fourth request has been served and before the fifth. The fifth is then sent the non-minimized response.
```
========== Before test 4
17-Nov-2021 06:17:13.568 clientmgr @0x7fef8ee53190 attach: 4
17-Nov-2021 06:17:13.568 client @0x7fef808ae838 (no-peer): allocate new client
17-Nov-2021 06:17:13.568 client @0x7fef808ae838 127.0.0.1#35491: UDP request
17-Nov-2021 06:17:13.568 client @0x7fef808ae838 127.0.0.1#35491: using view '_default'
17-Nov-2021 06:17:13.568 client @0x7fef808ae838 127.0.0.1#35491: request is not signed
17-Nov-2021 06:17:13.568 client @0x7fef808ae838 127.0.0.1#35491: recursion available
17-Nov-2021 06:17:13.568 client @0x7fef808ae838 127.0.0.1#35491 (qnamemintest.internet.nl): query: qnamemintest.internet.nl IN TXT + (127.0.0.1)
17-Nov-2021 06:17:13.568 client @0x7fef808ae838 127.0.0.1#35491 (qnamemintest.internet.nl): query (cache) 'qnamemintest.internet.nl/TXT/IN' approved
17-Nov-2021 06:17:13.568 fetch: a.b.qnamemin-test.internet.nl/TXT
17-Nov-2021 06:17:13.568 log_ns_ttl: fctx 0x7fef80044e60: fctx_create: a.b.qnamemin-test.internet.nl (in 'internet.nl'?): 1 3587
17-Nov-2021 06:17:13.568 QNAME minimization - not minimized, qmintype 16 qminname a.b.qnamemin-test.internet.nl
17-Nov-2021 06:17:13.568 expiring v4 for name 0x7fef8432c600
17-Nov-2021 06:17:13.568 expire_v4 set to MIN(2147483647,1637129843) import_rdataset
17-Nov-2021 06:17:13.568 dns_adb_createfind: found A for name ns1.sidnlabs.nl (0x7fef8432c600) in db
17-Nov-2021 06:17:13.568 fctx 0x7fef80044e60(a.b.qnamemin-test.internet.nl/TXT): createfind for 127.0.0.1#35491/54667 - success
17-Nov-2021 06:17:13.568 expiring v4 for name 0x7fef8432c4d0
17-Nov-2021 06:17:13.568 expire_v4 set to MIN(2147483647,1637129843) import_rdataset
17-Nov-2021 06:17:13.568 dns_adb_createfind: found A for name ns3.sidn.nl (0x7fef8432c4d0) in db
17-Nov-2021 06:17:13.568 fctx 0x7fef80044e60(a.b.qnamemin-test.internet.nl/TXT): createfind for 127.0.0.1#35491/54667 - success
17-Nov-2021 06:17:13.568 socket 0x7fef8419c178: socket_recv: event 0x7fef8419f160 -> task 0x7fef84914550
17-Nov-2021 06:17:13.568 sending packet to 94.198.159.8#53
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15820
;; flags:; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 6e57d9bce860fbf50100000061949e5c594abc51bbb6293a
;; QUESTION SECTION:
;a.b.qnamemin-test.internet.nl. IN TXT
======== done test 4
17-Nov-2021 06:17:13.844 socket 0x7fef8419c178: socket_recv: event 0x7fef8419f010 -> task 0x7fef84914550
17-Nov-2021 06:17:13.844 received packet from 94.198.159.8#53
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15820
;; flags: qr; QUESTION: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 6e57d9bce860fbf50100000061949e69a15a47ca6fecf4ce
;; QUESTION SECTION:
;a.b.qnamemin-test.internet.nl. IN TXT
;; AUTHORITY SECTION:
;qnamemin-test.internet.nl. 10 IN NS ns.qnamemin-test.internet.nl.
;37EVSMIUKP9K7OAANU0THSBL3AFJAJJI.internet.nl. 300 IN NSEC3 1 0 0 - (
; 3UK0OFP95GPMB6AJ2O611UGNO7EJ4O6U
; NS )
;37EVSMIUKP9K7OAANU0THSBL3AFJAJJI.internet.nl. 300 IN RRSIG NSEC3 13 3 300 (
; 20211212072148 20211112065813 16313 internet.nl.
; E/vfuxroRZjeupIxjp+s3aQpKPb0
; fYR3UjTMs3yoHhF66kz/wvPyuwvY
; 9vlHJ1UmifUBfmyAtZj560mQ0loV
; MQ== )
;; ADDITIONAL SECTION:
;ns.qnamemin-test.internet.nl. 10 IN A 185.49.140.61
;ns.qnamemin-test.internet.nl. 10 IN AAAA 2a04:b900::8:0:0:61
17-Nov-2021 06:17:13.844 log_ns_ttl: fctx 0x7fef80044e60: rctx_answer_none: a.b.qnamemin-test.internet.nl (in 'internet.nl'?): 1 3587
17-Nov-2021 06:17:13.844 QNAME minimization - not minimized, qmintype 16 qminname a.b.qnamemin-test.internet.nl
17-Nov-2021 06:17:13.844 log_ns_ttl: fctx 0x7fef80044e60: DELEGATION: a.b.qnamemin-test.internet.nl (in 'qnamemin-test.internet.nl'?): 0 3587
17-Nov-2021 06:17:13.844 dns_adb_destroyfind on find 0x7fef84329d10
17-Nov-2021 06:17:13.844 dns_adb_destroyfind on find 0x7fef84327e10
17-Nov-2021 06:17:13.844 expiring v4 for name 0x7fef8432c3a0
17-Nov-2021 06:17:13.844 expire_v4 set to MIN(2147483647,1637129843) import_rdataset
17-Nov-2021 06:17:13.844 dns_adb_createfind: found A for name ns.qnamemin-test.internet.nl (0x7fef8432c3a0) in db
17-Nov-2021 06:17:13.844 fctx 0x7fef80044e60(a.b.qnamemin-test.internet.nl/TXT): createfind for 127.0.0.1#35491/54667 - success
17-Nov-2021 06:17:13.844 socket 0x7fef8419c010: socket_recv: event 0x7fef841a0550 -> task 0x7fef849186d0
17-Nov-2021 06:17:13.844 sending packet to 185.49.140.61#53
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7077
;; flags:; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: e77abc1b4903389a
;; QUESTION SECTION:
;a.b.qnamemin-test.internet.nl. IN TXT
17-Nov-2021 06:17:14.236 socket 0x7fef8419c010: socket_recv: event 0x7fef841a0400 -> task 0x7fef849186d0
17-Nov-2021 06:17:14.236 received packet from 185.49.140.61#53
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7077
;; flags: qr aa; QUESTION: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 3
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;a.b.qnamemin-test.internet.nl. IN TXT
;; ANSWER SECTION:
;a.b.qnamemin-test.internet.nl. 10 IN TXT "NO - QNAME minimisation is NOT enabled on your resolver :("
;; AUTHORITY SECTION:
;a.b.qnamemin-test.internet.nl. 10 IN NS ns.a.b.qnamemin-test.internet.nl.
;; ADDITIONAL SECTION:
;ns.a.b.qnamemin-test.internet.nl. 10 IN A 185.49.140.61
;ns.a.b.qnamemin-test.internet.nl. 10 IN AAAA 2a04:b900::8:0:0:61
17-Nov-2021 06:17:14.236 log_ns_ttl: fctx 0x7fef80044e60: rctx_answer: a.b.qnamemin-test.internet.nl (in 'qnamemin-test.internet.nl'?): 1 10
17-Nov-2021 06:17:14.236 validating a.b.qnamemin-test.internet.nl/TXT: starting
17-Nov-2021 06:17:14.236 validating a.b.qnamemin-test.internet.nl/TXT: attempting insecurity proof
17-Nov-2021 06:17:14.236 validating a.b.qnamemin-test.internet.nl/TXT: checking existence of DS at 'nl'
17-Nov-2021 06:17:14.236 validating a.b.qnamemin-test.internet.nl/TXT: checking existence of DS at 'internet.nl'
17-Nov-2021 06:17:14.236 validating a.b.qnamemin-test.internet.nl/TXT: checking existence of DS at 'qnamemin-test.internet.nl'
17-Nov-2021 06:17:14.236 validating a.b.qnamemin-test.internet.nl/TXT: marking as answer (proveunsecure (4))
17-Nov-2021 06:17:14.236 validator @0x7fef80047440: dns_validator_destroy
17-Nov-2021 06:17:14.236 delete_node(): 0x7fef8482b940 ns.a.b.qnamemin-test.internet.nl (bucket 13)
17-Nov-2021 06:17:14.236 client @0x7fef808ae838 127.0.0.1#35491 (qnamemintest.internet.nl): reset client
17-Nov-2021 06:17:14.236 dns_adb_destroyfind on find 0x7fef84327e10
========== Before test 5
17-Nov-2021 06:17:16.580 client @0x7fef78053e18 127.0.0.1#45992: UDP request
17-Nov-2021 06:17:16.580 client @0x7fef78053e18 127.0.0.1#45992: using view '_default'
17-Nov-2021 06:17:16.580 client @0x7fef78053e18 127.0.0.1#45992: request is not signed
17-Nov-2021 06:17:16.580 client @0x7fef78053e18 127.0.0.1#45992: recursion available
17-Nov-2021 06:17:16.580 client @0x7fef78053e18 127.0.0.1#45992 (qnamemintest.internet.nl): query: qnamemintest.internet.nl IN TXT + (127.0.0.1)
17-Nov-2021 06:17:16.580 client @0x7fef78053e18 127.0.0.1#45992 (qnamemintest.internet.nl): query (cache) 'qnamemintest.internet.nl/TXT/IN' approved
17-Nov-2021 06:17:16.580 client @0x7fef78053e18 127.0.0.1#45992 (qnamemintest.internet.nl): reset client
======== done test 5
```
### What is the expected *correct* behavior?
We believe that served from cache or not, all requests should be minimized and this test should pass every time.
### Relevant logs and/or screenshots
We have `qname-minimization strict;` set in `named.conf.options`.
Beyond that and some logging changes, we are using the default configuration.
### Possible fixes
Wish I was that skilled to help out. I have previously opened https://gitlab.isc.org/isc-projects/bind9/-/issues/2665 which was similar, so some of the work there might be relevant.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3011rndc addzone accepts secondary zone without primaries2023-11-02T16:26:08ZJP Mensrndc addzone accepts secondary zone without primaries`rndc addzone` accepts addition of secondary zone to a running server without me specifying primaries, even though such a configuration is not permitted in `named.conf`. Is this an error or does it cater for a use-case I'm not familiar w...`rndc addzone` accepts addition of secondary zone to a running server without me specifying primaries, even though such a configuration is not permitted in `named.conf`. Is this an error or does it cater for a use-case I'm not familiar with?
`BIND 9.17.19 (Development Release) <id:e8d1dd3>`
#### named.conf
```
key "rndc-key" {
algorithm hmac-sha256;
secret "4tFLJTPa4EXIY0bkrIzJOj1WNp1KSvYI4HJE+n2vrbo=";
};
options {
directory "/tmp/named";
allow-query { any; };
listen-on { 127.0.0.2; };
listen-on-v6 { none; };
allow-new-zones yes;
recursion no;
};
controls {
inet 127.0.0.1 port 953
allow { 127.0.0.1; } keys { "rndc-key"; };
};
```
#### named -g
```
# named -g
11-Nov-2021 09:41:36.716 starting BIND 9.17.19 (Development Release) <id:e8d1dd3>
11-Nov-2021 09:41:36.716 running on Darwin x86_64 19.6.0 Darwin Kernel Version 19.6.0: Thu Sep 16 20:58:47 PDT 2021; root:xnu-6153.141.40.1~1/RELEASE_X86_64
11-Nov-2021 09:41:36.716 built with '--prefix=/usr/local/bind9git' '--with-libxml2' '--with-json-c' '--with-openssl=/usr/local/Cellar/openssl@1.1/1.1.1l_1/' 'LDFLAGS=-L/usr/local/Cellar/openssl@1.1/1.1.1l_1//lib/' 'CPPFLAGS=-I/usr/local/Cellar/openssl@1.1/1.1.1l_1//include/' 'PYTHON=/usr/local/bin/python3.9'
11-Nov-2021 09:41:36.716 running as: named -g -c /usr/local/etc/named-addzones.conf
11-Nov-2021 09:41:36.716 compiled by CLANG Apple LLVM 12.0.0 (clang-1200.0.32.29)
11-Nov-2021 09:41:36.716 compiled with OpenSSL version: OpenSSL 1.1.1l 24 Aug 2021
11-Nov-2021 09:41:36.716 linked to OpenSSL version: OpenSSL 1.1.1l 24 Aug 2021
11-Nov-2021 09:41:36.716 compiled with libxml2 version: 2.9.4
11-Nov-2021 09:41:36.716 linked to libxml2 version: 20904
11-Nov-2021 09:41:36.716 compiled with json-c version: 0.15
11-Nov-2021 09:41:36.716 linked to json-c version: 0.15
11-Nov-2021 09:41:36.716 compiled with zlib version: 1.2.11
11-Nov-2021 09:41:36.716 linked to zlib version: 1.2.11
...
11-Nov-2021 09:41:44.997 received control channel command 'addzone example.com { type secondary; file "example.com"; };'
11-Nov-2021 09:41:44.997 zone example.com/IN: cannot refresh: no primaries
11-Nov-2021 09:41:44.998 added zone example.com in view _default via addzone
```
#### rndc addzone
```console
$ rndc -k rndc.key addzone example.com '{ type secondary; file "example.com"; };'
```
#### nzf file
```console
# named-nzd2nzf /tmp/named/_default.nzd
zone "example.com" { type secondary; file "example.com"; };
```
If I try to load a `named.conf` with a statically configured secondary without primaries
```
zone "example.net" IN {
type secondary;
file "example.net";
};
```
I get an error:
```
named-addzones.conf:22: zone 'example.net': missing 'primaries' entry
```Not plannedhttps://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/2996Migrate PKCS11 from "engine" to "provider"2022-12-26T19:20:52ZMark AndrewsMigrate PKCS11 from "engine" to "provider"OpenSSL 3.0.0 has deprecated the `engine` api in favour of the `provider` api. We currently use the `engine` api and OpenSC for pkcs11 access to HSMs. We need to move to using the `provider` api as soon as possible.
OpenSC has an open...OpenSSL 3.0.0 has deprecated the `engine` api in favour of the `provider` api. We currently use the `engine` api and OpenSC for pkcs11 access to HSMs. We need to move to using the `provider` api as soon as possible.
OpenSC has an open ticket for OpenSSL 3.0.0 https://github.com/OpenSC/OpenSC/issues/2308Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2995about PKCS11 document2022-03-01T09:43:12Zperlangabout PKCS11 documentFrom release note of 9.16.22, there is following line,
The use of native PKCS#11 for Public-Key Cryptography in BIND 9 has been deprecated in favor of the engine_pkcs11 OpenSSL engine from the OpenSC project.
but in section 5.11.2 Nati...From release note of 9.16.22, there is following line,
The use of native PKCS#11 for Public-Key Cryptography in BIND 9 has been deprecated in favor of the engine_pkcs11 OpenSSL engine from the OpenSC project.
but in section 5.11.2 Native PKCS#11 of Bv9ARM(9.16.22), there is one opposite meaning line,
(Note: Eventually, when more HSMs become capable of supporting native PKCS#11, it is expected that OpenSSL-based PKCS#11 will be deprecated.)
I guess the latter(5.11.2) should be outdated. But not too sure.Not plannedhttps://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/stork/-/issues/597CI: solve TODO about automating changelog update in release notes2022-10-05T14:46:17ZAndrei Pavelandrei@isc.orgCI: solve TODO about automating changelog update in release notes```
# TODO:
# - automate pasting ChangeLog.md to release notes
``````
# TODO:
# - automate pasting ChangeLog.md to release notes
```outstandinghttps://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/stork/-/issues/587IPv6 support in Stork system test framework2023-07-27T12:26:19ZSlawek FigielIPv6 support in Stork system test frameworkThe system tests framework incorrectly handles IPv6 addresses. It causes a system test building to fail on some configurations.
We need to rewrite our scripts to support this IP schema.
We noticed also that some system tests were execut...The system tests framework incorrectly handles IPv6 addresses. It causes a system test building to fail on some configurations.
We need to rewrite our scripts to support this IP schema.
We noticed also that some system tests were executed, but produce incorrect results when IPv6 was used. We need to prepare some unit and system tests to cover IPv6-based configurations.
```
distro_agent = 'ubuntu/18.04', distro_server = 'centos/8'
@pytest.mark.parametrize("distro_agent, distro_server", SUPPORTED_DISTROS)
def test_pkg_upgrade_server_token(distro_agent, distro_server):
"""Check if Stork agent and server can be upgraded from latest release
to localy built packages."""
server = containers.StorkServerContainer(alias=distro_server)
agent = containers.StorkAgentContainer(alias=distro_agent)
# install the latest version of stork from cloudsmith
server.setup_bg('cloudsmith')
while server.mgmt_ip is None:
time.sleep(0.1)
agent.setup_bg('cloudsmith', server.mgmt_ip)
server.setup_wait()
agent.setup_wait()
# login
r = server.api_post('/sessions', json=dict(useremail='admin', userpassword='admin'), expected_status=200) # TODO: POST should return 201
assert r.json()['login'] == 'admin'
# install local packages
banner('UPGRADING STORK SERVER')
server.prepare_stork_server()
# get server token from server
for i in range(100):
try:
r = server.api_get('/machines-server-token')
break
except:
if i == 99:
raise
time.sleep(1)
data = r.json()
server_token = data['token']
# install kea on the agent machine
agent.install_kea()
# install local packages using server token based way
banner('UPGRADING STORK AGENT')
server_url = 'http://%s:8080' % server.mgmt_ip
> agent.run('curl -o stork-install-agent.sh %s/stork-install-agent.sh' % server_url)
agent = <containers.StorkAgentContainer object at 0x7fdd88d29970>
data = {'token': 'o85LV4YpOCqapgfaiZ4feeoUJL4fiw8v'}
distro_agent = 'ubuntu/18.04'
distro_server = 'centos/8'
i = 0
r = <Response [200]>
server = <containers.StorkServerContainer object at 0x7fdd88bfa040>
server_token = 'o85LV4YpOCqapgfaiZ4feeoUJL4fiw8v'
server_url = 'http://fd42:6657:6f41:ab43:216:3eff:fe59:2fea:8080'
tests.py:211:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
self = <containers.StorkAgentContainer object at 0x7fdd88d29970>, cmd = 'curl -o stork-install-agent.sh http://fd42:6657:6f41:ab43:216:3eff:fe59:2fea:8080/stork-install-agent.sh'
env = {'LANG': 'en_US.UTF-8', 'LANGUAGE': 'en_US:UTF-8', 'LC_ALL': 'en_US.UTF-8'}, ignore_error = False, attempts = 1, sleep_time_after_attempt = None
def run(self, cmd, env=None, ignore_error=False, attempts=1, sleep_time_after_attempt=None):
cmd2 = shlex.split(cmd)
if env is None:
env = {}
env['LANG'] = "en_US.UTF-8"
env['LANGUAGE'] = "en_US:UTF-8"
env['LC_ALL'] = "en_US.UTF-8"
for attempt in range(attempts):
result = self.cntr.execute(cmd2, env)
out = 'run: %s\n' % cmd
out += result[1]
self._trace_logs(out, 'out')
self._trace_logs(result[2], 'err')
if result[0] == 0:
break
elif attempt < attempts - 1:
print('command failed, retry, attempt %d/%d' % (attempt, attempts))
if sleep_time_after_attempt:
time.sleep(sleep_time_after_attempt)
if result[0] != 0 and not ignore_error:
> raise Exception('problem with cmd: %s' % cmd)
E Exception: problem with cmd: curl -o stork-install-agent.sh http://fd42:6657:6f41:ab43:216:3eff:fe59:2fea:8080/stork-install-agent.sh
attempt = 0
attempts = 1
cmd = 'curl -o stork-install-agent.sh http://fd42:6657:6f41:ab43:216:3eff:fe59:2fea:8080/stork-install-agent.sh'
cmd2 = ['curl', '-o', 'stork-install-agent.sh', 'http://fd42:6657:6f41:ab43:216:3eff:fe59:2fea:8080/stork-install-agent.sh']
env = {'LANG': 'en_US.UTF-8', 'LANGUAGE': 'en_US:UTF-8', 'LC_ALL': 'en_US.UTF-8'}
ignore_error = False
out = 'run: curl -o stork-install-agent.sh http://fd42:6657:6f41:ab43:216:3eff:fe59:2fea:8080/stork-install-agent.sh\n'
result = InstanceExecuteResult(exit_code=3, stdout='', stderr="curl: (3) Port number ended with ':'\n")
self = <containers.StorkAgentContainer object at 0x7fdd88d29970>
sleep_time_after_attempt = None
containers.py:228: Exception
```outstandinghttps://gitlab.isc.org/isc-projects/dhcp/-/issues/208isc-dhcp-client adopts server settings despite them not "request"ed2022-03-09T19:02:00ZCarlos Henrique Lima Melaraisc-dhcp-client adopts server settings despite them not "request"ed**Bug Description**
Hi, this is a bug well-known bug in Debian BTS (see [#407336](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407336), [#672232](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672232) and [#553023](https://bugs....**Bug Description**
Hi, this is a bug well-known bug in Debian BTS (see [#407336](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407336), [#672232](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=672232) and [#553023](https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=553023)), but it
still affects the dhclient/dhclient-scripts. The problem is that the dhclient "accepts"
options provided by the dhcp server even when they're not declared in `dhclient.conf`.
For example, I've removed the `ntp-servers` servers from my `dhclient.conf`, but the
dhclient still set `new_ntp_servers` variable and the dhclient-script that deals with
ntp configuration sets it as the ntp server.
**To Reproduce**
Steps to reproduce the behavior:
1. A DHCP server that sends options even if they're not requested
2. A dhclient version isc-dhclient-4.4.1 that doesn't request `ntp-servers` in `dhclient.conf`
3. Allowing the `debug` script show the following variables set by dhclient:
```
Thu Feb 14 08:12:04 -02 2019: entering /etc/dhcp/dhclient-enter-hooks.d, dumping variables.
reason='PREINIT'
interface='eth0'
--------------------------
Thu Feb 14 08:12:04 -02 2019: entering /etc/dhcp/dhclient-exit-hooks.d, dumping variables.
reason='PREINIT'
interface='eth0'
--------------------------
Thu Feb 14 08:12:12 -02 2019: entering /etc/dhcp/dhclient-enter-hooks.d, dumping variables.
reason='REBOOT'
interface='eth0'
new_ip_address='192.168.15.11'
new_network_number='192.168.15.0'
new_subnet_mask='255.255.255.0'
new_broadcast_address='192.168.15.255'
new_routers='192.168.15.1'
new_domain_name_servers='192.168.15.11'
new_netbios_name_servers='192.168.15.1'
new_ntp_servers='200.160.7.193'
--------------------------
Thu Feb 14 08:12:12 -02 2019: entering /etc/dhcp/dhclient-exit-hooks.d, dumping variables.
reason='REBOOT'
interface='eth0'
new_ip_address='192.168.15.11'
new_network_number='192.168.15.0'
new_subnet_mask='255.255.255.0'
new_broadcast_address='192.168.15.255'
new_routers='192.168.15.1'
new_domain_name_servers='192.168.15.11'
new_netbios_name_servers='192.168.15.1'
new_ntp_servers='200.160.7.193'
--------------------------
```
4. After that, Debian scripts take care of changing the ntp server to the one provided
by the dhcp server.
**Expected behavior**
I believe that the dhclient shouldn't set variables that weren't requested in `dhclient.conf`
**Environment:**
- Raspiberry Pi 3B
- Debian GNU/Linux 10 (buster) AArch64
- isc-dhclient-4.4.1
**Additional Information**
I've seen that there has been a lot of discussion on the bugs I've pointed out above,
there is a comment about using `supersede`, but I think this shouldn't be the preferred
solution since many people don't even touch in configuration files.
Also, the BTS indicates the bug has been forwarded upstream already, but I didn't find it.
And since I'm facing this annoying problem every time my rpi3 reboots, I've decided to
fill this bug.
I'll also add my `dhclient.conf` and the scripts I've talked about bellow.
<details>
<summary>dhclient.conf</summary>
```
# Configuration file for /sbin/dhclient.
#
# This is a sample configuration file for dhclient. See dhclient.conf's
# man page for more information about the syntax of this file
# and a more comprehensive list of the parameters understood by
# dhclient.
#
# Normally, if the DHCP server provides reasonable information and does
# not leave anything out (like the domain name, for example), then
# few changes must be made to this file, if any.
#
option rfc3442-classless-static-routes code 121 = array of unsigned integer 8;
send host-name = gethostname();
request subnet-mask, broadcast-address, time-offset, routers,
domain-name, domain-name-servers, domain-search, host-name,
dhcp6.name-servers, dhcp6.domain-search, dhcp6.fqdn,
netbios-name-servers, netbios-scope, interface-mtu,
rfc3442-classless-static-routes;
#send dhcp-client-identifier 1:0:a0:24:ab:fb:9c;
#send dhcp-lease-time 3600;
#supersede domain-name "fugue.com home.vix.com";
#prepend domain-name-servers 127.0.0.1;
#require subnet-mask, domain-name-servers;
#timeout 60;
#retry 60;
#reboot 10;
#select-timeout 5;
#initial-interval 2;
#script "/sbin/dhclient-script";
#media "-link0 -link1 -link2", "link0 link1";
#reject 192.33.137.209;
#alias {
# interface "eth0";
# fixed-address 192.5.5.213;
# option subnet-mask 255.255.255.255;
#}
#lease {
# interface "eth0";
# fixed-address 192.33.137.200;
# medium "link0 link1";
# option host-name "andare.swiftmedia.com";
# option subnet-mask 255.255.255.0;
# option broadcast-address 192.33.137.255;
# option routers 192.33.137.250;
# option domain-name-servers 127.0.0.1;
# renew 2 2000/1/12 00:00:01;
# rebind 2 2000/1/12 00:00:01;
# expire 2 2000/1/12 00:00:01;
#}
```
</details>
<details>
<summary>debug</summary>
```
#
# The purpose of this script is just to show the variables that are
# available to all the scripts in this directory. All these scripts are
# called from dhclient-script, which exports all the variables shown
# before. If you want to debug a problem with your DHCP setup you can
# enable this script and take a look at /tmp/dhclient-script.debug.
# To enable this script set the following variable to "yes"
RUN="yes"
if [ "$RUN" = "yes" ]; then
echo "$(date): entering ${1%/*}, dumping variables." \
>> /tmp/dhclient-script.debug
# loop over the 4 possible prefixes: (empty), cur_, new_, old_
for prefix in '' 'cur_' 'new_' 'old_'; do
# loop over the DHCP variables passed to dhclient-script
for basevar in reason interface medium alias_ip_address \
ip_address host_name network_number subnet_mask \
broadcast_address routers static_routes \
rfc3442_classless_static_routes \
domain_name domain_search domain_name_servers \
netbios_name_servers netbios_scope \
ntp_servers \
ip6_address ip6_prefix ip6_prefixlen \
dhcp6_domain_search dhcp6_name_servers ; do
var="${prefix}${basevar}"
eval "content=\$$var"
# show only variables with values set
if [ -n "${content}" ]; then
echo "$var='${content}'" >> /tmp/dhclient-script.debug
fi
done
done
echo '--------------------------' >> /tmp/dhclient-script.debug
fi
```
</details>
<details>
<summary>dhclient-exit-hooks.d/ntp</summary>
```
NTP_CONF=/etc/ntp.conf
NTP_DHCP_CONF=/run/ntp.conf.dhcp
ntp_server_restart() {
invoke-rc.d ntp try-restart
}
ntp_servers_setup_remove() {
if [ ! -e $NTP_DHCP_CONF ]; then
return
fi
rm -f $NTP_DHCP_CONF
ntp_server_restart
}
ntp_servers_setup_add() {
if [ -e $NTP_DHCP_CONF ] && [ "$new_ntp_servers" = "$old_ntp_servers" ]; then
return
fi
if [ -z "$new_ntp_servers" ]; then
ntp_servers_setup_remove
return
fi
tmp=$(mktemp "$NTP_DHCP_CONF.XXXXXX") || return
chmod --reference=$NTP_CONF $tmp
chown --reference=$NTP_CONF $tmp
(
echo "# This file was copied from $NTP_CONF with the server options changed"
echo "# to reflect the information sent by the DHCP server. Any changes made"
echo "# here will be lost at the next DHCP event. Edit $NTP_CONF instead."
echo
echo "# NTP server entries received from DHCP server"
for server in $new_ntp_servers; do
echo "server $server iburst"
done
echo
sed '/^[[:space:]]*\(server\|peer\|pool\)[[:space:]]/d' $NTP_CONF
) >>$tmp
mv $tmp $NTP_DHCP_CONF
ntp_server_restart
}
ntp_servers_setup() {
case $reason in
BOUND|RENEW|REBIND|REBOOT)
ntp_servers_setup_add
;;
EXPIRE|FAIL|RELEASE|STOP)
ntp_servers_setup_remove
;;
esac
}
ntp_servers_setup
```
</details>Outstanding