5 ms·

Why is DNS resolution even part of the libc and not, say, the base OS, a service on the base OS, or if need be, an external library like c-ares? In fact, I tho

Why is DNS resolution even part of the libc and not, say, the base OS, a service on the base OS, or if need be, an external library like c-ares? In fact, I thought Node already depended on c-ares, why is it failing on this?

silon42 5y ago
Typically, on a modern Linux system, DNS queries from libc (and everything else) will always query a local resolver (example: systemd-resolved).
- Spivak 5y ago
  That's up to your distro technically. DNS queries that use glibc (so everything basically) parse /etc/nsswitch.conf and follow the path of NSS modules which can do whatever they want to produce a name. The resolve module provided by systemd talks to systemd-resolved but the dns module parses /etc/resolv.conf and does the resolution itself.
p2t2p 5y ago
Adding to the other responder. 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.
- WJW 5y ago
  If the outlier has >100x as much market share as the rest of the other unixes combined, is Linux really still the outlier?
  - WastingMyTime89 5y ago
    Historically speaking? Yes. C and Unix are considerably older than Linux after all.
  - masklinn 5y ago
    Yes. It explains why things work the way they do, and have since long before linux was a thing.
  - nyrikki 5y ago
    Remember "Linux" is just the kernel, it is not an operating system itself. Alpine or Debian including libC is more equivalent to the BSDs including it.
tyingq 5y ago
It has certainly evolved to be pretty complicated. You have whatever libc chooses to do with getaddrinfo(), nsswitch.conf, resolv.conf, systemd-resolved, various pieces of software (docker, vpns, wsl), and so on, all trying to control the local resolver.
sharikone 5y ago
Linux as a system is very ill-defined. I'd argue that GNU/Linux by definition contains glibc even if they are not in the same tree and musl based distributions are a variation which you could call "musl/Linux".
- wahern 5y ago
  GNU formalized a system of tuple definitions for identifying build, host, and target environments, which was popularized by Autotools. See https://autotools.io/autoconf/canonical.html#autoconf.canonical.tuples https://autotools.io/autoconf/canonical.html#autoconf.canoni... and https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/html_node/Specifying-Target-Triplets.html https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/a... Even if you don't use Autotools, this is the canonical way to specify environments in the Unix world, though often a simplified version is employed. (By canonical I mean the one project-agnostic system that everybody at least nominally acknowledges. It's hardly the only system out there. Even Debian has their own alternative: https://wiki.debian.org/Multiarch/Tuples https://wiki.debian.org/Multiarch/Tuples .) 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.
trissylegs 5y ago
It probably made sense in 1983. https://github.com/dank101/4.2BSD/blob/master/include/netdb.h https://github.com/dank101/4.2BSD/blob/master/include/netdb....
- fanf2 5y ago
  I think back then libresolv was separate from libc since many programs didn’t need it, and memory was tight
devit 5y ago
Someone added it to libc and now it needs to be provided forever for compatibility.
fanf2 5y ago
libc provides the standard POSIX sockets APIs, which include DNS functions such as gethostbyname() and getaddrinfo()
Denvercoder9 5y ago
I certainly don't want DNS resolution inside the kernel, and outside the kernel, libc is as "base OS" as "base OS" comes, imo.
- Spivak 5y ago
  The Linux kernel can actually resolve names but it farms out the actual work to userspace using the request-key(8) machinery. 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.
Spivak 5y ago
Because people treat libraries differently today than 30 years ago. We're used to the integration points for things being some form of blocking IPC (like dbus on GNU/Linux, COM, or syscalls) but libc is different. 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.

silon42 5y ago

Typically, on a modern Linux system, DNS queries from libc (and everything else) will always query a local resolver (example: systemd-resolved).

Spivak 5y ago
That's up to your distro technically. DNS queries that use glibc (so everything basically) parse /etc/nsswitch.conf and follow the path of NSS modules which can do whatever they want to produce a name. The resolve module provided by systemd talks to systemd-resolved but the dns module parses /etc/resolv.conf and does the resolution itself.

p2t2p 5y ago

Adding to the other responder. 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.

WJW 5y ago
If the outlier has >100x as much market share as the rest of the other unixes combined, is Linux really still the outlier?
- WastingMyTime89 5y ago
  Historically speaking? Yes. C and Unix are considerably older than Linux after all.
- masklinn 5y ago
  Yes. It explains why things work the way they do, and have since long before linux was a thing.
- nyrikki 5y ago
  Remember "Linux" is just the kernel, it is not an operating system itself. Alpine or Debian including libC is more equivalent to the BSDs including it.

tyingq 5y ago

It has certainly evolved to be pretty complicated. You have whatever libc chooses to do with getaddrinfo(), nsswitch.conf, resolv.conf, systemd-resolved, various pieces of software (docker, vpns, wsl), and so on, all trying to control the local resolver.

sharikone 5y ago

Linux as a system is very ill-defined. I'd argue that GNU/Linux by definition contains glibc even if they are not in the same tree and musl based distributions are a variation which you could call "musl/Linux".

wahern 5y ago
GNU formalized a system of tuple definitions for identifying build, host, and target environments, which was popularized by Autotools. See https://autotools.io/autoconf/canonical.html#autoconf.canonical.tuples https://autotools.io/autoconf/canonical.html#autoconf.canoni... and https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.70/html_node/Specifying-Target-Triplets.html https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/a... Even if you don't use Autotools, this is the canonical way to specify environments in the Unix world, though often a simplified version is employed. (By canonical I mean the one project-agnostic system that everybody at least nominally acknowledges. It's hardly the only system out there. Even Debian has their own alternative: https://wiki.debian.org/Multiarch/Tuples https://wiki.debian.org/Multiarch/Tuples .) 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.

trissylegs 5y ago

It probably made sense in 1983. https://github.com/dank101/4.2BSD/blob/master/include/netdb.h https://github.com/dank101/4.2BSD/blob/master/include/netdb....

fanf2 5y ago
I think back then libresolv was separate from libc since many programs didn’t need it, and memory was tight

devit 5y ago

Someone added it to libc and now it needs to be provided forever for compatibility.

fanf2 5y ago

libc provides the standard POSIX sockets APIs, which include DNS functions such as gethostbyname() and getaddrinfo()

Denvercoder9 5y ago

I certainly don't want DNS resolution inside the kernel, and outside the kernel, libc is as "base OS" as "base OS" comes, imo.

Spivak 5y ago
The Linux kernel can actually resolve names but it farms out the actual work to userspace using the request-key(8) machinery. 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.

Spivak 5y ago

Because people treat libraries differently today than 30 years ago. We're used to the integration points for things being some form of blocking IPC (like dbus on GNU/Linux, COM, or syscalls) but libc is different. 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.