15 ms·

resolv.conf on Linux (2018)

214 points by kiyanwang 6y ago

jeroenhd 6y ago
Resolve.conf is a blessing and a curse. On the one hand, you've got a file that nearly every flavour of Linux will use for DNS resolution with a standardised format. On the other hand, you've got four hundred network managing programs that all need to be told separately that you don't want to use them to manage the file for you because you want to set it up yourself. Makes me wonder if the file options should be extended contain a config option to indicate what program manages the file so that others know to keep their hands off. Right now there's comments in there, but those comments are often hardly machine readable.
- vbezhenar 6y ago
  Run those programs under different users and make it writeable only for those programs that have permission to modify it.
- pravus 6y ago
  The handling for the resolv.conf file is embedded in the libc and is larger than Linux. This whole issue is a failure of the Linux distribution community to come up with coherent standards for managing a simple text file on a system using DHCP. The solutions today are horribly complicated and appear to optimize for laptop users on simple, naive networks. I have no idea why I have to mess with any of this garbage on my servers. No, we need to get back to software like it was in the early 2000s when people cared about consistent, long-term behavior instead of re-inventing everything because laptops.
  - viraptor 6y ago
    It makes sense to me. It solves the problem for simple networks and roaming users - so basically situations where things are expected to "just work" with minimal knowledge. It's our (sysadmins) job to configure the system correctly in other places. Especially in case of weird networks.
    - aj3 6y ago
      But simple networks and roaming users are perfectly fine with regular static file. I have no idea what user base this overengineered crap is catering but it seems equally useless both on (my) servers and laptops.
      - vetinari 6y ago
        > roaming users are perfectly fine with regular static file. If you want them to have broken DNS, then they are fine. If you want them to have working DNS, then not, regular static file is not fine.
      - viraptor 6y ago
        A significant number of hotels do the login portals using their own DNS servers, do if you ignore those, you can't use that network. Pretty much every corp environment forces local DNS servers.
        Lammy 6y ago
        The web portal isn't the only way on to a hotel network, just the most convenient. The Nintendo Switch console doesn't support captive portals either, so I've gotten in the habit of dialing the front desk any time I stay at a hotel and asking to be transferred to the network team. You tell them you need a device whitelisted and provide your room number, duration of stay, and the MAC of any devices.
        viraptor 6y ago
        This may work in a large hotel chain, but not in a b&b which licenses their it solution from a 3rd party that never wants to speak with you.
    - stefan_ 6y ago
      resolv.conf never worked for roaming users. glibc famously only read it on application startup.
  - Spivak 6y ago
    I disagree, this is historical baggage that /etc/resolve.conf is both configuration and runtime state and so any solution will be a little awkward. If you only let one thing on your system own it: NetworkManager, dhcpcd, systemd-resolved, netplan, ifcfg, $you then it’s no issue.
- segfaultbuserr 6y ago
  My proposal. $ cat /etc/resolv.conf # DO NOT EDIT THIS FILE. This file is currently under the management # of NetworkManager. It's automatically generated according to the # DNS configuration of the active network connection in NetworkManager. # Any change to this file will be overwritten. # # If you are trying to change your DNS resolver, it's officially recommended # to set it within NetworkManager on a per-connection basis via "nmtui", "nmcli", # or alternatively, by editing files under "/etc/NetworkManager/system-connections/". # # To stop NetworkManager from managing it altogether, edit # /etc/NetworkManager.conf, set the following and # restart NetworkManager, before you edit /etc/resolve.conf. # # [main] # dns=none # # If you are trying to set up a stub DNS resolver, it's recommended to # invoke NetworkManager's builtin support. Set "dns=dnsmasq" or "dns=unbound" # # See "man 5 NetworkManager.conf" for more details.
  - JdeBP 6y ago
    I recommend reading RFC 1034 section 5.3.1 first, and learning what a "stub resolver" actually is. It's actually the thing that is reading /etc/resolv.conf . * https://unix.stackexchange.com/a/500565/5132 https://unix.stackexchange.com/a/500565/5132
    - vetinari 6y ago
      Reading up about glibc's nsswitch would also help. The problem with RFC 1034 section 5.3.1 ideas is, that it is insufficient if you have more than 1 interface and DNS resolvers available over them might provide different answers for some zones (example: you have a VPN connection and the DNS resolver on the other side of the link has ACLs for the zones it is handling, providing you with answers that the public DNS won't provide); that's why networkmanger+dnsmasq/systemd-resolved/whatever are used. Linux is not the only system that has to handle /etc/resolv.conf being inadequte; but it is funny that we see articles like this only for Linux. I have yet to see an article "How to take back control of /etc/resolv.conf on MacOS".
      - JdeBP 6y ago
- iso1631 6y ago
  chattr +i will tell them impolitely to f-off.
iforgotpassword 6y ago
Or, if you're a lazy f, just recreate the file with your desired contents and then do chattr +i /etc/resolv.conf To make it immutable.
- noja 6y ago
  If you're lazy, never do this. It's not very visible and you or someone else will lose hours troubleshooting it later.
  - vsareto 6y ago
    Add a comment in the file?
    - qwertox 6y ago
      as well as a `etc/resolv.conf.README_IMPORTANT`-file.
      - encom 6y ago
        ...that says "Beware of the Leopard".
  - bawolff 6y ago
    Isn't that the quintessential lazy programmer solution? A quick hack that is beautiful but will cause lots of wasted time later.
  - ubercow13 6y ago
    Troubleshooting what?
    - gpvos 6y ago
      Maybe someone later has some legitimate edit they want to make to the file, which fails because it's immutable, which is in turn very hard to figure out. (E.g., I didn't know that there exists an "immutable" attribute.)
