BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-11-02T16:32:26Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/53Implement "NXDOMAIN cut" (RFC 8020)2023-11-02T16:32:26ZStéphane BortzmeyerImplement "NXDOMAIN cut" (RFC 8020)BIND has "NSEC aggressive caching" (NSEC-only, see #50) but this requires DNSSEC. For non-DNSSEC zones, "NXDOMAIN cut" could be interesting (RFC 8020).
It is already implemented in Unbound (option "harden-below-nxdomain:")
[Is there a ...BIND has "NSEC aggressive caching" (NSEC-only, see #50) but this requires DNSSEC. For non-DNSSEC zones, "NXDOMAIN cut" could be interesting (RFC 8020).
It is already implemented in Unbound (option "harden-below-nxdomain:")
[Is there a tag "Resolver"? This could be useful for resolver-only features.]Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4216Report missing DNSSEC algorithms in returned RRSIGs2023-11-02T16:30:30ZMark AndrewsReport missing DNSSEC algorithms in returned RRSIGsWhile we only require one DNSSEC algorithm to validate a response reporting missing algorithms listed in the DS RRset will be useful for the overall health of the system.While we only require one DNSSEC algorithm to validate a response reporting missing algorithms listed in the DS RRset will be useful for the overall health of the system.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4199dig (and other tools) may send queries with QID=0, which confuses Net::DNS2023-11-02T16:30:30ZMichał Kępieńdig (and other tools) may send queries with QID=0, which confuses Net::DNSUnless specified manually using `+qid=<value>`, `dig` uses a random
query ID for the DNS messages it sends out:
https://gitlab.isc.org/isc-projects/bind9/-/blob/bf8acd455693edef03881fd2180c5561bc0db66d/bin/dig/dighost.c#L2334
In partic...Unless specified manually using `+qid=<value>`, `dig` uses a random
query ID for the DNS messages it sends out:
https://gitlab.isc.org/isc-projects/bind9/-/blob/bf8acd455693edef03881fd2180c5561bc0db66d/bin/dig/dighost.c#L2334
In particular, the value chosen can be 0. While QID=0 is perfectly
legal protocol-wise, it seems that some code bases, e.g. Net::DNS, are
unable to properly handle queries with QID=0. Here is an example:
https://gitlab.isc.org/isc-private/bind9/-/jobs/3509123
```
2023-07-06 14:14:45 INFO:serve-stale I:serve-stale_tmp_iwl06k82:disable responses from authoritative server (89)
2023-07-06 14:14:57 INFO:serve-stale I:serve-stale_tmp_iwl06k82:failed
```
`bin/tests/system/serve-stale_tmp_iwl06k82/dig.out.test89`:
```
;; Warning: ID mismatch: expected ID 0, got 46879
;; communications error to 10.53.0.2#19223: timed out
; <<>> DiG 9.19.15 <<>> +time +tries -p 19223 @10.53.0.2 txt disable
; (1 server found)
;; global options: +cmd
;; no servers could be reached
```
This looked weird to me, so I started `ans2/ans2.pl` manually and sent a
query to it using `dig @10.53.0.2 -p 5300 disable. TXT +qid=0 +tries=1`.
Guess what:
```
;; Warning: ID mismatch: expected ID 0, got 27885
;; communications error to 10.53.0.2#5300: timed out
; <<>> DiG 9.19.15 <<>> @10.53.0.2 -p 5300 disable. TXT +qid=0 +tries=1
; (1 server found)
;; global options: +cmd
;; no servers could be reached
```
Looking at [Net::DNS sources][1], the documentation says:
```
=head2 id
print "query id = ", $packet->header->id, "\n";
$packet->header->id(1234);
Gets or sets the query identification number.
A random value is assigned if the argument value is undefined.
```
However, the above seems to be imprecise: apparently if the ID is
*defined*, but *set to 0*, Net::DNS treats it as an undefined value.
This causes the `$packet->header->id` call to return a random value
instead of 0 for queries with QID=0, breaking responses to such queries.
I don't see any reasonable way to work around this problem in our Perl
code (apart from converting it to Python). Adding `+qid` to every `dig`
invocation in the system test suite also seems over the top for working
around something this silly. However, until we do something about this,
we might be seeing a whole class of surprising failures in the system
test suite caused by this behavior.
[1]: https://www.net-dns.org/svn/net-dns/trunk/lib/Net/DNS/Header.pmNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4087Follow-up from "fix handling of TCP timeouts"2023-11-02T16:30:30ZEvan HuntFollow-up from "fix handling of TCP timeouts"The following discussion from !7937 should be addressed:
- [ ] @aram started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7937#note_375087): (+2 comments)
> While you are addressing Ondřej's comments, ...The following discussion from !7937 should be addressed:
- [ ] @aram started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7937#note_375087): (+2 comments)
> While you are addressing Ondřej's comments, would you please also look at something not strictly related to this MR, which caught my eye (cc @ondrej):
>
> ```c
> void
> dns_dispatch_resume(dns_dispentry_t *resp, uint16_t timeout);
> /*%<
> * Reset the read timeout in the socket associated with 'resp' and
> * continue reading.
> *
> * Requires:
> *\li 'resp' is valid.
> */
> ```
>
> The function is supposed to reset the read timeout, but if I am reading the code correctly, both `udp_dispatch_getnext()` and `tcp_dispatch_getnext()` (called by `dns_dispatch_resume()`) potentially can ignore the timeout value if the read operation is already ongoing. Is that by design?
>
> I think it should at least update the `resp->timeout` value with the new one, and probably call `isc_nmhandle_settimeout()` even when already reading, in case if the new timeout is smaller than the remaining time of the current one.Not plannedEvan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/3951TSIG-GSS keys should be deleted after use2023-11-02T16:30:30ZEvan HuntTSIG-GSS keys should be deleted after use@pspacek pointed out in !7629:
> Can we have test for key removal (coverage shows it's not tested)?
This is a problem. That code path was previously tested in the `tkey` system test, which negotiated the creation of DH keys and then del...@pspacek pointed out in !7629:
> Can we have test for key removal (coverage shows it's not tested)?
This is a problem. That code path was previously tested in the `tkey` system test, which negotiated the creation of DH keys and then deleted them, but that test has been removed now.
The `tsiggss` test runs `nsupdate`, which sets up GSS keys, but never deletes them.
RFC 3645 says:
```
When the client is not intended to continue using the established
security context, the client SHOULD delete an active context by
calling GSS_Delete_sec_context providing the associated
context_handle, AND client SHOULD delete the established context on
the DNS server by using TKEY RR with the Mode field set to 5, i.e.,
"key deletion" [RFC2930].
```
I take this to mean that `nsupdate` should be sending a delete message for negotiated keys when it's shutting down.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3938Improve readability of 'rndc dnssec -status'2023-11-02T16:30:30ZMatthijs Mekkingmatthijs@isc.orgImprove readability of 'rndc dnssec -status'The output of `rndc dnssec -status` can be quite difficult to read.
1. The states "omnipresent", "unretentive", etc don't mean much to users. Some users for example think BIND is stuck because the DS stays in
"rumoured" state, while...The output of `rndc dnssec -status` can be quite difficult to read.
1. The states "omnipresent", "unretentive", etc don't mean much to users. Some users for example think BIND is stuck because the DS stays in
"rumoured" state, while in fact BIND is waiting to be signaled that the DS is published (with `rndc dnssec -checkds` or through parental
agents.
2. Perhaps the states shouldn't be printed at all, except when a to be implemented new argument is added, `-v` for verbose output.
3. "key signing:" sounds like it is signing the DNSKEY RRset, "signing:" might be better.
4. The additional blank line within each key block makes it actually more difficult to read, perhaps only have newline breaks between each key
block.
5. With many keys, sorting may be useful. Sort on rollover due/scheduled date and group keys by their role (CSK, KSK, ZSK).Not plannedMatthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3896Add the TLS SNI +[no]tls-sni option to dig for DoT and DoH2023-11-02T16:30:30ZAlexey ChernyakAdd the TLS SNI +[no]tls-sni option to dig for DoT and DoH### Description
Currently, when doing DoT or DoH lookups, `dig` does not include the Server Name Indication (SNI) extension during its TLS handshake `ClientHello` request.
This makes dig unusable as a DoT or DoH client with TLS proxies...### Description
Currently, when doing DoT or DoH lookups, `dig` does not include the Server Name Indication (SNI) extension during its TLS handshake `ClientHello` request.
This makes dig unusable as a DoT or DoH client with TLS proxies and HTTPS proxies and DoT/DoH servers that implement:
* SNI based routing of requests to the correct backends as part of name-based virtual hosting, and/or
* SNI filtering based access control.
Currently `dig` also has very poor handling of the fatal-level SNI-related TLS handshake `Alert` response from server.
Example of such TLS Alert server response:
```
Transport Layer Security
TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Unrecognized Name)
Content Type: Alert (21)
Version: TLS 1.2 (0x0303)
Length: 2
Alert Message
Level: Fatal (2)
Description: Unrecognized Name (112)
```
Current dig behaviour is as follows when the server aborts the handshake by sending such a fatal-level `unrecognized_name(112)` alert:
```
~ $ dig +https @dns.example.com example.com A; echo $?
;; Connection to 192.0.2.53#443(192.0.2.53) for example.com failed: TLS error.
;; Connection to 192.0.2.53#443(192.0.2.53) for example.com failed: TLS error.
;; Connection to 192.0.2.53#443(192.0.2.53) for example.com failed: TLS error.
9
~ $ dig +tls @dns.example.com example.com A; echo $?
0
~ $
```
There is no dependency on implementing SNI support in `named` (which also would be nice for ACLs and for multiple views).
While `named` can be placed behind a SNI-capable proxy, there's no workarounds for `dig` other than replacing it with a SNI-capable client such as `kdig`.
### Request
Add `+[no]tls-sni=STR` option to `dig` similar to the [option](https://www.knot-dns.cz/docs/3.2/html/man_kdig.html#options) in `kdig`.
Expected behaviour is something roughly along the lines of:
```
if request is DoT or DoH
if +tls-sni option is specified
SNIHostName = option value
else if +notls-sni option is specified
SNIHostName = NULL
else if @server argument is a hostname
SNIHostName = server hostname FQDN
else if +tls-hostname option is specified
SNIHostName = option value
else
SNIHostName = NULL
if SNIHostName
remove trailing FQDN dot from SNIHostName if specified
Do IDN format conversion to ASCII if necessary
validate SNIHostName against SNI HostName format specification
if SNIHostName format is valid
include SNIHostName as a SNI in TLS ClientHello
include SNIHostName in the first line of dig query output?
else
exit with an error
else
Don't include SNI in TLS ClientHello
if ServerHello response includes "server_name" extension
include SNIHostName in SERVER line in dig query output
```
Better error handling of the fatal-level `unrecognized_name(112)` alert TLS responses from server:
* Start returning an error during DoT instead of a silent success.
* Consider a more descriptive error message than the current `TLS error`:
```
if a <SNI> value was included in ClientHello
Error message something along the lines of: `'<SNI>' SNI is unrecognised by the server`
else
Error message something along the lines of: `SNI is required by the server`
```
### Links / references
For the most recent background and guidance on SNI see [Section 3.7 of RFC 9325](https://www.rfc-editor.org/rfc/rfc9325#name-server-name-indication-sni).
For the latest SNI specification defining SNI `HostName` format and client/server behaviour see [Section 3 of RFC 6066](https://www.rfc-editor.org/rfc/rfc6066.html#section-3).
When implementing, consider application of Internationalized Domain Names (IDN) in SNI as per [RFC 5890](https://www.rfc-editor.org/rfc/rfc5890) and TLS Encrypted Client Hello (ECH) as per the latest [draft](thttps://www.ietf.org/archive/id/draft-ietf-tls-esni-15.html).Not plannedArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3889Follow-up from "kasp: Add test case for migrating KSK/ZSK to CSK"2023-11-02T16:30:30ZMatthijs Mekkingmatthijs@isc.orgFollow-up from "kasp: Add test case for migrating KSK/ZSK to CSK"The following discussion from !7306 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7306#note_341267): (+4 comments)
> We also need a test without `-P sync`. Lot...The following discussion from !7306 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7306#note_341267): (+4 comments)
> We also need a test without `-P sync`. Lots of zones being converted to dnssec-policy will never have set `-P sync`. The key in the triggering issue only had:
>
> ```
> ; This is a key-signing key, keyid ${ID1}, for my.domain.
> ; Created: 20200401100731 (Wed Apr 1 13:07:31 2020)
> ; Publish: 20200401100731 (Wed Apr 1 13:07:31 2020)
> ; Activate: 20200401100731 (Wed Apr 1 13:07:31 2020)
> my.domain. IN DNSKEY 257 3 13 <X3>
> ```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3885"Loop detected resolving..." and different query-behavior after flushing a ca...2023-11-02T16:30:30ZThomas Amgarten"Loop detected resolving..." and different query-behavior after flushing a cache entry between BIND-9.19.10 and BIND-9.18.12### Summary
Regarding https://www.mail-archive.com/bind-users@lists.isc.org/msg33119.html, I fill this GL issue.
BIND-9.19.10 behaves differently to BIND-9.18.12 regarding AAAA-Lookups, when an entry (for example A record for "ns2.comt...### Summary
Regarding https://www.mail-archive.com/bind-users@lists.isc.org/msg33119.html, I fill this GL issue.
BIND-9.19.10 behaves differently to BIND-9.18.12 regarding AAAA-Lookups, when an entry (for example A record for "ns2.comtronic.ch") was cached and then succesfully flushed with ``rndc flushname ns2.comtronic.ch``.
BIND-9.19.10 then always...
- does A and AAAA lookups for the requested query (``dig @resolver ns2.comtronic.ch``)
- shows an INFO ``21-Feb-2023 09:23:15.463 resolver: info: loop detected resolving 'ns2.comtronic.ch/A'``
... where BIND-9.18.12 only sporadic shows the loop detected info and doesn't do AAAA lookups.
### BIND version used
#### 9.19.10
```
$ named -V
BIND 9.19.10 (Development Release) <id:789be8e>
running on Linux x86_64 4.18.0-305.10.2.el8_4.x86_64 #1 SMP Tue Jul 20 20:34:55 UTC 2021
built by make with '--prefix=/usr/local/bind-9.19.10' '--sysconfdir=/opt/chroot/bind/etc/named/' '--mandir=/usr/local/share/man' '--localstatedir=/opt/chroot/bind/var' '--enable-largefile' '--enable-full-report' '--without-gssapi' '--with-json-c' '--enable-singletrace' '--enable-dnstap' '--with-libxml2' 'PKG_CONFIG_PATH=/usr/local/fstrm/lib/pkgconfig/:/usr/local/h2o/lib64/pkgconfig'
compiled by GCC 8.4.1 20200928 (Red Hat 8.4.1-1)
compiled with OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
linked to OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
compiled with libuv version: 1.41.1
linked to libuv version: 1.41.1
compiled with libnghttp2 version: 1.33.0
linked to libnghttp2 version: 1.33.0
compiled with libxml2 version: 2.9.7
linked to libxml2 version: 20907
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
compiled with protobuf-c version: 1.3.0
linked to protobuf-c version: 1.3.0
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): yes
TKEY mode 3 support (GSS-API): no
default paths:
named configuration: /opt/chroot/bind/etc/named/named.conf
rndc configuration: /opt/chroot/bind/etc/named/rndc.conf
DNSSEC root key: /opt/chroot/bind/etc/named/bind.keys
nsupdate session key: /opt/chroot/bind/var/run/named/session.key
named PID file: /opt/chroot/bind/var/run/named/named.pid
named lock file: /opt/chroot/bind/var/run/named/named.lock
```
#### 9.18.12
```
$ named -V
BIND 9.18.12 (Extended Support Version) <id:99783f9>
running on Linux x86_64 4.18.0-305.10.2.el8_4.x86_64 #1 SMP Tue Jul 20 20:34:55 UTC 2021
built by make with '--prefix=/usr/local/bind-9.18.12' '--sysconfdir=/opt/chroot/bind/etc/named/' '--mandir=/usr/local/share/man' '--localstatedir=/opt/chroot/bind/var' '--enable-largefile' '--enable-full-report' '--without-gssapi' '--with-json-c' '--enable-singletrace' '--enable-dnstap' '--with-libxml2' 'PKG_CONFIG_PATH=/usr/local/fstrm/lib/pkgconfig/:/usr/local/h2o/lib64/pkgconfig'
compiled by GCC 8.4.1 20200928 (Red Hat 8.4.1-1)
compiled with OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
linked to OpenSSL version: OpenSSL 1.1.1g FIPS 21 Apr 2020
compiled with libuv version: 1.41.1
linked to libuv version: 1.41.1
compiled with libnghttp2 version: 1.33.0
linked to libnghttp2 version: 1.33.0
compiled with libxml2 version: 2.9.7
linked to libxml2 version: 20907
compiled with json-c version: 0.13.1
linked to json-c version: 0.13.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
compiled with protobuf-c version: 1.3.0
linked to protobuf-c version: 1.3.0
threads support is enabled
DNSSEC algorithms: RSASHA1 NSEC3RSASHA1 RSASHA256 RSASHA512 ECDSAP256SHA256 ECDSAP384SHA384 ED25519 ED448
DS algorithms: SHA-1 SHA-256 SHA-384
HMAC algorithms: HMAC-MD5 HMAC-SHA1 HMAC-SHA224 HMAC-SHA256 HMAC-SHA384 HMAC-SHA512
TKEY mode 2 support (Diffie-Hellman): yes
TKEY mode 3 support (GSS-API): no
default paths:
named configuration: /opt/chroot/bind/etc/named/named.conf
rndc configuration: /opt/chroot/bind/etc/named/rndc.conf
DNSSEC root key: /opt/chroot/bind/etc/named/bind.keys
nsupdate session key: /opt/chroot/bind/var/run/named/session.key
named PID file: /opt/chroot/bind/var/run/named/named.pid
named lock file: /opt/chroot/bind/var/run/named/named.lock
```
### Steps to reproduce
```
# Start named on the resolver
$ systemctl start named
```
```
# Query the record, which causes the behavior
$ dig @resolver ns2.comtronic.ch
; <<>> DiG 9.19.10 <<>> @resolver ns2.comtronic.ch
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22395
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 6a9803403ae47edc0100000063f4e59976baec2fb3207c4a (good)
;; QUESTION SECTION:
;ns2.comtronic.ch. IN A
;; ANSWER SECTION:
ns2.comtronic.ch. 60 IN A 195.200.242.162
;; Query time: 12 msec
;; SERVER: 10.100.102.21#53(resolver) (UDP)
;; WHEN: Tue Feb 21 16:39:05 CET 2023
;; MSG SIZE rcvd: 89
```
```
# Run "rndc flushname ns2.comtronic.ch"
$ rndc flushname ns2.comtronic.ch
```
```
# Query the resolver with the same query again
$ dig @resolver ns2.comtronic.ch
; <<>> DiG 9.19.10 <<>> @resolver ns2.comtronic.ch
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43078
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 70097c934a18c03c0100000063f4e6a0cc14b1551adc474c (good)
;; QUESTION SECTION:
;ns2.comtronic.ch. IN A
;; ANSWER SECTION:
ns2.comtronic.ch. 60 IN A 195.200.242.162
;; Query time: 8 msec
;; SERVER: 10.100.102.21#53(resolver) (UDP)
;; WHEN: Tue Feb 21 16:43:28 CET 2023
;; MSG SIZE rcvd: 89
```
```
# On the resolver check the named.log for "loop detected"
21-Feb-2023 16:43:28.238 resolver: info: loop detected resolving 'ns2.comtronic.ch/A'
```
```
# On the resolver sniff dns traffic, which always shows A and AAAA lookups
16:43:28.239336 IP 10.100.2.62.43415 > 10.100.102.21.53: 43078+ [1au] A? ns2.comtronic.ch. (57)
16:43:28.240559 IP6 2001:db8::affe.44411 > 2603:1020:a01:2::34.53: 11540 [1au] A? ns2.comtronic.ch. (45)
16:43:28.240885 IP6 2001:db8::affe.33227 > 2001:67c:1010:2::53.53: 46123% [1au] AAAA? ns2.comtronic.ch. (45)
16:43:28.240984 IP6 2001:db8::affe.29014 > 2001:67c:1010:2::53.53: 50359% [1au] A? ns2.comtronic.ch. (45)
16:43:28.243680 IP6 2603:1020:a01:2::34.53 > 2001:db8::affe.44411: 11540*- 1/0/1 A 195.200.242.162 (61)
16:43:28.243951 IP 10.100.102.21.53 > 10.100.2.62.43415: 43078 1/0/1 A 195.200.242.162 (89)
16:43:28.246959 IP6 2001:67c:1010:2::53.53 > 2001:db8::affe.33227: 46123- 0/10/10 (695)
16:43:28.247176 IP6 2001:67c:1010:2::53.53 > 2001:db8::affe.29014: 50359- 0/10/10 (695)
16:43:28.247420 IP6 2001:db8::affe.36611 > 2a02:1368:1:47::53.53: 1441% [1au] AAAA? ns2.comtronic.ch. (45)
16:43:28.247515 IP6 2001:db8::affe.6551 > 2a02:1368:1:47::53.53: 45763% [1au] A? ns2.comtronic.ch. (45)
16:43:28.248042 IP6 2a02:1368:1:47::53.53 > 2001:db8::affe.36611: 1441*- 0/1/1 (96)
16:43:28.248080 IP6 2a02:1368:1:47::53.53 > 2001:db8::affe.6551: 45763*- 1/0/1 A 195.200.242.162 (61)
```
### What is the current *bug* behavior?
Regarding https://www.mail-archive.com/bind-users@lists.isc.org/msg33119.html it's not clear,
- what "loop detected resolving 'ns2.comtronic.ch/A' means here?
- why "loop detected resolving 'ns2.comtronic.ch/A'" always is reproducable in BIND-9.19.10 and sporadic in BIND-9.18.12?
- why BIND-9.19.10 behaves differently to BIND-9.18.12 regarding AAAA lookups after flushing the name "ns2.comtronic.ch"?
A ``tcpdump`` from BIND-9.18.12 shows the following traffic (excerpt from my mailing-list- question):
```
# Query from the client
09:36:34.242064 IP 10.100.2.62.59765 > 10.100.102.21.53: 58600+ [1au] A? ns2.comtronic.ch. (57)
# Query from the resolver to the authoritative
09:36:34.242787 IP6 2001:db8::affe.4717 > 2a02:1368:1:48::53.53: 26321 [1au] A? ns2.comtronic.ch. (45)
# Query from the resolver to the TLD server
09:36:34.242880 IP6 2001:db8::affe.25272 > 2001:620:0:ff::56.53: 50695% [1au] A? ns2.comtronic.ch. (45)
# Response back from the authoritative server
09:36:34.243673 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.4717: 26321*- 1/0/1 A 195.200.242.162 (61)
# Response back to the client
09:36:34.243841 IP 10.100.102.21.53 > 10.100.2.62.59765: 58600 1/0/1 A 195.200.242.162 (89)
# Delegation answer from the TLD server
09:36:34.244556 IP6 2001:620:0:ff::56.53 > 2001:db8::affe.25272: 50695- 0/10/10 (695)
# A 2nd query to the same authoritative
09:36:34.244750 IP6 2001:db8::affe.18083 > 2a02:1368:1:48::53.53: 21395% [1au] A? ns2.comtronic.ch. (45)
# 2nd response back from the authoritative server
09:36:34.245246 IP6 2a02:1368:1:48::53.53 > 2001:db8::affe.18083: 21395*- 1/0/1 A 195.200.242.162 (61)
```
### What is the expected *correct* behavior?
I'm not sure, which behavior is the correct one, 9.19.10 or 9.18.12.
### Relevant configuration files
--
### Relevant logs and/or screenshots
--
### Possible fixes
--Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3878Missing and undocumented statistics from the HTTP stats channel in the ARM2023-11-02T16:30:30ZPieter LexisMissing and undocumented statistics from the HTTP stats channel in the ARMHi folks,
I'm implementing a new monitoring solution and adding a bunch of stats from the HTTP-based stats channel to said monitoring solution. I'm basing the descriptions on what I can find in the ARM section 8.5 (I'm using the one fro...Hi folks,
I'm implementing a new monitoring solution and adding a bunch of stats from the HTTP-based stats channel to said monitoring solution. I'm basing the descriptions on what I can find in the ARM section 8.5 (I'm using the one from 9.18 and 9.19), but some stats are missing there. Some of them are self-evident based on the name, but some are not. I've compiled a list here, the naming is based on the JSON from the webserver:
* nsstats.TCPConnHighWater
* nsstats.SynthNXDOMAIN
* nsstats.CookieNew
* nsstats.CookieIn
* in view.NAME.resolver.stats
* BucketSize
* ClientCookieOut
* ServerCookieOut
* CookieIn
* CookieClientOk
* BadCookieRcode
* NextItem
* Priming
* traffic
The following stats are mostly unclear:
* view.NAME.resolver.cachestats - none of these statistics are described
* view.NAME.resolver.adb - none of these statistics are described
* opcodes.CODE - Are these the counts of received opcodes from clients?
* rcodes.CODE - Are these the counts of rcodes sent to clients?
* qtypes.CODE - Are these the counts of qtypes that were queried by clients?
* view.NAME.resolver.qtypes - what do these numbers mean?
* view.NAME.resolver.cache - Are the current cache entries for these types?
Cheers,
PieterNot plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3050Post load checking of missing delegations2023-11-02T16:26:08ZMark AndrewsPost load checking of missing delegationsIs it worth while to perform a post load DS lookup for each primary / slave zone against the other loaded zone looking for a NXDOMAIN response which would indicate a missing delegation? This would catch cases like bhutan.gov.bt where b...Is it worth while to perform a post load DS lookup for each primary / slave zone against the other loaded zone looking for a NXDOMAIN response which would indicate a missing delegation? This would catch cases like bhutan.gov.bt where both it and the parent zone are served by the same servers but there isn't a delegation for bhutan.gov.bt in the gov.bt zone.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/2883Let name of inline-signed zone file be configured2023-11-02T16:26:08ZMagnus HolmgrenLet name of inline-signed zone file be configured### Description
The names of journal files can be overridden (with `journal`), but not the names of the signed zone files created when `inline-signing=yes`. They are always named like the original file with `.signed` appended. https://g...### Description
The names of journal files can be overridden (with `journal`), but not the names of the signed zone files created when `inline-signing=yes`. They are always named like the original file with `.signed` appended. https://gitlab.isc.org/isc-projects/bind9/-/blob/2872d6a12efe578360a641c1ba90884ea9a7dd01/bin/named/zoneconf.c#L1116
It's not a huge deal, but I'd like to separate manually edited configuration from software managed data per the FHS, and thus keep non-dynamic master zones in /etc (which is also what the Debian package recommends) but the inline-signed zone data in /var/lib. (It appears that the Debian BIND maintainers didn't consider inline signing, because the included AppArmor profile prevents `named` from writing to /etc/bind.)
### Request
Define a new option `signed-file` or similar. Could something like [signed-file.patch](/uploads/ec5f66b98f5c986d867ea76ccc4a89d9/signed-file.patch) work?Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2879Add --disable-doh to a CI build?2023-11-02T16:26:08ZMark AndrewsAdd --disable-doh to a CI build?The following discussion from !5353 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5353#note_231504): (+1 comment)
> One remaining question is "do we add yet ano...The following discussion from !5353 should be addressed:
- [ ] @marka started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5353#note_231504): (+1 comment)
> One remaining question is "do we add yet another system with --disable-doh to CI?"
- [ ] Also should we have a CI build that does not have libnghttp2 installed.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2798named-checkconf -p does not print effective values2023-11-02T16:26:07ZPetr Špačekpspacek@isc.orgnamed-checkconf -p does not print effective values### Description
Bordeline bug and feature request:
`named-checkconf -p` does not print effective values but only how the _text_ was parsed.
Example:
`resolver-query-timeout 3;` is silently set to `10` by named, but named-checkconf stil...### Description
Bordeline bug and feature request:
`named-checkconf -p` does not print effective values but only how the _text_ was parsed.
Example:
`resolver-query-timeout 3;` is silently set to `10` by named, but named-checkconf still prints value `3`.
### Request
An option to print effective values would be useful, especially if it highlighted where effective value differs from the configured value.
Obviously this is hard to do. From what I see in code, config handling in server.c nad in named-checkconf is completely different. Inheritance rules limits are implemented as ad-hoc code in server.c.
### Links / references
*See also:*
* #1326;Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2772Update: Validation Easy Start Explained2023-11-02T16:26:07ZMark AndrewsUpdate: Validation Easy Start ExplainedThis section still references managed-keys as of 9.16.16. It needs to be updated to refer to `trust-anchors`.
Also `delv does not consult the managed-keys database maintained by named, which means that if either of the keys in /etc/bin...This section still references managed-keys as of 9.16.16. It needs to be updated to refer to `trust-anchors`.
Also `delv does not consult the managed-keys database maintained by named, which means that if either of the keys in /etc/bind.keys is revoked and rolled over, /etc/bind.keys must be updated to use DNSSEC validation in delv.` is out of date.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2734dns64 processing of stale AAAA doesn't use a non-stale A2023-11-02T16:26:07ZEvan Huntdns64 processing of stale AAAA doesn't use a non-stale AIn [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5102#note_216731) in !5102, @michal pointed out an edge case in stale-data/dns64 processing that may be a bug:
- we're searching for AAAA, but the auth server is...In [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5102#note_216731) in !5102, @michal pointed out an edge case in stale-data/dns64 processing that may be a bug:
- we're searching for AAAA, but the auth server is slow
- we reach the stale answer timeout, but we don't have a stale AAAA in the cache
- but we have a _current_ A record in the cache
- ...but dns64 can't use it to synthesize a reply, because when we're processing a stale timeout we only look for _stale_ data.
This can be observed by applying these changes to the test code that was introduced in that MR:
```
diff --git a/bin/tests/system/serve-stale/ans2/ans.pl b/bin/tests/system/serve-stale/ans2/ans.pl
index a046417e09c..5e11f22cf6a 100644
--- a/bin/tests/system/serve-stale/ans2/ans.pl
+++ b/bin/tests/system/serve-stale/ans2/ans.pl
@@ -119,7 +119,7 @@ sub reply_handler {
$rcode = "NOERROR";
} elsif ($qname eq "a-only.example") {
if ($qtype eq "A") {
- my $rr = new Net::DNS::RR("a-only.example 2 IN A $localaddr");
+ my $rr = new Net::DNS::RR("a-only.example 5 IN A $localaddr");
push @ans, $rr;
} else {
my $rr = new Net::DNS::RR($negSOA);
diff --git a/bin/tests/system/serve-stale/tests.sh b/bin/tests/system/serve-stale/tests.sh
index b287f8c1f07..7ac0288d329 100755
--- a/bin/tests/system/serve-stale/tests.sh
+++ b/bin/tests/system/serve-stale/tests.sh
@@ -2216,7 +2216,7 @@ $DIG -p ${PORT} @10.53.0.2 txt disable > /dev/null
# wait two seconds for the previous answer to become stale
sleep 2
# resend the query and wait in the background; we should get a stale answer
-$DIG -p ${PORT} @10.53.0.3 a-only.example AAAA > dig.out.2.test$n &
+$DIG -p ${PORT} +tries=1 @10.53.0.3 a-only.example AAAA > dig.out.2.test$n &
# re-enable queries after a pause, so the server gets a real answer too
sleep 2
$DIG -p ${PORT} @10.53.0.2 txt enable > /dev/null
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2666Document test only options2023-11-02T16:26:06ZMatthijs Mekkingmatthijs@isc.orgDocument test only optionsFrom the following discussion from !4925 should be addressed:
- [ ] @matthijs started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4925#note_209969): (+2 comments)
> I am not too fond on having `too-ma...From the following discussion from !4925 should be addressed:
- [ ] @matthijs started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4925#note_209969): (+2 comments)
> I am not too fond on having `too-many`. I would prefer an option that would disable the iteration value checking.
>
> Either way, this needs to be documented. Probably the manfile is the best place for it.
This option should be documented. There are more test options that should be documented.
1. Document `dnssec-signzone -H too-many`
2. Find other undocumented test options
3. Document those.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2651Follow-up from "ensure read timeouts are recoverable"2023-11-02T16:26:06ZEvan HuntFollow-up from "ensure read timeouts are recoverable"As discussed [here](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4930#note_208463), it is possible in `netmgr_test` for two TCP sends to occur before a read, which results in a read twice as long as expected. This is not cu...As discussed [here](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4930#note_208463), it is possible in `netmgr_test` for two TCP sends to occur before a read, which results in a read twice as long as expected. This is not currently causing a test failure because, as of !4930, we don't check for the block length to be exactly correct, we only check for a minimum size. This should probably be investigated, and we should either prevent double sends, or have the read callback loop over the block it reads and process all of the data.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2525Automated test for upgrading BIND2023-11-02T16:26:05ZVicky Riskvicky@isc.orgAutomated test for upgrading BINDsuggestion - can we consider creating a test for updating BIND versions?
This will need to look at what persistent data needs to be preserved across the update.
The complexity is that users update across multiple versions, perhaps the f...suggestion - can we consider creating a test for updating BIND versions?
This will need to look at what persistent data needs to be preserved across the update.
The complexity is that users update across multiple versions, perhaps the first scenario to address is migrating from the latest 9.11 version to the latest 9.16 version.
It might be good to measure how long the update takes, the time to reload (in case either of these are surprising that might indicate a problem), of course that bind restarts and reloads, maybe run a few queries??Not planned