4 ms·

I was wondering why they felt the need to add their own DNS resolver. From the changelog: "Hostnames, addresses and arbitrary RRs may be resolved via systemd-r

I was wondering why they felt the need to add their own DNS resolver. From the changelog: "Hostnames, addresses and arbitrary RRs may be resolved via systemd-resolved D-Bus APIs. In contrast to the glibc internal resolver systemd-resolved is aware of multi-homed system, and keeps DNS server and caches separate and per-interface. Queries are sent simultaneously on all interfaces that have DNS servers configured, in order to properly handle VPNs and local LANs which might resolve separate sets of domain names. systemd-resolved may acquire DNS server information from systemd-networkd automatically, which in turn might have discovered them via DHCP. A tool "systemd-resolve-host" has been added that may be used to query the DNS logic in resolved. systemd-resolved implements IDNA and automatically uses IDNA or UTF-8 encoding depending on whether classic DNS or LLMNR is used as transport. In the next releases we intend to add a DNSSEC and mDNS/DNS-SD implementation to systemd-resolved." Nice features, but I don't understand if they have to be under the systemd umbrella. Here's hoping it can be broken out to be useful in other situations.

viraptor 12y ago
> DNS server and caches separate and per-interface This is rather strange. I don't believe any glibc-based client will care to use the same interface for resolution and connection (can you even force an interface on gethostbyname()?) If that's not the case, why would multi-homed-aware system be of any use to the client? I can imagine the cache split helps, because you can drop only part of the cache when one connection drops - but unless programs are written to deal with this issue from the start, they're unlikely to re-resolve the hostname, or even use any network state events. So who gains something from this new crazy system? I also don't really get why they pull everything in - this sounds like a completely separate project... I hate the idea of Linux/systemd the world is heading for right now.
- vezzy-fnord 12y ago
  The idea, from what I'm deducing, is to migrate Avahi (a Linux implementation of Apple's Bonjour zeroconf protocol) into the systemd codebase.
  - viraptor 12y ago
    Sure. But we've got nsswitch and Avahi already... and they work. If they have some bugs that cannot be worked around, I'd expect a comment like "we couldn't get Avahi to work, upstream bugs xxx and yyy forced us to rewrite it".
    - derefr 12y ago
      I would guess making DNS resolution follow connection paths means DNS-over-Tor becomes something that just happens automatically.
dmm 12y ago
systemd offers great features but they all come as a part of the same giant ball of mud. Look at what happened to udev. In 2012 the udev codebase was added to the systemd source tree. At the time it was promised that using udev separately would continue to be supported[1]. Once kdbus is merged into the kernel using udev without systemd will amount to implementing a separate userspace kdbus[2]. This is happening with the release of 3.17 this year. Nothing will be broken out. systemd is a blackhole. Nothing escapes. systemd is good and useful but the trend here is clear. [1] http://article.gmane.org/gmane.linux.hotplug.devel/17392 http://article.gmane.org/gmane.linux.hotplug.devel/17392 [2] http://www.phoronix.com/scan.php?page=news_item&px=MTczNjI http://www.phoronix.com/scan.php?page=news_item&px=MTczNjI

viraptor 12y ago

> DNS server and caches separate and per-interface This is rather strange. I don't believe any glibc-based client will care to use the same interface for resolution and connection (can you even force an interface on gethostbyname()?) If that's not the case, why would multi-homed-aware system be of any use to the client? I can imagine the cache split helps, because you can drop only part of the cache when one connection drops - but unless programs are written to deal with this issue from the start, they're unlikely to re-resolve the hostname, or even use any network state events. So who gains something from this new crazy system? I also don't really get why they pull everything in - this sounds like a completely separate project... I hate the idea of Linux/systemd the world is heading for right now.

vezzy-fnord 12y ago
The idea, from what I'm deducing, is to migrate Avahi (a Linux implementation of Apple's Bonjour zeroconf protocol) into the systemd codebase.
- viraptor 12y ago
  Sure. But we've got nsswitch and Avahi already... and they work. If they have some bugs that cannot be worked around, I'd expect a comment like "we couldn't get Avahi to work, upstream bugs xxx and yyy forced us to rewrite it".
  - derefr 12y ago
    I would guess making DNS resolution follow connection paths means DNS-over-Tor becomes something that just happens automatically.

dmm 12y ago

systemd offers great features but they all come as a part of the same giant ball of mud. Look at what happened to udev. In 2012 the udev codebase was added to the systemd source tree. At the time it was promised that using udev separately would continue to be supported[1]. Once kdbus is merged into the kernel using udev without systemd will amount to implementing a separate userspace kdbus[2]. This is happening with the release of 3.17 this year. Nothing will be broken out. systemd is a blackhole. Nothing escapes. systemd is good and useful but the trend here is clear. [1] http://article.gmane.org/gmane.linux.hotplug.devel/17392 http://article.gmane.org/gmane.linux.hotplug.devel/17392 [2] http://www.phoronix.com/scan.php?page=news_item&px=MTczNjI http://www.phoronix.com/scan.php?page=news_item&px=MTczNjI