DNS Health Check failed for both primary DNS'es on Proxy
Production traffic isn't affected - all the hosts queries are resolved within internal DNS servers with no impact.
Release : 7.3.6.1
PROXYSG >> FIREWALL >> DNS SERVERS >> BLUECOAT.COM
DNS CONFIG:
Two defined groups with the same DNS servers for name resolution.
DNS Health Check failed would mean that the domain bluecoat.com is not resolvable by DNS.
Test of dns on Proxy shows that query is bluecoat.com is bypassing DNS server configured and eventually get resolved. DNS health check stays the same.
- When the test is performed PCAP capture does not show at first sight any issue in resolution.
- Jump server in the same subnet as Proxy with same DNS config is able to resolve bluecoat.com via 1st primary DNS
CMD> nslookup bluecoat.com
- ping to bluecoat.com should be possible if ICMP is not blocked by firewall
- DNS Health Check adds to the list of primary DNSes additional domains for the resolution. Health Check chooses the resolver based on the 5 entries as seen in the Sysinfo file:
- If you add the same DNS server to a custom group, the longest domain name is used as the default hostname for the health check in this situation virxxxxxxxxxxxxxxxxxxxxx.example.com
Proxy tries to resolve the www.bluecoat.com via viraxxxxxxxxxxxxxxxxxxxxx.example.com (longest domain) and doesn’t get any CNAME A response from the resolver (it gets SOA) which is reflected with the WARNING with health check.
DNS Health Check failing for internal/local DNS server
KB article: https://knowledge.broadcom.com/external/article?articleId=193870
About the health check for custom DNS groups
KB article: https://knowledge.broadcom.com/external/article?articleId=165332
The health check issue can be resolved by configuring the primary DNS entries: 10.xx.xx.xx, 10.xx.xx.xx as the defined servers (overriding default settings) for www.bluecoat.com.
To do so you need to go to
This setting will overcome issues if Proxy chooses different path for resolving www.bluecoat.com in the future.
It has no impact on the other configured DNS entries.
The second rule that might also reflect the situation whereas the DNS Health Check worked before is a priority on the list. If in last days both 10.xx.xx.xx DNS servers were not available for short time, the DNS resolution for www.bluecoat.com moves down to the next DNS resolvers on list and keeps them as long as they’re running and not being offline.
If access to domains would fail, the DNS resolver would goes back to the list and take 10.xx.xx.xx as the default and priority one. The Health Check would work once again with default hostname settings.
In SGOS 7.2.2 and all later 7.x releases, and SGOS 6.7.5.4 and later 6.7 releases, the appliance contacts the last DNS server in the primary group that responded successfully. If no record of a successful query exists, the appliance contacts servers based on the order that they are configured in the primary.The server that the appliance successfully contacts will be contacted again for future queries.
How DNS resolution works on the Proxy:
KB: https://knowledge.broadcom.com/external/article/165929/how-does-the-dns-resolution-work-on-the.html
After customer has changed the default hostname for the primary DNS servers, the issue with the Health Check was resolved.
Investigate DNS group entries, perform a PCAP trace and collect Sysinfo