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