Subject: [DNSOP] go further about DNS over TCP?

From: Francis Dupont <[email-masked]>
Date: Tue, 24 Mar 2015 21:39:27 +0100

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 closing, and should delay closing its end of the
     connection until all outstanding client requests have been
     satisfied.

   - If the server needs to close a dormant connection to reclaim
     resources, it should wait until the connection has been idle
     for a period on the order of two minutes.  In particular, the
     server should allow the SOA and AXFR request sequence (which
     begins a refresh operation) to be made on a single connection.
     Since the server would be unable to answer queries anyway, a
     unilateral close or reset may be used instead of a graceful
     close.

A 2mn timeout simply has no chance to scale.

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...

Regards

[email-masked]

PS: I'll try to raise this at the mic if there is still enough time
(as this message is sent during the DNSOP session at the 92th IETF).

---

From: Paul Wouters <[email-masked]>
Date: Tue, 24 Mar 2015 16:49:34 -0400 (EDT)

>  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

>  and point 5 allows more if the area director agree.

I believe that was specifically changed to accomodate for this, yes.

>  document means the 5966bis will be delayed...

If signaling for this is needed, then a separate document would be good.

Paul

---

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 24 Mar 2015 21:31:07 +0000

> On Mar 24, 2015, at 3:39 PM, Francis Dupont <[email-masked]> wrote:
> 
> 
> So I propose:

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

---

From: Francis Dupont <[email-masked]>
Date: Tue, 24 Mar 2015 22:26:56 +0100

>  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.

>  I believe that was specifically changed to accomodate for this, yes.

=> I think so too.a

>  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

---

From: Francis Dupont <[email-masked]>
Date: Tue, 24 Mar 2015 22:42:22 +0100

In your previous mail you wrote:

>(note: first point is to make TCP support mandatory)
>  
>  For example, it says:
>  

=> but has this statement got a consensus? If it is the case
of course there is no reason to write twice the same thing.

>     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

PS: I note your opinion is to improve 5966bis.

---

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 24 Mar 2015 22:04:11 +0000

> On Mar 24, 2015, at 4:42 PM, Francis Dupont <[email-masked]> wrote:
> 
>> For example, it says:
>> 

Sorry, I should have realized that RFC 5966 (August 2010) already says exactly the same thing.

DW

---

From: Francis Dupont <[email-masked]>
Date: Tue, 24 Mar 2015 23:13:49 +0100

> 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

---

From: Paul Vixie <[email-masked]>
Date: Tue, 24 Mar 2015 15:44:24 -0700

i'm replying to several messages here, all from francis dupont.

> Francis Dupont <mailto:[email-masked]>
> Tuesday, March 24, 2015 1:39 PM
> ...

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.
> 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:[email-masked]>
> Tuesday, March 24, 2015 2:26 PM
>  In previous mail [Paul Wouters] 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".

> Francis Dupont <mailto:[email-masked]>
> Tuesday, March 24, 2015 2:42 PM
>  In previous [Duane Wessels] wrote:
>

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.
> not supposed to do here even it both makes sense and follows the real
since i know of stub resolvers (which i wrote and which saw wide distribution) which treat premature closure by the responder as an urgent condition, i believe that a recommendation that this not be done is now necessary, and i also believe that such a recommendation constitutes, as francis claims here, a protocol change. 

-- 
Paul Vixie

---

From: Tony Finch <[email-masked]>
Date: Wed, 25 Mar 2015 12:17:55 +0000

> not supposed to do here even it both makes sense and follows the real

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.

RFC 1035 also specifies that TCP connections can be closed abruptly, e.g.
with a RST. Clients must cope with this.

A client is buggy if it does not have a mechanism to retry queries that
failed because of a broken TCP connection.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Biscay: North 4 or 5, backing southwest 5 to 7. Moderate or rough. Showers,
rain later. Moderate or good.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 25 Mar 2015 07:52:29 -0700

> 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.

> 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

---

From: Jared Mauch <[email-masked]>
Date: Wed, 25 Mar 2015 09:56:04 -0500

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 <[email-masked]> 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.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 25 Mar 2015 15:52:39 +0100

>  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.

>  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 :-).

>  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

---

