Hacker News Reader

Comment by Gordonjcp | Hacker News Reader

So because they have a weirdass edge case because of their broken design (ridiculously outsize DNS replies), they're going to stop using a particular distro that nearly everything in Docker is based on?

Oooh-kaaaay.... sure, I guess

View on HN

RFC 7766 [1] actually requires TCP support:

> Section 6.1.3.2 of [RFC1123] is updated: All general-purpose DNS implementations MUST support both UDP and TCP transport.

For stub resolvers like the ones provided by glibc and musl:

> Stub resolver implementations (e.g., an operating system's DNS resolution library) MUST support TCP since to do otherwise would limit the interoperability between their own clients and upstream servers.

[1]: https://datatracker.ietf.org/doc/html/rfc7766#section-5

`getaddrinfo` is a POSIX function, and the POSIX specification for it[1] allows implementations that only support UDP (it even allows implementations that don't use DNS). Such implementations should (but are not required to) set the `struct addrinfo` `hints` field to `IPPROTO_UDP`. Note that POSIX only mentions "In many cases it is implemented by the Domain Name System, as documented in RFC 1034, RFC 1035, and RFC 1886." and not any later RFCs, so RFC 7766 changes aren't required for POSIX-compliant implementations.

[1] https://pubs.opengroup.org/onlinepubs/9699919799/

> musl (by design) doesn't support DNS-over-TCP

I find this surprising. Most DNS hostname lookups do work via UDP but I would expect TCP to also be supported. Caveat emptor.

The Docker containers I run are a mixed bag of base images. I often reach for Alpine first. If that doesn't work for some reason I think "Oh well" and switch to Debian or Ubuntu.

Wouldn't a similar approach work for most people? I don't know how it works in other companies, so perhaps I'm just privileged to not need a specific base image for everything.

> I often reach for Alpine first. If that doesn't work for some reason I think "Oh well" and switch to Debian or Ubuntu.

No, the moment something doesn't quite meet your needs you must abandon it immediately.

Like for example I used to cycle a lot but then one day it snowed and my feet got cold and my bike got stuck in the snow, so now I will never cycle again and I just drive everywhere in a massive 6x6 7-tonne army truck, except I don't because that would be fucking idiotic.

I don't get why everyone has to be so polarised these days.

I expect the author of the article is polarized due to the pain inflicted by the bug, the unreasonable design decision that led to it (seems like the bug exists by design) and the fact that there’s not really a workaround that would prevent the problem from happening again.

I’d personally like to see a fix, but my thinking might be different if I’d gone through what sounds like several days of downtime that could have been avoided.

There's something to be said about swapping the glibc with musl and just hoping for the best. Maybe there's other musl oddities which will cause issues in Alpine Linux?

I think its fair to say that most Linux developers test on glibc. Now I hear of some programs using ulibc or so forth (ex: Busybox) where space / embedded is key... but that's a purposeful choice with tradeoffs.

But for a general application... is there really any reason to port off of glibc?

You get a static library that always works on myriads of distros. You can more easily cross-compile. When you want to cross-compile for Linux on macOS, or crosscompile for arm on intel, much simpler to use musl.

I honestly think it's worth testing how your code builds against musl, if you think it's likely to be something that ends up in Docker.

“Weirdly outsized” which happens regularly k8s which is in place in most professional docker deployments. Docker being the primary use case for alpine…

I’d say this is a pretty reasonable gripe.

Reply on news.ycombinator.com