zwischenzug 6y ago
Oh man, this nightmare situation drove me completely nuts when I was trying to get DNS + VMs working with K8s test scripts. I ended up writing this series to exorcise the demons: https://zwischenzugs.com/2018/06/08/anatomy-of-a-linux-dns-lookup-part-i/ https://zwischenzugs.com/2018/06/08/anatomy-of-a-linux-dns-l... https://zwischenzugs.com/2018/06/18/anatomy-of-a-linux-dns-lookup-part-ii/ https://zwischenzugs.com/2018/06/18/anatomy-of-a-linux-dns-l... https://zwischenzugs.com/2018/07/06/anatomy-of-a-linux-dns-lookup-part-iii/ https://zwischenzugs.com/2018/07/06/anatomy-of-a-linux-dns-l... https://zwischenzugs.com/2018/08/06/anatomy-of-a-linux-dns-lookup-part-iv/ https://zwischenzugs.com/2018/08/06/anatomy-of-a-linux-dns-l...
- venamresm__ 6y ago
  I loved that series, thank you! The DNS system on Unix-like systems is such a complicated mess. Personally, I've set adsuck and my /etc/resolv.conf points to 127.0.0.1
- 3np 6y ago
  I'm more and more leaning towards "run dnsmasq on every single machine and be done with it", it feels like the sweet sweet spot to get flexibility and the predictability. Otherwise, systemd-resolved is not as unpredictable and frustrating as resolvconf or networkmanager.
  - cinquemb 6y ago
    > "run dnsmasq on every single machine and be done with it" Haha this is what I do…
  - vetinari 6y ago
    > Otherwise, systemd-resolved is not as unpredictable and frustrating as resolvconf or networkmanager. NetworkManager uses dnsmasq or systemd-resolved as it's backend...
    - AlphaSite 6y ago
      Isn’t systemd-resolvd using dnsmasq under the hood?
roadst4r 6y ago
Don't tools like network manager have config options to manage resolv.conf - so you can have autoconfig with your own customisations if you wish... This seems similar to the "don't disable selinux, learn how to use it" shenanigans..
z3t4 6y ago
I like to use Linux network namespaces for fun and profit. You can for example run a program with it's own IP/network. Network namespaces doesn't however work with network managers, systemd-resolv et.al. because network namespaces create separate unique mounts for /etc/resolv.conf
pbhjpbhj 6y ago
Oh, I had that fun once, when Ubuntu had moved to a systemd resolver, I'd managed to get two/three programs conflicting - think I used `lsof` to track which programs were opening resolv.conf.
person_of_color 6y ago
Does anyone actually like NetworkManager
- amenod 6y ago
  I do. When installing Linux on some comp which doesn't have specific networking requirements, it saves a lot of time.
- nulbyte 6y ago
  It is quite handy on a laptop, where network conditions may change frequently.
- usr1106 6y ago
  If you are Linux hacker with special requirements you might not like it. I give it to all members of the wider family that I convert to Linux and I have not had any tech support requests related to that ever.
- moonbug 6y ago
  nope.
  - maest 6y ago
    It's funny that the only technically correct answer got downvoted. You can never answer that question with 100% certainty with "yes", only with "no".
- rcxdude 6y ago
  yeah, it does actually do its job pretty well in a large number of circumstances (especially compared to its competition). But if you don't have the problem its solving (which is basically the problem of dealing with dynamically connecting to a wide variety of different networks, i.e. a laptop), then there are nicer options (there's basically no reason to ever use it on a server, for example).
- vetinari 6y ago
  Yes.
ulzeraj 6y ago
Sometimes I’m baffled that setting a static value for DNS servers is harder than updating resolv conf itself. Not to mention the fact that the information containing the proper steps to do this simple task of often buried among other network configuration information. I think SUSE had the best approach: if file doesn’t have a certain header (a comment stating something like “automatically created by x”) it means management scripts shouldn’t touch it. Not sure if it’s still like that.
duncan_bayne 6y ago
To be honest, it's this sort of thing that makes me happy to be back on FreeBSD for everything but gaming and DRM media (hi Spotify). Sure there's a little more work to get set up (which I've scripted and put in Gitlab, so it's easy the second and subsequent times). But the documentation is first class (in particular, the FreeBSD Handbook is great), and generally, when you set something up it stays that way. Reminds me of late 90s / early 2000s GNU/Linux in that regard.
- nulbyte 6y ago
  I love FreeBSD. Are you using it in a laptop? If so, which one? I've been looking for a friendly laptop to check out the latest FreeBSD. It's been a while.
  - blackhaz 6y ago
    I've been using it on X1 as a desktop driver since 9.0. Lovely setup: http://trafyx.com/?p=2551 http://trafyx.com/?p=2551 OpenBSD would be even cleaner and leaner, but I needed wine, keras, theano and a few other things it didn't offer.
  - duncan_bayne 6y ago
    I've used it with much success on the ThinkPad X220 and more recently the ThinkPad W540 (the latter of which I dual-boot into Ubuntu). I'm having a few issues with the docking station on the W540, which I'm currently putting down to the docking station being faulty, as I had no such issues docking the X220. I plan to test a different docking station in the next few days and see if the glitches go away (USB mouse sometimes needs resetting, and X loses the external monitor until it's restarted).
