> Francis Dupont <mailto:francis.dup...@fdupont.fr> > Wednesday, March 25, 2015 3:48 PM > In your previous mail you wrote: > >> i believe that the last of the old-style initiators who treated >> premature closure by the responder as an urgent condition warranting a >> message to the console or the system log file have diminished to the >> level of noise, but that the change francis is asking for here, along >> with the clarification i'm asking for above as to non-idleness, along >> with a clarification to the effect that initiators SHOULD NOT treat >> premature closure by the responder as an urgent condition, reaches the >> level of "protocol change" not "clarification". > > => so we should not allow servers to use a too small timeout, i.e., > we have to propose a value of some seconds. BTW this should be enough > for the only standard case of idling which is the SOA + xXFR (the > initiator just checks the serial in the returned SOA is greater).
i don't think we should give a specific timeout period. if a server decides to send a FIN immediately after its first response, or immediately after it detects an empty "input socket buffer" or implementation dependent equivalent, then the initiator will have to send its subsequent request in a new TCP session. in other words it's not the two minute timeout that's a problem in RFC 1035, it's any known minimum, since such a limit merely describes the minimum size of the botnet that keeps all of those resources tied up and unavailable to clients. we should allow servers to use whatever timeout they want -- but we should warn server implementers in this document that some existing AXFR/IXFR clients attempt to send an SOA query first, and then once they hear the SOA response, they may decide to send an AXFR or IXFR within the same session, and they may not be prepared for a server-initiated close between those two transactions, thus causing the client to always restart from the first transaction, and potentially never reach the point of sending the second transaction. and then we should advise that due to this old style behaviour, a timeout of at least a few seconds is advisable, other than when the server is experiencing heavy connection load such as an attack. similarly, we must advise client implementers that the server may close the connection at any time, and that they should not count on being able to send any transactions on a newly open session, or more than one transaction. and we should advise client implementers that older servers which faithfully implement RFC 1035 4.2.2 may not have timeout logic that is in the server's best interests, and thus no connection should be allowed to become idle on the client (initiator) side unless explicitly negotiated using some later signaling. in other words: << Too many implementations have guessed differently when presented with a loose specification, and interoperability today is a moving, organic target. When I periodically itch to rewrite the specification from scratch, I know there are too many things that must be said that also cannot be said. It's as though, in a discussion of the meaning of some bit pattern, a modern description of the protocol---written with full perspective on all that has been done in the DNS field---would have to say, "It could mean x but some implementations will think it means y so you must be cautious." >> (http://queue.acm.org/detail.cfm?id=1242499) -- Paul Vixie
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
