Hi, Stephane. I cannot agree with you any more. However, with regard to “the lying resolver” you’ve mentioned, to make it clearer, I’d like to bring in the Cache Poisoning which IPsec and TSIG cannot protect against. In practice, the response form the intended recursive server is in the form of plaintext. Once a recursive server has been hacked by the cache poisoning attack, the IPSec or the TSIG is to actually guarantee integrity and authentication of the “fake response”. And it needs to be pointed out that a poisoning attack on a single ISP DNS recursive server can affect numerous users serviced directly by the compromised server or indirectly by its downstream server(s) if applicable. To give a countermeasure, the response from a recursive sever might as well be cached in form of both plaintext and ciphertext which is generated by the very recursive server. That’s to say, once a certain DNS resource record arrives from an authoritative name-server, the recursive sever should encrypt the DNS response and then cache it right away before the potential cache poisoning attack. If the data exchanged between local recursive server and authoritative name-server is secured by DNSSEC, a similar course should be followed by the recursive sever right after the DNSSEC verification. Once the requester, a PC typically, gets the response in dual forms, it can then verify the correlation between them. If so, even the attacker has poisoned the DNS information cache, yet the two forms of poisoned cache, plaintext and ciphertext, could not be in accordance with each other. Consequently, the verification to them by a requester will never pass and then the phishing would be avoided. With respect to the generation and the distribution of the key for the ciphertext mentioned above, further deliberation is needed. Any critical will be appreciated.
2009-04-30 madi 发件人： Stephane Bortzmeyer 发送时间： 2009-04-23 19:40:15 收件人： Scott Rose 抄送： m...@cnnic.cn; dnsop 主题： Re: dns data exchanged between host and local dns-sever On Thu, Apr 23, 2009 at 07:10:13AM -0400, Scott Rose <sco...@nist.gov > wrote a message of 65 lines which said: >>Those are the DNS protocol mechanisms in place. There is also lower >>level security technologies such as IPsec that could be used between >>stub clients and recursive servers that don't rely on DNSSEC at all. >TSIG, IPsec and friends have all the same issue: they check that the >response does come from the intended resolver, not that the response >is authentic. At a time where any hotel provides Internet access with >a lying resolver, this is probably not sufficient.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
