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?
Update
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
Update2
As requested, the results of dnscmd /info
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[0] => 192.168.1.201
Addr[1] => 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.