From: Paul Vixie <[email-masked]>
Date: Wed, 25 Mar 2015 08:00:03 -0700

> Jared Mauch <mailto:[email-masked]>
> Wednesday, March 25, 2015 7:56 AM

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

---

From: Ray Bellis <[email-masked]>
Date: Wed, 25 Mar 2015 15:05:41 +0000

On 25 Mar 2015, at 09:52, Paul Vixie <[email-masked]> 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.
 
> 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

---

From: Jared Mauch <[email-masked]>
Date: Wed, 25 Mar 2015 10:10:29 -0500

You can read the jabber logs. Let me know if you need help finding them. 

Jared Mauch

> On Mar 25, 2015, at 10:00 AM, Paul Vixie <[email-masked]> wrote:
> 
> 
> 
>> 	Jared Mauch	Wednesday, March 25, 2015 7:56 AM
> 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

---

From: Paul Vixie <[email-masked]>
Date: Wed, 25 Mar 2015 08:12:05 -0700

> 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

---

From: Ray Bellis <[email-masked]>
Date: Wed, 25 Mar 2015 15:12:53 +0000

> we are in trouble with the current proposed text (or mine :-).

That’s an interesting point.

IMHO, the client should rotate to the next available server, but shouldn’t mark the server as unavailable (for TCP connections) unless it fails to establish a connection at all.

Ray

---

From: Francis Dupont <[email-masked]>
Date: Wed, 25 Mar 2015 16:07:39 +0100

> current behaviors may be helpful?

=> I am afraid it could only add confusion so IMHO it may not.

>  > initiators have historically been able to assume that the responder would 
>  not close first. that's the operational environment in which RFC 1035 has be
>  en interpreted since 1987. if we want the initiator to change its assumption
>  s then we have to say so. the saying of so may or may not constitute a proto
>  col change since we're clarifying the assumptions rather than asking for dif
>  ferent 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 bu
>  ndling this guidance into a single document which is collectively a revision
>   to the protocol.

Thanks

---

From: Jared Mauch <[email-masked]>
Date: Wed, 25 Mar 2015 10:19:32 -0500

Nor is your comment helpful in moving the discussion forward. As the scribe from yesterday I tried to capture the essence of the room. I'm not aware of a requirement to post the contents to the list.

I would kindly ask you to take a quick read to get the essence of what transpired yesterday as you were not here in person. It might help with the context with what was discussed. 

I will send you a link in private. 

Jared Mauch

