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
___
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
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
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
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
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
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
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
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
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,
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
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
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
As we have more and more DNS over TCP (large responses, response
rate limitation, even TLS for privacy) I think we should fix the
way DNS over TCP is supposed to be handled by servers.
Quoting RFC 1035 4.2.2 TCP usage:
- The server should assume that the client will initiate
connection
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,
15 matches
Mail list logo
