Here's a reply I received from one of my colleagues:
"There isn't enough data here to know what his problem is, but yes, one of
the root servers recently changed.
That shouldn't be a big problem. CNR is configured with root "hints", which
are servers that are queried to learn the real root servers. As long as CNR
can successfully query one of these "hint" servers and learn the list of
current root-servers, it will be OK. Also, if one of the root servers is
changed, but we have cached information pointing to the old address, it will
be found not to work, and the other servers will be prefered. So the
root-server change is really a non-issue, though all customers should always
check the validity of their root hints from time to time.
He says he queried one of the root servers and got back something about
A.GTLD-SERVER.NET. He doesn't say what question he asked the root server, but I assume he asked it about some name he's having trouble resolving. This is a completely expected answer. The root servers do not provide recursion, so the best they can provide is a referral, which they did. They said that all they know is that the name in question is delegated to
A.GTLD-SERVERS.NET, which is one of the servers for .com and .net. Assuming he was asking about a name ending in .com or .net, this is the expected response.
None of this helps answer his original question, and for that he needs to
perform some real diagnosis about where CNR is sending it's queries and
whether the answers can come back. One of the most likely causes is that
someone in his org added a firewall which blocks inbound packets on UDP port 53."
Hope this helps,
...TC...