> On Mar 25, 2015, at 10:12 AM, Paul Vixie <[email-masked]> wrote:
> 
> 
> 
> Jared Mauch wrote:
>> 
>>> (is the definition of an IETF WG's "membership" still its mailing list not its meeting rooms?)
> 
> -- 
> Paul Vixie

---

From: Paul Vixie <[email-masked]>
Date: Wed, 25 Mar 2015 09:02:44 -0700

> Ray Bellis <mailto:[email-masked]>
> Wednesday, March 25, 2015 8:05 AM

are you sure? because if a server is going to close connections
prematurely, it may do so based on instantaneous load spikes, such as
the number of active connections reaching 80% of quota, where the
premature closure is designed to avoid connection overload rather than
signalling actual connection overload. if in the UDP case we would
respond to an unanswered query by repeating the same query to the same
server, then in the TCP case we might want to do likewise.

it could also be that the traditional UDP retry mechanism is seriously
flawed, and that even in that case we should move on to the next server,
and only return to the timed-out server if all other servers also time out.

this bears discussion.
> IMHO, any client that ever did this is over-reacting and I don’t believe specific guidance is required.

if 100% of the installed base had not at one time in the history of DNS
behaved that way, i could agree. but because the specification's
guidance is demonstrably light in this area, is there any harm in
extending that guidance -- "for the avoidance of confusion or doubt" ?

perhaps you've got me procmailed. see below:

> From: Paul Vixie <[email-masked]>
> Date: Saturday, February 28, 2015 10:04 AM
> To: Stephane Bortzmeyer <[email-masked]>
> CC: [email-masked]
> Subject: [DNSOP] [TCP] edns-tcp-keepalive, and 5966bis
>
>
>
> ... please do not change recommended initiator behaviour in ways that
> violate reasonable assumptions of current responders. if the client
> wants to keep a connection open longer than it takes to send and
> receive the queries they have on-hand, they should find out whether
> the server agrees with this incompatible change to the connection
> management logic described in RFC 1035 4.2.2.

see also:

> From: Paul Vixie <[email-masked]>
> Date: Thursday, March 19, 2015 4:27 AM
> To: Andrew Sullivan <[email-masked]>
> CC: [email-masked]
> Subject: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01
>
>
> Andrew Sullivan wrote:
>> On Thu, Mar 19, 2015 at 03:58:47AM -0700, Paul Vixie wrote:
>>> >
>>> > if you want new behaviour, negotiate for it.
>> So you want a way to signal the new behaviour and negotiate that?
>
> i don't care whether there's new behaviour. but if new behaviour is
> going to be incompatible with existing implementations, then that new
> behaviour must be negotiated. that's how we rebuilt this airplane in
> flight over and over again from 1986 to the present. it's all "DNS".

see also:

> From: Paul Vixie <[email-masked]>
> Date: Wednesday, March 18, 2015 1:59 AM
> To: [email-masked]
> Subject: [DNSOP] remarks on draft-ietf-dnsop-5966bis-01
> i have read draft-ietf-dnsop-5966bis-01, and i have some comments.
>
> tl;dr: this document is nowhere near ready to ship.
>
>> ...
>>
> this language is too strong, and breaks working configurations. many
> DNS servers are completely functional for all intents and purposes
> even though an upstream firewall or other middlebox prevents them
> from hearing TCP requests.
>
> i suggest some adjective other than REQUIRED here. perhaps STRONGLY
RECOMMENDED.
...
>>    Whilst this document makes no specific requirements for operators of
>>    DNS servers to meet,
>
> if that's true, then you really can't say REQUIRED (see above).
>
>> ...
>>
>>    However, transport of UDP packets that exceed the size of the path
>>    MTU causes IP packet fragmentation, which has been found to be
>>    unreliable in some circumstances.
>
> can i ask, as the RFC 2671 author, that you change the word "some" to
be instead the word "many" ?
>
>> 6.  Connection Handling
>>
>>    One perceived disadvantage to DNS over TCP is the added connection
>>    setup latency, generally equal to one RTT.  To amortize connection
>>    setup costs, both clients and servers SHOULD support connection reuse
>>    by sending multiple queries and responses over a single TCP
>>    connection.
>>
>>    servers may close a connection at any time.
>
> this is factually wrong. servers are not permitted to close a
> connection at any time. (this is what the spec says, and the
> expectations of any implementation that faithfully followed the spec
> must be called "reasonable").
>
>>   Clients MUST be prepared
> this is factually wrong. a client can give up on a server for at
> least the duration of the current transaction if it closes a
> connection prematurely.
>
>>    Section 4.2.2 of [RFC1035] says:
>>
>>       If the server needs to close a dormant connection to reclaim
>>       resources, it should wait until the connection has been idle for a
>>       period on the order of two minutes.  In particular, the server
>>       should allow the SOA and AXFR request sequence (which begins a
>>       refresh operation) to be made on a single connection.  Since the
>>       server would be unable to answer queries anyway, a unilateral
>>       close or reset may be used instead of a graceful close.
>>
>>    Other more modern protocols (e.g., HTTP/1.1 [RFC7230]) have support
>>    for persistent TCP connections and operational experience has shown
>>    that long timeouts can easily cause resource exhaustion and poor
>>    response under heavy load.  Intentionally opening many connections
>>    and leaving them dormant can trivially create a "denial-of-service"
>>    attack.
>
> noting: this is why i frequently refer to the RFC 1035 connection
management logic as "unfortunate".
>
>>    It is therefore RECOMMENDED that the default application-level idle
>>    period should be of the order of seconds, but no particular value is
>>    specified.  In practice, the idle period may vary dynamically, and
>>    servers MAY allow dormant connections to remain open for longer
>>    periods as resources permit.
>
> noting, as a recommendation, this is harmless to the installed base,
> as long as the installed base remembers that a faithful
> implementation of RFC 1035 4.[2].2 will not be doing this, and avoids
> perturbing those servers with long-lived TCP sessions that their
> connection management logic is ill-equipped to handle.
>
>>    To mitigate the risk of unintentional server overload, DNS clients
>>    MUST take care to minimize the number of concurrent TCP connections
>>    made to any individual server.
>
> not just concurrent, but also, idle. no idle connections can be
> permitted unless the client knows absolutely that the server is
> modern and is following the specification now being reviewed.
>
>> ...
>>    For reasons of efficiency, implementations SHOULD wherever possible
>>    attempt to coalesce the two byte length field and subsequent DNS
>>    payload data into a single packet.
>
> i think you can word this more strongly. as in: "Since TCP responders
> are sensitive to timeout conditions, some extant implementations will
> abort a TCP session if the first TCP window does not contain both the
> two-octet length field and the entire request message described by
> that length field. TCP initiators should therefore take care to
> transmit the two-octet length field, and the message described by
> that length field, in a single TCP window."
...
>> 7.  Query Pipelining
>>
>>    Due to the use of TCP primarily for zone transfer and truncated
>>    responses, no existing RFC discusses the idea of pipelining DNS
>>    queries over a TCP connection.
>>
>>    In order to achieve performance on par with UDP DNS clients SHOULD
>>    pipeline their queries.  When a DNS client sends multiple queries to
>>    a server, it should not wait for an outstanding reply before sending
>>    the next query.  Clients should treat TCP and UDP equivalently when
>>    considering the time at which to send a particular query.
>
> add: "TCP initiators should be aware that some responders will answer
> in order no matter what, and they should not therefore expect
> parallelism. If performance is a consideration, the use of UDP will
> be a better guarantor of same, unless the initiator is sure that the
> responder is acting according to this amendment to the DNS
> protocol."
>
>>    DNS servers (especially recursive) SHOULD expect to receive pipelined
>>    queries.  The server should process TCP queries in parallel, just as
>>    it would for UDP.  The handling of responses to pipelined queries is
>>    covered in the following section.
>>
>>    When pipelining queries over TCP it is very easy to send more DNS
>>    queries than there are DNS Message ID's.  Implementations MUST take
>>    care to check their list of outstanding DNS Message ID's before
>>    sending a new query over an existing TCP connection.  This is
>>    especially important if the server could be performing out-of-order
>>    processing.
>
> i think you mean "since" rather than "if", as in, "since the server
> could be performing out-of-order processing." that is, if an
> initiator is sure that the responder is answering in order, as most
> TCP responders do today, then the initiator would be free to re-use
> the same TXID over and over, as some TCP initiators are known to do
> today.
>
>>   In addition, when sending multiple queries over TCP it
>>    is very easy for a name server to overwhelm its own network
>>    interface.  Implementations MUST take care to manage buffer sizes or
>>    to throttle writes to the network interface.
>
> i cannot imagine what this could mean, in real terms, to a resolver
> implementer, having only UNIX or Windows system calls to work with.
> can you provide some examples?
>
>> 8.  Response Reordering
>>
>>    RFC 1035 is ambiguous on the question of whether TCP responses may be
>>    reordered -- the only relevant text is in Section 4.2.1, which
>>    relates to UDP:
>>
>>       Queries or their responses may be reordered by the network, or by
>>       processing in name servers, so resolvers should not depend on them
>>       being returned in order.
>>
>>    For the avoidance of future doubt, this requirement is clarified.
>
> you can't do that. let me explain:
>
>>    Authoritative servers and recursive resolvers are RECOMMENDED to
>>    support the sending of responses in parallel and/or out-of-order,
>>    regardless of the transport protocol in use.
>
> this works as a recommendation for responders, which initiators had
> better be prepared to cope with, since the only time they have to
> cope with it is if they use pipelining.
>
>>   Stub and recursive
>>    resolvers MUST be able to process responses that arrive in a
>>    different order to that in which the requests were sent, regardless
>>    of the transport protocol in use.
>
> this does not work as a MUST, because existing implementations which
> were faithful to RFC 1035 might not be able to do this -- and you
> know this or you would not be trying to clarify the point at this
> late date. i think that if you want new behaviour you have to
> negotiate for it, not merely mandate it, since to mandate it would
> invalidate previously-valid implementations and break
> previously-working configurations.
>
>> ...
>> 9.  TCP Fast Open
>>
>>    This section is non-normative.
>>
>> ...
>>
>>    Adding support for this to existing name server implementations is
>>    relatively easy, but does require source code modifications.  On the
>>    client, the call to connect() is replaced with a TFO aware version of
>>    sendmsg() or sendto(). ...
>
> i object to the use of UNIX syscalls being used to describe a
> protocol, even non-normatively.
>
> let me close by quoting my final remarks in the review of
> [Connection-Oriented-DNS]:
>
> --------
> the backdrop of these comments is that the DNS is a large, complex,
> and mostly-working system. as the stewards of its protocol, we have
> an obligation to do no avoidable harm. since a TCP/53 listener may
> have been developed and deployed by someone not within the sound of
> DNSOP's voice today, but who faithfully followed the unfortunate
> advice in RFC 1035 regarding TCP connection management, we have to
> respect their choices. what that really means is we have to avoid
> saturating their small TCP connection capacity (as managed by their
> long session timeouts) since that TCP capacity is the only hope of
> any UDP initiator who hears TC=1 from them. i argue that while any
> attacker can take down that TCP capacity at will with a trivial
> one-line perl script, that does not give us the right to take it down
> willfully, by using persistent TCP by default.
>
> --------
>
> see also:
>
> http://www.circleid.com/posts/20130913_on_the_time_value_of_security_features_in_dns/
>
> http://queue.acm.org/detail.cfm?id=1242499

so, yes, we "must."

-- 
Paul Vixie

---

From: Ray Bellis <[email-masked]>
Date: Wed, 25 Mar 2015 16:20:05 +0000

On 25 Mar 2015, at 11:02, Paul Vixie <[email-masked]> wrote:

> are you sure? because if a server is going to close connections prematurely, it may do so based on instantaneous load spikes, such as the number of active connections reaching 80% of quota, where the premature closure is designed to avoid connection overload rather than signalling actual connection overload. if in the UDP case we would respond to an unanswered query by repeating the same query to the same server, then in the TCP case we might want to do likewise.
> 
> it could also be that the traditional UDP retry mechanism is seriously flawed, and that even in that case we should move on to the next server, and only return to the timed-out server if all other servers also time out.
> 
> this bears discussion.

Yes, it does :)

