I've had to battle quite a few portability issues, but everytime it was a program incorrectly assuming some sort of behaviour from glibc and not really musl's fault.
In fact, I thought Node already depended on c-ares, why is it failing on this?
The resolve module provided by systemd talks to systemd-resolved but the dns module parses /etc/resolv.conf and does the resolution itself.
Traditionally, in Unix libc is part of the OS. This situation is different in Linux but Linux is an outlier here, if we look at various BSDs they keep libc in the same tree as kernel.
C and Unix are considerably older than Linux after all.
Alpine or Debian including libC is more equivalent to the BSDs including it.
The tuples historically had 3 components--cpu, vendor and operating system. But especially as uclibc and musl became more widespread the last component is commonly split into kernel-libc. (I think this was originally extended for the benefit of Debian GNU/kFreeBSD.) The formal OS identifier for glibc-based Linux systems is "linux-gnu" (e.g. x86_64-pc-linux-gnu), and for musl "linux-musl" (e.g. aarch64-alpine-linux-musl).
Vendor is not very useful these days. It's common to see 3-tuples of cpu-kernel-libc, as opposed to 4-tuples or traditional 3-tuples. Sometimes the system is extended into, e.g., 5-tuples like cpu-vendor-kernel-libc-compiler. Autotools projects commonly have a bit of generated shell code for parsing tuples; it's quite complex owing to ~30 years of accumulated idiosyncrasies.
https://github.com/dank101/4.2BSD/blob/master/include/netdb....
I personally it should be renamed because it's just a generic way for the kernel to ask for data from userspace, not just keys but still.
libc is that service on the base OS. But rather than connecting to an OS service and passing messages back and forth you dlopen and setjmp to do the same thing. On GNU/Linux libc isn't an interface to the NSS service, libc is the NSS service. That fact that you access it via your linker is just an implementation thing.
The kernel itself actually exposes integration points this way too with lib-vdso! The kernel will actually just stick it's own routines in your programs memory space so that you can avoid the syscall overhead for certain calls.
What are you doing?
dig is not affected by alpine’s decision here because dig does not use gethostbybame.
No DNS client would be.
This affects gethostbyname which very few programs in my experience even support robustly, so any “use-case” where someone is using 100 results would surprise me.
It seems if you need to write something custom, a www client is better (which consul also supports).
I think if you insist on writing gethostbyname instead of the res_* calls in bind, and robustly handle all results in a sensible way, then that’s silly, and if you have an existing application that works great with ~70 addresses but not 100 I would be curious to know what it is.
And getaddrinfo returns a linked list of results so it's not exactly hard to support 100 results. All the actual junk about TCP/UDP is completely abstracted away from the caller.
So sure, while you could use your own DNS client specifically for talking to Consul's DNS server the whole point of the thing is to act as a compatibility layer for software you didn't write and which will 100% of the time use glibc's methods.
I don't think that's right.
gethostbyname() doesn't query DNS, it queries names, which includes /etc/hosts, and possibly NIS, active directory, and other possible things. Most applications would never be expecting 100 results from one of these queries and many will not tolerate it well.
Specialised users of gethostbyname() can certainly do better, but what I doubt is the wisdom of such specialisation: It certainly has nothing to do with the application -- it is literally under the control of the network administrator as you are well aware. Specialisation can occur in your application, but it can just as easily specialise another way.
On the other hand, if your application really wants to specially speak to Consul's DNS (as opposed to whatever the network administrator is doing) it can definitely use res_query()
> so it's not exactly hard to support 100 results
Maybe we mean different things by "support": What do you do with them?
> I'm not really sure what you mean by "support gethostbyname robustly"
When most applications connect to a host they get from gethostbyname they often connect to the first, and give up if the connection opens and resets: This is exceptionally common with load balancers and address translation. To those applications, what is the point of giving them multiple results in this situation?
A few applications try to handle the result robustly: connect to a random member of the list, or connect to several in parallel and try the request in parallel. Some applications do really wild stuff here to make a good user-experience.
Most do not.
When someone types `ping google.com` (for example) you only ever get one result. If that name doesn't ping, it doesn't try another.
Most are like that.
Hopefully that makes what I mean by "robustly" clearer.
I'm conflicted on this. I'm currently running an Alpine-based container in production but am thinking about revisiting the choice of base image.
On the one hand, using a smaller base system and (especially) a simpler libc translates to a smaller attack surface, and less noise in static scans for vulnerabilities. So I could argue that using Alpine is the responsible choice from a security perspective.
But maybe I'm just rationalizing a desire to pursue the kind of software quality (simplicity, minimization of bloat) that only we developers appreciate and that often has hidden downsides. Then I read about such downsides, like the sibling comment about DNS resolution, and I wonder if the responsible thing to do as a pragmatic product developer (and future manager of such developers) is to banish Alpine from the stack, tolerate the relative bloat of something like Debian, and throw more (and more complex) tools at the problem of the larger attack surface and more noise in vulnerability scans.
As the user, you have the choice to use musl and "battle quite a few portability issues" (whether that's the program's fault or not!) or to use glibc and not have to battle. If the benefits of musl outweigh that in your opinion, then go ahead. I don't see it.