gorgoiler 6y ago
What is the real world impact of every host doing their own recursive lookups? The popular TLD nameservers would receive a lot of traffic but the amount depends on average TTLs in the wild — metrics which hopefully someone here will be knowledgeable about. Presumably handling the traffic is nothing compared to handling www.google.com, but the TLDs can’t afford the same scale of infra that FAANG can? Several billion people resolving their favourite websites every 86400 seconds — it’s either a lot, or one of those things the C10k folks love to show can be handled by a Pentiun III.
- zeeZ 6y ago
  There's been several articles and HN posts about chromium's nxdomain/intranet detection feature and its impact on root DNS traffic that may give a hint. https://news.ycombinator.com/item?id=24231857 https://news.ycombinator.com/item?id=24231857 https://news.ycombinator.com/item?id=24270369 https://news.ycombinator.com/item?id=24270369
- zrm 6y ago
  A lot of this depends on where we want to go from here, too. If you use traditional UDP DNS, it's one of those things the C10k folks love to show can be handled by a Pentium III. You could probably get a single modern server to handle more than a billion UDP DNS requests per second. But if you want to add a TLS handshake to each request and that sort of thing, not so much.
sixhobbits 6y ago
Haha I had a pi for toy projects and somehow dns kept breaking. I didn't have time to find the root cause so I made a cronjob to overwrite the file every minute. Maybe top 10 dirtiest things I've ever done but it worked fine for months
- notsureaboutpg 6y ago
  If you can't beat 'em...
andrewshadura 6y ago
This article offers wrong advice of disabling resolvconf. You shouldn't be doing that, since it's resolvconf that acts as an arbiter of resolvconf writes. Rdnssd in Debian, unfortunately, bypasses it, and it's a bug in the package.
DavideNL 6y ago
I've spent hours on figuring out Dns related issues in Ubuntu and always wonder how such a basic part of the OS can become such a huge mess... Impossible to figure out for average (/non techies) people.
- JdeBP 6y ago
  https://news.ycombinator.com/item?id=23718997 https://news.ycombinator.com/item?id=23718997 might help you to understand some of the reasons why.
maccam94 6y ago
I'm pretty sure that just replacing the /etc/resolv.conf symlink with a regular file will prevent all of the major network configuration tools from modifying it. I've verified this for resolvconf and systemd-resolved at least: > To make the resolver use this dynamically generated resolver configuration file the administrator should ensure that /etc/resolv.conf is a symbolic link to /run/resolvconf/resolv.conf. This link is normally created on installation of the resolvconf package. The link is never modified by the resolvconf program itself.[0] > To improve compatibility, /etc/resolv.conf is read in order to discover configured system DNS servers, but only if it is not a symlink... [1] [0]: http://manpages.ubuntu.com/manpages/zesty/man8/resolvconf.8.html#contenttoc4 http://manpages.ubuntu.com/manpages/zesty/man8/resolvconf.8.... [1]: https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html https://www.freedesktop.org/software/systemd/man/systemd-res...
- d2wa 6y ago
  No, it won't. Some of the managers for this file will overwrite it.
  - techdevangelist 6y ago
    It can be worth trying to set the file to immutable; chattr +i /etc/resolv.conf
  - maccam94 6y ago
    NetworkManager is the one exception I'm aware of here, but I don't think any server distros use it. Using NM is also the best option for configuring desktop environments, so I wouldn't bother disabling its resolv.conf management functionality.
    - CameronNemo 6y ago
      Doesn't RHEL ship with NM by default? And test on its usage?
pinebox 6y ago
Pretty sure I remember finding this ctrl.blog page when fighting with this systemd-related Ubuntu bug that changed resolv.conf to use "127.0.0.53": https://bugs.launchpad.net/bugs/1624320 https://bugs.launchpad.net/bugs/1624320 My hate for this whole situation (but especially the fact that it broke resolution of short names with search domains) is bone-deep.
- jrnichols 6y ago
  It also adds to my hate for Google Chrome.. "The primary purpose of adding 127.0.0.53 to resolv.conf is for client software that wants to do DNS resolution by itself instead of using NSS -- most notable example is Google Chrome, and third-party software which is statically linked (e. g. Go)." All this mess just to work around Chrome? That's annoying.
NelsonMinar 6y ago
This article is a great condemnation of how badly Unix networking has gone in the last 10 years. For many, many, many years we used /etc/resolv.conf to configure name service. Easy and simple, but not very flexible. All the tools this article talks about turning off are trying to solve problems. They're trying to let resolv.conf be configured with DHCP, or handle VPNs correctly, or roam across networks. You need software to do that, not just a static config file. The problem is every Linux distro has a different tool. And those tools behave opaquely or do bizarre things like use 127.0.0.53 as the loopback address. No one built the One True Tool that got it right. And so we have a mess that has the sysadmin throwing up their hands, disabling all the tools, and making immutable config files just to get back to basic static file functionality.
- aj3 6y ago
  Linux != UNIX
- rlpb 6y ago
  > No one built the One True Tool that got it right. Finding the One True Tool takes time. Developers need to experiment to explore the various corners of the problem space. Eventually we'll settle on the best way to solve the problem for the majority of use cases, and distributions will in time settle on that solution. In the meantime, sysadmins who only need the simple 20 year old use case can continue to disable the modern tooling and get what they want. Those who need the newer use cases can do so, provide feedback, and the ecosystem can slowly develop and settle on the best solution. This is open development of Free Software in action. Tools can evolve incrementally or new tools can take big leaps, taking advantage of both the lessons learnt and the code produced in older tools. It's how the ecosystem gets better. I don't see it as a condemnation at all.
