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 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
