On Sun, Jan 24, 2021 at 10:14:22AM +0100, Florian Obser wrote:
> 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?
To be clear, "happens already" was specific to the config being
present/shown but not used.
Regarding my network: No, not at all. My gateway does NAT64 and DNS64
without any interception, `divert-to' or whatever.
What I'm seeing here is that unwind forwards the very first query to my
gateway (learned via SLAAC), that one succeeds, but all successive AAAA
queries of A only domains do not work... that's what makes the query in
my previous mail work. I can always reproduce it like that:
$ doas rcctl restart unwind
unwind(ok)
unwind(ok)
$ dig +noall +question +answer github.com aaaa
;github.com. IN AAAA
github.com. 44 IN AAAA 64:ff9b::8c52:7904
$ dig +noall +question +answer github.com aaaa
;github.com. IN AAAA
Here's the output of `unwind -dv' (with 'udp connect failed' log spam
for IPv4 addresses removed):
check_resolver_done: dhcp: unknown
check_resolver_done: stub: unknown
check_resolver_done: oDoT-dhcp rcode: SERVFAIL
check_resolver_done: recursor: unknown
[127.0.0.1]:22827: github.com. IN AAAA ?
try_next_resolver[+0ms]: recursor[validating] github.com. IN AAAA
try_next_resolver[+6ms]: dhcp[validating] github.com. IN AAAA
try_next_resolver[+6ms]: stub[resolving] github.com. IN AAAA
try_next_resolver: could not find (any more) working resolvers
resolve_done[stub]: github.com. IN AAAA rcode: NOERROR[0], elapsed:
1ms, running: 1
check_resolver_done: oDoT-dhcp rcode: SERVFAIL
[127.0.0.1]:5226: github.com. IN AAAA ?
try_next_resolver[+0ms]: dhcp[validating] github.com. IN AAAA
resolve_done[dhcp]: github.com. IN AAAA rcode: NOERROR[0], elapsed:
0ms, running: 1
> >
> > 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.
Asking because my assumption was that, if I don't configured `stub' or
`dhcp' in unwind.conf, the NAT64 would/should not be discovered.
As in: Why does unwind do LAN specific DNS64 synthesis if I told it not
to use any LAN specific resolvers.
I'll assume my logic is flawed here.
> 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.
Sure, that makes sense; see above.
I assumed unwind would not do DNS64 at all in cases like
`preference { resolver }'.
