>Synopsis: unwind ignores 'force' directive for home.arpa
>Category: system
>Environment:
System : OpenBSD 7.2
Details : OpenBSD 7.2-current (GENERIC.MP) #1015: Thu Feb 2
06:25:57 MST 2023
[email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Architecture: OpenBSD.amd64
Machine : amd64
>Description:
Nameserver 10.0.1.1 provides the zone home.arpa on my network, and I
would like unwind to forward requests for home.arpa and its subdomains
to 10.0.1.1.
unwind.conf(5) claims in its last example that I can force unwind(8) to
use this forwarder to resolve home.arpa and its subdomains using a
stanza 'force forwarder { home.arpa }'. Unexpectedly, unwind serves
libunbound's default static, empty home.arpa zone instead of forwarding
the request to the name server. Adding the 'bogus' keyword does not
change this behaviour.
>How-To-Repeat:
Create /etc/unwind.conf with the following contents:
forwarder { 10.0.1.1 }
force accept bogus forwarder { home.arpa }
preference { forwarder }
Start unwind with verbose debugging:
# unwind -d -vvv
Attempt to lookup a name in the home.arpa zone:
$ nslookup asteria.home.arpa
Observe that unwind does not forward the request to the forwarder, but instead
uses libunbound's static local zone:
----------8<----------------------
from: [127.0.0.1]:2489
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 57138
;; flags: rd ; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
asteria.home.arpa. IN A
;; ANSWER SECTION:
;; AUTHORITY SECTION:
;; ADDITIONAL SECTION:
;; MSG SIZE rcvd: 35
[127.0.0.1]:2489: asteria.home.arpa. IN A ?
find_force: asteria.home.arpa. -> home.arpa.[forwarder]
try_next_resolver[+0ms]: forwarder[validating] asteria.home.arpa. IN A
[1675711613] libunbound[3896:0] debug: using localzone home.arpa. static
resolve_done[forwarder]: asteria.home.arpa. IN A rcode: NXDOMAIN[3], elapsed:
0ms, running: 1
find_force: asteria.home.arpa. -> home.arpa.[forwarder]
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 0
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; QUESTION SECTION:
asteria.home.arpa. IN A
;; ANSWER SECTION:
;; AUTHORITY SECTION:
home.arpa. 10800 IN SOA localhost. nobody.invalid. 1 3600 1200
604800 10800
;; ADDITIONAL SECTION:
; EDNS: version: 0; flags: do ; udp: 1232
;; MSG SIZE rcvd: 105
from: [127.0.0.1]:2489
;; ->>HEADER<<- opcode: QUERY, rcode: NXDOMAIN, id: 57138
;; flags: qr aa rd ra ; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
asteria.home.arpa. IN A
;; ANSWER SECTION:
;; AUTHORITY SECTION:
home.arpa. 3600 IN SOA localhost. nobody.invalid. 1 3600 1200
604800 10800
;; ADDITIONAL SECTION:
;; MSG SIZE rcvd: 94
----------8<----------------------
In case it matters, also observe that the name server correctly serves the
desired name:
----------8<----------------------
$ dig asteria.home.arpa @10.0.1.1
; <<>> dig 9.10.8-P1 <<>> asteria.home.arpa @10.0.1.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35815
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;asteria.home.arpa. IN A
;; ANSWER SECTION:
asteria.home.arpa. 60 IN A 10.0.1.103
;; Query time: 12 msec
;; SERVER: 10.0.1.1#53(10.0.1.1)
;; WHEN: Mon Feb 06 14:20:12 EST 2023
;; MSG SIZE rcvd: 62
----------8<----------------------
