Virtualmin is configured to setup DNS zones, but this system is not setup to use itself as a DNS server. Either add 127.0.0.1

The subject heading is a repetition of many before, since around 2010, all asking for a solution. I just want to point out two errors in the error message itself.

  1. Virtualmin prints the error message: “It appears that DHCP is being used to dynamically configure your network interfaces, … Using a static IP address is strongly recommended with Virtualmin.”

    Almost every cloud server gets a static IP address via DHCP. The DHCP protocol is just a mechanism used here for assigning a static IP address good for the life of the server. The IP address is dynamically configured only in the sense that it is assigned when the server boots. But it’s already a static IP address, and there is no need to ask the user to use a static IP address.

  2. Virtualmin prints the error message: “this system is not setup to use itself as a DNS server. Either add 127.0.0.1 to the list of DNS servers…”. This too may be incorrect in some or many situations.

    There is no guarantee that /etc/resolv.conf is consulted by the resolver library. In Ubuntu 20.04, for example, if you use the command “resolvectl status”, it will print the DNS servers in use, and there need not be any overlap between these and the ones listed in /etc/resolv.conf.

    Virtualmin should detect the actual DNS servers in use by whatever mechanism applies, and not simply search the /etc/resolv.conf file.

  1. This is tricky, because we see a lot of users try to run Virtualmin on systems with a truly dynamic IP, which doesn’t work. You can ignore this message if DHCP is assigning a constant IP.

  2. Doesn’t whatever manages DNS resolvers also update /etc/resolv.conf on Ubuntu, for the benefit of other binaries?

There is a third error that I did not mention. Once Virtualmin notices that DHCP is in use, it stops checking further for configuration errors. All checks should be done, and the user given a complete list of results, even if one check fails.

If there is a minority trying to use Virtualmin on a dynamic IP address, it’s best to identify them and give only them the current warning based on DHCP. For everyone else, the error message is incorrect and may be considered a bug.

I don’t think /etc/resolv.conf was ever intended for programmatic use by anything except the resolver itself. It was only a question of time before such use became erroneous. I don’t see any portable way of figuring out which DNS servers are actually consulted by the resolver. So you may have to probe each OS version to figure out how, specific to that OS version.

All these issues can be quickly solved by providing an override button of the type “Not an error, don’t warn me again”.

Also, the current classification of OSes as grade A or not A might be too broad. Perhaps we need ratings more like AAA, AA, A, B, …, where AAA means the above errors won’t occur.

I don’t know about Ubuntu, but a workable kludge on CentOS is to populate /etc/resolv.conf with known-good resolvers, add a line nameserver 127.0.0.1, and make the file immutable. It’s ugly and inelegant, but it works.

Richard

You can have Virtualmin skip these DNS and DHCP checks by adding the line dns_check=0 to the end of /etc/webmin/virtual-server/config

That said, Virtualmin should read the resolvers from the Netplan config if in use. On Ubuntu systems that are seeing this incorrect error, is /etc/resolv.conf a file or symlink? And are the correct resolvers listed in a file under /etc/netplan ?

1 Like

I didn’t find any /etc/netplan file in Ubuntu 20.04. /etc/resolv.conf is a symlink pointing to …/run/systemd/resolve/stub-resolv.conf.

There is another file /run/systemd/resolve/resolv.conf that (probably) contains the actual name servers consulted by the resolver, but I don’t think there is any guarantee that this will always be the case.

I force some systems to use the DNS servers of my choice by editing the following file:

/etc/update-resolv-conf.sh

And add these lines:

foreign_option_1=‘dhcp-option DNS 1.1.1.1’
foreign_option_2=‘dhcp-option DNS 1.0.0.1’

1 Like

On a different Ubuntu 20.04 machine, the resolv.conf file says that the command to get the actual name servers is:

systemd-resolve --status

The command that I previously documented (above), which also works, is:

resolvectl status

I think they’re trying to tell us to stop parsing resolv.conf.

Currently the error message provides only two alternatives:

I think it should also mention dns_check=0.

Good idea, I’ll add that

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.