bind9 registers itself with resolvconf even though it's unable to provide name service

[Jeff Lane ]

We're noticing this on every server we're installing Precise dailys on for sniff testing.

First, we use DHCP exclusively in the certification labs for assigning IP info to machines. So while Stefan Bader ran into this with his static IP setup (https://bugs.launchpad.net/ubuntu/+source/resolvconf/+bug/923685) we're seeing it with our dhcp set up. This is new behaviour also, I do not believe this was an issue in earlier Precise images, (alpha 2) so this seems to have been introduced since then.

At some point, I assume during the install, the system /etc/resolv.conf is created using information gathered from the dhcp server and it gets a single entry that looks like this:

nameserver 10.XXX.XXX.XXX

However, as soon as resolvconf is installed, this all gets replaced by the resolvconf files, and our working resolv.conf becomes /etc/resolvconf/resolv.conf.d/original, which is ignored by resolvconf.

After this, we get a useless resolvconf file that points to localhost:

ubuntu@ubuntu:~$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
search example.org

Now, looking into /etc/resolvconf/resolv.conf.d, there are three files: base, head and original.

ubuntu@ubuntu:/etc/resolvconf/resolv.conf.d$ cat base
ubuntu@ubuntu:/etc/resolvconf/resolv.conf.d$ cat head
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
ubuntu@ubuntu:/etc/resolvconf/resolv.conf.d$ cat original
nameserver 10.189.84.1
ubuntu@ubuntu:/etc/resolvconf/resolv.conf.d$

so right now, by default, resolvconf is breaking resolv.conf on dhcp setups (this is epidemic across our test labs)

I CAN resolve (no pun intended) this by simply replacing /etc/resolv.conf with /etc/resolvconf/resolv.conf.d/original but that's only a very temporary bandaid and NOT desired as a resolution.

[Jeff Lane  (bladernr)]

Per the readme, we can get around this by deleting /etc/resolv.conf and replacing it with /etc/resolvconf/resolv.conf.d/original also. But again, that's a workaround of the real issue:

For whatever reason, resolvconf itself is getting bad information creating a resolv.conf file that points to localhost rather than using the info it gets when an interface is brought up and gets dhcp information.

[Steve Langasek (vorlon)]

Spoke with Jeff on IRC; apparently he's getting bind9 installed when he wasn't expecting it, and this is where resolv.conf is being pointed. So the bug here is with bind9: the debconf question bind9/run-resolvconf defaults to 'true', which means that if resolvconf is present (which, as of 12.04, it always is), it automatically registers itself as a caching nameserver - but at least in some cases is failing to actually resolve anything.

This may be particular to the case where you have a firewall blocking access to port 53 on the public Internet and are required to use the DHCP-provided DNS information. In that case, installing bind9 is probably a bad idea... but just to be sure, assigning this bug to bind9 so we can consider whether bind9 should be hooking into resolvconf by default.

[Steve Langasek (vorlon)]

At the very least, this behavior is awkward because it means installing bind9 on a machine will immediately break nameservice until it's configured, even if the admin *knows* that this configuration is needed and is planning to address it ASAP.

So I think bind9 should probably not inject itself into resolvconf by default.

I also think the cert lab should probably fix its install tests to not pull in an unconfigured bind9 server while testing.

[Steve Langasek (vorlon)]

The resolvconf /usr/share/doc/resolvconf/README.gz also points to a Debian bug report for bind9:

  http://bugs.debian.org/483098

It seems that, *either* bind9 should not inject itself into resolvconf by default, *or* bind9 should completely integrate with resolvconf and pick up upstream resolver info from other sources.

[Thomas Hood (jdthood)]

Yes, I think that Debian bug report #483098 gives the background information needed to understand what's going on here.

Bind9 should certainly not by default send its (loopback) address to resolvconf. Bind9 should only send its address to resolvconf if it is known that named can provide general DNS.

Seems to me to be rather important.

[LaMont Jones (lamont)]

The next upload of bind9 will default to not enabling resolvconf, since there is no way for it to guarantee that it can resolve addresses and is not behind some egress-filtering firewall.

[Peter Lemieux (seijisensei)]

I get the exact same behavior on the Kubuntu Precise desktop beta, though bind9 is not installed. I end up with the resolv.conf posted by the OP with 127.0.0.1 as the nameserver. I cannot override this even with static DNS settings in Kubuntu's network configuration. When the network starts, the manager ignores both the DNS settings on my DHCP-serving router and any static nameserver and search list entries I provide via network configuration.

The notion that bind9 would be installed by default on ordinary client machines is ludicrous.

[Peter Lemieux (seijisensei)]

One other thing: There is no /etc/resolvconf/resolv.conf.d/original, just the "head" and "base" files, on my installation.

[Thomas Hood (jdthood)]

People continue to report the problem that named registers 127.0.0.1 with resolvconf even though named is not set up to forward queries. So I suppose that the upload promised in #6 should happen before Precise is released.

[Launchpad Janitor (janitor)]

This bug was fixed in the package bind9 - 1:9.8.1.dfsg.P1-3

---------------
bind9 (1:9.8.1.dfsg.P1-3) unstable; urgency=low

  [Zlatan Todoric]

  * fixed Serbian latin translation of debconf template. Closes: #634951

  [Peter Eisentraut]

  * Add support for "status" action to lwresd init script. Closes: #651540

  [Bjørn Steensrud]

  * NB Translations. Closes: #654454

  [LaMont Jones]

  * Default to run_resolvconf=false. LP: #933723
  * Deliver named.conf.options on fresh install. Closes: #657042 LP: #920202
  * Do not deliver /usr/share/bind9/bind9-default.md5sum in the bind9 deb.
    Closes: #620007 LP: #681536
  * Deliver and use /etc/apparmor.d/local/usr.sbin.named for local overrides.
    LP: #929563

 -- LaMont Jones <email address hidden> Fri, 17 Feb 2012 14:40:29 -0800

[Saivann Carignan (oxmosys)]

This bug is not fixed!!

With 1:9.8.1.dfsg.P1-3, /etc/resolv.conf still always fallback to 127.0.0.1. If I uninstall bind9 and that I reboot my server, the nameserver is correctly set to 192.168.1.1. But if I install bind9 1:9.8.1.dfsg.P1-3, it immediately overwrites /etc/resolv.conf with 127.0.0.1 even though manual nameservers are set in /etc/network/interfaces and that network-manager is not installed.

This is a real problem with a authoritative non-recursive DNS server, as it is not configured to serve more than its own DNS database. Which means the server becomes itself unable to resolve any domain name!!

[Saivann Carignan (oxmosys)]

OK, here is what happens :

RESOLVCONF=yes must be changed to RESOLVCONF=no in /etc/default/bind9 by the user. The bind9 update won't change this default setting if it is already set.

Therefore it might be important to make sure that this default setting will be included in the final release. Because the update won't update the default configuration.

[Saivann Carignan (oxmosys)]

OK definitively not fixed, RESOLVCONF=yes is added into /etc/default/bind9 when the file is created for the first time by the installation of bind9.. Which is exactly what this fix should have prevented.

I can't go with a complete patch suggestion due to my restricted knowledge in packaging, but the problem seems to belongs to line 87 to 92 of bind9.postinst in the source package :

db_get bind9/run-resolvconf
if [ ! -z "$RET" ] && [ "$RET" = "true" ]; then
   echo "RESOLVCONF=yes" >> $config
else
   echo "RESOLVCONF=no" >> $config
fi

I don't know what $RET refers to, perhaps it interacts with bind9.config?

[Nathan Stratton Treadway (nathanst)]

Saivann,

1:9.8.1.dfsg.P1-3 changes the default value of the bind9/run-resolvconf debconf setting to "false" -- but if that setting has already been set to "true" by an earlier installation of the bind9 package then the RESOLVCONF=yes will still get written to the config file until you manually reconfigure the bind9 package. There's another bug open on that issue: LP: #996088 .

($RET is the return from the db_get function call, which reads the current value of the bind9/run-resolvconf setting from the debconf database.)

Nathan

[Vinit Adhopia (vinitadhopia)]

I'm hoping to understand the status of this a bit better. I am still having issues with my Ubuntu desktop. This seems to have occurred after an upgrade and I've been struggling to find a solution. I am running Ubuntu 12.04.1 LTS and my system is up-to-date.

Here is what my resolv.conf originally looked like. When it looked like this, I was unable to connect to most web sites.
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.0.1
search phub.net.cable.rogers.com

I do not believe bind9 is installed as /etc/default/bind9 does not exist.

One of the workarounds on this thread suggested deleting /etc/resolv.conf and replacing it with /etc/resolvconf/resolv.conf.d/original. After copying /etc/resolvconf/resolv.conf.d/original to /etc/resolv.conf, /etc/resolv.conf now looks like:
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
domain phub.net.cable.rogers.com
search phub.net.cable.rogers.com
nameserver 192.168.0.1

After applying the above workaround, the problem persists. Any ideas on how to resolve this?

It might also be worth mentioning that when I connect to my work VPN, I am able to resolve all websites without issue, though /etc/resolv.conf doesn't look any different.

I am not having any issues on any the other devices on my network, both wired and wireless (Xbox, Android phones, Ubuntu laptop running 11.04 and a MacBook)

Also, could I get some clarification on whether this problem is specific to upgrades only? i.e. If I were to re-install Ubuntu, should I still expect to see this problem?

I would appreciate any help and look forward to hearing back on this.

[Thomas Hood (jdthood)]

Link to similar upstream bug report with title "Please default to RESOLVCONF=no...". (Upstream bug report #483098 is now being tracked in Launchpad by wishlist bug #1091602 with title "Please add resolvconf hook script to generate dynamic forwarders list".)

[Alexis Wilke (alexis-m2osw)]

As I ran in this problem too, I wanted to mention one thing:

The RESOLVCONF=no parameter one can set in /etc/default/bind9 is NOT "in effect" until you reboot.

I put "in effect" between quotes because it is, but bind9 will not delete the file it created on boot:

/run/resolvconf/interface/lo.named

And if resolvconf sees that file, it uses it and ignores the other files. Therefore it looks like the flag does not work.

After a reboot, the /run/... being in RAM, it will have been wiped out and thus it won't include the lo.named anymore.