BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2023-11-02T16:30:30Zhttps://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/3948Remove the artificial limit on max zone keys2023-03-15T09:37:28ZOndřej SurýRemove the artificial limit on max zone keysThe `struct dns_update_state` contains the following member `dst_key_t *zone_keys[DNS_MAXZONEKEYS];` limiting the number of the zone keys to `32`. This seems enough, but since we already pass memory context to both `lib/dns/zone.c:dns__...The `struct dns_update_state` contains the following member `dst_key_t *zone_keys[DNS_MAXZONEKEYS];` limiting the number of the zone keys to `32`. This seems enough, but since we already pass memory context to both `lib/dns/zone.c:dns__zone_findkeys()`, `lib/dns/dnssec.c:dns_dnssec_findzonekeys()`, and `lib/dns/update.c:find_zone_keys()` and return the number of found keys in `&nkeys`, we could as well allocate the array in `dns_dnssec_findzonekeys()` by calling `dns_rdataset_count()` first, allocating the array to hold all the possible keys and then shrinking to the actual number of keys.
Alternatively, this could be converted to `ISC_LIST()` instead of a static array.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/3920dnstap logging does not log "opening dnstap destination" to the dnstap channel2023-03-05T16:01:59ZJeremy Reeddnstap logging does not log "opening dnstap destination" to the dnstap channel
### Summary
I have a category dnstap setup and I get the "closing dnstap" logged to my dnstap channel. But the logging of "opening dnstap destination ..." did not go to my dnstap channel but to my default (syslog).
I am using dnstap t...
### Summary
I have a category dnstap setup and I get the "closing dnstap" logged to my dnstap channel. But the logging of "opening dnstap destination ..." did not go to my dnstap channel but to my default (syslog).
I am using dnstap to a unix domain socket. It works fine. I have a dnstap channel and category setup. I get the "closing dnstap" logged as expected at named shutdown.
### BIND version used
BIND 9.18.13-dev (Extended Support Version) <id:3e46baa>
But I also see that this happened in another version. See https://www.mail-archive.com/bind-users@lists.isc.org/msg30000.html which says "I would have expected to see logged in /var/opt/isc/scls/isc-bind/log/named/dnstap" and "... I can't seem to get any more
information out other than the single message about "closing dnstap"."
### What is the expected *correct* behavior?
The ./lib/dns/dnstap.c appears to show that the "opening dnstap destination ..." to be logged same as the "closing" message. Does this mean the dns_dt_create() happens before the (not-dnstap) logging subsystem is enabled?Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3919Test RRSIG churn on large zones2023-03-03T15:06:25ZPetr Špačekpspacek@isc.orgTest RRSIG churn on large zonesObservation
===========
Large zones (in order of 10 M RRs) need RRSIG inception and expiration times to be spread out evenly so resigning does not cause CPUs and zone transfers to explode at single point in time. Spreading resigning then...Observation
===========
Large zones (in order of 10 M RRs) need RRSIG inception and expiration times to be spread out evenly so resigning does not cause CPUs and zone transfers to explode at single point in time. Spreading resigning then causes non-negligible sustained update rate, and that reportedly is or was problem for some providers.
Inspired by https://indico.dns-oarc.net/event/46/contributions/979/
Test ideas
==========
Impact of ongoing resigning on:
- [ ] AXFR
- [ ] IXFR
- [ ] journal maintenance
- [ ] query latency?
I guess, if nothing else, `fsync()` and journal compaction might cause some mess.https://gitlab.isc.org/isc-projects/bind9/-/issues/3918Add tests for ultra-complex NSEC(3) proofs2023-03-03T15:02:10ZPetr Špačekpspacek@isc.orgAdd tests for ultra-complex NSEC(3) proofsThis is essentially list of ideas for tests from DNS-OARC 40.
Check NSEC(3) proofs returned by auth, plus also ability to validate these.
- Chain of CNAME/DNAME alternating between zones on the same box
- Mix of NSEC/NSEC3/unsigned zon...This is essentially list of ideas for tests from DNS-OARC 40.
Check NSEC(3) proofs returned by auth, plus also ability to validate these.
- Chain of CNAME/DNAME alternating between zones on the same box
- Mix of NSEC/NSEC3/unsigned zones in the chain
- Wildcards in the mix
- Zone with wildcard and opt-out enabled for the LOLz?
Does forwarding change anything related to validation (the process how we gather data)?
Inspiration: https://indico.dns-oarc.net/event/46/contributions/979/ slides 17, 21, 22https://gitlab.isc.org/isc-projects/bind9/-/issues/3914ability to detect and restart stalled zone transfers2023-05-22T18:55:35ZPetr Špačekpspacek@isc.orgability to detect and restart stalled zone transfers### Description
Sometimes TCP connection can get stuck at very low throughput - network problem in remote locations etc. Low means > 0 througput, so transfer timeout does not kill it and it "never" finishes.
For context, this happens o...### Description
Sometimes TCP connection can get stuck at very low throughput - network problem in remote locations etc. Low means > 0 througput, so transfer timeout does not kill it and it "never" finishes.
For context, this happens on global DNS backbone, which literally spans the globe. The problem is not caused by BIND, but by network along the path and TCP stacks not coping that great with it. I.e. essentially this is workaround for someone else's mess.
### Request
First, implement #3883 Expose data about transfers
Then, this:
Provide configuration knob which sets something like (lower bound of transfer rate in bytes, check frequency). Check running transfers periodically, and kill transfers if they are slower than configured limit. This should cause retry down the road.
### Links / references
E.g. Red Hat package manager YUM has something like that. If download is too slow it reports error like:
> Operation too slow. Less than 1000 bytes/sec transferred the last 30 seconds
[Yum docs](https://github.com/rpm-software-management/yum/blob/4ed25525ee4781907bd204018c27f44948ed83fe/docs/yum.conf.5#L446)
I think this is a good mechanism as it removes need for alternative proposal: yet another rndc command to kill ongoing zone transfer. That is, good if we accept we should be solving this problem.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3913timing issue in statschannel system test2023-03-03T08:07:02ZTom Krizektiming issue in statschannel system testIn job [#3207137](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3207137) the `statschannel` failed on check `fetch zone 'dnssec' stats data after updating DNSKEY RRset (7)`.
The test expects 1 zsk sign operation and 1 ksk sign operat...In job [#3207137](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3207137) the `statschannel` failed on check `fetch zone 'dnssec' stats data after updating DNSKEY RRset (7)`.
The test expects 1 zsk sign operation and 1 ksk sign operation. These happen:
```
02-Mar-2023 09:10:06.228 add re-sign dnssec. 300 IN RRSIG DNSKEY 13 1 300 20230401091005 20230302081006 7913 dnssec. MT/JQRYMGsWYBwyRkdnj+tB7h2oSbpVfZ9n+DMr1oyDdXtRSoxGwydIO a2GRjUgP5kQ/N5JWUQMK2LkvThFvsA==
02-Mar-2023 09:10:06.228 add re-sign dnssec. 300 IN RRSIG SOA 13 1 300 20230401091006 20230302081006 35685 dnssec. unerVqERet0Xr8KV19/D174G3moa5NVkDoXIbvpc3cPQuzCd/z+eYC2h zuLlEZawAFe2NTI3jw+TDkIgKfpnCw==
```
Then the test waits for `next key event`:
```
02-Mar-2023 09:10:06.228 zone dnssec/IN: next key event: 02-Mar-2023 10:10:06.220
```
However, 100 milliseconds later, before the test retrieves the zone statistics from the statschannel, additional signing operations take place:
```
02-Mar-2023 09:10:06.328 zone_maintenance: zone dnssec/IN: enter
02-Mar-2023 09:10:06.328 zone_resigninc: zone dnssec/IN: enter
02-Mar-2023 09:10:06.328 zone_journal: zone dnssec/IN: enter
02-Mar-2023 09:10:06.328 writing to journal
02-Mar-2023 09:10:06.328 del dnssec. 300 IN SOA mname1. . 4 20 20 1814400 3600
02-Mar-2023 09:10:06.328 del re-sign dnssec. 300 IN RRSIG NS 13 1 300 20230309211006 20230302080959 35685 dnssec. kaS58YnGbS/p3V8088p+yREiSINte5ETOr/3QvFU9XsHyuxDqRLkux6i XqY5/PSkQFm094MO/wNLdbTp8LaB2g==
02-Mar-2023 09:10:06.328 del re-sign a.dnssec. 300 IN RRSIG NSEC 13 2 300 20230309211006 20230302080959 35685 dnssec. 12MDX1o0qgh0T3SoM0aKsu6AjJYcueqHpOT//xD0l/EjFJgBOVu3VJpA 0OO3R/VdQzFeBq1tgY88dpLnTwvKUw==
02-Mar-2023 09:10:06.328 del re-sign a.dnssec. 300 IN RRSIG MX 13 2 300 20230309211006 20230302080959 35685 dnssec. vGNl05h/fsvnnHvU1RX3yUuCRS5Egqd9Mr5HxZ8J3uZAleQNVxUa+gG9 f9ZJ+q6+Zp8Kz8AFHqCxN1vMq0+5zw==
02-Mar-2023 09:10:06.332 del re-sign mail.dnssec. 300 IN RRSIG A 13 2 300 20230309211006 20230302080959 35685 dnssec. RRafXWoDHpbErUBXOVzI3rbREe8ezmj8QEHpHampjKVNJrfzFWbP1cku meg3TPsTCQdy/1v6v4cvfB03SusQoQ==
02-Mar-2023 09:10:06.332 del re-sign a.dnssec. 300 IN RRSIG A 13 2 300 20230309211006 20230302080959 35685 dnssec. ofun5lwcYTsK0OawryLIViK/sdJHPSHT7RxoQR5ErmkAPpjZvTIoE4EO ua95xdHE1X5h/hnJCBYPpl5kHS+Lfg==
02-Mar-2023 09:10:06.332 del re-sign mail.dnssec. 300 IN RRSIG NSEC 13 2 300 20230309211006 20230302080959 35685 dnssec. GspggAHIxa6RQMbauI4On2esTEWifodSorcCjxqlwtZ71XOF7LdtWTbw HLf5o1xYP76o2RRN3CAZRPmAOs1Lkw==
02-Mar-2023 09:10:06.332 del re-sign ns2.dnssec. 300 IN RRSIG NSEC 13 2 300 20230309211006 20230302080959 35685 dnssec. FJXd9+ncwyBxhrMpmAO3xs1sEGlP3g0EhmOk9IHa4/Ljgv6qIJYIL7hW dz2JbfYjI3oI+QqbCEM/5mIM9AO5Jw==
02-Mar-2023 09:10:06.332 del re-sign ns2.dnssec. 300 IN RRSIG A 13 2 300 20230309211006 20230302080959 35685 dnssec. gzliUistEykm6hpMGY8ForYJewFzaUB4rPOJxHROOupf8jaX+GhbelWU tfcnLKmjypuWEIdyFkGugFpzE/slCA==
02-Mar-2023 09:10:06.332 del re-sign dnssec. 300 IN RRSIG SOA 13 1 300 20230401091006 20230302081006 35685 dnssec. unerVqERet0Xr8KV19/D174G3moa5NVkDoXIbvpc3cPQuzCd/z+eYC2h zuLlEZawAFe2NTI3jw+TDkIgKfpnCw==
02-Mar-2023 09:10:06.332 add dnssec. 300 IN SOA mname1. . 5 20 20 1814400 3600
02-Mar-2023 09:10:06.332 add re-sign dnssec. 300 IN RRSIG NS 13 1 300 20230401084359 20230302081006 35685 dnssec. C+vYMDHLb6wperZxXwTAAK3vM9XJ+7/WAGddPyQcdI+fp6hRXL6UM4hz C5qj8+hnKY0E2bHq1jYLoQaw62M/mw==
02-Mar-2023 09:10:06.332 add re-sign a.dnssec. 300 IN RRSIG NSEC 13 2 300 20230401084359 20230302081006 35685 dnssec. h1X7d4NBfaVyRJnkzcsiyjAZPXufVBgKPw08wxAm8Zx1W8N5Tg0WS2/m Xx6MyytvPoCSFFvFOQLkCXurucZUww==
02-Mar-2023 09:10:06.332 add re-sign a.dnssec. 300 IN RRSIG MX 13 2 300 20230401084359 20230302081006 35685 dnssec. J5uy5bjeXLdt73gV8nv4/dbj+cjOIcyFHuh6Qp/sdqFE/sswo8izCdRU 3/iYmjwLS9EeNs6dEb2xx0l9heRmDg==
02-Mar-2023 09:10:06.332 add re-sign mail.dnssec. 300 IN RRSIG A 13 2 300 20230401084359 20230302081006 35685 dnssec. wCLJPDVyC8ja84GHqaA/OnUrOocpAKNOZiTQJdHJkwkkd0BbVxLazYiP fE2rKG54VIFvGxC/EcXavXcqiFeQEg==
02-Mar-2023 09:10:06.332 add re-sign a.dnssec. 300 IN RRSIG A 13 2 300 20230401084359 20230302081006 35685 dnssec. /BXz8YtxNfEo3tJYFGRHVjMQQDAtzZ8ne2nJOm6CQm3d803qzs5JaHLy /4hmNB5oTEz1l9kXw3LQnB94iuH/yA==
02-Mar-2023 09:10:06.332 add re-sign mail.dnssec. 300 IN RRSIG NSEC 13 2 300 20230401084359 20230302081006 35685 dnssec. QWpfnMgaVTitdgvpdIBTimLxJY+YUPcCvcQcVlnVta8FkmhSxgRhLkRs NGM9H1J5o+4K9uFwso3bSmLTADq1YA==
02-Mar-2023 09:10:06.332 add re-sign ns2.dnssec. 300 IN RRSIG NSEC 13 2 300 20230401084359 20230302081006 35685 dnssec. o/RJ6s2Jcccttnk2PxugOcjnyQ9kX9BfxEu5nKLZglAcaFAl7pnPjhNm 9455gOUH62iNPlxHS3KXrac8HuruIQ==
02-Mar-2023 09:10:06.332 add re-sign ns2.dnssec. 300 IN RRSIG A 13 2 300 20230401084359 20230302081006 35685 dnssec. E59RXGdRykOWp+Oad6UJ6DjIJDJT0vtX326pRcoW54obolq/sc2ZjCha GZk634z/MvcNFHWaQnF2rmtOj0SuGg==
02-Mar-2023 09:10:06.332 add re-sign dnssec. 300 IN RRSIG SOA 13 1 300 20230401091006 20230302081006 35685 dnssec. aSQQxKw8rg8Pbn6bacb22o993cEwzPXchCB9wQM4nLjMWq5VgW5JIQeG Tkz2VIWj9dPCQVRv4xKInZmBjHSwfg==
```
This results in the test detecting extra 9 signature operations which it doesn't expect and thus fails.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3912Updates to DoH +http and +https options for dig2023-03-14T16:16:02ZAlexey ChernyakUpdates to DoH +http and +https options for dig### Description
This is a request for updating DoH options in `dig` by:
1. Adding new options for specifying HTTP `:authority` pseudo-header and/or `Host:` header
2. Adding shorter alternatives to the existing HTTP/2 options.
### Reque...### Description
This is a request for updating DoH options in `dig` by:
1. Adding new options for specifying HTTP `:authority` pseudo-header and/or `Host:` header
2. Adding shorter alternatives to the existing HTTP/2 options.
### Request
**1. New DoH Options**
Add new `+http-authority=value` option to control the HTTP/2 (or HTTP/3) `:authority` pseudo-header within the DoH HTTP request, i.e.:
```
:method = GET
:scheme = https
:authority = dnsserver.example.net
```
Also add new `+http-host=value` option to control the HTTP/1.1 or HTTP/2 or HTTP/3 `Host:` header within the DoH HTTP request, i.e.:
```
:method = GET
:scheme = https
Host: dnsserver.example.net
```
These options are required for 2 use cases:
1. Bootstrapping a DoH query to a `@server` IP address without relying on any additional DNS resolution of the `@server` hostname.
2. Domain Fronting of DoH once issue #3896 implements SNI support in `dig`.
The expected future behaviour is:
* `@server` argument and `-p` option control what server IP address and port `dig` connects to.
* `+tls-sni` option controls what SNI hostname `dig` requests in `ClientHello` during TLS handshake.
* `+http-authority` and `-p` options control what `dig` requests within the HTTP `:authority` pseudo-header.
* `+http-host` and `-p` options control what `dig` requests within the HTTP `Host:` header.
* `+tls-hostname` option controls `dig` validation of certificate returned by `ServerHello` during TLS handshake.
HTTP `:authority` pseudo-header or HTTP `Host:` header should apply regardless of whether or not DoH connection is encapsulated in TLS.
Proposed logic is something along the lines of:
```
if request is DoH (either h2 or h2c)
if +http-authority option is specified
validate option input
HTTPauthority = option value
else if +http-host option is specified
validate option input
HTTPHost = option value
else if @server argument is a hostname
HTTPauthority = argument value
else if +tls-sni option is specified
HTTPauthority = option value
else if +tls-hostname option is specified
HTTPauthority = option value
else
HTTPauthority = server IP address
if +http-host option is specified
validate option input
HTTPHost = option value
if -p option is specified
if HTTPauthority is specified
if HTTPauthority doesn't include :port
HTTPauthority = HTTPauthority + ":" + port
if HTTPHost is specified
if HTTPHost doesn't include :port
HTTPHost = HTTPHost + ":" + port
if HTTPHost and HTTPauthority are specified
if HTTPHost differs from HTTPauthority
error
```
**2. Shorter Alternatives**
The DNSSEC option in `dig` currently has a number of shorter alternatives:
```
+dnssec, +do, +nodnssec, +nodo
```
This request is to add similar shorter standard HTTP/2 `h2` and `h2c` protocol identifier option alternatives to all existing `+http*` options in `dig`.
The proposed changes are outlined in the table below:
| Current | Proposed |
| --- | --- |
| `+https[=value], +nohttps` | `+https[=value], +h2[=value], +nohttps, +noh2 ` |
| `+https-get[=value], +nohttps-get` | `+https-get[=value], +h2-get[=value], +nohttps-get, +noh2-get` |
| `+https-post[=value], +nohttps-post` | `+https-post[=value], +h2-post[=value], +nohttps-post, +noh2-post` |
| `+http-plain[=value], +nohttp-plain` | `+http-plain[=value], +h2c[=value], +nohttp-plain, +noh2c` |
| `+http-plain-get[=value], +nohttp-plain-get` | `+http-plain-get[=value], +h2c-get[=value], +nohttp-plain-get, +noh2c-get` |
| `+http-plain-post[=value], +nohttp-plain-post` | `+http-plain-post[=value], +h2c-post[=value], +nohttp-plain-post, +noh2c-post` |
The use cases for this are:
* Reduction of some options length down to just 30% of the current.
* In the future ability to differentiate them from `+h3*` versions of these options when support for HTTP/3 DoH3 and DoQ is added (e.g. via nghttp3).
### Links / references
For HTTP `:authority` pseudo-header and `Host:` header request see:
* [Section 7.2 of RFC 9110: HTTP Semantics](https://datatracker.ietf.org/doc/html/rfc9110#section-7.2).
* [Section 8.3.1 of RFC 9113: HTTP/2](https://datatracker.ietf.org/doc/html/rfc9113#section-8.3.1).
* [Section 4.3.1 of RFC 9114: HTTP/3](https://datatracker.ietf.org/doc/html/rfc9114#section-4.3.1).
For standard definitions of `h2`, `h2c`, `h3`, `dot` and `doq` protocol identifiers see:
* [TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs](https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids)
* [Section 3.1 of RFC 9113: HTTP/2](https://datatracker.ietf.org/doc/html/rfc9113#section-3.1).
* [Section 11.1 of RFC 9114: HTTP/3](https://datatracker.ietf.org/doc/html/rfc9114#section-11.1).Not plannedArtem BoldarievArtem Boldarievhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3908Follow-up from "Remove TKEY Mode 2 (Diffie-Hellman)"2023-03-01T06:16:51ZOndřej SurýFollow-up from "Remove TKEY Mode 2 (Diffie-Hellman)"The following discussion from !7626 should be addressed:
- [ ] @each started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7626#note_355457): (+5 comments)
> I was wondering if, with `DH` gone, we could...The following discussion from !7626 should be addressed:
- [ ] @each started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7626#note_355457): (+5 comments)
> I was wondering if, with `DH` gone, we could also deprecate some options to `dnssec-keygen` and `-keyfromlabel`, such as `-n` and `-t` and `-T`.
>
> It looks like `-T` (which lets you choose `DNSKEY` vs `KEY` as the rdata type) is still used for SIG(0), so there are `KEY` records that aren't `DH`, so this option can't go away.
>
> Since we still need to be able to set the type to `KEY`, we also still need to be able to set the `KEY` rdata flags field, so `-t` also needs to stay. We don't make any real use of it, none of our tests currently set it, but it seems wrong to make it impossible to set. (Its purpose is to set the flags that indicate whether a key can be used for confidentiality or authentication or both or neither, the default being both.)
>
> `-n` is used for `ZONE` keys or `ENTITY` (aka `HOST`) keys. The function of that is to prevent certain keys from being found when searching for signing keys for a zone. I wonder if it we could just use the rrtype to do that (`DNSKEY` is always zone, `KEY` is always entity)? In any case it's also used for `USER` keys which are never used anywhere in BIND and could definitely go away.
>
> (This should spin off to a separate issue, I'm just writing about it here because I was thinking about it while reviewing this MR.)https://gitlab.isc.org/isc-projects/bind9/-/issues/3906ThreadSanitizer: data race lib/dns/request.c:1020 in req_senddone (v9_18)2023-03-01T16:11:39ZArаm SаrgsyаnThreadSanitizer: data race lib/dns/request.c:1020 in req_senddone (v9_18)TSAN report during the `xferquota` system test on commit 6b7d2df6 (based on `9_18`): https://gitlab.isc.org/isc-projects/bind9/-/jobs/3201521
```
==================
WARNING: ThreadSanitizer: data race (pid=24022)
Read of size 4 at 0x7...TSAN report during the `xferquota` system test on commit 6b7d2df6 (based on `9_18`): https://gitlab.isc.org/isc-projects/bind9/-/jobs/3201521
```
==================
WARNING: ThreadSanitizer: data race (pid=24022)
Read of size 4 at 0x7b44000615a0 by thread T6:
#0 req_senddone /builds/isc-projects/bind9/lib/dns/request.c:1020 (libdns-9.18.13-dev.so+0x1814d3)
#1 send_done /builds/isc-projects/bind9/lib/dns/dispatch.c:2061 (libdns-9.18.13-dev.so+0x68967)
#2 isc__nm_async_sendcb netmgr/netmgr.c:2930 (libisc-9.18.13-dev.so+0x2967b)
#3 isc__nm_sendcb netmgr/netmgr.c:2906 (libisc-9.18.13-dev.so+0x298ec)
#4 udp_send_cb netmgr/udp.c:806 (libisc-9.18.13-dev.so+0x3f9ec)
#5 uv__udp_run_completed /usr/src/libuv-v1.44.1/src/unix/udp.c:155 (libuv.so.1+0x264f2)
#6 isc__trampoline_run /builds/isc-projects/bind9/lib/isc/trampoline.c:189 (libisc-9.18.13-dev.so+0x80114)
Previous write of size 4 at 0x7b44000615a0 by thread T2 (mutexes: write M55023186806375632, write M56149086713218488):
#0 request_cancel /builds/isc-projects/bind9/lib/dns/request.c:889 (libdns-9.18.13-dev.so+0x181130)
#1 dns_request_cancel /builds/isc-projects/bind9/lib/dns/request.c:905 (libdns-9.18.13-dev.so+0x18191b)
#2 dns_requestmgr_shutdown /builds/isc-projects/bind9/lib/dns/request.c:230 (libdns-9.18.13-dev.so+0x181a9b)
#3 view_flushanddetach /builds/isc-projects/bind9/lib/dns/view.c:656 (libdns-9.18.13-dev.so+0x1ed89e)
#4 dns_view_detach /builds/isc-projects/bind9/lib/dns/view.c:716 (libdns-9.18.13-dev.so+0x1ed96f)
#5 ns_client_endrequest /builds/isc-projects/bind9/lib/ns/client.c:246 (libns-9.18.13-dev.so+0x13ceb)
#6 ns__client_reset_cb /builds/isc-projects/bind9/lib/ns/client.c:1621 (libns-9.18.13-dev.so+0x13ceb)
#7 nmhandle_detach_cb netmgr/netmgr.c:1851 (libisc-9.18.13-dev.so+0x279e5)
#8 isc__nm_async_detach netmgr/netmgr.c:2960 (libisc-9.18.13-dev.so+0x2ba57)
#9 process_netievent netmgr/netmgr.c:981 (libisc-9.18.13-dev.so+0x2ba57)
#10 process_queue netmgr/netmgr.c:1013 (libisc-9.18.13-dev.so+0x2bdce)
#11 process_all_queues netmgr/netmgr.c:767 (libisc-9.18.13-dev.so+0x2cb44)
#12 async_cb netmgr/netmgr.c:796 (libisc-9.18.13-dev.so+0x2cb44)
#13 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163 (libuv.so.1+0x1118e)
#14 isc__trampoline_run /builds/isc-projects/bind9/lib/isc/trampoline.c:189 (libisc-9.18.13-dev.so+0x80114)
Location is heap block of size 280 at 0x7b4400061580 allocated by thread T6:
#0 malloc <null> (libtsan.so.2+0x3f618)
#1 mallocx /builds/isc-projects/bind9/lib/isc/jemalloc_shim.h:35 (libisc-9.18.13-dev.so+0x5d262)
#2 mem_get /builds/isc-projects/bind9/lib/isc/mem.c:343 (libisc-9.18.13-dev.so+0x5d262)
#3 isc__mem_get /builds/isc-projects/bind9/lib/isc/mem.c:761 (libisc-9.18.13-dev.so+0x5dfea)
#4 new_request /builds/isc-projects/bind9/lib/dns/request.c:362 (libdns-9.18.13-dev.so+0x17e093)
#5 dns_request_create /builds/isc-projects/bind9/lib/dns/request.c:665 (libdns-9.18.13-dev.so+0x180749)
#6 notify_send_toaddr /builds/isc-projects/bind9/lib/dns/zone.c:12693 (libdns-9.18.13-dev.so+0x211206)
#7 task_run /builds/isc-projects/bind9/lib/isc/task.c:815 (libisc-9.18.13-dev.so+0x745c5)
#8 isc_task_run /builds/isc-projects/bind9/lib/isc/task.c:896 (libisc-9.18.13-dev.so+0x745c5)
#9 isc__nm_async_task netmgr/netmgr.c:848 (libisc-9.18.13-dev.so+0x1fdeb)
#10 process_netievent netmgr/netmgr.c:920 (libisc-9.18.13-dev.so+0x2b0fd)
#11 process_queue netmgr/netmgr.c:1013 (libisc-9.18.13-dev.so+0x2bdce)
#12 process_all_queues netmgr/netmgr.c:767 (libisc-9.18.13-dev.so+0x2cb44)
#13 async_cb netmgr/netmgr.c:796 (libisc-9.18.13-dev.so+0x2cb44)
#14 uv__async_io /usr/src/libuv-v1.44.1/src/unix/async.c:163 (libuv.so.1+0x1118e)
#15 isc__trampoline_run /builds/isc-projects/bind9/lib/isc/trampoline.c:189 (libisc-9.18.13-dev.so+0x80114)
Mutex M55023186806375632 is already destroyed.
Mutex M56149086713218488 is already destroyed.
Thread T6 'isc-net-0005' (tid=24096, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.2+0x5f0e6)
#1 isc_thread_create /builds/isc-projects/bind9/lib/isc/thread.c:73 (libisc-9.18.13-dev.so+0x76b3a)
#2 isc__netmgr_create netmgr/netmgr.c:311 (libisc-9.18.13-dev.so+0x20890)
#3 isc_managers_create /builds/isc-projects/bind9/lib/isc/managers.c:31 (libisc-9.18.13-dev.so+0x5c8f3)
#4 create_managers /builds/isc-projects/bind9/bin/named/main.c:1029 (named+0x427f86)
#5 setup /builds/isc-projects/bind9/bin/named/main.c:1293 (named+0x427f86)
#6 main /builds/isc-projects/bind9/bin/named/main.c:1562 (named+0x427f86)
Thread T2 'isc-net-0001' (tid=24073, running) created by main thread at:
#0 pthread_create <null> (libtsan.so.2+0x5f0e6)
#1 isc_thread_create /builds/isc-projects/bind9/lib/isc/thread.c:73 (libisc-9.18.13-dev.so+0x76b3a)
#2 isc__netmgr_create netmgr/netmgr.c:311 (libisc-9.18.13-dev.so+0x20890)
#3 isc_managers_create /builds/isc-projects/bind9/lib/isc/managers.c:31 (libisc-9.18.13-dev.so+0x5c8f3)
#4 create_managers /builds/isc-projects/bind9/bin/named/main.c:1029 (named+0x427f86)
#5 setup /builds/isc-projects/bind9/bin/named/main.c:1293 (named+0x427f86)
#6 main /builds/isc-projects/bind9/bin/named/main.c:1562 (named+0x427f86)
SUMMARY: ThreadSanitizer: data race /builds/isc-projects/bind9/lib/dns/request.c:1020 in req_senddone
==================
ThreadSanitizer: reported 1 warnings
```Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3897dig IPv6 Simplified Reverse Lookups2023-02-28T06:57:20ZChris Mirchandanidig IPv6 Simplified Reverse Lookups<!--
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 make sure that you make the new issue
confident...<!--
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 make sure that you make the new issue
confidential!
-->
### Summary
When using -x with IPv6 the only address that is accepted is properly handled is a /128. If you try to use an IPv6 notation other than a /128, it assumes the address is an IPv4 address and converts the query value to the IPv4 dotted-decimal notation.
<details><summary>Correct IPv6 Handling for an IPv6 /128</summary>
$ dig +noall +answer +question -x 2607:f3f0:0:b:20c:29ff:fe10:14f8
;8.f.4.1.0.1.e.f.f.f.9.2.c.0.2.0.b.0.0.0.0.0.0.0.0.f.3.f.7.0.6.2.ip6.arpa. IN PTR
8.f.4.1.0.1.e.f.f.f.9.2.c.0.2.0.b.0.0.0.0.0.0.0.0.f.3.f.7.0.6.2.ip6.arpa. 86360 IN PTR msentry1.njwtech.com.
$ dig +noall +answer +question NS -x 2607:f3f0:0:b:20c:29ff:fe10:14f8
;8.f.4.1.0.1.e.f.f.f.9.2.c.0.2.0.b.0.0.0.0.0.0.0.0.f.3.f.7.0.6.2.ip6.arpa. IN NS
</details>
<details><summary>Incorrect Handling for an IPv6 /32</summary>
$ dig +noall +answer +question NS -x 2607:f3f0:0:b
;2607:f3f0:0:b.in-addr.arpa. IN NS
$ dig +noall +answer +question NS -x 2607:f3f0:0:b:
;2607:f3f0:0:b:.in-addr.arpa. IN NS
$ dig +noall +answer +question NS -x 2607:f3f0:0:b::/64
;2607:f3f0:0:b::/64.in-addr.arpa. IN NS
</details>
### BIND version used
$ dig -v
DiG 9.10.6
### Steps to reproduce
<details><summary>Incorrect Handling for an IPv6 /32</summary>
$ dig +noall +answer +question NS -x 2607:f3f0:0:b
;2607:f3f0:0:b.in-addr.arpa. IN NS
$ dig +noall +answer +question NS -x 2607:f3f0:0:b:
;2607:f3f0:0:b:.in-addr.arpa. IN NS
$ dig +noall +answer +question NS -x 2607:f3f0:0:b::/64
;2607:f3f0:0:b::/64.in-addr.arpa. IN NS
</details>
### What is the current *bug* behavior?
If you try to use an IPv6 notation other than a /128, it assumes the address is an IPv4 address and converts the query value to the IPv4 dotted-decimal notation.
### What is the expected *correct* behavior?
Dig should recognize an IPv6 address by looking for a colon and convert what is provided to the nibble format. I think the issue would be recognizing IPs like 234::/16. Using the same format as for IPv4 dig would not be able to distinguish between IPv4 and IPv6 as dig NS -x 234 could be 234.in-addr.arpa. or 4.3.2.0.ip6.arpa. I suggest one of the following options for IPv6.
1) Ending a IPv6 address with a colon like 234: for 4.3.2.0.ip6.arpa., 2607:f8b0: for 0.b.8.f.7.0.6.2.ip6.arpa., etc.
2) Using cider notation like 234::/16 for 4.3.2.0.ip6.arpa., 2607::/32 for 0.0.0.0.7.0.6.2.ip6.arpa., 2607:f8b0::/32 for 0.b.8.f.7.0.6.2.ip6.arpa., etc.
3) Having a dedicated option -X (that's a capital X) for simplified IPv6 reverse lookups.
For more clarity on the expected output for IPv6, with IPv4 address the octets needed to represent a class A, B, or C zone can be entered with -x and dig will convert them to the IPv4 dotted-decimal notation. This is very useful if you are looking for zone level records like SOA, NS, DNSSEC, etc. Dig also accepts RFC 2317 zone names with -x which is useful for every RDNS record type. I have provided some examples below for reference.
<details><summary>Class A Example</summary>
$ dig +noall +answer +question NS -x 8
;8.in-addr.arpa. IN NS
8.in-addr.arpa. 86400 IN NS x.arin.net.
8.in-addr.arpa. 86400 IN NS z.arin.net.
8.in-addr.arpa. 86400 IN NS u.arin.net.
8.in-addr.arpa. 86400 IN NS r.arin.net.
8.in-addr.arpa. 86400 IN NS y.arin.net.
8.in-addr.arpa. 86400 IN NS arin.authdns.ripe.net.
</details>
<details><summary>Class B Example</summary>
$ dig +noall +answer +question NS -x 8.8
;8.8.in-addr.arpa. IN NS
8.8.in-addr.arpa. 3600 IN NS ns2.Level3.net.
8.8.in-addr.arpa. 3600 IN NS ns1.Level3.net.
</details>
<details><summary>Class C Example</summary>
$ dig +noall +answer +question NS -x 216.139.200
;200.139.216.in-addr.arpa. IN NS
200.139.216.in-addr.arpa. 86172 IN NS ns1.esnet.com.
200.139.216.in-addr.arpa. 86172 IN NS ns4.esnet.com.
200.139.216.in-addr.arpa. 86172 IN NS ns2.esnet.com.
200.139.216.in-addr.arpa. 86172 IN NS ns3.esnet.com.
</details>
<details><summary>RFC 2317 NS Example</summary>
$ dig +noall +answer +question NS -x 24.96.81.192-28
;192-28.81.96.24.in-addr.arpa. IN NS
192-28.81.96.24.in-addr.arpa. 528 IN NS ns2.tvaoig.gov.
192-28.81.96.24.in-addr.arpa. 528 IN NS ns3.tvaoig.gov.
</details>
<details><summary>RFC 2317 PTR Example</summary>
$ dig +noall +answer +question -x 24.96.81.192-28.196
;196.192-28.81.96.24.in-addr.arpa. IN PTR
196.192-28.81.96.24.in-addr.arpa. 21586 IN PTR join.tvaoig.gov.
</details>
### Relevant configuration files
N/A
### Relevant logs and/or screenshots
See examples provided above.
### Possible fixes
Not sure...Not plannedhttps://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/3888Resolver under load retransmits even though the authoritative replies promptly2023-03-01T09:35:12ZŠtěpán BalážikResolver under load retransmits even though the authoritative replies promptly### Summary
With enough traffic going to and from BIND 9.18 running as a resolver, some packets from the authoritative (sent well before the 800ms retransmit deadline in packet capture seem) to get _stuck somewhere in BIND_.
### BIND v...### Summary
With enough traffic going to and from BIND 9.18 running as a resolver, some packets from the authoritative (sent well before the 800ms retransmit deadline in packet capture seem) to get _stuck somewhere in BIND_.
### BIND version
```shell
$ ./named -V
BIND 9.18.10 (Stable Release) <id:7011eaf>
```
### Steps to reproduce
1. Start an authoritative server serving this zone on `1.0.0.100` (Knot was used in testing):
```zone
. 86400 IN SOA j.root-servers.net. nstld.verisign-grs.com. 2019072500 1800 900 604800 86400
*. 3600 IN A 1.1.1.1
. 86400 IN NS j.root-servers.net.
```
2. Start BIND 9.18 with this config:
```
options {
listen-on {1.0.0.1; };
listen-on-v6 { };
directory "/tmp/maze-one_server-5y3fes_c/resolver";
recursion yes;
query-source address 1.0.0.1;
dnssec-validation no;
empty-zones-enable yes;
};
zone "." {
type hint;
file "/tmp/maze-one_server-5y3fes_c/resolver/root.hints";
}
```
with hints file:
```
. 3600000 NS J.ROOT-SERVERS.NET.
J.ROOT-SERVERS.NET. 3600000 A 1.0.0.100
```
3. Optional: set up constant delay on authoritative server's answers with `netem` (done in the example below (delay is set to 10ms), but not necessary).
4. Set up traffic capture.
5. Run `dnsperf` as a client to create traffic:
```
dnsperf -d q -Q 5000 -q 10000 -t 10
```
with the file `q` that contains the lines `0. A` to `9999. A`.
6. Inspect the resulting PCAP with Wireshark and filter for long delays on responses to client. This can be achieved with the filter `dns.time > 0.08`.
### Details (current behavior)
This was run as an comparison between `9.16.36`, `9.18.10` and `35e2842` (marked as `main` in the text and images bellow).
There is only one authoritative server in this case and its RTT is set to 10 ms. This was run on a 2-core/4-thread VM with Knot as the authoritative.
The resolution of culprit queries look like this when examined packet by packet:
```
t = 0 ms, client asks the resolver
t = 0+ε ms, resolver asks the authoritative
t = 10 ms, authoritative sends response
t = 800 ms, resolver asks the authoritative again
t = 810 ms, authoritative answers again
t = 810+ε ms, resolver finally answers
```
The delayed responses also appear in chunks pointing to them maybe being stuck in some kind of queue (_looking and you `libuv`_) this can be shown by graphing the response times to client with a sliding window average:
![comparison_sliding_windows.svg](/uploads/6a9eecfb005779a5be4edd6ebdda73ee/comparison_sliding_windows.svg)
Note, that there are no peaks with 9.16.
I also attach the [pcap](/uploads/b172ef4b6d77bfac220ec6e0211c6e3b/result_named-9-18.pcap) of the run with 9.18 for reference.
### Expected behavior
There should be no such retransmits.https://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/3877Support _FORTIFY_SOURCE=32023-02-16T10:57:26ZTony FinchSupport _FORTIFY_SOURCE=3Recent versions of clang, gcc, and glibc support `_FORTIFY_SOURCE=3` which adds support for tracking sizes of allocations at run time in a way that can be checked by `memmove()` and friends. To make use of the new fortification level, al...Recent versions of clang, gcc, and glibc support `_FORTIFY_SOURCE=3` which adds support for tracking sizes of allocations at run time in a way that can be checked by `memmove()` and friends. To make use of the new fortification level, allocation functions need attributes indicating which argument is the size (`__alloc_size__`) and other functions need to tell the compiler which arguments are pointer, size pairs (`__access__`). For more details see https://developers.redhat.com/articles/2023/02/06/how-improve-application-security-using-fortifysource3#Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3876Follow-up from "Resolve "Dig fails to cleanup OpenSSL references""2023-02-17T07:39:57ZMark AndrewsFollow-up from "Resolve "Dig fails to cleanup OpenSSL references""The following discussion from !7535 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7535#note_352479): (+1 comment)
> I was thinking that this code might go into...The following discussion from !7535 should be addressed:
- [ ] @ondrej started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7535#note_352479): (+1 comment)
> I was thinking that this code might go into the library destructor with ease - we just need a single global atomic bool to indicate where we need deinit and add a wrapper with `atomic_compare_exchange()` to the `dst_lib_destroy()`, so it doesn't get run twice. That would solve the de-init for all uses of `dst_lib_init()` (which can't be run from the constructor because of the ENGINE initialization).Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3870OPENSSL_cleanup fails to return all memory2023-03-21T00:21:28ZMark AndrewsOPENSSL_cleanup fails to return all memoryThe following discussions from !7417 should be addressed:
- [ ] @pemensik started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7417#note_345928): (+7 comments)
> But I found current 9.19.8 release does...The following discussions from !7417 should be addressed:
- [ ] @pemensik started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7417#note_345928): (+7 comments)
> But I found current 9.19.8 release does not compile on latest RHEL9 system with FIPS mode enabled. It crashes all programs:
>
> ```
> $ doc/misc/.libs/cfg_test --zonegrammar primary
> zone <string> [ <class> ] {
> type primary;
> ...
> zero-no-soa-ttl <boolean>;
> zone-statistics ( full | terse | none | <boolean> );
> };
> ../../../lib/isc/mem.c:993: REQUIRE(((ctx) != ((void *)0) && ((const isc__magic_t *)(ctx))->magic == ((('M') << 24 | ('e') << 16 | ('m') << 8 | ('C'))))) failed, back trace
> /root/rpmbuild/BUILD/bind-9.19.8/build/doc/misc/../../lib/isc/.libs/libisc-9.19.8.so(+0x2e6c3)[0x7ffff7a2e6c3]
> /root/rpmbuild/BUILD/bind-9.19.8/build/doc/misc/../../lib/isc/.libs/libisc-9.19.8.so(isc_assertion_failed+0x10)[0x7ffff7a2e450]
> /root/rpmbuild/BUILD/bind-9.19.8/build/doc/misc/../../lib/isc/.libs/libisc-9.19.8.so(isc__mem_free+0x91)[0x7ffff7a46741]
> /usr/lib64/ossl-modules/fips.so(+0x15074)[0x7ffff6a0a074]
> /lib64/ld-linux-x86-64.so.2(+0x9f5e)[0x7ffff7fd0f5e]
> /lib64/libc.so.6(+0x574b5)[0x7ffff76574b5]
> /lib64/libc.so.6(on_exit+0x0)[0x7ffff7657630]
> /lib64/libc.so.6(+0x3feb7)[0x7ffff763feb7]
> /lib64/libc.so.6(__libc_start_main+0x80)[0x7ffff763ff60]
> ```
>
> in gdb:
> ```
> (gdb) bt
> #0 0x00007ffff76a154c in __pthread_kill_implementation () from /lib64/libc.so.6
> #1 0x00007ffff7654d46 in raise () from /lib64/libc.so.6
> #2 0x00007ffff76287f3 in abort () from /lib64/libc.so.6
> #3 0x00007ffff7a2e455 in isc_assertion_failed (file=<optimized out>, line=<optimized out>, type=<optimized out>, cond=<optimized out>)
> at ../../../lib/isc/assertions.c:50
> #4 0x00007ffff7a46741 in isc__mem_free (ctx=<optimized out>, ptr=<optimized out>, flags=<optimized out>) at ../../../lib/isc/mem.c:993
> #5 0x00007ffff6a0a074 in cleanup () at providers/fips/self_test.c:170
> #6 0x00007ffff7fd0f5e in _dl_fini () at dl-fini.c:142
> #7 0x00007ffff76574b5 in __run_exit_handlers () from /lib64/libc.so.6
> #8 0x00007ffff7657630 in exit () from /lib64/libc.so.6
> #9 0x00007ffff763feb7 in __libc_start_call_main () from /lib64/libc.so.6
> #10 0x00007ffff763ff60 in __libc_start_main_impl () from /lib64/libc.so.6
> #11 0x0000555555555995 in _start ()
> ```
>
> It seems FIPS mode cleanup is different than normal OpenSSL. It works fine without FIPS mode. But does not even compile under it. Found when trying to test these changes can pass, but haven't even got so far. To be investigated later.
- [ ] @fabled started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/7417#note_347559): (+1 comment)
> > @fabled This might affect the PKCS#11 provider as well.
>
> To some extent yes. But especially the case if using SoftHSMv2 with OpenSSL backend. Then there is circular dependency OpenSSL -> pkcs11-provider -> SoftHSMv2 -> OpenSSL. And care is needed to make sure things are released in right order during exit.