On 25 Mar 2015, at 09:52, Paul Vixie <p...@redbarn.org> wrote: > well then it bears further discussion, because to me it's certainly a change. > there is no guidance in RFC 1035 as to whether an initiator should treat > premature closure by the responder as a signal to try the same server again > or move to the next server
That sounds like a potentially useful addition to 5966bis - moving on to the next server would seem to me to be the preferred reaction. > and, there is no guidance as to whether premature closure is an urgent > operational matter deserving notification to the user's console or system > logs. IMHO, any client that ever did this is over-reacting and I don’t believe specific guidance is required. A server-initiated close (per 1035) for resource exhaustion reasons might be of note to the server operator, but the client ought to just treat this as a non-event, just like not getting a response to a UDP query. >> RFC 1035 allows the server to close the connection at any time to reclaim >> resources. It specifies a generous idle time, but clients cannot assume >> that this is guaranteed - the server might be restarted, etc. > > initiators have historically been able to assume that the responder would not > close first. In general usage, yes. And that’s still the case, albeit 5966 makes it a bit more likely. > that's the operational environment in which RFC 1035 has been interpreted > since 1987. if we want the initiator to change its assumptions then we have > to say so. the saying of so may or may not constitute a protocol change since > we're clarifying the assumptions rather than asking for different behaviour. OK… > but since we must also guide the initiator to not leave a tcp session idle, We must? > which absolutely is a protocol change, i see no harm is bundling this > guidance into a single document which is collectively a revision to the > protocol. kind regards Ray _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