> if 100% of the installed base had not at one time in the history of DNS behaved that way, i could agree. but because the specification's guidance is demonstrably light in this area, is there any harm in extending that guidance -- "for the avoidance of confusion or doubt” ?

That’s fair - I guess it wouldn’t do any harm.

> perhaps you've got me procmailed. see below:

No, I saw those.  I just didn’t agree with the conclusion :p

I will however re-read those messages and see whether my position changes.

Ray

---

From: Francis Dupont <[email-masked]>
Date: Wed, 25 Mar 2015 21:49:20 +0100

I am splitting the thread in separate points.

---

From: Francis Dupont <[email-masked]>
Date: Wed, 25 Mar 2015 22:04:28 +0100

>  that document was a protocol change not a clarification.

=> this raises again the 2 not technical points (DNSOP or not,
5966bis or not) and adds a choice:
 - don't change the TCP requirement
 - make TCP RECOMMENDED
 - make TCP REQUIRED

IMHO to not change the TCP requirement (which is today a MAY for
deployment on clients and servers) will be very irresponsible because
we push DNS over TCP at many places:
 - long responses for IPv6 and/or DNSSEC
 - response rate limitation
 - privacy (how to talk about TLS if TCP doesn't work? :-)
 - even no answer (cf QTYPE=ANY messages)
so as we add everyday a new reason to switch to a TCP transport it is
time to make it to work everywhere in the real world.

Now between RECOMMENDED and REQUIRED there is no real case where someone
can justify to not follow the RECOMMENDED, and if today the lack of TCP
doesn't break too many things (i.e., it can be considered as an
inconvenience) it could be no longer the case tomorrow.
So I am in favor of a REQUIRED but as you wrote the fight won't be
on the requirement level but more on the requirement idea itself.

