yup, OK
On 2024 Feb 24 (Sat) at 03:18:34 +0100 (+0100), Einfach Jemand wrote:
:Hiya,
:
:when working with my OpenBSD-Laptop (running OpenBSD 7.4-current (GENERIC.MP)
:#1667: Wed Feb 7 20:09:35 MST 2024) using unwind in a large customer network
:and having problems resolving some PTRs from 18.172.in-addr.arpa but not from
:168.192.in-addr.arpa (and verifying that the customers DNS resolved the PTRs
:from 18.172.in-addr.arpa when queried directly) I checked
:/usr/src/sbin/unwind/resolver.c and probably found the issue. The patch below
:follows unbounds util/as112.c.
:
:Compiling unwind with the patch applied I had no more problems resolving
:PTRs from 20.172.in-addr.arpa.
:
:Bye,
:rru142
:
:Index: resolver.c
:===================================================================
:RCS file: /cvs/src/sbin/unwind/resolver.c,v
:diff -u -p -u -p -r1.163 resolver.c
:--- resolver.c 14 Dec 2023 09:59:27 -0000 1.163
:+++ resolver.c 24 Feb 2024 01:44:51 -0000
:@@ -236,6 +236,20 @@ static const char * const forward_trans
: /* RFC1918 */
: "10.in-addr.arpa. transparent",
: "16.172.in-addr.arpa. transparent",
:+ "17.172.in-addr.arpa. transparent",
:+ "18.172.in-addr.arpa. transparent",
:+ "19.172.in-addr.arpa. transparent",
:+ "20.172.in-addr.arpa. transparent",
:+ "21.172.in-addr.arpa. transparent",
:+ "22.172.in-addr.arpa. transparent",
:+ "23.172.in-addr.arpa. transparent",
:+ "24.172.in-addr.arpa. transparent",
:+ "25.172.in-addr.arpa. transparent",
:+ "26.172.in-addr.arpa. transparent",
:+ "27.172.in-addr.arpa. transparent",
:+ "28.172.in-addr.arpa. transparent",
:+ "29.172.in-addr.arpa. transparent",
:+ "30.172.in-addr.arpa. transparent",
: "31.172.in-addr.arpa. transparent",
: "168.192.in-addr.arpa. transparent",
:
--
Outside of a dog, a book is a man's best friend: and inside a dog,
it's too dark to read.
-- Groucho Marx
