bind9 registers itself with resolvconf even though it's unable to provide name service
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
bind9 (Debian) |
Fix Released
|
Unknown
|
|||
bind9 (Ubuntu) |
Fix Released
|
Low
|
LaMont Jones |
Bug Description
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:/
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
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
ubuntu@
ubuntu@
# 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@
nameserver 10.189.84.1
ubuntu@
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
Changed in bind9 (Debian): | |
status: | Unknown → New |
Changed in bind9 (Ubuntu): | |
status: | New → Fix Committed |
summary: |
- resolvconf creating bogus resolv.conf file + bind9 registering itself with resolvconf but not set up to forward + queries |
Changed in bind9 (Debian): | |
status: | Unknown → New |
Changed in bind9 (Debian): | |
status: | New → Fix Released |
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.