BIND issues
https://gitlab.isc.org/isc-projects/bind9/-/issues
2024-02-24T07:53:11Z
https://gitlab.isc.org/isc-projects/bind9/-/issues/3792
incoming AXFR sometimes does not close TCP connection
2024-02-24T07:53:11Z
Petr Špaček
pspacek@isc.org
incoming AXFR sometimes does not close TCP connection
### Summary
I've noticed in PCAPs that sometimes BIND does not close TCP connection after successful incoming AXFR. This might cause source port depletion on a busy server.
### BIND version used
* ~"Affects v9.19": 9.19.9 56d7e01
* No...
### Summary
I've noticed in PCAPs that sometimes BIND does not close TCP connection after successful incoming AXFR. This might cause source port depletion on a busy server.
### BIND version used
* ~"Affects v9.19": 9.19.9 56d7e01
* Not reproducible on ~"v9.18" (9.18.11 equivalent, b04ab06) - albeit closing the connection can take more than one second, it happens from the secondary side as expected
* ~"Affects v9.16": (9.16.37, b4a65aaea19762a3712932aa2270e8a833fbde22) - reproducible
Don't ask me how is that possible ...
### Steps to reproduce
1. Configure primary with 100k zones + catalog - can be BIND or Knot DNS (recommended to take BIND out of equation on one side)
2. Configure BIND as secondary for the catalog
3. Start secondary with clean state
### What is the current *bug* behavior?
PCAPs show that sometimes the primary closes hanging connection after primary-side timeout.
### What is the expected *correct* behavior?
Connections are closed as soon as possible.
### Relevant configuration files
#### Primary
* [named.conf](/uploads/863bf85788384d2e4893ea94cc606c89/named.conf)
* [catalog.db](/uploads/c515216922d648acf6065f7a50b36233/catalog.db)
* [empty.db](/uploads/5686c122ffb6fd4eb035bc1b88931e0f/empty.db)
Knot DNS version: [knotd.conf](/uploads/e59561f0b1f2047d348a51303d5a2119/knotd.conf)
#### Secondary
* [named.conf](/uploads/984a16e8322400cc6465b14ca45710ef/named.conf)
### Relevant logs and/or screenshots
* Primary: [primary.log.zst](/uploads/e50efe9e008cd762b3a671245e207b7d/primary.log.zst)
* Secondary: [secondary-for-knotd-conf3000.log.zst](/uploads/e8732553815f19ebf3b483629afd6279/secondary-for-knotd-conf3000.log.zst)
* search for `z19823.test` and look at timestamps
* PCAP: [bindconf3000.pcap.zst](/uploads/86b89c9ddc6d4e1c6066cfd1a997c25b/bindconf3000.pcap.zst)
* search for `tcp.stream eq 37322` in Wireshark to get `z19823.test` transfer
Suspicious conversation from the PCAP, times relative to the previous packet:
|No. | Time | Source | Source Port | Destination | Reply code | Info|
|--- | --- | --- | --- | --- | --- | ---|
|484345 | 0 | 192.0.2.2 | 40571 | 192.0.2.1 | | 40571 → 53 [SYN] Seq=0 Win=64660 Len=0 MSS=1220 SACK_PERM TSval=3661096036 TSecr=0 WS=128|
|484346 | 0,000027 | 192.0.2.1 | 53 | 192.0.2.2 | | 53 → 40571 [SYN, ACK] Seq=0 Ack=1 Win=65232 Len=0 MSS=1220 SACK_PERM TSval=1123290483 TSecr=3661096036 WS=128|
|484347 | 0,000008 | 192.0.2.2 | 40571 | 192.0.2.1 | | 40571 → 53 [ACK] Seq=1 Ack=1 Win=64768 Len=0 TSval=3661096036 TSecr=1123290483|
|511718 | 1,98078 | 192.0.2.2 | 40571 | 192.0.2.1 | | Standard query 0x47aa AXFR z19823.test|
|511719 | 0,000019 | 192.0.2.1 | 53 | 192.0.2.2 | | 53 → 40571 [ACK] Seq=1 Ack=32 Win=65280 Len=0 TSval=1123292464 TSecr=3661098017|
|511724 | 0,000107 | 192.0.2.1 | 53 | 192.0.2.2 | No error | Standard query response 0x47aa AXFR z19823.test SOA <Root> NS invalid SOA <Root>|
|511726 | 0,000009 | 192.0.2.2 | 40571 | 192.0.2.1 | | 40571 → 53 [ACK] Seq=32 Ack=121 Win=64768 Len=0 TSval=3661098017 TSecr=1123292464|
|601979 | 9,49634 | 192.0.2.1 | 53 | 192.0.2.2 | | 53 → 40571 [FIN, ACK] Seq=121 Ack=32 Win=65280 Len=0 TSval=1123301960 TSecr=3661098017|
|602469 | 0,040942 | 192.0.2.2 | 40571 | 192.0.2.1 | | 40571 → 53 [ACK] Seq=32 Ack=122 Win=64768 Len=0 TSval=3661107554 TSecr=1123301960|
|621475 | 1,959518 | 192.0.2.2 | 40571 | 192.0.2.1 | | 40571 → 53 [FIN, ACK] Seq=32 Ack=122 Win=64768 Len=0 TSval=3661109514 TSecr=1123301960|
|621476 | 0,000019 | 192.0.2.1 | 53 | 192.0.2.2 | | 53 → 40571 [ACK] Seq=122 Ack=33 Win=65280 Len=0 TSval=1123303961 TSecr=3661109514|
### Possible fixes
May 2024 (9.18.27, 9.18.27-S1, 9.19.24)