About the 5966[bis] text in the introduction:

   Most DNS [RFC1034] transactions take place over UDP [RFC0768].  TCP
   [RFC0793] is always used for full zone transfers (AXFR) and is often
   used for messages whose sizes exceed the DNS protocol's original
   512-byte limit.

This text is clearly outdated.

And:

   DNS servers to meet, ...

This must be changed and not only for servers. If it can't be done
in DNSOP it has to be done at another place (intarea itself?).

Thanks

---

From: Mark Andrews <[email-masked]>
Date: Thu, 26 Mar 2015 08:23:32 +1100

> deployment on clients and servers) will be very irresponsible because

DNS + TCP was *never* a MAY.  RFC 1123 says SHOULD.  People took
liberties and treated it as a MAY. 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Francis Dupont <[email-masked]>
Date: Wed, 25 Mar 2015 23:48:02 +0100

>  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).

>  since i know of stub resolvers (which i wrote and which saw wide distributio
>  n) which treat premature closure by the responder as an urgent condition, i 
>  believe that a recommendation that this not be done is now necessary, and i 
>  also believe that such a recommendation constitutes, as francis claims here,
>   a protocol change. 

=> we are in strong agreement about this point.

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Thu, 26 Mar 2015 00:01:59 +0100

(other points, i.e., not TCP mandatory or timeouts)

