Post #2358493
2026-05-04 07:00 UTC
Replies (3)
-
@phils@chaos.social 2026-05-04 07:58
@Oskar456@mastodon.social @nygren@hachyderm.io True. Feel invited to also give feedback on the DNSOP list alongside with a comment whether you see the need for a draft updating RFC3901bis.
-
@nygren@hachyderm.io 2026-05-04 12:17
@Oskar456@mastodon.social @phils@chaos.social RFC3901bis is clear NOT to put IPv4-mapped IPv6 addresses into AAAA records for this reason. Full current text is: > To maintain name space continuity, every DNS zone MUST be served by at least two authoritative DNS servers providing services via IPv6. To avoid reachability issues, authoritative DNS servers MUST NOT use IPv4-embedded addresses [RFC6052] (including IPv4-Mapped IPv6 addresses and deprecated IPv4-Compatible addresses [RFC4291]) for receiving queries. Furthermore, the delegation configuration of an NS (Resolution of the parent, resolution of sibling domain names, glue) MUST NOT rely on IPv4 connectivity being available.
-
@kasperd@westergaard.social 2026-05-04 18:03
I disagree with the assertion that new applications should avoid IPv4-mapped addresses in general. New applications should be designed with an IPv6-first mentality, by that I mean that one should first decide on what’s a good design if you don’t need to support IPv4 at all. And once you have that design you can decide how to add IPv4 support, and doing so must not compromise the design you want for IPv6. In some situations it will add complexity to listen on two separate sockets. And more complexity increase the risk of bugs including security vulnerabilities. For that reason I think one need to decide on a case-by-case basis what is the best design for a particular application. Mandating a more complex design is not how we get developers to fix the few applications which still lack IPv6 support.