Please also truncate nameserver list after a loopback address in resolv.conf.d/head

[MarianoAbsatz]

I created a /etc/default/resolvconf file with the option:
TRUNCATE_NAMESERVER_LIST_AFTER_LOOPBACK_ADDRESS="yes"
in it.

The contents of /etc/resolvconf/resolv.conf.d/head are:
########################################
# 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

# local resolver (unbound)
nameserver ::1
nameserver 127.0.0.1
########################################

However, after rebooting, I still get my ISP's DNS servers below mine.

[Thomas Hood (jdthood)]

Thanks for the report, but the behavior you describe is correct. The "head" and "tail" files are always included in the dynamic resolv.conf file without any change.

Of the files in /etc/resolvconf/resolv.conf.d/, only the "base" file has contents subject to truncation. That is a better place to put your two "nameserver" lines. (An even better place is /etc/network/interfaces .)

[Steve Langasek (vorlon)]

Hi Thomas,

> Of the files in /etc/resolvconf/resolv.conf.d/, only the "base" file has
> contents subject to truncation.

Ok, but why should that be? The issue isn't that there are contents *in* /head that should be truncated; the issue is that the contents of /head don't trigger truncation of entries from other sources, and they really ought to. Note that the *only* servers listed in /head in this example are loopback. The user actually did this at my suggestion, because I assumed resolvconf's behavior would be to honor /head, then discard other sources because a loopback resolver is present.

This seems the logically consistent behavior to me, even if it requires adding additional parsing of /head that isn't currently happening.

[Thomas Hood (jdthood)]

Hi Steve.

I see what you are saying. Hmm.

Resolvconf works in this respect as originally intended and I don't think that there is anything wrong with specifying that "head" will be prepended verbatim, "tail" will be appended verbatim, and "base" will be combined with dynamic content and subjected to ordering and truncating. That's easy to understand and implement. True, what's in head won't trigger truncation, but it also won't obey interface-order(5). So I wouldn't characterize the current behavior as inconsistent. If the documentation doesn't make it clear how things currently work then that is a documentation bug which should be fixed in the next release unless we decide to change the behavior.

On the other hand I am happy to discuss the possibility of changing the behavior so that the contents of "head" are taken into account when applying the truncation rule.

1. Impact on existing users

If we change the behavior I don't think there is anyone who will be inconvenienced. There is probably no one out there who wants to put a loopback address in the "head" file and *not* have this trigger truncation.

2. Implementation

What if the "head" file itself contains a loopback address and then another address? For consistency I suppose we would indeed have to truncate between the first and the second, otherwise we would not be truncating after the first loopback address.

3. Usefulness

I don't think that the proposed behavior is very useful. First, if you have resolvconf, a dynamic resolv.conf writer, then it's better to have correct contents in resolv.conf rather than force this file to contain a static nameserver list which is false whenever the local nameserver is not running. Second, there are already two methods of forcing the nameserver list to be exactly the following line.

    nameserver <loopback-address>

A good method is to add a line

    dns-nameservers <loopback-address>

to the "iface lo inet loopback" stanza in /etc/network/interfaces. Another method, which we don't want to encourage but is in fact frequently employed, is to replace the symbolic link /etc/resolv.conf with a static file containing the line in question.

Conclusion: Because I don't currently see the need to implement the change, I'd favor the lazy, conservative course of not implementing it.

[Thomas Hood (jdthood)]

Under discussion

[Steve Langasek (vorlon)]

"opinion" means "this request is a matter of opinion and the maintainer disagrees". That seems to be the opposite of what you mean by "under discussion".

[MarianoAbsatz (el-baby)]

So... I add the 'dns-nameservers 127.0.0.1' entry to /etc/network/interfaces but it seems to be completely ignored.

I tried adding it to the eth0 entry, to the loopback entry and to both, and everytime I restart networking I get my ISP's nameserverrs on /etc/resolv.conf.

My current /etc/network/interfaces file look like this:

auto lo
iface lo inet loopback
 dns-nameservers 127.0.0.1

auto eth0
iface eth0 inet dhcp
 dns-nameservers 127.0.0.1

[Thomas Hood (jdthood)]

The dns-nameservers option will only have an effect when ifup is used. I am not sure what you mean by 'restarting networking'. The lo interface is normally only ifup'ped at boot time, but you can ifdown-ifup it by hand. (Or you can reboot.)

I just tested this on my machine. I edited /etc/network/interfaces and added a line "dns-nameservers 127.0.0.1" to the "iface lo" stanza.

    auto lo
    iface lo inet loopback
        dns-nameservers 127.0.0.1

Then in a terminal I became root

    sudo su

and I ifdown-ifupped the "lo" interface

    ifdown lo
    ifup lo

with the result that /etc/resolv.conf contained the following.

    # 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

The lo stanza is the appropriate stanza to put it in. Under some circumstances you can also but the dns-nameservers option in the eth0 stanza, but note that if you have

    [ifupdown]
    managed=true

in /etc/NetworkManager/NetworkManager.conf then NetworkManager brings up eth0 but it ignores the "dns-nameservers" option. On the other hand if you have

    managed=false

then eth0 should be ifupped at boot along with lo and the dns-nameservers option should work. But I repeat that for a local caching nameserver the "iface lo" stanza is the appropriate place to put a dns-nameservers option if you really want to have one.

I want to add that normally you don't have to put a "dns-nameservers 127.0.0.1" option anywhere. Every nameserver in Ubuntu that listens by default on 127.0.0.1 tells resolvconf to add the "nameserver 127.0.0.1" line to resolv.conf when the nameserver starts and tells resolvconf to remove that line when it stops. If that is not happening on your machine then we should find out why not and fix that. (Open a new bug report for that.)

[MarianoAbsatz (el-baby)]

You're right, Thomas.

Thanx a lot for your help.

I thought that restarting the "networking" service would ifdown/ifup all interfaces... well it does all of them BUT "lo" :)

I connected to the server through a terminal server and could test it and it works fine now (I don't have phisical access and was afraid of locking myself out of the server).