Re: [DNSOP] go further about DNS over TCP?
Jared Mauch wrote: You can read the jabber logs. Let me know if you need help finding them. that's not responsive to my question. (is the definition of an IETF WG's membership still its mailing list not its meeting rooms?) -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] go further about DNS over TCP?
Jared Mauch mailto:ja...@puck.nether.net Wednesday, March 25, 2015 7:56 AM As mentioned in the wg yesterday an informational document with current behaviors may be helpful? as the notes have not been published, those of us not in the room have not had a chance to observe or comment. (is the definition of an IETF WG's membership still its mailing list not its meeting rooms?) -- Paul Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] go further about DNS over TCP?
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
Re: [DNSOP] go further about DNS over TCP?
In your previous mail you wrote: = 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. 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. = the RFC 1035 problem is it doesn't use the now standard MUST/SHOULD/MAY keywords so it has to be interpreted. In this particular case the cases where the idle time is not granted are clearly exceptions so IMHO the right interpretation is a server SHOULD accept some idle. This is confirmed by Paul Vixie's post and by a private conversation with Mark Andrews: - me - A server should be allowed to use the (idle) timeout it wants, even a zero one. - marka - This will break the SOA + xXFR case. So I am afraid it is both a change and a good topic for a discussion. RFC 1035 also specifies that TCP connections can be closed abruptly, e.g. with a RST. Clients must cope with this. = it doesn't change things (and BTW I believe most programmers even have no idea about how to abort (vs close) a TCP connection :-). A client is buggy if it does not have a mechanism to retry queries that failed because of a broken TCP connection. = I agree but if clients consider a broken TCP connection as an exception, e.g., marking the server as temporary unavailable, we are in trouble with the current proposed text (or mine :-). Thanks francis.dup...@fdupont.fr ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] go further about DNS over TCP?
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
Re: [DNSOP] go further about DNS over TCP?
As mentioned in the wg yesterday an informational document with current behaviors may be helpful? Jared Mauch On Mar 25, 2015, at 9:52 AM, Paul Vixie p...@redbarn.org wrote: 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. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] go further about DNS over TCP?
I am splitting the thread in separate points. francis.dup...@fdupont.fr ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] go further about DNS over TCP?
i'm replying to several messages here, all from francis dupont. Francis Dupont mailto:francis.dup...@fdupont.fr Tuesday, March 24, 2015 1:39 PM ... A 2mn timeout simply has no chance to scale. i agree. it cannot scale. in addition, it's exceedingly easy to attack responders which implement [RFC 1035 4.2.2] by repeatedly connecting and doing nothing. however, for servers not at that moment under attack, the responders who implement the specification's two minute timeout is adequate for the limited volume of TCP traffic a server will see from clients who fail over to TCP after trying UDP. this means that while it's not ideal, it's not as broken as it could be. with changes to recommended initiator behaviour, we could make these existing servers more broken, or we could preserve their present level of brokenness, but we cannot make them less broken. i'm going to argue, below, for preserving their present level of brokenness. So I propose: - make clear that TCP support is mandatory. - allow servers to use the timeout they like, even a zero timeout (the last point should be discussed). Note a zero timeout doesn't mean send the response and close but send the response, check there is not pending query, and close. i am comfortable with this approach, but i would like to also specify (in one of the tcp related documents now circulating, or in a new one, that's a detail) that initiators SHOULD NOT remain connected and idle unless they are acting under some later specification under which idleness has been explicitly negotiated. obviously, any existing initiators will not obey the SHOULD NOT, but i would like to preserve the responders' present level of brokenness by not adding any new TCP connection idlers until and unless there is a protocol change by which a responder can signal its willingness to participate in an idle mesh. note that http://tools.ietf.org/html/draft-ietf-dnsop-edns-tcp-keepalive-01 is an example of a protocol revision by which idleness could be explicitly negotiated. i think a simpler approach could work, like adding one bit of the EDNS extended-flags mask to say the sender of this message would be happy about remaining connected but idle. my reason for thinking this would be enough is, there's no way to reliably tune specific idle periods, and a TCP speaker who signals their willingness to remain idle must also be prepared to close least-recently-used connections when the pool of potential connections is running dry. Francis Dupont mailto:francis.dup...@fdupont.fr Tuesday, March 24, 2015 2:26 PM In previous mail [Paul Wouters] wrote: If signaling for this is needed, then a separate document would be good. = not needed but very useful: the idea is not to allow servers to use short timeouts with clients which express they don't matter, but to allow them with all clients. Note this is why it is a protocol change... 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. Francis Dupont mailto:francis.dup...@fdupont.fr Tuesday, March 24, 2015 2:42 PM In previous [Duane Wessels] wrote: I believe 5966bis already addresses your first point quite clearly. (note: first point is to make TCP support mandatory) For example, it says: This document therefore updates the core DNS protocol specifications such that support for TCP is henceforth a REQUIRED part of a full DNS protocol implementation. = but has this statement got a consensus? If it is the case of course there is no reason to write twice the same thing. because of the installed base, i think we should say RECOMMENDED rather than REQUIRED. we cannot reasonably redefine existing working systems as unfit for duty. note, i do not know if we have consensus on this general approach, nor do i know whether the strength of that consensus would be higher for RECOMMENDED than for REQUIRED. however, i do know that i would lodge an objection if the REQUIRED form were to reach consensus. i realize that this language is already in RFC 5966 (August 2010), so, that document was a protocol change not a clarification. Regarding your second point, Paul already pointed you to draft-ietf-dnsop-edns-tcp-keepalive, which I quite liked myself, but I think others felt it was unnecessarily complex. Here's what 5966bis says: 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
Re: [DNSOP] go further about DNS over TCP?
In your previous mail you wrote: I believe 5966bis already addresses your first point quite clearly. (note: first point is to make TCP support mandatory) For example, it says: This document therefore updates the core DNS protocol specifications such that support for TCP is henceforth a REQUIRED part of a full DNS protocol implementation. = but has this statement got a consensus? If it is the case of course there is no reason to write twice the same thing. Regarding your second point, Paul already pointed you to draft-ietf-dnsop-edns-tcp-keepalive, which I quite liked myself, but I think others felt it was unnecessarily complex. Here's what 5966bis says: 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 agree with Paul Hoffman that connection signaling should be done in a separate document. = we have one (in fact the problem is we have two). Thanks francis.dup...@fdupont.fr PS: I note your opinion is to improve 5966bis. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] go further about DNS over TCP?
In your previous mail you wrote: So I propose: - make clear that TCP support is mandatory. - allow servers to use the timeout they like, even a zero timeout (the last point should be discussed). Note a zero timeout doesn't mean send the response and close but send the response, check there is not pending query, and close. Are you aware of draft-ietf-dnsop-edns-tcp-keepalive-01 ? = yes and I agree it will be nice to have a way to negociate the timeout between the client and the server. But unfortunately this won't apply to the current deployed base. Now there are the not technical questions to solve first: - is DNSOP chartered to do this? Point 4 says protocol maintenance and point 5 allows more if the area director agree. I believe that was specifically changed to accomodate for this, yes. = I think so too.a - is 5966bis the right place? I don't think so but another document means the 5966bis will be delayed... If signaling for this is needed, then a separate document would be good. = not needed but very useful: the idea is not to allow servers to use short timeouts with clients which express they don't matter, but to allow them with all clients. Note this is why it is a protocol change... Thanks francis.dup...@fdupont.fr ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] go further about DNS over TCP?
On Mar 24, 2015, at 4:42 PM, Francis Dupont francis.dup...@fdupont.fr wrote: For example, it says: This document therefore updates the core DNS protocol specifications such that support for TCP is henceforth a REQUIRED part of a full DNS protocol implementation. = but has this statement got a consensus? If it is the case Sorry, I should have realized that RFC 5966 (August 2010) already says exactly the same thing. DW ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] go further about DNS over TCP?
In your previous mail you wrote: This document therefore updates the core DNS protocol specifications such that support for TCP is henceforth a REQUIRED part of a full DNS protocol implementation. Sorry, I should have realized that RFC 5966 (August 2010) already says exactly the same thing. = and it seems it is not very applied (e.g., my home ISP doesn't support DNS over TCP), perhaps because of [5966/5966bis]: Whilst this document makes no specific recommendations to operators of DNS servers, it should be noted that failure to support TCP (or the blocking of DNS over TCP at the network layer) may result in resolution failure and/or application-level timeouts. = so IMHO there are still things to do, even in the 5966bis intro... Thanks francis.dup...@fdupont.fr ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] go further about DNS over TCP?
On Mar 24, 2015, at 3:39 PM, Francis Dupont francis.dup...@fdupont.fr wrote: So I propose: - make clear that TCP support is mandatory. - allow servers to use the timeout they like, even a zero timeout (the last point should be discussed). Note a zero timeout doesn't mean send the response and close but send the response, check there is not pending query, and close. Now there are the not technical questions to solve first: - is DNSOP chartered to do this? Point 4 says protocol maintenance and point 5 allows more if the area director agree. - is 5966bis the right place? I don't think so but another document means the 5966bis will be delayed... I believe 5966bis already addresses your first point quite clearly. For example, it says: This document therefore updates the core DNS protocol specifications such that support for TCP is henceforth a REQUIRED part of a full DNS protocol implementation. Regarding your second point, Paul already pointed you to draft-ietf-dnsop-edns-tcp-keepalive, which I quite liked myself, but I think others felt it was unnecessarily complex. Here's what 5966bis says: 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. I agree with Paul Hoffman that connection signaling should be done in a separate document. DW ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] go further about DNS over TCP?
On Tue, 24 Mar 2015, Francis Dupont wrote: So I propose: - make clear that TCP support is mandatory. - allow servers to use the timeout they like, even a zero timeout (the last point should be discussed). Note a zero timeout doesn't mean send the response and close but send the response, check there is not pending query, and close. Are you aware of draft-ietf-dnsop-edns-tcp-keepalive-01 ? http://tools.ietf.org/html/draft-ietf-dnsop-edns-tcp-keepalive-01 Now there are the not technical questions to solve first: - is DNSOP chartered to do this? Point 4 says protocol maintenance and point 5 allows more if the area director agree. I believe that was specifically changed to accomodate for this, yes. - is 5966bis the right place? I don't think so but another document means the 5966bis will be delayed... If signaling for this is needed, then a separate document would be good. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
