Hi, On my phone and travelling so can't trivially find out the answer to the following question right now. Is libnss-resolve automatically seeded via a Depends or does it require manual seeding? Regards, Martin. <div class="gmail_quote">On 31 May 2016 11:36, "Martin Pitt" <<a href="mailto:martin.pitt@ubuntu.com">martin.pitt@ubuntu.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello all, yesterday I landed [1] in Yakkety which changes how DNS resolution works -- i. e. how names like "<a href="http://www.ubuntu.com" rel="noreferrer" target="_blank">www.ubuntu.com</a>" get translated to an IP address like 1.2.3.4. Until now, we used two different approaches for this: * On desktops and touch, NetworkManager launched "dnsmasq" configured as effectively a local DNS server which forwards requests to the "real" DNS servers that get picked up usually via DHCP. Thus /etc/resolv.conf said "nameserver 127.0.0.1" and it was rather non-obvious to show the real DNS servers. (This was one of the complaints/triggers that led to creating this blueprint). But dnsmasq does proper rotation and fallback between multiple nameservers, i. e. if one does not respond it uses the next one without long timeouts. * On servers, cloud images etc. we did not have any local DNS server. Configured DNS servers (via DHCP or static configuration in /etc/network/interfaces) were put into /etc/resolv.conf, and every program (via glibc's builtin resolver) directly contacted those. This had the major drawback that if the first DNS server does not respond (or is slow), then *every* DNS lookup suffers from a ~ 10s timeout, which makes every network operation awfully slow. Addressing this was the main motivation for the blueprint. On top of that, there was no local caching, thus requesting the same name again would do another lookup. As of today, we now have one local resolver service for all Ubuntu products; we picked "resolved" as that is small and lightweight, already present (part of the systemd package), does not require D-Bus (unlike dnsmasq), supports DNSSEC, provides transparent fallback to contacting the real DNS servers directly (in case anything goes wrong with the local resolver), and avoids the first issue above that /etc/resolv.conf always shows 127.0.0.1. Now DNS resolution goes via a new "libnss-resolve" NSS module which talks to resolved [2]. /etc/resolv.conf has the "real" nameservers, broken name servers are handled efficiently, and we have local DNS caching. NetworkManager now stops launching a dnsmasq instance. I've had this running on my laptop for about three weeks now without noticing problems, but there may well be some corner cases where this causes problems. If you encounter a regression that causes DNS names to not get resolved correctly, please do "ubuntu-bug libnss-resolve" with the details. Thanks, Martin [1] <a href="https://blueprints.launchpad.net/ubuntu/+spec/foundations-y-local-resolver" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/ubuntu/+spec/foundations-y-local-resolver</a> [2] This is configured in /etc/nsswitch.conf ("hosts: files ... resolve dns") -- Martin Pitt | <a href="http://www.piware.de" rel="noreferrer" target="_blank">http://www.piware.de</a> Ubuntu Developer (<a href="http://www.ubuntu.com" rel="noreferrer" target="_blank">www.ubuntu.com</a>) | Debian Developer (<a href="http://www.debian.org" rel="noreferrer" target="_blank">www.debian.org</a>) -- ubuntu-devel mailing list <a href="mailto:ubuntu-devel@lists.ubuntu.com">ubuntu-devel@lists.ubuntu.com</a> Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel" rel="noreferrer" target="_blank">https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel</a> </blockquote></div>