what the hell is a "right to foss" exactly? also, the only thing my proposed change does is encode something that is already a fact: mixing musl and glibc runtimes results in an unstable system.
Conversation
it's not pointless complaining when you're the one who gets to deal with the pile of shit some "consultant" created 2 years from now.
1
11
perhaps instead of replying to every post on hacker news with the same thing, because you can't take that a trans girl on the internet wrote about mixing alpine and glibc, you should try reading my post.
4
11
this is actually a point of contention in the alpine community, and we're working on a solution for it, but the best thing developers can (and should) do is use a proper DNS library instead of getaddrinfo(3)
4
15
Replying to
I don't see how that solves anything. You can't expect users to use a nonstandard library in their software. The solution available that works just fine right now is switching to a nonbroken (not Google) recursive, or running caching (+validating 👍) nameserver on ::1.
4
3
I think the nicest setup would be shipping with a minimal unbound as a forwarding-only caching resolver automatically using the DNS servers from DHCP/SLAAC.
It'd be nice to have opportunistic DoT by default like AOSP too but I don't think unbound can enable it automatically yet.
1
2
DANE TLSA isn't being broadly adopted outside of mail servers yet but it has momentum going now. SSHFP records are also really nice and available today. I always set up ed25519 sha256 SSHFP record for each server with zeroed ones for names that aren't meant to be used with SSH.
1
1
It's also nice to have a separate process for all this complexity so it can be contained separately from applications.
There's little downside to a shared local resolver/cache since everyone is just using a caching resolver over the network anyway.
1
1
systemd has these features via systemd-resolved. I always replace it with unbound on systemd distributions but their implementation isn't that bad anymore.
It would be nice if non-systemd distributions kept up and started providing DNSSEC and the other advantages of this too.
1
1
systemd still defaults to DNSSEC=allow-downgrade because it's broken for a lot of clients. It's rarely ever broken on servers though. I think for Alpine, it wouldn't be particularly disruptive to deploy enforcing DNSSEC by default. Really not that bad for clients overall anyway.
1
1
I think users on Alpine, Arch, etc. can be expected to figure out if they have a network breaking DNSSEC and either fix the network or use DoT to bypass it.
Harder to get deployed for distributions aimed at less technical people because DNSSEC is broken for ~1% or so of clients.
Especially for something like AOSP, it's hard for them to ship DNSSEC without limiting it to only being active when DoT/DoH is being used. IMO, that's how it should get deployed by default for most users.
Opportunistic DoT + use DNSSEC when DoT is used + easy way to force DoT.
1
1
And if stuff like Arch, Alpine, etc. starts enabling DNSSEC by default it starts clearing the way for Ubuntu, AOSP, iOS, etc. since those pesky power users are going to get their employers, universities, etc. to fix their broken networks.
1
2