The DNS people think that the network people should fix the network code
so existing DNS resolvers work. While the network people think the DNS
people should fix the DNS resolvers to work with existing network code.
Pick your poison.
By the way, it's not resolvers that need IPv4 literals. It's any
application that connects to IPv4 addresses that are either built into the
code or found through a config or lookup, often not the DNS. I can't tell
you how common that is, but it's not as rare as you mght hope. I also
couldn't tell you the relative difficulty of writing shims and putting
them around connect to an IPv4 address or around DNSSEC validation.
R's,
John
On Sun, 9 Jul 2023, Momoka Yamamoto wrote:
Dear All,
Thank you for your constructive feedback and the rich discussion that has
followed the sharing of the draft. I've taken the time to digest all your
comments.
Concerning the DNS64 breaking DNSSEC issue:
As Philip rightfully pointed out, the inclusion of DNS64 in this draft has
indeed been misleading, and I will amend it by removing references to
DNS64. DNSSEC is an important topic but this proposal doesn't directly
interact with DNS64, hence the DNSSEC issues associated with DNS64 are out
of its scope.
Regarding the specificity of DNS resolvers when RFC7051 exists, there is a
diverse range of opinions on this topic on list, some arguing the necessity
of such documentation and others deeming it redundant. Some considerations
I think are important include:
* A resolver is one of the few applications that have a genuine requirement
to use an IPv4 literal.
* The inability of an iterative resolver to utilize RFC7050 for Pref64
discovery may be worth highlighting.
* While 464XLAT has demonstrated its effectiveness in home networks
supporting various apps and devices, the situation is different for DNS
servers with more uniform tasks. In these cases, executing the translation
within the resolver software could be more efficient.
The process of the iterative resolver creating an IPv4 socket, which is
then translated to an IPv6 packet by the CLAT, is inefficient as it adds an
unnecessary layer of packet translation.
* However, considering instances like Thread and other applications such as
browsers, which already implement the synthesizing function, a draft
dedicated to iterative resolvers may seem repetitive.
Concerning the appropriate Working Group for this draft:
While there is ongoing debate about whether this draft should be adopted or
not, I did not find any strong opinions stating that this draft should be
conducted at DNSOP.
Furthermore, as Med proposed, BCP 91 could be updated, 19 years
post-publication, to include these solutions for IPv6-only networks.
For a more comprehensive and balanced draft, future steps will include
removing references to DNS64 and incorporating both the 464XLAT and Pref64
solutions.
For those unable to transition to 464XLAT promptly, having the resolver
execute the translation will act as an essential bridge. This, however,
does not preclude the consideration of 464XLAT as a potential future
strategy.
This approach aims to provide well-rounded guidance, assisting in better
decision-making.
I look forward to further discussions and appreciate your feedback on these
matters.
Best Regards,
Momoka Y
Regards,
John Levine, [email protected], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
