> >As a fallback to a response with a TC bit set, it may be > >worth using EDNS0 instead (or in addition) to a TCP fallback. > > Both EDNS0 and TCP would have to be tried in such a case. I suggest > to wait and see whether _FFR_DNS_UPGRADE is working as expected first.
I have no doubt the _FFR_DNS_UPGRADE will provide a solution to a retry on TC. This however should not prevent us from exploring other possibilities. The RFC 2181 says: Where TC is set, the partial RRSet that would not completely fit may be left in the response. When a DNS client receives a reply with TC set, it should ignore that response, and query again, using a mechanism, such as a TCP connection, that will permit larger replies. It says 'such as a TCP', and does not mandate switching to TCP right away. > Some firewalls may block EDNS0. I wonder what silly mind would block EDNS0 but would allow TCP queries. TCP is a heavyweight protocol compared to DNS, several packets need to be exchanged, server needs to allocate resources to keep state. EDNS0 is just an ordinary lightweight UDP (with possibly larger packets), it is still just one exchange of packets, no resources on the server need to be allocated, no opening up of a DoS opportunity due to SYNC attacks, half-open connections and such. I haven't explored current practices, but I have an impression that DNS servers mostly do support EDNS0 (perhaps without their administrators realizing it), and that trying EDNS0 query on the first retry after a TC might be beneficial, both for the servers and well as for the clients. Perhaps some statistics gathering by dkim-milter could offer further guidelines. Mark ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ dkim-milter-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss
