mode to offload most of the work of DNS resolution to a recursive name server." A stub resolver will simply forward a request to a recursive name server, and use the Authenticated Data (AD) bit in the response as a "hint to find out whether the recursive name server was able to validate signatures for all of the data in the Answer and Authority sections of the response." Microsoft Windows uses a stub resolver, and Windows Server 2008 R2 and Windows 7 in particular use a non-validating but AD-bit-aware stub resolver. A validating stub resolver can also potentially perform its own signature validation by setting the Checking Disabled (CD) bit in its query messages. A validating stub resolver uses the CD bit to perform its own recursive authentication. Using such a validating stub resolver gives the client end-to-end DNS security for domains implementing DNSSEC, even if the Internet service provider or the connection to them is not trusted. Non-validating stub resolvers must rely on external DNSSEC validation services, such as those controlled by the user's Internet service provider or a public recursive name server, and the communication channels between itself and those name servers, using methods such as DNS over TLS. Trust anchors and authentication chains To be able to prove that a DNS answer is correct, one needs to know at least one key or DS record that is correct from sources other than the DNS. These starting points are known as trust anchors and are typically obtained with the operating system or via some other trusted source. When DNSSEC was originally designed, it was thought that the only trust anchor that would be needed was for the DNS root. The root anchors were first published on 15 July 2010. An authentication chain is a series of linked DS and DNSKEY records, starting with a trust anchor to the authoritative name server for the domain in question. Without a complete authentication chain, an answer to a DNS lookup cannot be securely authenticated. Signatures and zone signing To limit replay attacks, there are not only the normal DNS TTL values for caching purposes, but additional timestamps in RRSIG records to limit the validity of a signature. Unlike TTL values which are relative to when the records were sent, the timestamps are absolute. This means that all security-aware DNS resolvers must have clocks that are fairly closely in sync, say to