To:
bert hubert <ahu@ds9a.nl>
CC:
dnsop@cafax.se
From:
Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp>
Date:
Fri, 07 Nov 2003 14:23:37 +0900
In-Reply-To:
<20031106070043.GA18570@outpost.ds9a.nl>
Sender:
owner-dnsop@cafax.se
User-Agent:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax)
Subject:
Re: preventing cache contamination
bert hubert; >>Does the following work to prevent DNS cache contamination > > > A proper algorithm prevents that. There is a slight chance of spoofing > answers to a nameserver if you can guess its source port and query id. That's what I'm trying to prevent. > You need to trust your local segment indeed. >> 2) have separate cache for glue > This isn't necessary and a bad idea. It is a just enough protection against well known attack to contaminate cache by glue A, which I confirmed to work about 10 years ago. That is, with hpcl.titech.ac.jp. NS foo.bar foo.bar. A 131.112.32.132 a manager of hpcl.titech.ac.jp (that is, I) can tell anything about A of foo.bar or whatever domain, cache of which should be used only for glue A of hpcl.titech.ac.jp. I know both PV and DJB didn't understand it and tried to use insufficient or excessively complex approaches. >> 3) cache an answer to a query but activate it only after a >> compatible answer is returned for latter query (to protect >> against ID space attack) > I don't understand this one, but indeed, there are some things you need to > do to prevent birthday attacks on the ID space. I'm saying answer should be stored in cache for latter use, only if the same answer is obtained multiple times with independent IDs. Then, attackers must guess all the IDs, which effectively enlengthen the number of ID bits, though it reduces the effectiveness of cache. Masataka Ohta #---------------------------------------------------------------------- # To unsubscribe, send a message to <dnsop-request@cafax.se>.