On Mon, 18 Aug 2008, Jim Reid wrote:
On 18 Aug 2008, at 05:11, Dean Anderson wrote:
Ok, I agree that totally DNSSEC-oblivious servers won't be a problem
for DOS, but of course remain susceptible to poisoning even if the
stub resolver and the authority server both implement DNSSEC.
On Mon, 18 Aug 2008, Paul Hoffman wrote:
At 1:27 PM +0100 8/18/08, Jim Reid wrote:
The fact is DNSSEC is the *only* game in town for preventing cache poisoning.
Note the subject of this particular thread. A more carefully-worded
sentence would be The fact is DNSSEC is the *only* game in
On 18 Aug 2008, at 00:43, Dean Anderson wrote:
First, Putting any kind of large record in the root creates the
opportunity to use root servers in a DOS attack by sending queries for
the large records to the root servers.
Well in that case we better not put anything into any DNS zone.
Jim Reid wrote:
I suspect you're talking about the absurdly hypothetical scenario where
someone gets a non DNSSEC-aware resolving server to lookup some RRSIG,
Suppose you are using DNSSEC-unaware caching forwarder shared by
others including those who are using PODS, which is often
Mark Andrews wrote:
RFC 4035 requires the upstream cache to be RFC 4035 aware.
Thanks. As examplified by assumptions of RFC3225, that's a so
unrealistic requirement that no further discussion on DNSSEC
is necessary. PERIOD.
And lack of TCP support will also break PODS responses as
Mark Andrews wrote:
RFC 4035 requires the upstream cache to be RFC 4035 aware.
Thanks. As examplified by assumptions of RFC3225, that's a so
unrealistic requirement that no further discussion on DNSSEC
is necessary. PERIOD.
Given just about anyone can configure a validator
