Tony Finch wrote: > Francis Dupont <francis.dup...@fdupont.fr> wrote: >> > >>> > > DNS currently has no connection signaling mechanism. Clients and >>> > > servers may close a connection at any time. Clients MUST be >>> > > prepared >>> > > to retry failed queries on broken connections. >> > >> > => unfortunately this is a change in the protocol the document is >> > not supposed to do here even it both makes sense and follows the real >> > world situation. > > I disagree that this is a change.
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, 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. > > 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. 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. but since we must also guide the initiator to not leave a tcp session idle, 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. -- Paul Vixie
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
