"nameserver 127.0.0.1" in resolv.conf causes failure of name resolution

[janl]

This has happened a number of times both with some laptops. When they get up resolv.conf contains this:

$ 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 langfeldt.net

This is nowhere like right and makes it impossible to get name-resolution. When I remove resolvconf everything works right. This is right:

$ cat /etc/resolv.conf
# Generated by NetworkManager
domain langfeldt.net
search langfeldt.net
nameserver 192.168.1.1

(except that domain and search should not appear in the same resolv.conf file).

# apt-cache policy resolvconf
resolvconf:
  Installed: (none)
  Candidate: 1.63ubuntu11
  Version table:
     1.63ubuntu11 0
        500 http://no.archive.ubuntu.com/ubuntu/ precise/main amd64 Packages

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: resolvconf (not installed)
ProcVersionSignature: Ubuntu 3.2.0-24.37-generic 3.2.14
Uname: Linux 3.2.0-24-generic x86_64
ApportVersion: 2.0.1-0ubuntu7
Architecture: amd64
Date: Sun May 20 11:00:20 2012
ProcEnviron:
 LANGUAGE=
 TERM=xterm
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: resolvconf
UpgradeStatus: Upgraded to precise on 2012-05-20 (0 days ago)

[Stéphane Graber (stgraber)]

This is actually the expected configuration. The fact that you don't get working DNS resolving might be caused by bug 993379 which should get resolved with the next batch of Network Manager updates (workaround is to reconnect to the network post-boot).

You can learn more about the DNS changes here: http://www.stgraber.org/2012/02/24/dns-in-ubuntu-12-04/ (linked from the official Ubuntu release notes).

[janl (janl)]

On 05/20/2012 08:08 PM, Stéphane Graber wrote:
> This is actually the expected configuration. The fact that you don't get
> working DNS resolving might be caused by bug 993379 which should get
> resolved with the next batch of Network Manager updates (workaround is
> to reconnect to the network post-boot).
>
> You can learn more about the DNS changes here:
> http://www.stgraber.org/2012/02/24/dns-in-ubuntu-12-04/ (linked from the
> official Ubuntu release notes).

Brilliant phrasing: "The expected configuration" falls so hard into the
deep black hole of bug number 1 that there is no come back.

I wonder what the people that don't know about /etc/resolv.conf and
resolvconf do.

Regards,
  Nicolai

[Thomas Hood (jdthood)]

People who don't know about resolvconf won't be so clever as to remove it as a way of solving a name resolution problem in another package.

In the submitted file, "nameserver 127.0.0.1" correctly refers to the caching nameserver (dnsmasq) listening on that loopback address. If dnsmasq doesn't resolve names --- by forwarding queries (to 192.168.1.1, in the submitter's case) --- then that is a matter to be taken up with the dnsmasq maintainers.

[Steve Langasek (vorlon)]

On Sun, May 20, 2012 at 07:05:10PM -0000, janl wrote:
> Brilliant phrasing: "The expected configuration" falls so hard into the
> deep black hole of bug number 1 that there is no come back.

It doesn't for the vast majority of users.

Do you have a local nameserver installed on your system? This is one
explanation for the behavior you're seeing - i.e., you may be hitting bug
#996088.

Another possibility is that, by installing dnsmasq and resolvconf, the
settings from your DHCP server are now being correctly provided to
/etc/resolv.conf and these settings are themselves incorrect (which you can
verify by checking /run/nm-dns-dnsmasq.conf).

> I wonder what the people that don't know about /etc/resolv.conf and
> resolvconf do.

Generally, those people are quite happy with the results in 12.04. It's the
users who know about /etc/resolv.conf and are doing non-standard things with
it that manage to find the bugs. :)

[janl (janl)]

