1. DNS/Google公開キャッシュ
/queryaddress /togetter.com /togetter.com-0 /ttl /yatz /yatz.qmail.jp |
https://code.google.com/intl/ja/speed/public-dns/docs/security.html
http://code.google.com/intl/ja/speed/public-dns/docs/performance.html
2. Google public DNS
https://developers.google.com/speed/public-dns/faq?hl=ja
yatz.qmail.jp などの扱いや、 TTLの扱い、 毒盛り対策、 TCP などについて調べる予定。
http://www.itmedia.co.jp/news/articles/0912/09/news023.html
Security Benefits https://code.google.com/intl/ja/speed/public-dns/docs/security.html
3. Implementing basic validity checking
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 nameserver, 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 nameservers' 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 nameserver in the delegation chain explicitly, rather than allowing another nameserver 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 nameserver.
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 nameserver is not credible. We determine the "credibility" of a nameserver 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 nameserver's credibility for responding to a particular request.