Internal DNS Server Issues (no resolutions)

Is this happening for other computers?  If not, have you tried flushing the DNS cache on your computer? (I'm guessing you have.)

If you restore a config backup from before this started, do you still have the same problem?

Cheers - Bob

Hi Bob, yes it is happening on all computers. Happening after factory reset and fraction of a rebuild too which is odd.

I went to install XG and that install had issues (did NOT like the product once it was installed - layout was too different and I don't like WiFi int's etc when there are none physically .... an OCD thing I guess) but now EVERY time I go to reinstall UTM9 I get a install.tar or similar file is missing. from both the original iso and the newly downloaded one (put onto usb flash trying both balena etcher and rufus). I'm starting to query hardware failure though that still doesn't quite account for why I still had internet through it just no internal name resolutions despite the static list being WELL populated.

When I'd do a restore or restart from scratch it would work for a minute or so on 1 computer then splat again.

I'm at a loss on it aye. It's been BRILLIANT and faithful for years now just recently it's not. No changes were made even.

What brought the problem to light was the QNAP had a busted lead so I took LAN3 out of aggregate on the QNAP for a bit, rebuild the leads and patch panel for boxes in the rack recently and hooked all 4 in and LAN3 got a different .197 address. Once I realised something as amiss there I re-did the link aggregation so ALL 4 were as one (.001) and then noticed every computer refused to drop the .197 so started nslookup's etc and noticed they were all failing.

I have rebuilt netstacks on a few machines, done all the flushdns' etc without change. The box resolves instantly for external but nothing internal. It's the only DNS and DHCP server internally and as I said that static mappings is WELL populated to keep the regular machines inside their own range (OCD control thing) so there should not be anything arguing.

Fix 1 problem get 4 more it seems.

Hi Bob, yes it is happening on all computers. Happening after factory reset and fraction of a rebuild too which is odd.

I went to install XG and that install had issues (did NOT like the product once it was installed - layout was too different and I don't like WiFi int's etc when there are none physically .... an OCD thing I guess) but now EVERY time I go to reinstall UTM9 I get a install.tar or similar file is missing. from both the original iso and the newly downloaded one (put onto usb flash trying both balena etcher and rufus). I'm starting to query hardware failure though that still doesn't quite account for why I still had internet through it just no internal name resolutions despite the static list being WELL populated.

When I'd do a restore or restart from scratch it would work for a minute or so on 1 computer then splat again.

I'm at a loss on it aye. It's been BRILLIANT and faithful for years now just recently it's not. No changes were made even.

What brought the problem to light was the QNAP had a busted lead so I took LAN3 out of aggregate on the QNAP for a bit, rebuild the leads and patch panel for boxes in the rack recently and hooked all 4 in and LAN3 got a different .197 address. Once I realised something as amiss there I re-did the link aggregation so ALL 4 were as one (.001) and then noticed every computer refused to drop the .197 so started nslookup's etc and noticed they were all failing.

I have rebuilt netstacks on a few machines, done all the flushdns' etc without change. The box resolves instantly for external but nothing internal. It's the only DNS and DHCP server internally and as I said that static mappings is WELL populated to keep the regular machines inside their own range (OCD control thing) so there should not be anything arguing.

Fix 1 problem get 4 more it seems.

Whack-a-mole - frustrating!

What happens if you ping one of the internal FQDNs from the 'Support >> Tools' 'Ping' tab?

Cheers - Bob

The install.tar file problem is a common issue when rebuilding from a USB drive and/or CD drive using USB.

"Error: install.tar wasn’t found on the installation media."

This happens because during part of the installation process. the USB drive is un-mounted and needs to be mounted again.

Reboot and load all the way up to where it wants to start the install.  Hit ALT + F2 and you get a console.

Type:  mount /dev/sdb1 /install (hit Enter)

Hit ALT + F1 and it takes you back to the installation.  Run at your leisure.

I've had plenty of experience with this one.  ;)  It's just become part of my installation if I ever need to rebuild my UTM.

Doing a ping or nslookup from ssh/putty was netting appropriate (correct) responses.

Thanks Amodin I'll give that a burl a little later and see if I can get a working install again.

Same result if you ping from inside WebAdmin, Glen? (I would expect so, but I might be a little OCD, too. )

Cheers - Bob

Amodin said:

Type:  mount /dev/sdb1 /install (hit Enter)

This returns "failed: device or resource busy" :(

I finally got that working (seems some weird clash with running the installer through ventoy). So I've a new clean install fnished, restored the old backup and same issue so it's not hardware or OS based.

--------------------

When I go to nslookup I get this...

C:\Users\glen>nslookup qnap
Server:  router
Address:  192.168.1.254

*** router can't find qnap: Non-existent domain

C:\Users\glen>

The static list in Sophos I have can be seen here and you'll note that it's as you'd expect for a DNS server.

orileynetworks-my.sharepoint.com/.../EVUGipX8jS5Ml25KrA1leeEBmSgy9PUxf_79KVKJurNj3w

I'm surprised your DNS worked in that setup.  I've never ever had any luck with just names, they had to be FQDN (qnap.(xxxx).home and not just qnap) for me to get any DNS working right, not only for internal, but when I VPN in as well from the outside.

It always worked in Windoze server DNS setups too just pinging a machine name.

Well you got me to thinking Amodin. I thought you meant you need to ping device.domain (or nslookup for that).I then remembered that whilst you just put device name in for MS DNS, the service itself would table that as device.domain in the table.

** For future readers here ..... I've gone through to DHCP and changed the domain to "lan" then did an nslookup "cctv" and it failed (rightfully so I guess) then changed the DNS name to cctv.lan and repeat the nslookup with an instant pass.

I'd forgotten the extra steps over the years and a stroke in between did no favors.

So I can still "nslookup device" (no .lan after) and it'll work 100% but it NEEDS that .domain in the name table in the static device mapping it would appear.

The setup without the .domain used to work but they've changed something at some point and it stopped... who knows what or when.

So thank you Amodin for at least prompting me to think why your "surprised it ever worked like that". Apparently that stroke killed off a bit too much of the memory.

Hey, glad to have helped!  ;)