On Sun, Jan 24, 2021 at 11:12:49AM +0100, Klemens Nanni wrote:
> 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
>
Are you sure you are running with the config you think you are running
with? I can not reproduce and from the logging, especially the
check_resolver_done bits it very much looks like you are running
without any config at all.
$ obj/unwind -nvf ./unwind.conf
preference { recursor }
$ doas obj/unwind -dvf ./unwind.conf
check_resolver_done: recursor: unknown
[::1]:39989: ripe.net. IN AAAA ?
try_next_resolver[+0ms]: recursor[validating] ripe.net. IN AAAA
try_next_resolver: could not find (any more) working resolvers
resolve_done[recursor]: ripe.net. IN AAAA rcode: NOERROR[0], elapsed: 403ms,
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.
[...]
> I assumed unwind would not do DNS64 at all in cases like
> `preference { resolver }'.
I don't know. So you find yourself in a IPv6 only network which does
provide a NAT64 service, you'd rather not be able to reach IPv4-only
services?
Note that from the point of view of DNS you are talking to the right
destination, we will only do synthesis if we are not receiving a bogus
answer.
>From my point of view detecting presence of NAT64 and doing synthesis
is independent of the resolving strategy preference. We are not asking
dhcp or the stub to do resolving, we fire up one query to detect the
NAT64 prefix.
Are you saying you need to switch to turn off DNS64, or is it fine
like this and you were just surprised?
--
I'm not entirely sure you are real.
