DNS/security/Google/validity-checkingについて、ここに記述してください。
https://developers.google.com/speed/public-dns/docs/security#validity_check
Some DNS cache corruption can be due to unintentional, and not necessarily malicious, mismatches between requests and responses (e.g. perhaps because of a misconfigured name server, a bug in the DNS software, and so on). At a minimum, DNS resolvers should put in checks to verify the credibility and relevance of name servers' responses. We recommend (and implement) all of the following defenses:
Do not set the recursive bit in outgoing requests, and always follow delegation chains explicitly. Disabling the recursive bit ensures that your resolver operates in "iterative" mode so that you query each name server in the delegation chain explicitly, rather than allowing another name server to perform these queries on your behalf.
Reject suspicious response messages. See below for details of what we consider to be "suspicious".
Do not return A records to clients based on glue records cached from previous requests. For example, if you receive a client query for ns1.example.com, you should re-resolve the address, rather than sending an A record based on cached glue records returned from a .com TLD name server.
Rejecting responses that do not meet required criteria
Google Public DNS rejects all of the following:
Unparseable or malformed responses.
Responses in which the query ID, source IP, source port, or query name do not match those of the request.
Records which are not relevant to the request.
Answer records for which we cannot reconstruct the CNAME chain.
Records (in the answer, authority, or additional sections) for which the responding name server is not credible. We determine the "credibility" of a name server by its place in the delegation chain for a given domain. Google Public DNS caches delegation chain information, and we verify each incoming response against the cached information to determine the responding name server's credibility for responding to a particular request.