- m463 6y ago
  > No one built the One True Tool that got it right. not systemd. gah!
- JdeBP 6y ago
  It's not bizarre, and it's an idea that is a lot more than 10 years old. * http://cr.yp.to/dnsroot.html http://cr.yp.to/dnsroot.html * http://jdebp.uk./Softwares/nosh/guide/services/djbdns.html http://jdebp.uk./Softwares/nosh/guide/services/djbdns.html You don't erroneously think that the systemd people invented this idea, do you? It's in RFC 1122.
known 6y ago
I've saved these commands for Ubuntu; sudo apt install resolvconf; sudo vi /etc/resolvconf/resolv.conf.d/head; sudo service resolvconf restart
Angeo34 6y ago
Just point resolv.conf to your pihole and then make it read only. Problem solved
idoubtit 6y ago
This post is simply wrong. Even on a plain old Debian without any of those programs (networkmanager, ...), the file /etc/resolv.conf will probably be written over at boot time. I don't want to draw a political comparison to the Brexit, but before engaging in "taking back control", one should learn how the current situation works and what the change will bring. The main missing concept in the article is DHCP. Most computers use this to get their IP and the DNS servers. For example, for as long as I can remember the default Debian way to handle the network was ifupdown, where a hook called `dhcp` after an interface is connected, and by doing so the file resolv.conf is updated. If resolv.conf is manually controlled, there is no DHCP to update it, and then you have to declare your DNS servers. But the DNS that you can query from home may not be reachable from a public wifi. And at work, you won't have access to the intranet unless you add some private DNS servers at the top of your resolv.conf. So a totally manual handling of resolv.conf is a bad idea, at least for a laptop. The article also never wonder why do all these programs try to "take control" of resolv.conf. Some of them just try to update it when they receive DHCP data about DNS. Other, like resolvconf, try to separate the manual part from the dhcp-generated part (which is what "manual control" should aim to). Other programs may add features, like a local cache or automatic knowledge of the local network (containers and such).
- asveikau 6y ago
  Sometimes you don't want to blindly trust dhcp. My isp is set up so that the internet-facing host gets an IP through dhcp. I don't want to use the ISP's dns however. I use OpenBSD on that machine. I think it was "ignore domain-name-servers" in dhclient.conf that fixed that for me.
  - Skunkleton 6y ago
    > I don't want to use the ISP's dns however. Careful. Even if you point at a different dns resolver, your ISP still gets to see this traffic, and it can still MITM it. This is not theoretical, it is trivial. Many ISPs do it.
    - zamadatix 6y ago
vinay_ys 6y ago
I recently installed Ubuntu 20.04 and configured a home gateway. I had not done something like that in a while (3+ years). My experience was not much different this time than any other time before as far as I remember. It took me an hour of reading the ubuntu official documentation and a few man pages on systemd, interfaces, networkd, resolvd, netplan etc to figure out how stuff works on this distro. After that I was able to simply do 'systemctl status' and look at all the running processes, then stop and disable all the ones I didn't want. I wanted to run unbound dns as my dnssec verifying, tls-forwarding, blocklist/filtering resolver. I was able to do that without any difficulty – stopped resolvd, enabled and started unbound and changed the entry in resolv.conf. I also brought up dhcpd for my network and was able to serve that dns server to the devices on my network. Then I had to spend a bit of time figuring out pppd, policy routing and nftables to do a bit of fancy dual wan routing and traffic filtering. I found netplan to be quite good at what it does (still incomplete for more advanced scenarios - but then so was all the previous tools similar to this). In all this, I actually found systemd quite helpful. I think those who complain don't take the few minutes it takes to read the man pages and familiarize themselves with the tools on the OS. Ofcourse things change, and you will have to learn new things. Expecting things to stay constant is unrealistic. As long as I'm able to depend on man-pages and official distro documentation, I'm not objecting to change.
- ed25519FUUU 6y ago
  Then you restart, and /etc/resolv.conf is different again? Despite resolvd being disabled(??)
