0

When setting up a DNS server, the Ubuntu documentation says to change RESOLVCONF=no to RESOLVCONF=yes in /etc/default/bind9

Ref: https://help.ubuntu.com/stable/serverguide/dns-troubleshooting.html

But it doesn't explain what that actually does. And, I only found it on the "troubleshooting" page; not as part of the configuration steps. Strange.

Some additional reading in a variety of sources leads me to believe that it tells systemd-resolved to consider the local DNS server (presumably first?) in addition to the other nameservers configured in /etc/netplan/ files. But I don't really see that spelled out in so many words ... anywhere.

Also, I can find no way to tell that anything elsewhere has changed. For example, the output of networkctl status and systemd-resolve --status both appear to be unchanged after making the change in /etc/default/bind9 and restarting bind9.

So, my questions are:

1) What exactly does setting RESOLVCONF=yes do? That is, what behavior(s) in which systems does it change?

2) Where can I see the result? That is, what command(s) can I run before and after to see that it has taken effect, either to verify that it is working, or to understand better what it is doing?

3) Where can I find documentation for the answers to #1 and #2.

Thanks!

6
  • @Karlom - That man page does not mention this setting nor answer the questions asked above. – Michael Fox Jun 24 '19 at 15:11
  • No, the documentation says that the nameservers themselves do it. I run a bind9 name server, and I do not have that file. Also, I am one of only a couple of people that publish the Ubuntu serverguide. Please know that the guide is suffering from a lack of subject matter expert contributions and reviews. Improvement is in the works. Perhaps that paragraph is incorrect or obsolete, although I didn't find a related bug report. – Doug Smythies Jun 24 '19 at 15:37
  • @Doug Smythies - Thanks. When you say "I do not have that file", to which file are you referring? The /etc/default/bind9 file has been in Ubuntu for (I think) at least the last couple of LTS releases. But this is the first LTS release in which that file contains the RESOLVCONF option. – Michael Fox Jun 24 '19 at 17:10
  • @MichaelFox : Sorry, my mistake. I looked on the wrong server. Yes, the file is there on my nameserver, with RESOLVCONF=no. 16.04 LTS. – Doug Smythies Jun 24 '19 at 18:11
1

Actually, RESOLVCONF=yes in /etc/default/bind9 does nothing on modern systems which use systemd. That line was only used with the old bind9 init script, /etc/init.d/bind9, which is not used on systemd systems.

What it used to do is cause the locally-installed bind9 server to be used as the name server in /etc/resolv.conf. That is, it would put nameserver 127.0.0.1 in /etc/resolv.conf. It does this calling a resolvconf program from package called resolvconf (or openresolv, which is a compatible replacement for resolvconf).

To achieve this configuration with systemd, you just have to enable the bind9-resolvconf service: systemctl enable --now bind9-resolvconf

With versions of the bind9 package in Debian bullseye or later (or Debian derivatives like Ubuntu based on such, or Debian buster with the backported bind9 package), the service has been renamed from bind9 to named, so the corresponding service would be named-resolvconf.

I don't think there is any documentation on this, other than the code itself.

0

What exactly does setting RESOLVCONF=yes do? That is, what behavior(s) in which systems does it change?

RESOLVCONF=yes 

It sets an evironment variable where BIND9 is told to run the resolver. The resolver it what allows resolvconf to add IP addresses to resolv.conf when a nameserver listens to localhost(/127.*).

Where can I see the result? That is, what command(s) can I run before and after to see that it has taken effect, either to verify that it is working, or to understand better what it is doing?

more /etc/resolv.conf 

Where can I find documentation for the answers to #1 and #2.

There is likely no such thing except for the source code of bind9. Bind9 uses its own lightweight resolver and that setting arranges to call that resolver. Nothing more.

5
  • Thanks. Let me see if I understand what you're saying: – Michael Fox Jun 24 '19 at 18:23
  • Thanks. So, my /etc/resolv.conf is a symlink to /run/systemd/resolve/stub-resolv.conf, which I understanding is the the systemd-resolved resolver. Are you saying that setting RESOLVCONF=yes changes that to use a different resolver? And when you say, "... allows resolvconf to add IP addresses to resolv.conf", are you referring to the resolvconf package? In my case, I do not have the resolvconf package installed and the only IP in /etc/resolv.conf is 127.0.0.53. – Michael Fox Jun 24 '19 at 18:33
  • you have bind9 installed. bind9 includes a resolver. The option tells bind9 to use its resolver. Other options could also include your 127.* ip into /etc/resolve.conf. systemd also has a resolver. All these resolvers do the same though and the one in bind9 should be set to the default (it used to be true and it was set to false when we started using systemd iirc). – Rinzwind Jun 24 '19 at 18:51
  • Thanks. So, to make sure I understand: Setting RESOLVCONF=yes in /etc/default/bind9 sets an environmental variable which tells bind to use it's own resolver, rather than whatever the system is using. So, for example, if the system was using systemd-resolved, then bind's own resolver is used instead of systemd-resolved. And, unless I have a specific reason for choosing the bind resolver, it's best to leave it at the default value of RESOLVCONF=no. And, perhaps the above troubleshooting documentation should be updated to not suggest changing the value from the default. Yes? – Michael Fox Jun 25 '19 at 4:02
  • Can you please confirm that I've correctly captured your answer (or else correct me) so I can close this? Thanks much! – Michael Fox Jun 27 '19 at 3:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.