Temporary failure resolving 'software.virtualmin.com'

What might be causing the error below?
I cant install any updates on Virtualmin GPL system (which is my backup for Virtulamin Professional mail server)

Err:1 Index of /vm/6/gpl/apt virtualmin-universal/main amd64 usermin all 1.803
Temporary failure resolving ‘software.virtualmin.com

mxtoolbox returns the following…i havent touched the server settings in ages, so i dont know why all of a sudden this is happening?

SMTP Banner Check Reverse DNS does not match SMTP Banner More Info
SMTP TLS Warning - Does not support TLS. More Info
SMTP Transaction Time 24.312 seconds - Not good! on Transaction Time More Info
SMTP Reverse DNS Mismatch OK - 123.456.789 resolves to host1.domain.com.au
SMTP Valid Hostname OK - Reverse DNS is a valid Hostname
SMTP Connection Time 0 seconds - Good on Connection time
SMTP Open Relay OK - Not an open relay.

The error says exactly what it was. A temporary name resolution failure.

I broke our DNS while migrating it, and then I fixed it.

I am still getting the same error…its not resolving on my system.

Err:1 Index of /vm/6/gpl/apt virtualmin-universal/main amd64 usermin all 1.803
Temporary failure resolving ‘software.virtualmin.com
Err:2 Index of /vm/6/gpl/apt virtualmin-universal/main amd64 webmin all 1.955
Temporary failure resolving ‘software.virtualmin.com
Err:3 Index of /vm/6/gpl/apt virtualmin-universal/main amd64 webmin-ruby-gems all 1.9
Temporary failure resolving ‘software.virtualmin.com
Err:4 Index of /vm/6/gpl/apt virtualmin-universal/main amd64 webmin-virtual-server all 6.12.gpl
Temporary failure resolving ‘software.virtualmin.com
Err:5 Index of /vm/6/gpl/apt virtualmin-universal/main amd64 webmin-virtualmin-awstats all 5.11
Temporary failure resolving ‘software.virtualmin.com
Err:6 Index of /vm/6/gpl/apt virtualmin-universal/main amd64 webmin-virtualmin-dav all 3.13
Temporary failure resolving ‘software.virtualmin.com
Err:7 Index of /vm/6/gpl/apt virtualmin-universal/main amd64 webmin-virtualmin-git all 1.14
Temporary failure resolving ‘software.virtualmin.com
Err:8 Index of /vm/6/gpl/apt virtualmin-universal/main amd64 webmin-virtualmin-htpasswd all 2.11
Temporary failure resolving ‘software.virtualmin.com
Err:9 Index of /vm/6/gpl/apt virtualmin-universal/main amd64 webmin-virtualmin-init all 2.10
Temporary failure resolving ‘software.virtualmin.com
Err:10 Index of /vm/6/gpl/apt virtualmin-universal/main amd64 webmin-virtualmin-registrar all 2.10
Temporary failure resolving ‘software.virtualmin.com
Err:11 Index of /vm/6/gpl/apt virtualmin-universal/main amd64 webmin-virtualmin-slavedns all 1.13
Temporary failure resolving ‘software.virtualmin.com
Err:12 Index of /vm/6/gpl/apt virtualmin-universal/main amd64 webmin-virtualmin-sqlite all 1.8
Temporary failure resolving ‘software.virtualmin.com
Err:13 Index of /vm/6/gpl/apt virtualmin-universal/main amd64 virtualmin-config all 6.0.31-1
Temporary failure resolving ‘software.virtualmin.com
Err:14 Index of /vm/6/gpl/apt virtualmin-buster/main amd64 virtualmin-lamp-stack all 6.0.12+deb-10
Temporary failure resolving 'software.virtualmin.com

Here are my current package repositories as shown in webmin>software package updates

buster/main Yes Index of /debian
buster/updates/main Yes Index of /debian-security
buster-updates/main Yes Index of /debian
buster-backports/main Yes Index of /debian
virtualmin-buster/main Yes Index of /vm/6/gpl/apt
virtualmin-universal/main Yes Index of /vm/6/gpl/apt

what is a workaround for this so i can run the latest updates?

Have you hardcoded an IP for the hostname software.virtualmin.com on your system? Is your DNS recursive resolver working or is it serving cached results?

I can’t think of any reason it wouldn’t be working. The problem that caused the initial report has been fixed a couple days ago. Any new problem with the same symptom has to be something else.

Edit: Actually, I guess it can’t be hardcoded, since you’re seeing a name resolution failure…it’d just be a timeout or a 404 or something if it were going to the wrong IP.

what should i do as a workaround Joe?

is there a way for me to manually assign a dns resolution in Virtualmin for updates that will work? I ask this because i am wondering if i may have inadvertantly at some time in the past done something that might have stuffed this? (although this particulary server was setup earlier this year and i largely left it to its own devices running autoupdates because it only acts as a backup mail server)

Also, i tried to run a separate update notification on this server for webmin…

Failed to upgrade from www.webmin.com : Failed to lookup IP address for www.webmin.com

Maybe clear the Bind cache:

# rndc flush
# rndc reload

and if successful, try pinging the update server from your server:

# ping -c 5 software.virtualmin.com

If you get a response, try the updates again. If not, then most likely you have a problem with your upstream resolvers. I’d try new ones.


Your local DNS is broken somehow. Webmin.com is a wholly separate zone and did not have the problem that virtualmin.com had (and is working fine, and was not broken at any recent point to the best of my knowledge…though I don’t manage that zone, so I’m not entirely sure of that).

See if your server can resolve any outside domains (e.g. host google.com on the server). Presumably recursive lookups are failing. You’ll have to figure out why…you can check the named logs for clues. This is assuming you use the server for DNS; it may be you’re configured to use outside servers and they’re failing. Usually this is in /etc/resolv.conf, but may need to be set elsewhere if your system uses dhcp or has otherwise dynamically configured network.

Also, if we need to keep this conversation going, please start a new topic. Yours is not the same problem as OP, even though the error message is the same.

Ummm… He is the OP, Joe…


1 Like

Oh, shoot. I’m an idiot.

Nevermind. :wink:

Also, I’ve unmarked this solved, since the original problem is the problem that continues to exist, and that problem is whatever is causing DNS recursive lookups to fail on Adam’s server.

1 Like

root@server2:~# rndc flush
rndc: connect failed: connection refused

when i goto webmin>webmin servers index> my server1 i get

Failed to lookup IP address for server1.domain.com (where domain.com is my other server that this one is supposed to be linked too in webmin).

the same error happens when doing this from server1 to server2 in webmin servers index.

this is really strange, i 100% have not touched anything to do with this since i first networked these servers earlier this year. something in updates has screwed this up, however, i havent a clue where to even start looking.

if i goto mxtoolbox and do a dns lookup on both servers, they resolve no problems from the outside…so they are 100% visible on the www and server1 has websites on it that are resolving no problems.

Joe, my /etc/resolve.conf on server2.domain.com doesnt exist…there isnt that file even in /etc/resolveconf/

i dont follow what you mean about /etc/resolve.conf…that is not a file on either server…

Searching for resolve.conf . . . . found 0 results :

No Webmin modules or pages matching resolve.conf were found.

there is only a link to /run/resolve.conf (where is that exactly?) I dont run any internal nameservers on these systems btw, i use external dns hosting at my registrar)

It’s /etc/resolv.conf (no second “e” in “resolv”).

What’s in there?


Are you sure that named is even running?

# systemctl status named


hi richard,
thanks for your reply,

systemctl status named returns

unit named.service could not be found

I dont use this system as a nameserver…i use external dns hosting for all domains on both of my virtualmin servers (my other system “server2” is simply a backup mail server for mx2 records)

ill post /etc/resolv.conf if i can find it

nano /etc/resolv.conf

Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)



I went into /etc/resolv.conf and commented out


and added


now the update runs no problems.

however, i dont see this as being a fix. is it?

Could i also add, if this file is not supposed to have had nameserver in it, because i dont use my system as a dns server, then how is it that 2 servers that have been running without problems for many months all of a sudden have now experienced this issue and i havent touched anything to do with this on either of them in months?

I had both of these systems working perfectly in webmin>webmin servers index…they both were resolving each other and running updates no problems for ages. I honestly have not touched them in any way other than to run updates as shown in virtualmin update panels on both systems.

This says to me that at some point in the last 12 months, virtualmin updates have overwritten settings on my systems and screwed them up! Not good!

Typically, /etc/resolv.conf would have nameserver entries for plus two or more upstream nameservers. But I really have no idea how DNS resolution on a Virtualmin server works if you’re using external DNS. I’m afraid someone smarter than I am will have to taken it from here.

Fortunately, people smarter than I am are easy to find. In any random group of three of which I am a member, you’re likely to find two of them.


thanks richard.
what i suspect has happened is the following…

when i setup these systems, i did not install them as local nameservers. I never setup my vps that way because my domain registrar provide free dns hosting. All my clients on my systems use registrars with the same policy (ie free dns hosting)

I provide mail services on both these systems (where server2 is the backup mx record) as well as websites on server1. So i linked both of them through webmin>webmin servers index and they have been singing along nicely for many months.

at some point recently, the dns resolution settings on both systems has gone haywire. Now i know 100% i havent touched them in ages. I have basically let them look after themselves in that i just ensure that updates are run whenever they are offered in virtualmin and debian. Other than that, i havent tinkered with anything to do with the hosts files on either system.

the fact that 2 completely separate systems have experienced the same failure tells me that what has happened is a direct result of an update at some point using a generic setting in its scripts that has overwritten important settings on both of these systems that i configured myself in the past.

my suspicion is that this generic script setting written into the updates has presupposed that all virtualmin systems are running as nameservers!

in any case, how do i ensure that my changes in /etc/resolv.conf are not overwritten now?

Not necessarily, nor even likely. /etc/resolv.conf is actually a dynamically-created file.

I often make it immutable to prevent DHCP from overwriting it on reboot, but that’s really not the right way to do it.

Red Hat recommends replacing /etc/resolv.conf with a symlink to a manually-configured file if you want to manually configure it. Debian / Ubuntu have some other way of doing it, but I don’t remember it offhand.