leephillips 6y ago
Inaccurate information in the man pages doesn’t help. The one for resolved.conf claims that, if the DNS entry is not present in its configuration, systemd resolved will use the DNS servers in /etc/resolv.conf. But using strace showed me that, in fact, it is ignoring that file and using the resolver provided by my ISP (as resolved’s status output confirms). After copying the entries (for 8.8.8.8 and a few backups) into resolved’s configuration, it’s doing what I want it to, now. I’ve suspected for a while, and am now pretty sure, that this system has become so byzantine that the (incredibly talented) people assembling distros, writing the software, and maintaining the man pages, don’t know how it works.
- fao_ 6y ago
  > I’ve suspected for a while, and am now pretty sure, that this system has become so byzantine that the (incredibly talented) people assembling distros, writing the software, and maintaining the man pages, don’t know how it works. Which is... precisely what a lot of people were worried about re: systemd :(
  - zamadatix 6y ago
    I'd say the vast majority of systemd makes things more consistent and easier to understand how something is working at a glance. For some reason resolved in particular is one of the pieces that happens to have a wacky take on the service implementation choices ON TOP OF all of the other services that want to make things "just work" screwing with "how it's supposed to work". If it were just resolved or just the other tools doing wacky things DNS stuff would be a lot less messy to configure.
  - LukeShu 6y ago
    As one of the people assembling distros: If you think things are byzantine with systemd, you should have seen how things were before!
    - salawat 6y ago
      Deterministic, and not as prone inexplicable flakiness?
jaimex2 6y ago
Great article. I installed pihole one a server once instead of running the image. It was amazing to see the 3 way fist fight that broke out on resolv.conf

214 points by kiyanwang 6y ago

Resolve.conf is a blessing and a curse. On the one hand, you've got a file that nearly every flavour of Linux will use for DNS resolution with a standardised format. On the other hand, you've got four hundred network managing programs that all need to be told separately that you don't want to use them to manage the file for you because you want to set it up yourself. Makes me wonder if the file options should be extended contain a config option to indicate what program manages the file so that others know to keep their hands off. Right now there's comments in there, but those comments are often hardly machine readable.

vbezhenar 6y ago
Run those programs under different users and make it writeable only for those programs that have permission to modify it.
pravus 6y ago
The handling for the resolv.conf file is embedded in the libc and is larger than Linux. This whole issue is a failure of the Linux distribution community to come up with coherent standards for managing a simple text file on a system using DHCP. The solutions today are horribly complicated and appear to optimize for laptop users on simple, naive networks. I have no idea why I have to mess with any of this garbage on my servers. No, we need to get back to software like it was in the early 2000s when people cared about consistent, long-term behavior instead of re-inventing everything because laptops.
- viraptor 6y ago
  It makes sense to me. It solves the problem for simple networks and roaming users - so basically situations where things are expected to "just work" with minimal knowledge. It's our (sysadmins) job to configure the system correctly in other places. Especially in case of weird networks.
  - aj3 6y ago
    But simple networks and roaming users are perfectly fine with regular static file. I have no idea what user base this overengineered crap is catering but it seems equally useless both on (my) servers and laptops.
    - vetinari 6y ago
      > roaming users are perfectly fine with regular static file. If you want them to have broken DNS, then they are fine. If you want them to have working DNS, then not, regular static file is not fine.
    - viraptor 6y ago
      A significant number of hotels do the login portals using their own DNS servers, do if you ignore those, you can't use that network. Pretty much every corp environment forces local DNS servers.
      - Lammy 6y ago
        The web portal isn't the only way on to a hotel network, just the most convenient. The Nintendo Switch console doesn't support captive portals either, so I've gotten in the habit of dialing the front desk any time I stay at a hotel and asking to be transferred to the network team. You tell them you need a device whitelisted and provide your room number, duration of stay, and the MAC of any devices.
        viraptor 6y ago
        This may work in a large hotel chain, but not in a b&b which licenses their it solution from a 3rd party that never wants to speak with you.
  - stefan_ 6y ago
    resolv.conf never worked for roaming users. glibc famously only read it on application startup.
- Spivak 6y ago
  I disagree, this is historical baggage that /etc/resolve.conf is both configuration and runtime state and so any solution will be a little awkward. If you only let one thing on your system own it: NetworkManager, dhcpcd, systemd-resolved, netplan, ifcfg, $you then it’s no issue.
segfaultbuserr 6y ago
My proposal. $ cat /etc/resolv.conf # DO NOT EDIT THIS FILE. This file is currently under the management # of NetworkManager. It's automatically generated according to the # DNS configuration of the active network connection in NetworkManager. # Any change to this file will be overwritten. # # If you are trying to change your DNS resolver, it's officially recommended # to set it within NetworkManager on a per-connection basis via "nmtui", "nmcli", # or alternatively, by editing files under "/etc/NetworkManager/system-connections/". # # To stop NetworkManager from managing it altogether, edit # /etc/NetworkManager.conf, set the following and # restart NetworkManager, before you edit /etc/resolve.conf. # # [main] # dns=none # # If you are trying to set up a stub DNS resolver, it's recommended to # invoke NetworkManager's builtin support. Set "dns=dnsmasq" or "dns=unbound" # # See "man 5 NetworkManager.conf" for more details.
- JdeBP 6y ago
  I recommend reading RFC 1034 section 5.3.1 first, and learning what a "stub resolver" actually is. It's actually the thing that is reading /etc/resolv.conf . * https://unix.stackexchange.com/a/500565/5132 https://unix.stackexchange.com/a/500565/5132
  - vetinari 6y ago
    Reading up about glibc's nsswitch would also help. The problem with RFC 1034 section 5.3.1 ideas is, that it is insufficient if you have more than 1 interface and DNS resolvers available over them might provide different answers for some zones (example: you have a VPN connection and the DNS resolver on the other side of the link has ACLs for the zones it is handling, providing you with answers that the public DNS won't provide); that's why networkmanger+dnsmasq/systemd-resolved/whatever are used. Linux is not the only system that has to handle /etc/resolv.conf being inadequte; but it is funny that we see articles like this only for Linux. I have yet to see an article "How to take back control of /etc/resolv.conf on MacOS".
    - JdeBP 6y ago
iso1631 6y ago
chattr +i will tell them impolitely to f-off.

iforgotpassword 6y ago

Or, if you're a lazy f, just recreate the file with your desired contents and then do chattr +i /etc/resolv.conf To make it immutable.

noja 6y ago
If you're lazy, never do this. It's not very visible and you or someone else will lose hours troubleshooting it later.
- vsareto 6y ago
  Add a comment in the file?
  - qwertox 6y ago
    as well as a `etc/resolv.conf.README_IMPORTANT`-file.
    - encom 6y ago
      ...that says "Beware of the Leopard".
- bawolff 6y ago
  Isn't that the quintessential lazy programmer solution? A quick hack that is beautiful but will cause lots of wasted time later.
