BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2024-03-01T09:52:29Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3992The XFR unreachable cache redesign2024-03-01T09:52:29ZOndřej SurýThe XFR unreachable cache redesignThe unreachable cache for **dead primaries** was added to BIND 9 in 2006 via 1372e172d0e0b08996376b782a9041d1e3542489. It features a 10-slot LRU array with 600 seconds (10 minutes) fixed delay. During this time, any primary with a hicc...The unreachable cache for **dead primaries** was added to BIND 9 in 2006 via 1372e172d0e0b08996376b782a9041d1e3542489. It features a 10-slot LRU array with 600 seconds (10 minutes) fixed delay. During this time, any primary with a hiccup would be blocked for the whole block duration (unless overwritten by a different dead primary).
One can argue:
- 10 minutes is too long for a fixed, non-configurable delay
- 10 slots are not enough - servers could be running 1M and more zones with different primaries; and especially in situations like these, there's a high chance that more primaries would be having problems
I think this needs a redesign, but meanwhile - I think that we can drop the `UNREACH_HOLD_TIME` to something like 10 seconds (or 60?) - this should still prevent a thundering herd over the unresponsive server, but the recovery is going to be much faster.Not plannedhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3987Change DNSKEY TTL of inline-signed zone2024-02-24T07:55:08ZGerald VogtChange DNSKEY TTL of inline-signed zone### Description
I have a few zones using inline-signing which I have set up originally with 2d TTL. Due to this the existing DNSKEY RRs also have 2d TTL. Now I have been trying to reduce the TTL to 1d but it seems there is no supported ...### Description
I have a few zones using inline-signing which I have set up originally with 2d TTL. Due to this the existing DNSKEY RRs also have 2d TTL. Now I have been trying to reduce the TTL to 1d but it seems there is no supported way or tool to do so.
I have set dnskey-ttl to 1d and replace keys, still all DNSKEY RRs have 2d TTL. Setting it on the key with dnssec-settime doesn't help either and man pages specifically mention:
```
This option sets the default TTL to use for this key when it is converted into a DNSKEY RR.
This is the TTL used when the key is imported into a zone, unless there was already a DNSKEY
RRset in place, in which case the existing TTL takes precedence.
```
Running AlmaLinux 9 bind-9.16.23-5.el9_1.x86_64.
### Request
Add some way to change the TTL of DNSKEY RRs in inline-signed zones.
### Links / references
I have found a thread from 2016 about the same problem: https://www.mail-archive.com/bind-users@lists.isc.org/msg23186.htmlMay 2024 (9.18.27, 9.18.27-S1, 9.19.24)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/3979filter-aaaa plugin should mark replies it modified2023-03-30T14:17:02ZPetr Menšíkfilter-aaaa plugin should mark replies it modified### Description
Some network administrators choose to filter out AAAA queries on their legacy-only IPv4 networks. I do not think this is the best approach, but it should be possible to identify when a response were modified by filter-AA...### Description
Some network administrators choose to filter out AAAA queries on their legacy-only IPv4 networks. I do not think this is the best approach, but it should be possible to identify when a response were modified by filter-AAAA (or filter-A) query plugin.
I think the primary change should be in end devices to not ask unnecessary queries, not server blocking them. But it seems the only supported way in case AAAA queries generates costly traffic. No alternative system-wide way to reduce unnecessary queries does not seem to be supported.
### Request
I think Extended DNS Codes are ideal for small notice this not original response forwarded, but something created locally. But current plugins to not use any authority section nor EDE codes. Unless I can validate the response via DNSSEC, I have no way to say whether the address does not exist. Or just the network provider does not want me to try connecting there or just forward AAAA queries.
Unless the administrator wants to hide his change, I think named should mark synthetized empty response by indication this is not a reply from authoritative server itself. I haven't found a good matching EDE code for this use case in [RFC 8914](https://www.rfc-editor.org/rfc/rfc8914.html) or its registry. Should a new one for be allocated?
It seems to be very similar to overriding responses by RPZ rules.
```
# dig example.org @localhost aaaa
; <<>> DiG 9.16.23-RH <<>> example.org @localhost aaaa
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31531
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: fc6601cf1f17184a010000006425996e453f0431ac31b8e4 (good)
;; QUESTION SECTION:
;example.org. IN AAAA
;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Thu Mar 30 10:15:10 EDT 2023
;; MSG SIZE rcvd: 68
```
### Links / references
- Proposal to limit sent queries from clients - https://bugzilla.redhat.com/show_bug.cgi?id=2182745https://gitlab.isc.org/isc-projects/bind9/-/issues/3958Adjust default tcp-clients value upward2023-09-12T09:09:13ZVicky Riskvicky@isc.orgAdjust default tcp-clients value upwardThe default for tcp-clients is set at 150. As more users are now supporting encrypted DNS, which sessions use TCP, it is likely that the % of overall DNS sessions using TCP will increase, and the current default quota will be too low for...The default for tcp-clients is set at 150. As more users are now supporting encrypted DNS, which sessions use TCP, it is likely that the % of overall DNS sessions using TCP will increase, and the current default quota will be too low for many users.
Although it is impossible to determine the ideal setting for all users, it seems likely that users who need to limit TCP sessions can support at least an order of magnitude more sessions, like maybe 2,000.
If we are very worried about impacting small-system users of BIND, perhaps we could just change the setting for BIND -S, which is not available to hobbyists?https://gitlab.isc.org/isc-projects/bind9/-/issues/3954Forwarding mode has unnecessary overhead2023-03-21T12:53:25Zshipei.xuForwarding mode has unnecessary overheadIn forwarding mode, when the domain name has a cname record, bind will send multiple requests to the target server. Even if the response obtained by the first forwarding request is already the final result.
For example:
- DomainA cname D...In forwarding mode, when the domain name has a cname record, bind will send multiple requests to the target server. Even if the response obtained by the first forwarding request is already the final result.
For example:
- DomainA cname DomainB
- DomainB cname DomainC
- DomainC A 1.1.1.1
In this example, bind will send three forwarding requests, the first request for DomainA's A record,and then get the final result of all above. The second request for DomainB's A record, and the third time for DomainC's A record. I think this is causing unnecessary overhead. Why is it designed this way?Not plannedhttps://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.