linksys.var@terabyte.net
With all due respect to Cisco's folks, we've seen and just learned to ignore this error for almost a year. It's never once been correct. Just because www.cisco.com doesn't resolve doesn't mean that the DNS server is down or slow. IMHO, you should change what it's looking up to an internal name and see if that helps, but even when we’ve done that we’ve had TBAs come back saying it can’t resolve names. I had internal DNS logging set to max on several DNS servers and never found any errors other than what TBA sent us. If every customers’ DNS servers, we’ve seen this error from pretty much every TBA installed, were having this problem we’d be hearing complaints about browsing daily from every customer. I’m convinced the problem is elsewhere.
Hi Brian (and Yogi),
Transient DNS problems can be hard to pin down. Brian, you didn't say whether the DNS server's logs showed the queries from the TBA around the time that the event was reported - do you see ANY successful queries in the server logs at around the time of a failure event?
DNS servers tend to cache queries until the record's TTL expires, possibly the failure is happening only when the local DNS server is forced to expire the local cache and re-resolve. Based on the timestamp Yogi reported, (7:17am), I was curious if the events seemed to occur at customer locations only during off-hours when typical office users wouldn't be around to notice (or report) the issue, maybe during a period when the DNS server is under load for some other reason, possibly a backup. Looking into Yogi's customer's events, I see large periods of time (> 1 hour) where DNS service is unresponsive, this really looks a valid issue at the site and deserves some attention.
You CAN change the target of the DNS resolution by editing the TBA device in the portal and going to the Monitors tab and selecting the DNS Service monitor. You could try putting in a record that the local DNS server is authoritative for, to rule out upstream resolution problems. If you still continue receive failure to resolve events, you could try putting in localhost as the resolution target, this will cause the TBA to perform the resolution itself. If you still continue to recieve events for failing to resolve localhost, this would certainly be a bug with the TBA that would need to be addressed. Otherwise, the TBA is just a generic DNS client, and is reporting that the server it's asking isn't giving it the record it's asking for.
A DOS batch or unix shell script could be written pretty easily to perform a DNS query of the same target every 30 seconds and run from another machine on the network, it could then be used to confirm or rule out that other DNS clients on the network are seeing the same issue. It would just need to print 'date', perform the nslookup, wait 30 seconds, then loop, with the output hopefully redirected to a file. You could then go back in it's log and compare what was happening at the time the TBA saw and reported an event to see if it saw the same thing.