On 05/20/2012 10:56 PM, Thomas Hood wrote:
> People who don't know about resolvconf won't be so clever as to remove
> it as a way of solving a name resolution problem in another package.
>
> In the submitted file, "nameserver 127.0.0.1" correctly refers to the
> caching nameserver (dnsmasq) listening on that loopback address. If
> dnsmasq doesn't resolve names --- by forwarding queries (to 192.168.1.1,
> in the submitter's case) --- then that is a matter to be taken up with
> the dnsmasq maintainers.

There is no dnsmasq running on my laptop. It is installed but not
running. So I guess that is the _real_ problem?

Nicolai

[Thomas Hood (jdthood)]

Nicolai: You say that the dnsmasq package is installed but that no dnsmasq process is running. How did you disable dnsmasq?

Also, please send the output of this command run in a terminal on the system in question:

    dpkg -l \*dnsmasq\*

[janl (janl)]

On 05/22/2012 12:14 PM, Thomas Hood wrote:
> Nicolai: You say that the dnsmasq package is installed but that no
> dnsmasq process is running. How did you disable dnsmasq?

I don't think I did. For hor many versions of ubuntu has it been
supposed to be running?

> Also, please send the output of this command run in a terminal on the
> system in question:
>
> dpkg -l \*dnsmasq\*

un dnsmasq <none> (no description available)
ii dnsmasq-base 2.59-4 Small caching DNS proxy and
DHCP/TFTP server

The binary is from the base package.

Nicolai

[Thomas Hood (jdthood)]

Nicolai: I'm glad I asked because my first thought was that you might have the "dnsmasq" package installed and disabled in a non-standard way. The "dnsmasq" initscript sends "nameserver 127.0.0.1" to resolvconf unless the dnsmasq service is disabled in a standard way. But you don't have the "dnsmasq" package which contains the aforementioned initscript, so this can't be the problem.

We need to find out where that "nameserver 127.0.0.1" line is coming from. It shouldn't be there if you have no caching/forwarding nameserver running.

Please install resolvconf, reboot, confirm that you have resurrected the problem and send the output of:

ls -l /etc/resolv.conf
lsattr /etc/resolv.conf
ls -l /run/resolvconf
ls -l /run/resolvconf/interface
for F in /run/resolvconf/interface/* ; do echo "=== $F ===" ; cat "$F" ; done
for F in /etc/resolvconf/resolv.conf.d/* ; do echo "=== $F ===" ; cat "$F" ; done

[Thomas Hood (jdthood)]

Nicolai: Please also do the following.

dpkg -l bind9
ps -ef|grep dns
ps -ef|grep named

(That is, run these in a terminal and post the output here.)

[Thomas Hood (jdthood)]

Nicolai: In addition to what I asked for above (##8, 9) also please post the contents of your /etc/NetworkManager/NetworkManager.conf file.

[janl (janl)]

So, installed resolvconf and with a bit more determination than just "WTF that's wrong" I rebooted, logged in and netstat -lnp showed that named was listening on port 53. Of course it is, I fiddle with DNS now and again (http://www.amazon.co.uk/The-Concise-Guide-BIND-guides/dp/0789722739/ref=sr_1_3) and it is _very_ handy if I suddenly find myself in a place with broken DNS-resolution. Which still happens.

So, my local resolver uses the default root hints file and therefore bypasses the local network firewalls dnsmasq server which serves up the addresses to be used for the mail-server and other things at home.

But mostly I don't need it so I use the DNS-server provided by DHCP and this is what I want unless I find myself somewhere where it is needed to override it.

So the use of resolvconf short-circuits this setup, sends the queries to the local BIND and it in turn buypasses the helpfull firewall dnsmasq. Resulting in bypassing the DHCP given DNS-server. I guess bind9 satisfies some "resolver" dependency in resolvconf but then _still_ overrides the already configured named.conf on the host breaking the admins assumptions about where to resolve things.

This will break on ubuntu servers that authoritative non-recursive name servers.

I think resolvconf should only step in in this way if dnsmasq is running and not if BIND is running since BIND could very well be non-recursive. Or at the very least have a installation time question about this.

[Steve Langasek (vorlon)]

As already mentioned, this in bug #996088. Marking as a duplicate.