- ubercow13 6y ago
  Troubleshooting what?
  - gpvos 6y ago
    Maybe someone later has some legitimate edit they want to make to the file, which fails because it's immutable, which is in turn very hard to figure out. (E.g., I didn't know that there exists an "immutable" attribute.)

zwischenzug 6y ago

Oh man, this nightmare situation drove me completely nuts when I was trying to get DNS + VMs working with K8s test scripts. I ended up writing this series to exorcise the demons: https://zwischenzugs.com/2018/06/08/anatomy-of-a-linux-dns-lookup-part-i/ https://zwischenzugs.com/2018/06/08/anatomy-of-a-linux-dns-l... https://zwischenzugs.com/2018/06/18/anatomy-of-a-linux-dns-lookup-part-ii/ https://zwischenzugs.com/2018/06/18/anatomy-of-a-linux-dns-l... https://zwischenzugs.com/2018/07/06/anatomy-of-a-linux-dns-lookup-part-iii/ https://zwischenzugs.com/2018/07/06/anatomy-of-a-linux-dns-l... https://zwischenzugs.com/2018/08/06/anatomy-of-a-linux-dns-lookup-part-iv/ https://zwischenzugs.com/2018/08/06/anatomy-of-a-linux-dns-l...

venamresm__ 6y ago
I loved that series, thank you! The DNS system on Unix-like systems is such a complicated mess. Personally, I've set adsuck and my /etc/resolv.conf points to 127.0.0.1
3np 6y ago
I'm more and more leaning towards "run dnsmasq on every single machine and be done with it", it feels like the sweet sweet spot to get flexibility and the predictability. Otherwise, systemd-resolved is not as unpredictable and frustrating as resolvconf or networkmanager.
- cinquemb 6y ago
  > "run dnsmasq on every single machine and be done with it" Haha this is what I do…
- vetinari 6y ago
  > Otherwise, systemd-resolved is not as unpredictable and frustrating as resolvconf or networkmanager. NetworkManager uses dnsmasq or systemd-resolved as it's backend...
  - AlphaSite 6y ago
    Isn’t systemd-resolvd using dnsmasq under the hood?

roadst4r 6y ago

Don't tools like network manager have config options to manage resolv.conf - so you can have autoconfig with your own customisations if you wish... This seems similar to the "don't disable selinux, learn how to use it" shenanigans..

z3t4 6y ago

I like to use Linux network namespaces for fun and profit. You can for example run a program with it's own IP/network. Network namespaces doesn't however work with network managers, systemd-resolv et.al. because network namespaces create separate unique mounts for /etc/resolv.conf

pbhjpbhj 6y ago

Oh, I had that fun once, when Ubuntu had moved to a systemd resolver, I'd managed to get two/three programs conflicting - think I used `lsof` to track which programs were opening resolv.conf.

person_of_color 6y ago

Does anyone actually like NetworkManager

amenod 6y ago
I do. When installing Linux on some comp which doesn't have specific networking requirements, it saves a lot of time.
nulbyte 6y ago
It is quite handy on a laptop, where network conditions may change frequently.
usr1106 6y ago
If you are Linux hacker with special requirements you might not like it. I give it to all members of the wider family that I convert to Linux and I have not had any tech support requests related to that ever.
moonbug 6y ago
nope.
- maest 6y ago
  It's funny that the only technically correct answer got downvoted. You can never answer that question with 100% certainty with "yes", only with "no".
rcxdude 6y ago
yeah, it does actually do its job pretty well in a large number of circumstances (especially compared to its competition). But if you don't have the problem its solving (which is basically the problem of dealing with dynamically connecting to a wide variety of different networks, i.e. a laptop), then there are nicer options (there's basically no reason to ever use it on a server, for example).
vetinari 6y ago
Yes.

ulzeraj 6y ago

Sometimes I’m baffled that setting a static value for DNS servers is harder than updating resolv conf itself. Not to mention the fact that the information containing the proper steps to do this simple task of often buried among other network configuration information. I think SUSE had the best approach: if file doesn’t have a certain header (a comment stating something like “automatically created by x”) it means management scripts shouldn’t touch it. Not sure if it’s still like that.

duncan_bayne 6y ago

To be honest, it's this sort of thing that makes me happy to be back on FreeBSD for everything but gaming and DRM media (hi Spotify). Sure there's a little more work to get set up (which I've scripted and put in Gitlab, so it's easy the second and subsequent times). But the documentation is first class (in particular, the FreeBSD Handbook is great), and generally, when you set something up it stays that way. Reminds me of late 90s / early 2000s GNU/Linux in that regard.

nulbyte 6y ago
I love FreeBSD. Are you using it in a laptop? If so, which one? I've been looking for a friendly laptop to check out the latest FreeBSD. It's been a while.
- blackhaz 6y ago
  I've been using it on X1 as a desktop driver since 9.0. Lovely setup: http://trafyx.com/?p=2551 http://trafyx.com/?p=2551 OpenBSD would be even cleaner and leaner, but I needed wine, keras, theano and a few other things it didn't offer.
- duncan_bayne 6y ago
  I've used it with much success on the ThinkPad X220 and more recently the ThinkPad W540 (the latter of which I dual-boot into Ubuntu). I'm having a few issues with the docking station on the W540, which I'm currently putting down to the docking station being faulty, as I had no such issues docking the X220. I plan to test a different docking station in the next few days and see if the glitches go away (USB mouse sometimes needs resetting, and X loses the external monitor until it's restarted).

gorgoiler 6y ago