>  below, for preserving their present level of brokenness.

=> IMHO this means we need to introduce a bit of signaling before
trying a better behaviour at any side, so legacy initiators and
servers are recognized.

>  idleness has been explicitly negotiated.

=> at the exception of the SOA + xXFR case I don't believe that
idling initiators are common today.

>  obviously, any existing

=> I fully agree and fortunately we can publish 3966bis before even
adopting one of the signaling proposal.

>  pool of potential connections is running dry.

=> the advantage of the keepalive proposal is the server can give the
timeout it wants to use. And a bit carries too few infos, e.g.,
how to announce the initiator is smart but in this case allows
(or wants) the server to close after the response?

Thanks

---

From: Francis Dupont <[email-masked]>
Date: Thu, 26 Mar 2015 00:13:06 +0100

>  liberties and treated it as a MAY. 

=> there is a NANOG stuff explaining these liberties.
So IMHO we have to make clear it is at least a SHOULD and not
only in implementations but also in deployments (i.e.,
a SHOULD/MUST NOT filter tcp/53 out).

Thanks

PS: I want to no longer see my home ISP (Free) supporting IPv6,
DNSSEC but not DNS over TCP...

---

From: Paul Vixie <[email-masked]>
Date: Wed, 25 Mar 2015 17:37:05 -0700

> Wednesday, March 25, 2015 3:48 PM

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

---

From: Paul Vixie <[email-masked]>
Date: Wed, 25 Mar 2015 17:51:34 -0700

> Wednesday, March 25, 2015 4:01 PM

we are in agreement on this point.
> idling initiators are common today.

you are correct, and you have corrected me. even though the initiator's
second transaction in the SOA+xFR case is synchronous to its receipt of
the response to its first transaction, that period could be described as
"idle". in extreme endpoint sets (where much RTT and congestion exist)
this could be a matter of seconds, which is an eternity from the point
of view of a server trying to resist an attack against its connection
resources. (this realization came from a different thread, and informed
my recommendation in that thread as to how a server should set up its
timeout policy.)

> (or wants) the server to close after the response?

that draft deserves discussion. in your example, the client could send a
FIN at the end of its request, which is an unambiguous signal to the
server that it should likewise send a FIN at the end of its response. in
my mind's eye, i envision a server policy that can change at the end of
each response, so that if its connection resources are in the "green
zone" it sets the "idle OK" bit on its response, and in the "yellow
zone" it clears the "idle OK" bit, allowing a client to send pent-up
back to back requests but then to FIN when they run out of things to
send. (if the server gets into the "red" zone, it just starts closing
connections.)

-- 
Paul Vixie

---

From: Tony Finch <[email-masked]>
Date: Thu, 26 Mar 2015 00:56:32 +0000

> On 25 Mar 2015, at 23:01, Francis Dupont <[email-masked]> wrote:
> 

I believe adns keeps its TCP connection open.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at

---

From: Francis Dupont <[email-masked]>
Date: Thu, 26 Mar 2015 15:17:54 +0100

I like your proposed text so if there is no objection I suggest to
simply adopt it (and to close this particular point).

Thanks

PS: for people who want to match the text here are the first 2 lines: