> 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.
Sorry we are talking about RFC 4035 not RFC 2535.
RFC 2535 was designed to work through a non-RFC 2535 aware
cache.
RFC 4035 requires the upstream cache to be RFC 4035 aware.
RFC 4035 compliant validators DO NOT request RRSIGs if they
are missing from the response. Instead the response is
rejected if it is deemed the response should have included
them.
The type code roll prevents RFC 2535 aware caches impacting
on the operation of RFC 4035 validators.
> 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 lack of TCP support will also break PODS responses as well.
Authoritative servers can sometimes get away with disabling TCP.
Stub and caches have never been able to get away with disabling
TCP.
> 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
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
