Windows – DNS lookup fails after resume from sleep

My guess is that Windows somehow misbehaves upon wakeup from sleep regarding the system time. According to a Wikipedia article the registry key you are citing doesn't fully work, even on recent versions of Windows:

Windows expects the real-time clock of the computer to run on local time. Since Windows NT there has been a registry entry RealTimeIsUniversal=1, but this feature is not supported or fully implemented yet (including Vista), so it is not possible to run the real-time clock on Coordinated Universal Time.

I think your best bet here would be to tell Linux that the system clock runs in local time and bite the bullet two times a year with DST.

ETA: This article details the problem a little more and also hints on the fact that the issues with that registry key are fixed in Vista SP2 and Windows 7:

2001-07-09: I got a reply from someone in Microsoft's Base Kernel Team who got interested in RealTimeIsUniversal and they had a look at the relevant parts of the NT kernel source code. The RealTimeIsUniversal flag is there (a leftover from the days when NT still ran on RISC machines with UTC RTCs), but its implementation seems now incomplete and it is currently not covered by Microsoft's documentation and regression test suite, therefore using it is not recommended at this time. A couple of potential RealTimeIsUniversal bugs have been identified over the past few days, there might be more. For instance, the kernel debugger assumes that the CMOS time is local time and will get the time wrong when RealTimeIsUniversal=1. There might be a similar problem in the code that resumes processing after the CPU was suspended or in the code that calculates DST change times.

2008-10-31: Hurray! Someone from Microsoft's Core Operating Systems Division hints in an email to me that both Vista SP2 and Windows 7 will fix the problems in the RealTimeIsUniversal=1 support that have made running the CMOS clock in UTC so far not practical with Windows (i.e., the time was wrong after resuming a suspended/hibernating Windows). He warns though that this improved support for UTC in the CMOS clock may not immediately be widely documented and details may change in the future.

So, concluding I think you have two options:

1. Upgrade to a recent OS.
2. Switch Linux over to local time.

P.S.: Contrary to other posters here, this can't be the CMOS battery. The real-time clock isn't powered by the battery as long as the system has power. This includes sleep mode (obviously). In case the CMOS battery is dead the real-time clock would reset itself to its factory settings which is usually January 1 a few years back. A couple of hours offset simply doesn't happen, as there is no clock "state" that survives a complete power loss. It's not akin a wall clock with a flaky battery which retains its time even when the battery is dead.

Actually it is probably due to using a .local domain. That conflicts with the mDNS resolution (zero configuration networking) which by default uses .local.

Some versions of OS X can support both name resolution methods, mDNS and normal DNS, but at least Yosemite doesn't seem to support it any more.

This little bit older Apple Support document explains the background. For Yosemite what does work still is adding "domain.local" to the DNS search list in the network settings.

The real solution is not using the .local domain for DNS resolved hosts.