Server Fault Asked by hokie1999 on December 30, 2021
There’s a python-based in-house app that runs on our pair of CentOS 7 app servers. The app pulls packet capture files on an as-need basis.
We recently added two new DNS servers to our environment. When we disabled the named service on the "old" dns server, the app failed. Turn on service on old dns server and app worked. The new dns servers are on, btw.
There’s no hard-coding of dns in the app. /etc/resolv.conf on the app servers points to new dns servers and NOT to old dns server. No ncsd or named on this app server. An nslookup on app server finds target servers gathering pcap using correct "new" dns servers.
tcpdump on the old dns server shows that app server is sending dns requests to it on port 53, which IS the problem being discussed here. Should be sending to new dns servers.
The app has been restarted manually several times in this troubleshoot incident.
nsswitch.conf has standard settings: hosts: files dns myhostname
There’s no browser or browser cache involved in this problem.
In summary: DNS seems to be "stuck" on old dns resolver.
Was wondering if anyone had idea on how to troubleshoot, and thanks.
I left a big piece of this out, to simplify.
There is Saltstack automation running on app server. The actual app itself calls Saltstack code as an api (tho you could call it a RPC). Running "above" this is a process that controls the api and associated code. It was last restarted three weeks before the DNS problem started. Intend to restart this week. It likely grabbed the "old" DNS server and won't let go until we restart it.
Answered by hokie1999 on December 30, 2021
Get help from others!
Recent Questions
Recent Answers
© 2024 TransWikia.com. All rights reserved. Sites we Love: PCI Database, UKBizDB, Menu Kuliner, Sharing RPP