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)
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.
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.
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…
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.
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.
Also,
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)
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)
Could i also add, if this file is not supposed to have had nameserver 127.0.0.1 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 127.0.0.1 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.
