summaryrefslogtreecommitdiff
path: root/net-dns/djbdns/files/djbdns-udp-overflow-response-buffer-truncate-v6.patch
diff options
context:
space:
mode:
authorJaco Kroon <jaco@uls.co.za>2024-05-27 16:37:52 +0200
committerViorel Munteanu <ceamac@gentoo.org>2024-05-27 18:08:30 +0300
commitb938f9f9a917d3bacb73ef914c371dfc5f2d8ebe (patch)
tree1e3f7b51ca2a6650c6cec704612a9f05d51bdb15 /net-dns/djbdns/files/djbdns-udp-overflow-response-buffer-truncate-v6.patch
parent208c21eb43eac8c92ce6d9d47f3a2974b000ffdc (diff)
downloadgentoo-b938f9f9a917d3bacb73ef914c371dfc5f2d8ebe.tar.gz
gentoo-b938f9f9a917d3bacb73ef914c371dfc5f2d8ebe.tar.bz2
gentoo-b938f9f9a917d3bacb73ef914c371dfc5f2d8ebe.zip
net-dns/djbdns: 1.05-r40
Work around local receive overflow bug. Bug: https://bugs.gentoo.org/932846 Signed-off-by: Jaco Kroon <jaco@uls.co.za> Closes: https://github.com/gentoo/gentoo/pull/36841 Signed-off-by: Viorel Munteanu <ceamac@gentoo.org>
Diffstat (limited to 'net-dns/djbdns/files/djbdns-udp-overflow-response-buffer-truncate-v6.patch')
-rw-r--r--net-dns/djbdns/files/djbdns-udp-overflow-response-buffer-truncate-v6.patch34
1 files changed, 34 insertions, 0 deletions
diff --git a/net-dns/djbdns/files/djbdns-udp-overflow-response-buffer-truncate-v6.patch b/net-dns/djbdns/files/djbdns-udp-overflow-response-buffer-truncate-v6.patch
new file mode 100644
index 000000000000..bf55e7dd86df
--- /dev/null
+++ b/net-dns/djbdns/files/djbdns-udp-overflow-response-buffer-truncate-v6.patch
@@ -0,0 +1,34 @@
+Deal with local recv() truncation.
+
+In the case where an upstream cache sends a UDP response that would overflow
+the djb cache's default receive buffer, then djbdns would treat this as an
+invalid response. The norm nowadays is the send >512b UDP responses,
+especially for TXT RRs. It looks like up to around 4KB is deemed acceptable in
+most cases I've investigated.
+
+So, in the case where we locally end up reciving a truncated packet by way of
+recv() because the local UDP buffer is too small, treat that like the TC bit
+was set, because really we can know the response was truncated.
+
+Therefor check the irrelevant (inappropriate response) data first, then if the
+buffer was fully received (it might be that the response fits exactly, but
+short of parsing this buffer there is no simple way to confirm this, so just
+assume it's unlikely to get an exact sized buffer back and retry using TCP
+anyway). Yes, this is a waste of resources in this specific case, but so be
+it.
+
+Signed-off-by: <jaco@uls.co.za>
+
+--- djbdns-1.05.o/dns_transmit.c 2024-05-27 13:20:25.788463090 +0200
++++ djbdns-1.05/dns_transmit.c 2024-05-27 14:13:38.786335627 +0200
+@@ -266,9 +266,9 @@
+ if (errno == error_connrefused) if (d->udploop == 2) return 0;
+ return nextudp(d);
+ }
+- if ((size_t)r + 1 > sizeof udpbuf) return 0;
+
+ if (irrelevant(d,udpbuf,r)) return 0;
++ if ((size_t)r + 1 > sizeof udpbuf) return firsttcp(d); /* if udp overflowed, retry with TCP */
+ if (serverwantstcp(udpbuf,r)) return firsttcp(d);
+ if (serverfailed(udpbuf,r)) {
+ if (d->udploop == 2) return 0;