Moin,
during the hackathon i gave setting up Unbound 1.18.0 (which implements
the draft already [1]) a shot with Momoka (2a06:d1c7:: if anyone wants
to try; Some ratelimiting present), and we also replayed a couple of DS
zones to resolve the question if 'prefer-ip6: yes' should be set [2].
The observation is that unbound in the current implementation actually
does do happy eyeballs with nat64, i.e., without 'prefer-ip6: yes'
there are indeed queries for v6 capable authoritative servers handled
via nat64 instead of via native IPv6.
I think this opens an interesting can of worms; RFC8305 in not really
(BCP14 level) clear on the matter (other than indicated in [3]); This
is essentially for cases where a client wants to connect to a v4
literal and SHOULD then perform translation; The AUTHNS part does not
use authoritative language.
However, the issue with Unbound (I'd argue) is that the part that does
the HE decision is independent of the part that then does nat64, i.e.,
the HE part assumes v4 connectivity, and does normal HE; However, v6
should be preferred as v6 will not have to go through a transition
mechanism; I see some perspectives on this that could range this in the
area of 'implementation case' though.
All being said, i personally see three options for handling this:
- Accept that NAT64 (also with literals) with HE and DS may lead to
hosts being contacted via a transition technique even though a
native AFI path is available.
- Put a SHOULD/SUGGESTED into draft-ietf-v6ops-ipv6-only-resolver to
only use this with 'prefer-ip6: yes' (or similar depending on the
implementation.
- Think about touching RFC8305; _Technically_ the point above is
already in RFC8305:
"If a DNS server is configured to be accessible over IPv6, IPv6
should be assumed to be the preferred address family."
So, technically, making that should <bcp14>SHOULD</bcp14> would
essentially solve the point above.
Going a bit further, Sec. 7 could be amended to explicitly state that
in cases where NAT64/Other TT are used, IPv6 SHOULD be preferred...
but writing this feels like something far to likely of having
overlooked far too many corner cases and earlier discussions.
With best regards,
Tobias
[1]
https://github.com/NLnetLabs/unbound/pull/722
[2]
https://github.com/NLnetLabs/unbound/pull/722#issuecomment-1497488164
[3]
https://github.com/NLnetLabs/unbound/pull/722#issuecomment-1497823690
--
Dr.-Ing. Tobias Fiebig
T +31 616 80 98 99
M tob...@fiebig.nl
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