What is the real world impact of every host doing their own recursive lookups? The popular TLD nameservers would receive a lot of traffic but the amount depends on average TTLs in the wild — metrics which hopefully someone here will be knowledgeable about. Presumably handling the traffic is nothing compared to handling www.google.com, but the TLDs can’t afford the same scale of infra that FAANG can? Several billion people resolving their favourite websites every 86400 seconds — it’s either a lot, or one of those things the C10k folks love to show can be handled by a Pentiun III.

zeeZ 6y ago
There's been several articles and HN posts about chromium's nxdomain/intranet detection feature and its impact on root DNS traffic that may give a hint. https://news.ycombinator.com/item?id=24231857 https://news.ycombinator.com/item?id=24231857 https://news.ycombinator.com/item?id=24270369 https://news.ycombinator.com/item?id=24270369
zrm 6y ago
A lot of this depends on where we want to go from here, too. If you use traditional UDP DNS, it's one of those things the C10k folks love to show can be handled by a Pentium III. You could probably get a single modern server to handle more than a billion UDP DNS requests per second. But if you want to add a TLS handshake to each request and that sort of thing, not so much.

sixhobbits 6y ago

Haha I had a pi for toy projects and somehow dns kept breaking. I didn't have time to find the root cause so I made a cronjob to overwrite the file every minute. Maybe top 10 dirtiest things I've ever done but it worked fine for months

notsureaboutpg 6y ago
If you can't beat 'em...

andrewshadura 6y ago

This article offers wrong advice of disabling resolvconf. You shouldn't be doing that, since it's resolvconf that acts as an arbiter of resolvconf writes. Rdnssd in Debian, unfortunately, bypasses it, and it's a bug in the package.

DavideNL 6y ago

I've spent hours on figuring out Dns related issues in Ubuntu and always wonder how such a basic part of the OS can become such a huge mess... Impossible to figure out for average (/non techies) people.

JdeBP 6y ago
https://news.ycombinator.com/item?id=23718997 https://news.ycombinator.com/item?id=23718997 might help you to understand some of the reasons why.

maccam94 6y ago

I'm pretty sure that just replacing the /etc/resolv.conf symlink with a regular file will prevent all of the major network configuration tools from modifying it. I've verified this for resolvconf and systemd-resolved at least: > To make the resolver use this dynamically generated resolver configuration file the administrator should ensure that /etc/resolv.conf is a symbolic link to /run/resolvconf/resolv.conf. This link is normally created on installation of the resolvconf package. The link is never modified by the resolvconf program itself.[0] > To improve compatibility, /etc/resolv.conf is read in order to discover configured system DNS servers, but only if it is not a symlink... [1] [0]: http://manpages.ubuntu.com/manpages/zesty/man8/resolvconf.8.html#contenttoc4 http://manpages.ubuntu.com/manpages/zesty/man8/resolvconf.8.... [1]: https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html https://www.freedesktop.org/software/systemd/man/systemd-res...

d2wa 6y ago
No, it won't. Some of the managers for this file will overwrite it.
- techdevangelist 6y ago
  It can be worth trying to set the file to immutable; chattr +i /etc/resolv.conf
- maccam94 6y ago
  NetworkManager is the one exception I'm aware of here, but I don't think any server distros use it. Using NM is also the best option for configuring desktop environments, so I wouldn't bother disabling its resolv.conf management functionality.
  - CameronNemo 6y ago
    Doesn't RHEL ship with NM by default? And test on its usage?

pinebox 6y ago

Pretty sure I remember finding this ctrl.blog page when fighting with this systemd-related Ubuntu bug that changed resolv.conf to use "127.0.0.53": https://bugs.launchpad.net/bugs/1624320 https://bugs.launchpad.net/bugs/1624320 My hate for this whole situation (but especially the fact that it broke resolution of short names with search domains) is bone-deep.

jrnichols 6y ago
It also adds to my hate for Google Chrome.. "The primary purpose of adding 127.0.0.53 to resolv.conf is for client software that wants to do DNS resolution by itself instead of using NSS -- most notable example is Google Chrome, and third-party software which is statically linked (e. g. Go)." All this mess just to work around Chrome? That's annoying.

NelsonMinar 6y ago

This article is a great condemnation of how badly Unix networking has gone in the last 10 years. For many, many, many years we used /etc/resolv.conf to configure name service. Easy and simple, but not very flexible. All the tools this article talks about turning off are trying to solve problems. They're trying to let resolv.conf be configured with DHCP, or handle VPNs correctly, or roam across networks. You need software to do that, not just a static config file. The problem is every Linux distro has a different tool. And those tools behave opaquely or do bizarre things like use 127.0.0.53 as the loopback address. No one built the One True Tool that got it right. And so we have a mess that has the sysadmin throwing up their hands, disabling all the tools, and making immutable config files just to get back to basic static file functionality.

aj3 6y ago
Linux != UNIX
rlpb 6y ago
> No one built the One True Tool that got it right. Finding the One True Tool takes time. Developers need to experiment to explore the various corners of the problem space. Eventually we'll settle on the best way to solve the problem for the majority of use cases, and distributions will in time settle on that solution. In the meantime, sysadmins who only need the simple 20 year old use case can continue to disable the modern tooling and get what they want. Those who need the newer use cases can do so, provide feedback, and the ecosystem can slowly develop and settle on the best solution. This is open development of Free Software in action. Tools can evolve incrementally or new tools can take big leaps, taking advantage of both the lessons learnt and the code produced in older tools. It's how the ecosystem gets better. I don't see it as a condemnation at all.
m463 6y ago
> No one built the One True Tool that got it right. not systemd. gah!
JdeBP 6y ago
It's not bizarre, and it's an idea that is a lot more than 10 years old. * http://cr.yp.to/dnsroot.html http://cr.yp.to/dnsroot.html * http://jdebp.uk./Softwares/nosh/guide/services/djbdns.html http://jdebp.uk./Softwares/nosh/guide/services/djbdns.html You don't erroneously think that the systemd people invented this idea, do you? It's in RFC 1122.

