Comment 3 for bug 1035098

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.