DNS/1/CNAME/調査 - moin.qmail.jp

DNS/CNAME/調査について、ここに記述してください。

1. CNAME がどう扱われているかの調査

http://stackoverflow.com/questions/11196930/cname-record-in-additional-section

RFC 1034+1035 state the CNAME records should cause no additional section processing.
But I am seeing an increasing trend of services like wordpress sending a CNAME chain
with one part of the chain in the additional section.
So, without parsing the additional section you cannot decode the DNS response.

RFC 2181: "Additional section processing does not include CNAME records, let alone the address records that may be associated with the canonical name derived from the alias."

https://lists.isc.org/pipermail/bind-users/2011-September/085088.html

https://www.rfc-editor.org/rfc/rfc6672.txt DNAME Redirection in the DNS

http://lists.roaringpenguin.com/pipermail/mimedefang/2011-October/036329.html

http://insecure.org/sploits/dns.cache-poison.cname.html

poison the DNS cache by returning a bogus IP as a CNAME for a real server

14 June 1997 (It was actually discovered in April, apparently)

http://www.cs.utexas.edu/~shmat/shmat_securecomm10.pdf The Hitchhiker’s Guide to DNS Cache Poisoning

http://unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html

https://secunia.com/advisories/38219/

A vulnerability is caused due to BIND caching CNAME or DNAME records of a response without proper DNSSEC verification when processing recursive client requests with checking disabled (CD) or internally triggered queries for missing records for recursive name resolution.

https://lists.isc.org/pipermail/bind-users/2012-June/088012.html

https://lists.isc.org/pipermail/bind-users/2004-August/051831.html

http://books.google.co.jp/books?id=_Kh5OvEZGlYC&pg=PA478&lpg=PA478&dq=cname+DNS+cache+poisoning+cname&source=bl&ots=xdzVTGeVeR&sig=M9TWL7t1vWXuGbLF6w5TKime0sM&hl=ja&sa=X&ei=V_SXUqDiN8OKlQWD64GQCQ&ved=0CDAQ6AEwATgU#v=onepage&q=cname%20DNS%20cache%20poisoning%20cname&f=false

MoinQ: DNS/1/CNAME/調査

1. CNAME がどう扱われているかの調査