known 6y ago

I've saved these commands for Ubuntu; sudo apt install resolvconf; sudo vi /etc/resolvconf/resolv.conf.d/head; sudo service resolvconf restart

Angeo34 6y ago

Just point resolv.conf to your pihole and then make it read only. Problem solved

idoubtit 6y ago

This post is simply wrong. Even on a plain old Debian without any of those programs (networkmanager, ...), the file /etc/resolv.conf will probably be written over at boot time. I don't want to draw a political comparison to the Brexit, but before engaging in "taking back control", one should learn how the current situation works and what the change will bring. The main missing concept in the article is DHCP. Most computers use this to get their IP and the DNS servers. For example, for as long as I can remember the default Debian way to handle the network was ifupdown, where a hook called `dhcp` after an interface is connected, and by doing so the file resolv.conf is updated. If resolv.conf is manually controlled, there is no DHCP to update it, and then you have to declare your DNS servers. But the DNS that you can query from home may not be reachable from a public wifi. And at work, you won't have access to the intranet unless you add some private DNS servers at the top of your resolv.conf. So a totally manual handling of resolv.conf is a bad idea, at least for a laptop. The article also never wonder why do all these programs try to "take control" of resolv.conf. Some of them just try to update it when they receive DHCP data about DNS. Other, like resolvconf, try to separate the manual part from the dhcp-generated part (which is what "manual control" should aim to). Other programs may add features, like a local cache or automatic knowledge of the local network (containers and such).

asveikau 6y ago
Sometimes you don't want to blindly trust dhcp. My isp is set up so that the internet-facing host gets an IP through dhcp. I don't want to use the ISP's dns however. I use OpenBSD on that machine. I think it was "ignore domain-name-servers" in dhclient.conf that fixed that for me.
- Skunkleton 6y ago
  > I don't want to use the ISP's dns however. Careful. Even if you point at a different dns resolver, your ISP still gets to see this traffic, and it can still MITM it. This is not theoretical, it is trivial. Many ISPs do it.
  - zamadatix 6y ago

vinay_ys 6y ago

I recently installed Ubuntu 20.04 and configured a home gateway. I had not done something like that in a while (3+ years). My experience was not much different this time than any other time before as far as I remember. It took me an hour of reading the ubuntu official documentation and a few man pages on systemd, interfaces, networkd, resolvd, netplan etc to figure out how stuff works on this distro. After that I was able to simply do 'systemctl status' and look at all the running processes, then stop and disable all the ones I didn't want. I wanted to run unbound dns as my dnssec verifying, tls-forwarding, blocklist/filtering resolver. I was able to do that without any difficulty – stopped resolvd, enabled and started unbound and changed the entry in resolv.conf. I also brought up dhcpd for my network and was able to serve that dns server to the devices on my network. Then I had to spend a bit of time figuring out pppd, policy routing and nftables to do a bit of fancy dual wan routing and traffic filtering. I found netplan to be quite good at what it does (still incomplete for more advanced scenarios - but then so was all the previous tools similar to this). In all this, I actually found systemd quite helpful. I think those who complain don't take the few minutes it takes to read the man pages and familiarize themselves with the tools on the OS. Ofcourse things change, and you will have to learn new things. Expecting things to stay constant is unrealistic. As long as I'm able to depend on man-pages and official distro documentation, I'm not objecting to change.

ed25519FUUU 6y ago
Then you restart, and /etc/resolv.conf is different again? Despite resolvd being disabled(??)

leephillips 6y ago

Inaccurate information in the man pages doesn’t help. The one for resolved.conf claims that, if the DNS entry is not present in its configuration, systemd resolved will use the DNS servers in /etc/resolv.conf. But using strace showed me that, in fact, it is ignoring that file and using the resolver provided by my ISP (as resolved’s status output confirms). After copying the entries (for 8.8.8.8 and a few backups) into resolved’s configuration, it’s doing what I want it to, now. I’ve suspected for a while, and am now pretty sure, that this system has become so byzantine that the (incredibly talented) people assembling distros, writing the software, and maintaining the man pages, don’t know how it works.

fao_ 6y ago
> I’ve suspected for a while, and am now pretty sure, that this system has become so byzantine that the (incredibly talented) people assembling distros, writing the software, and maintaining the man pages, don’t know how it works. Which is... precisely what a lot of people were worried about re: systemd :(
- zamadatix 6y ago
  I'd say the vast majority of systemd makes things more consistent and easier to understand how something is working at a glance. For some reason resolved in particular is one of the pieces that happens to have a wacky take on the service implementation choices ON TOP OF all of the other services that want to make things "just work" screwing with "how it's supposed to work". If it were just resolved or just the other tools doing wacky things DNS stuff would be a lot less messy to configure.
- LukeShu 6y ago
  As one of the people assembling distros: If you think things are byzantine with systemd, you should have seen how things were before!
  - salawat 6y ago
    Deterministic, and not as prone inexplicable flakiness?

jaimex2 6y ago

Great article. I installed pihole one a server once instead of running the image. It was amazing to see the 3 way fist fight that broke out on resolv.conf