Weird DNS Issue ...

[thecomputerguy]

Dental client uses https://www.3shape.com/ Software to send 3D Images to labs. The ability to send stopped working and I worked for a couple hours trying to resolve it.

Tech support had me opening and closing ports and this and that but none of it made sense because the connection isn't inbound it's outbound. The data is sent from our in-house laptop the laboratory.

I ruled out DNS early on because I changed the stations DNS from our local DC/File server which also handles DNS to Google DNS.

We were about to give up and have the Doctor take the laptop home to try it on her internet when on a whim I decided to restart the DNS server in our Server. BAM Fixed!

Now today, same issue. Do basic troubleshooting then again, login to the Server and stop and start the DNS server and it sends fine again.

I can't have the doctor logging into the Server just to restart the DNS server every time she wants to send a 3D scan ... any ideas?

 

[HCHTech]

I think I'd be combing through the logs for hints. I remember writing a script to restart some service or another every 12 hours for some recalcitrant LOB app several years ago - I'd only do that as a last resort, though.

 

[Computer Bloke]

"It's not DNS. There is no way it's DNS. It was DNS." -- SSBroski.

The next time it happens, run ipconfig /displaydns on the workstation and save the output to a file. Then run ipconfig /flushdns and retest; if the problem's gone away then it's something to do with an incorrect or outdated DNS entry on the workstation. Running ipconfig /displaydns again and comparing the results may lead to enlightenment.

If that doesn't change anything then the problem is more likely to be on your DNS server, in which case you should restart the DNS server, confirm that the problem's gone away, and run ipconfig /displaydns again and compare results. Again, enlightenment may follow.

I'm betting on overaggressive caching and an outdated entry in the server's DNS cache, but as Sherlock Holmes said: "It is a capital mistake to theorise before one has data".

 

[YeOldeStonecat]

Check resources and health of the DC. Since it runs active directory, the server MUST look at itself for primary DNS in its own TCP/IP properties, or..127.0.0.1 (which it...still itself)...and nothing...NOTHING else. UNless there is another DC in the AD. But no public DNS there.

Check DNS forwards in DNSMGMT.MSC on the server. I put Quad 9 server here...9.9.9.9
Check to see that scavenging is enabled

Servers DHCP should run DHCP for the network, not a router
Servers DHCP should ONLY hand out the IP of the server for primary DNS...nothing...NOTHING...else. No handing out Google DNS or Quad9 or whatever. Only hand out the DCs IP for primary DNS, and secondary should only be populated with another member servers IP on the network that runs DNS if there is one (like on larger networks).

Check even logs as to why DNS server service is stopping. Troubleshoot. A server should not have important infrastructure services crashing. Leaving crappily running servers doing Google DNS in DHCP is a poor bandaid..."but..if server isn't there...client won't browse the 'net unless they have google DNS (or other public DNS). Well, a server should run reliably 24x7x365....built it right, put it on quality real server hardware, keep it tuned up properly, regular updates and reboots, good hardware/resource specs based on load, don't bog it down with too much other junk...and it will not fail.