At 15:52 08-09-2007, Mark Martinec wrote: >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.
I agree. >It says 'such as a TCP', and does not mandate switching to TCP right away. I'll comment below. >I wonder what silly mind would block EDNS0 but would allow TCP queries. Some firewalls may block UDP packets larger than 512 bytes on the assumption that a valid UDP packet would not be larger than 512 bytes. >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. The advantage of using EDNS0 is that there is less overhead compared to establishing a TCP session. It is, as you said, more lightweight. There may be MTU issues but that can be dealt with by choosing an appropriate payload size. I'll avoid the discussion about DNS amplification attacks. If EDNS0 was to be used first, the logic would be: 1. Client sends UDP DNS query with indication that requestor fully implements EDNS0 2. If there is no response or a RCODE indicating failure, send DNS query using UDP 3. If TC is set, upgrade to TCP >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 Some administrators may not realize that their DNS server supports EDNS0. >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. Yes, that would help determine which algorithm solves the DNS-related issues while having a lower overhead. Regards, -sm ------------------------------------------------------------------------- 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
