On Sun, Jan 24, 2021 at 09:35:26AM +0100, Klemens Nanni wrote:
> 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
Yes, the config is present, it's just not being used.
You can also define forwarders or DoT forwarders and not use them.
> $ dig +short @::1 github.com. aaaa
> 64:ff9b::8c52:7903
>
> This happens without your DNS64 diff already.
This does not make any sense, is your gateway intercepting DNS
queries?
>
> 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
Yes, that's intentional. That's how it learns the NAT64 prefix.
They way NAT64/DNS64 is normally setup is that the gateway performes
NAT64 and Router Advertisements contain nameservers that perform
DNS64. So we ask those for a name that is known to not have a AAAA
record to force them to perform synthesis.
As in, we have to ask those, we can't just do our own recurion and
hope that someone intercepts our query. See check_dns64, that
intentionally uses ASR to learn the prefix.
>
> 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?
that code is not being used.
>
> > 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').
>
So are you saying this works or does not? It kinda sounds like you
claim it already worked without the diff?
--
I'm not entirely sure you are real.
