24 Bře
2024
24 Bře
'24
5:34
debian 12
# uname -a
Linux rip.psg.com 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01)
x86_64 GNU/Linux
# knotc --version
knotc (Knot DNS), version 3.2.6
AXFR of a 750k zone from seattle to, lebanon, europe, iceland, southern
africa, ...) fails over v5 and v6, i.e. somewhat larger rtt
same AXFR seattle seattle or seattle to ashburn works v4 and v6.
seattle to dallas v4 good, v6 fails, but it smells of an HE.net hop.
when it fails, it is always within a hundred or so mytes of the same
place, approximately 10% through the file.
pcap of seattle->beirut at https://archive.psg.com/240323.beirut.pcap
the last payload is in frame 217. at 219, seattle (b) sends a
FIN/PSH/ACK. then at 251, after acking everything, beirut (nabil)
FIN/ACKs seattle's FIN and we're dead.
i am not positive this is the key question as my tcp fu is a bit rusty.
but why did seattle send the FIN at 219, 10% through the file?
randy
24 Bře
24 Bře
9:15
hi Randy,
Mar 24, 2024 05:35:11 Randy Bush <randy(a)psg.com>om>:
debian 12
# uname -a
Linux rip.psg.com 6.1.0-18-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.76-1 (2024-02-01)
x86_64 GNU/Linux
# knotc --version
knotc (Knot DNS), version 3.2.6
AXFR of a 750k zone from seattle to, lebanon, europe, iceland, southern
africa, ...) fails over v5 and v6, i.e. somewhat larger rtt
same AXFR seattle seattle or seattle to ashburn works v4 and v6.
seattle to dallas v4 good, v6 fails, but it smells of an HE.net hop.
when it fails, it is always within a hundred or so mytes of the same
place, approximately 10% through the file.
pcap of seattle->beirut at https://archive.psg.com/240323.beirut.pcap
the last payload is in frame 217. at 219, seattle (b) sends a
FIN/PSH/ACK. then at 251, after acking everything, beirut (nabil)
FIN/ACKs seattle's FIN and we're dead.
i am not positive this is the key question as my tcp fu is a bit rusty.
but why did seattle send the FIN at 219, 10% through the file?
I have experienced the same some time ago and I think this is what you need to tune:
https://www.knot-dns.cz/docs/3.3/singlehtml/#tcp-io-timeout
(for 3.2 there might be differences in the names of these options; the developers suggest
to use their debian repo https://pkg.labs.nic.cz/doc/?project=knot-dns)
Regards,
Tamás
17:45
i am not
positive this is the key question as my tcp fu is a bit rusty.
but why did seattle send the FIN at 219, 10% through the file?
I have experienced the same some time ago and I think this is what you
need to tune:
https://www.knot-dns.cz/docs/3.3/singlehtml/#tcp-io-timeout 
19:11
On 3/24/24 17:45, Randy Bush wrote:
omg!
it's shipped by default not being able to run reliably on the internet
and has no big "before you open this" warning on the box? it has cost
me days, and cost other folk hours.
If you enabled debug logging, you would see the connection is closed due to IO timeout.
A high timeout value has other disadvantages. That's why it's configurable!
i am not positive this is the key question as my tcp
fu is a bit rusty.
but why did seattle send the FIN at 219, 10% through the file?
I have experienced the same some time ago and I think this is what you
need to tune:
https://www.knot-dns.cz/docs/3.3/singlehtml/#tcp-io-timeout
i really appreciate the pointer and i have adjusted `tcp-io-timeout:
2000`, as i see no advice on tuning it to run on the internet.
randy, now wondering what other traps await
--
19:38
it's
shipped by default not being able to run reliably on the internet
and has no big "before you open this" warning on the box? it has cost
me days, and cost other folk hours.
If you enabled debug logging, you would see the connection is closed
due to IO timeout. A high timeout value has other disadvantages.
That's why it's
configurable!
while i appreciate the vuln, and appreciate that it is tunable, a
default which does not work on the intertubes and no prominent warning
is, imiho, not reasonable. to quote one of the old dns dogs who was one
of the victims of this little adventure
defaulting to 500ms" and apply it to both outgoing zone transfers
and all other "normal" queries carried over TCP for a non-hidden
publishing primary name server distributing non-trivial-sized zone
files to secondaries which are geographically widely distributed
seems like a recipe for disaster.
randy
19:47
btw, what is a reasonably safe value for `tcp-io-timeout` to run on the
global internet? i am giving 2000 a shot and it seems ok for the set of
servers we have for this cctld.
randy
20:26
Mar 24, 2024 19:47:45 Randy Bush <randy(a)psg.com>om>:
btw, what is a reasonably safe value for
`tcp-io-timeout` to run on the
global internet? i am giving 2000 a shot and it seems ok for the set of
servers we have for this cctld.
My understanding is that tcp-io-timeout should be bigger than your rtt so if you set 1.5 -
2x you should be fine.
Regards,
Tamás
20:32
btw, what is a
reasonably safe value for `tcp-io-timeout` to run on the
global internet? i am giving 2000 a shot and it seems ok for the set of
servers we have for this cctld.
My understanding is that tcp-io-timeout should be bigger than your rtt
so if you set 1.5 - 2x you should be fine.
34
days inactive
34
days old
7 comments
3 participants
participants (3)
-
Csillag Tamás -
Daniel Salzman -
Randy Bush