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 the case
when you are behind NAT.
RFC3225 does admit such a case as:
non-compliant caching or forwarding servers inappropriately copy data
from classic headers as queries are passed on to authoritative
servers, the use of a bit from the EDNS0 header is proposed.
You ask a query on some name, maybe with DO bit set, and receive
an answer without any SIG RRs.
You now ask SIG RRs of the name through TCP (SIG RRs is usually
larger than 1500B and can easily be larger than 64KB) and the SIG
RRs will be cached, if everything works fine.
There are a lot of possibilities that you can't get any SIG RRs,
though. For example, the caching forwarder may not support TCP or
may not be able to accept large answers.
And, you must turn DNSSEC off, which is the instability I already
mentioned.
If you are little more unlucky, server's cache may overflow,
inappropriate code against which may crash the server, which
may never occured before with small PODS answers.
It should also be noted that, in RFC3225, SIG RR query through TCP,
which is unavoidable in this case, is considered harmful as:
TCP DNS queries result in significant overhead due to connection
setup and teardown. Operationally, the impact of these TCP queries
will likely be quite detrimental in terms of increased network
traffic (typically five packets for a single query/response instead
of two), increased latency resulting from the additional round trip
times, increased incidences of queries failing due to timeouts, and
significantly increased load on nameservers.
Masataka Ohta
PS
I'm very happy now because my proposal of "Simple Secure DNS", which
was designed to carefully avoid using large messages, is not deployed.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
