On Thu, Jan 21, 2021 at 05:16:24PM +0100, Florian Obser wrote:
> When unwind(8) learns new autoconf resolvers (from dhcp or router
> advertisements) it checks if a DNS64 is present in this network
> location and tries to recover the IPv6 prefix used according to
> RFC7050.
I noticed that unwind learns autoconf resolvers regardless of "stub" or
"dhcp" being present in unwind.conf:
$ doas rcctl restart unwind
unwind(ok)
unwind(ok)
$ unwind -nv
preference { recursor }
$ unwindctl status autoconf
autoconfiguration forwarders:
SLAAC[trunk0]: fd00::1
$ dig +short @::1 github.com. aaaa
64:ff9b::8c52:7903
This happens without your DNS64 diff already.
So it seems unwind will effectively always synthesize, no matter what
`preference {}' is used.
I also verified that unwind always asks my autoconf resolver for
ipv4only.arpa by using tcpdump and running with this diff
Index: libunbound/dns64/dns64.c
===================================================================
RCS file: /cvs/src/sbin/unwind/libunbound/dns64/dns64.c,v
retrieving revision 1.4
diff -u -p -U0 -r1.4 dns64.c
--- libunbound/dns64/dns64.c 29 Aug 2020 08:22:42 -0000 1.4
+++ libunbound/dns64/dns64.c 24 Jan 2021 07:58:10 -0000
@@ -65 +65 @@
-static const char DEFAULT_DNS64_PREFIX[] = "64:ff9b::/96";
+static const char DEFAULT_DNS64_PREFIX[] = "2001:db9::/96";
Is that intentional?
> The learned autoconf resolvers are then prevented from upgrading to
> the validating state since DNS64 breaks DNSSEC.
>
> unwind(8) can now perform its own synthesis. If a query for a AAAA
> record results in no answer we re-send the query for A and if that
> leads to an answer we synthesize an AAAA answer using the learned
> prefixes.
Using different configurations/preferences has been working just fine
for me in IPv6 only networks, i.e. unwind properly picks up the DNS64
prefix (if for example changed with unbound.conf(5)'s `dns64-prefix').
