On Thu, Apr 30, 2009 at 02:15:48PM +0800, madi wrote:
> Hi, Stephane.
>
> 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. Thatbcursive server and authoritative name-server is
> secured by DNSSEC, a similar course should be followed by the recursive sever
> right after the DNSSEC verification.
>
this presumes that the query to the authoritiative server is not
intercepted and
replied to by a rogue nameserver -first-....
the primary benefit to DNSSEC is that it protects the integrity of the
data - regardless
of where it is coming from. if the cache is corrupted/poisoned, the
data will fail to
validate - and depending on your validator response - will fail
resolution.
what is missing/needed here is a way for a validator to mark a
recursive server as "bad"
and find/select an alternate server... which is outside the scope of
the DNSSEC design.
> 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.
DNSSEC already does this.
>
> 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
>
>
>
> ed;6d::o< Stephane Bortzmeyer
> ei f6i4o< 2009-04-23 19:40:15
> f6d;6d::o< Scott Rose
> f
i o< [email protected]; dnsop
> d8;i"o< Re: dns data exchanged between host and local dns-sever
>
> On Thu, Apr 23, 2009 at 07:10:13AM -0400,
> Scott Rose <[email protected] > 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
