I'm not an admin but since our regular guy is on vacation, the problem ended up in my lap. I'll be as brief as I can.
We noticed that our SQL Server 2005 instance was acting weird: app starts, app fails to connect to db. However, app works just fine after restart. Same goes for SQL Server Managemetn Studio. This behavior has been observed on several network machines so it's probably not a client issue. At the same time, using the server's IP address works all the time, which to me as a novice looks like a name resolution issue.
Pinging the server by name results in a
Destination host unreachable on the first try and successful pings on subsequent tries. After waiting an indeterminate time, this same cycle repeats iself. Again, pinging the server's IP works flawlessly.
Event Viewer contains Errors 4004 and 4015 in the DNS section. Attempts to fix them using Google have so far been unsuccessful.
Question: is there a simple fix?
I managed to eliminate Error 4004 by reinstalling the DNS service, although Error 4015 is still present.
Another interesting thing I noticed related to that failed first ping:
Pinging oxyserver [169.254.2.62] with 32 bytes of data: Reply from 169.254.74.29: Destination host unreachable. Reply from 169.254.74.29: Destination host unreachable.
I have no idea how it came up with this IP address (169.254.2.62), because right after that, ping correctly gets the server's IP address and it works just fine:
Pinging oxyserver [192.168.1.201] with 32 bytes of data: Reply from 192.168.1.201: bytes=32 time<1ms TTL=128 Reply from 192.168.1.201: bytes=32 time<1ms TTL=128
As requested, the results of
Query result: Server info server name = oxyserver.Oxy.loc version = 0ECE0205 (5.2 build 3790) DS container = cn=MicrosoftDNS,cn=System,DC=Oxy,DC=loc forest name = Oxy.loc domain name = Oxy.loc builtin domain partition = ForestDnsZones.Oxy.loc builtin forest partition = DomainDnsZones.Oxy.loc last scavenge cycle = not since restart (0) Configuration: dwLogLevel = 00000000 dwDebugLevel = 00000000 dwRpcProtocol = FFFFFFFF dwNameCheckFlag = 00000002 cAddressAnswerLimit = 0 dwRecursionRetry = 3 dwRecursionTimeout = 15 dwDsPollingInterval = 180 Configuration Flags: fBootMethod = 3 fAdminConfigured = 0 fAllowUpdate = 1 fDsAvailable = 1 fAutoReverseZones = 1 fAutoCacheUpdate = 0 fSlave = 0 fNoRecursion = 0 fRoundRobin = 1 fStrictFileParsing = 0 fLooseWildcarding = 0 fBindSecondaries = 1 fWriteAuthorityNs = 0 fLocalNetPriority = 1 Aging Configuration: ScavengingInterval = 0 DefaultAgingState = 0 DefaultRefreshInterval = 168 DefaultNoRefreshInterval = 168 ServerAddresses: Addr Count = 2 Addr => 192.168.1.201 Addr => 169.254.2.62 ListenAddresses: NULL IP Array. Forwarders: NULL IP Array. forward timeout = 5 slave = 0 Command completed successfully.
The two addresses are an obvious red flag.
Changing the priority of the NICs in Network Connections/Advanced appears to have gotten rid of error 4015. However, the original problem still exists.