I have spent weeks reading and trying things and cannot resolve this. I always try to sort it myself before asking for help. If I ask for help it is because I am stuck. I am currently reading about how to flush the caches to see if that helps. I have also searched the entire server for references of that IP address and it reports that it does not exist. perhaps the grep command I used was wrong? I tried:
grep -rl “213.186.33.99” /
Is there another search I should use?
Also, when I run it I get a long list of “permission Denied”, “Invalid argument” and “Input/output error” listings so it is not searching those files. how do I make the search get inside those file (I am logged in as root)?
Cleared bind cache and reloaded. Inserted my DNS Servers to network configuration and applied the configuration. It returns with the single incorrect server!!!
Where is it getting this information from?
I have now checked and read through all startup services and tried to understand systemd but I cannot find any reference to the server establishing 213.186.33.99 as my dns server. I cannot move forward without some clear help.
Well I have managed a workaround that prevents resolve.conf being overwritten by using
chatter +i resolv.conf
but this is a plaster on a boil and I want to lance the boil so I would still appreciate assistance on it.
I am now going to try to discover why bind is not showing my zone. Any guidance please on where to start?
As with resolve.conf above, I have managed a solution but it does not explain why this is happening.
To overcome the problem I;
I then created a new virtual server test.xorex.rocks and it immediately became visible in bind.
The original (non-showing) entry generated in /etc/bind/named.config.local was as follows:
zone “xorex.rocks” {
type master;
file “/var/lib/bind/xorex.rocks.hosts”;
allow-transfer
127.0.0.1;
localnets;
213.251.188.141;
2001:41d0:1:4a8d::1;
};
};
The replacement was simpler:
zone “xorex.rocks” {
type master;
file “/var/lib/bind/xorex.rocks.hosts”;
};
Yet the new virtual server is visible with the entry:
zone “test.xorex.rocks” {
type master;
file “/var/lib/bind/test.xorex.rocks.hosts”;
allow-transfer {
127.0.0.1;
localnets;
213.251.188.141;
2001:41d0:1:4a8d::1;
};
};
and if I then re-insert the original entry and restart bind it still shows the zone so this is not what is causing the original problem.
Joe, I have read lots of posts on google with this problem and all are using a workaround. I believe it is either a virtualmin problem or a compatibility issue with Debian 10. Is this something you could look into please?
@reeza. Please see the workaround I sorted. It should work for you as well but let me know if it does or not.
If an IP gets written within the BIND service, its most likely a setting from your hoster and from virtualmin. I think its more likely to be the first.
Which bind version do you use?
dpkg -l bind9bind9 1:9.11.5.P4+dfsg-5.1 amd64 Internet Domain Name Server
Sitting on Debian 10
I contacted the hoster and they just do not want to know! Have not even responded to my ticket despite bumping it several times. If I have disabled the cloud initiation services, and flushed the cache for bind, how can it be rewriting the resolv.conf file? the behaviour is quite unusual and I cannot think why it is happening.
If your hoster is pre-setting that in his system, then you cant change it. I am currently not sure if its really that or something you did.
You can try to install the latest BIND9 version from the backports repo.
Thank you so much for the effect you have put in with this @GeoffatMM
I read through everything here, and I thought id try this first before I start anything, and so far it’s worked (still testing).
sudo apt-get install rblcheck bind9 bind9utils bind9-doc dnsutils
sudo reboot
That’s it, my domain zone has re appeared and seems to be working as it should.
Cheers, Leo.
Hi, tried but it did not work for me (on a second test site I have installed with another host).
My solution appears to have worked as all new sites are now registering. Maybe the next update will clear the problem.
Yep, tested another and it didn’t work 
I’ve used your work around and that’s working for now. Thanks again.;
@reeza
That will only give you the latest BIND9 version from the repo which is the one @GeoffatMM uses.
@GeoffatMM
You still might want to update BIND9 from the backport repo or use the bind repo from sury.
It is currently updated through backport. I now have it working and am going to leave it for now. I was just hoping that @Joe would look at the post and see if it is a virtualmin issue on Debian 10.
I have now solved both the initial problems. Bind is working as it should, my workaround has reset the dns settings and today I successfully organised the SSL certs after rebuilding the virtual server once again! Not all sub entries are yet on the certificate as both mail and webmail currently make it fail but I will wait once more and post something new if it is still an issue. I have copied the cert I have generated to the various modules so hopefully all should now work.
The next task is to set up the mail servers. Such fun! (You need to be a fan of Miranda, a UK comedienne, to appreciate that).
Thanks for all your inputs.
This post is now closed.
I doubt its a general issue, since I am not running into your mentioned issues. But that doesnt have to mean anything.
Postscript: Mail servers worked first time on the new server.
Thanks @DrCarsonBeckett.
I have enabled both backport and sury, but they are telling me “bind9 is already the newest version (1:9.11.5.P4+dfsg-5.1)”
Cheers.
That version isnt the latest one you can get.
Try the following command: apt install -t buster-backports bind9 .
Thanks DrCarsonBeckett, still have the same issue saying it’s the latest.
apt install -t buster-backports bind9
bind9 is already the newest version (1:9.11.5.P4+dfsg-5.1)
Anyway not to worry, i’ll just use and other distro.
Cheers.