Hi Nathaniel, On Sat, Aug 19, 2023 at 05:34:00PM +0100, Nathaniel Filardo wrote: > DNS absolutely can and does
I mean I can (and used to) enter fe80::/64 link local addressess into DNS but it turns out this is actually forbidden by the RFCs but nothing will stop you. I'm not convinced putting ::ffff: into DNS is a legitimate use-case given that it it entirely up to an application whether it uses the IPV6_V6ONLY socket option or dual-stack sockets instead as you've noticed. This is supported by my reading of RFC4038. I checked RFC4291/5156 for mentions of how IPv4-mapped v6 addresses are to be treated but they don't mention any restrictions. So I guess it's up to us to decide whether it's a legitimate use-case or not. Unless anyone else has a reference to the contrary? > In my use case they arise because I have scripts that take wireguard peer > addresses and register them with my DNS service provider, and it's > simpler to update a single AAAA record per peer regardless of address > family than it is to switch between having an AAAA and A record for the > name. > > At the very least, the radio silence after the kernel accepts a > v4-mapped v6 address is unexpected behavior. Not really, in networking traffic black holes are pretty common. I'd expect the ::ffff:0.0.0.0/96 traffic to get sent via the default route and being filtered somewhere. Expected behaviour, some people might want to use ::ffff:0.0.0.0/96 as their NAT64 prefix for example. Though that might be ill advised when a standardized local prefix exists ;) > More generally, I don't see what good setting the v6only flag here is > doing (in fact, that's true in general; there are very few > circumstances, and most of those are for *listening* sockets, where > v6only seems remotely sensible; the v4 to v6 migration is such a > mess), so "the established wg behavior" makes no sense to me. What you're probably not seeing is that there's a technical reason wg doesn't use a single socket: The code currently supports CONFIG_IPV6 not being set, so then it can't rely on being able to create a v6 socket! The way it's written it's just easier to have two sockets and not switch between v4-only and v6-mapped sockets. I'm a IPv6-only-or-bust kind of guy so IMO we should just mandate CONFIG_IPV6 and get rid of a whole bunch of legacy IPv4 code (yey), but eh. someones probably going to complain about code-size for their v4-only legacy use-case then :] > (It's also plausibly true that I'm the first to *notice* this aspect > of the established behavior!) You're not, I noticed too when I was working-around the lack of the AddressFamily= option with a PostUp= script using `getent ahostsv6` and while the additional `| sed -n '/^::ffff:/d;s/\s*DGRAM.*$//p'` pushed the PostUp= line over 80 characters I don't consider it an overly onerous requirement :) > In any case, in decreasing order of preference, I'd suggest: > 1. Drop the v6only flag on peer sockets and allow the kernel speak to > v4-mapped v6 addresses. > 2. I missed something and v6only does serve a purpose; add special > handling for v4-mapped v6 addresses to the wg kernel interface, > bending them into v4 sockaddrs internally. > 3. For some reason 2 isn't acceptable either, so add special handling > to the wg userspace tools and do the transmogrification there. > 4. For some reason none of that is tolerable, so have the kernel > reject v4-mapped v6 addresses rather than silently accept them and > fail to speak. I don't like any of those. The way I see it your DynDNS approach is broken please use the appropriate rrtype for each address-family. Note my opinion is not authoritive here, Jason likely has the final say or, recently, more likely lack of say ;) In userspace we ask getaddrinfo() not to return v4-mapped addressess by having AI_V4MAPPED unset, unfortunately this doesn't work when you enter those addresses into DNS (a libc bug perhaps? *hint* *hint*). I would suggest filtering them on our side if they get returned anyway and emitting a warning so this is less of a stumbling block for the next poor soul. I do wonder what the behavoir of the other wg implementations is on this point, if it's inconsistent with the kernel impl. that's even more reason to warn about it. --Daniel
