Subject: [dnsext] Draft: WGLC draft-ietf-dnsext-dns-tcp-requirements

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 15 Feb 2010 18:18:36 -0500

Dear Colleagues,

This message starts a Working Group Last Call for "DNS Transport over 
TCP - Implementation Requirements"
http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-dns-tcp-requirements/

This WGLC will conclude on midnight March 31st 2010 UTC.

This document is aimied at the standards track, if published, will
update RFC1034 and RFC1123. The docoument states in clear modern 
standards language the TCP requirements for implementations.

Please send a message to namedroppers that you have reviewed the 
document and whether you support it.

     Olafur

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 15 Feb 2010 19:50:43 -0500

Just for the record this is not a Draft but full WGCL,
sorry for the cut and paste error :-(

	Olafur

---

From: Mark Andrews <[email-masked]>
Date: Tue, 16 Feb 2010 13:02:18 +1100

Most DNS [RFC1035] transactions take place over UDP [RFC0792].  The
   TCP [RFC0793] is used for zone transfers and for the transfer of
   other packets which exceed the protocol's original 512 byte packet-
   size limit.

"The TCP is used" just doesn't read correct.

"TCP is used" or "The TCP protocol is used".  Yes I know the
later is like saying "PIN number"

Which "protocol" is not clear in "exceed the protocol's original".

Also it's the UDP message limit not the UDP packet size limit.  The later
is at least 540 bytes without IP options.

   Most DNS [RFC1035] transactions take place over UDP [RFC0792]. 
   TCP [RFC0793] is used for zone transfers and for the transfer of
   other packets which exceed the DNS's original 512 byte UDP message
   size limit.

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

---

From: [email-masked]
Date: Tue, 16 Feb 2010 08:54:40 +0000

>    other packets which exceed the DNS's original 512 byte UDP message

Thanks Mark, good spots.  As those are just editorial I'll ensure they're 
resolved before this goes to the IESG.

kind regards,

Ray

-- 
Ray Bellis, MA(Oxon) MIET
Senior Researcher in Advanced Projects, Nominet
e: [email-masked], t: +44 1865 332211

---

From: Jim Reid <[email-masked]>
Date: Tue, 16 Feb 2010 16:43:41 +0000

Some editorial nits:

"Existing" can be removed from "Existing deployments". Can there be a  
deployment of something that doesn't exist?

I think Mark's tweaks don't scan well. So how about:
   Most DNS [RFC1035] transactions take place over UDP [RFC0792].
   TCP [RFC0793] is used for zone transfers and for other DNS
   packets which exceed the 512 byte UDP message size limit
   imposed in RFC1035.

I'd change "some implementations lack the software logic  
necessary...." to some implementations are unable to reassemble  
fragmented datagrams".

The comma at "has arrived, and the only" is superflous and incorrect.

Long responses doesn't seem right: large responses?

"Authoritative resolver implementations MUST support TCP so that they  
may serve any long responses that they are configured to serve" seems  
clumsy and ambiguous: It suggests TCP might be optional if there are  
no big responses to serve. What's an authoritative resolver anyway? It  
may be better to say:

"Authoritative servers MUST support TCP so that they can serve  
responses in cases where EDNS is not available and the reply would  
exceed the 512 byte UDP limit in RFC1035.

Is it really necessary to put denial of service in quotes?

A comma is needed after "overload" in "To mitigate the risk of  
unintentional server overload DNS..."

"Whilst" seems rather quaint and may confuse non-native speakers.  
[Yeah verily thy noble lord...] How about "Although there is..."?

---

From: Mark Andrews <[email-masked]>
Date: Wed, 17 Feb 2010 12:25:52 +1100

> exceed the 512 byte UDP limit in RFC1035.

You want TCP to be implemented independently of EDNS support.

* Authoritative servers MUST support TCP.  While RFC1123 listed
  TCP support for DNS as a SHOULD it has been treated as a MAY by
  some vendors and operators leading to lookup failurs when clients
  fell back to TCP when TC was set or illegal splitting of RRsets
  in attempts to return data that wouldn't fit without setting TC 
  when only UDP was supported.  UDP only configurations are removed
  in the interest of a more robust DNS service.

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 16 Feb 2010 17:36:27 -0800

Earlier drafts allowed authoritative servers that don't allow AXFR and
don't serve responses >512 bytes to disable TCP support, but this
seems to have been omitted from the latest draft.  I'd like to see
this reintroduced.

---

From: [email-masked]
Date: Wed, 17 Feb 2010 10:24:32 +0000

> seems to have been omitted from the latest draft.  I'd like to see

Matthew, the previous text to which you refer was:

"On a case by case basis, authoritative DNS server operators MAY elect 
 to disable DNS transport over TCP if all of the following conditions
 are satisfied:

 o  the server is authoritative only
 o  the server does not support AXFR
 o  all requests and responses are guaranteed to be <= 512 bytes".

This was describing an _operational_ case in which TCP support is not 
required, and the group consensus was that the draft should focus on 
implementation rather than operations.

Hence the new version mandates TCP support for _implementations_, with the 
caveat (at the end of the introduction) that operators may disable it, 
albeit with side effects.

kind regards,

Ray

---

From: [email-masked]
Date: Wed, 17 Feb 2010 10:53:47 +0000

>    packets which exceed the 512 byte UDP message size limit

How's this:

"Most DNS [RFC1035] transactions take place over UDP [RFC0792]. TCP 
[RFC0793] is used for zone transfers and for messages whose sizes exceed 
the DNS protocol's original 512 byte limit"

> necessary...." to some implementations are unable to reassemble 

"Many firewalls routinely block fragmented IP packets, and some do not 
implement the algorithms necessary to reassemble fragmented packets"
 
> The comma at "has arrived, and the only" is superflous and incorrect.

My style guide disagrees - I'll leave that for the RFC Editors to decide. 
They like commas.
 
> Long responses doesn't seem right: large responses?

"long" is used consistently through the draft.

> exceed the 512 byte UDP limit in RFC1035.

As Mark says the question of EDNS is really separate, and that would make 
this more than an editorial change.  How about:

"Authoritative server implementations MUST support TCP so that they do not 
limit the size of responses.".

> Is it really necessary to put denial of service in quotes?

Probably not - removed.
 
> unintentional server overload DNS..."

OK.

> [Yeah verily thy noble lord...] How about "Although there is..."? 

Done.

BTW, Niall O'Reilly noticed the draft still said "of the order of TBD 
seconds" for connection timeouts.  I propose to simply remove the "TBD" 
qualifier, since to specify a particular recommended value ould almost 
certainly lead to endless arguments about what that specific value should 
be.

kind regards,

Ray

p.s. please don't forget to actually support the document's progress!

---

From: "George Barwood" <[email-masked]>
Date: Wed, 17 Feb 2010 11:14:06 -0000

----- Original Message ----- 
From: "Olafur Gudmundsson" <[email-masked]>
To: "namedroppers" <[email-masked]>
Sent: Monday, February 15, 2010 11:18 PM
Subject: [dnsext] Draft: WGLC draft-ietf-dnsext-dns-tcp-requirements

> document and whether you support it.

I have reviewed the document, and support it.

"This document therefore RECOMMENDS that the application-level idle
period should be of the order of TBD seconds."

We need to know what TBD is going to be. 10? 30? 120?
Or leave that to implementations and operators to decide.

" Operators of recursive servers should ensure that they only accept
   connections from expected clients, and do not accept them from
   unknown sources.  In the case of UDP traffic this will protect
   against reflector attacks [RFC5358]"

Not entirely : since the source IP address is forged, reflector attacks are not stopped,
but they are limited to attacks against expected clients. I suggest a weakening word
be inserted "this will help protect". In any case I think UDP security is outside the scope of
this document, so why mention it?

I suggest an informative reference to a general document on TCP security, e.g.

---

From: Niall O'Reilly <[email-masked]>
Date: Wed, 17 Feb 2010 11:22:31 +0000

> p.s. please don't forget to actually support the document's progress!

	This is to express my support (FWIW) and to confirm
	that I've actually read the document and think it's useful.

	/Niall

---

From: [email-masked]
Date: Wed, 17 Feb 2010 11:26:18 +0000

> Or leave that to implementations and operators to decide.

See recent reply to Jim Reid.
 
> Not entirely : since the source IP address is forged, reflector 
> attacks are not stopped, but they are limited to attacks against
> expected clients. I suggest a weakening word

Strictly speaking full protection is attained by using border ingress 
filters, not just server configuration.  I don't mind dropping "help" in 
though.

Ray

---

From: Jim Reid <[email-masked]>
Date: Wed, 17 Feb 2010 11:35:34 +0000

> 	that I've actually read the document and think it's useful.

<AOL Mode>Me too!</AOL Mode>

---

From: Jim Reid <[email-masked]>
Date: Wed, 17 Feb 2010 11:53:28 +0000

> the DNS protocol's original 512 byte limit"

Fine with me.

> implement the algorithms necessary to reassemble fragmented packets"

Aside from the unnecessary comma :-), I don't think your text tells  
the full story. That's why I suggested the document could say some  
implementations can't reassemble fragments without going into  
specifics. There could be many reasons for failure to reassembly  
fragments. A box could have software that implements the reassembly  
algorithms but never gets to exercise that code path: bugs in the  
code, fragments get dropped by the network interface, etc, etc.

> "long" is used consistently through the draft.

True. But a packet's dimensions are more usually discussed in terms of  
size rather than (string) length.

>  How about:

Fine here Ray.

---

From: [email-masked]
Date: Wed, 17 Feb 2010 12:31:43 +0000

> >limit the size of responses.".

	and we are saying nothig about resolvers MUST support TCP so
	that they can receive responses too large for UDP?

--bill

---

From: [email-masked]
Date: Wed, 17 Feb 2010 12:39:17 +0000

>    that they can receive responses too large for UDP?

Yes, we do:

"A recursive resolver or forwarder MUST support TCP so that it does not 
prevent long responses from a TCP-capable server from reaching its 
TCP-capable clients."

Ray

---

From: [email-masked]
Date: Wed, 17 Feb 2010 12:43:51 +0000

> prevent long responses from a TCP-capable server from reaching its 
	and stubs are left off the hook... UDP/512 only...?

--bill

---

From: [email-masked]
Date: Wed, 17 Feb 2010 12:46:41 +0000

>    and stubs are left off the hook... UDP/512 only...?

No, Bill, they're not.  Read the next line of the draft... ;-)

Ray

---

From: Jim Reid <[email-masked]>
Date: Wed, 17 Feb 2010 13:00:31 +0000

On 17 Feb 2010, at 12:31, [email-masked] wrote:

>>> "Authoritative server implementations MUST support TCP so that they
>>> do not limit the size of responses.".
>>

Ray's text already does that IMO. An authoritative server has to be  
able to speak DNS over TCP in case the responses are too big. For some  
definition of 'big'. It doesn't matter if the size limitation is  
imposed by UDP or EDNS: supporting TCP means the data will get through.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 17 Feb 2010 09:58:37 -0800

Overall, I support this draft, however, I'd make the following suggestion.

For section 5: Connection handling.

I think a fixed timeout is limiting, rather, I'd suggest text perhaps more like this:

> Other more modern protocols (e.g.  HTTP [RFC2616]) 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.

At the same time, prematurely closing connections increases client query latency.  Since DNS is commonly on the critical path for numerous network activities, maintaining low latency is a priority.  Thus this document therefore RECOMMENDS that the application-level idle period should be undefined, as it will vary based on the traffic a particular server received.  

A server should monitor its current resource utilization and, when under state pressure, MAY elect to terminate idle connections in order to free state.  Therefore if the server needs to unilaterally close a dormant TCP connection it MUST be free to do so whenever required.  At the same time, when the idle connections are not consuming significant resources, the server SHOULD maintain idle connections in order to reduce protocol latency for subsequent queries.  

Servers MAY instead use a fixed timeout for idle connections, but clients MUST NOT rely on such a timeout being consistent.  Likewise, a server MAY limit the number of concurrent connections a client has outstanding to a number greater than four.  If this limit is exceeded, may terminate an arbitrary set of the client's connections until the client is below the limit, even if some of the connections have outstanding queries.

(Rationall:  Timeout on idle connections should be dynamic in practice, so it should be expressed as such.
The server should be allowed to limit the number of outstanding connections from any particular client, although there should be a default minimum limit)

---

From: Jim Reid <[email-masked]>
Date: Wed, 17 Feb 2010 18:22:52 +0000

On 17 Feb 2010, at 17:58, Nicholas Weaver wrote:

> Servers MAY instead use a fixed timeout for idle connections, but  
> clients MUST NOT rely on such a timeout being consistent. Likewise,  
> a server MAY limit the number of concurrent connections a client has  
> outstanding to a number greater than four.

Why four and not three or five?

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 17 Feb 2010 10:25:40 -0800

On Feb 17, 2010, at 10:22 AM, Jim Reid wrote:

>> Servers MAY instead use a fixed timeout for idle connections, but clients MUST NOT rely on such a timeout being consistent. Likewise, a server MAY limit the number of concurrent connections a client has outstanding to a number greater than four.
> 

You want an arbitrary number, probably greater than two, but why four in particular to say as a minimum?

Four is a number of concurrent HTTP sessions that web browsers will keep open to a given server.  Its also a power of 2.

So its one of those "traditionally pointless numbers"

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 17 Feb 2010 12:12:41 -0800

> albeit with side effects.

I continue to oppose the ridiculous notion that an IETF working group
gets to decide unobservable implementation details.  There's no way
for you to distinguish an authoritative server that supports TCP but
disables it from an authoritative server that does not support TCP,
and so there's no impact on interoperability of allowing both instead
of just one.

>From RFC 2119, Section 6:

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

You're violating RFC 2119 by using "MUST" to describe TCP support
requirements in a situation not required for interoperation.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 17 Feb 2010 12:32:51 -0800

> and so there's no impact on interoperability of allowing both instead

Actually, there is a huge distinction:

An implementation has no way of knowing that responses will never need to be truncated.

An operational deployment does.

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 17 Feb 2010 12:49:53 -0800

> An implementation has no way of knowing that responses will never need to be truncated.

False.  djbdns includes a dedicated RBL DNS server (rbldns) that uses
a database consisting of just a bunch of blacklisted CIDR blocks.  It
only ever returns answers with a single A record and/or a single TXT
record less than about 100 bytes long.  It knows it will never return
a truncated response.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 17 Feb 2010 12:53:09 -0800

> record less than about 100 bytes long.  It knows it will never return

A GENERAL purpose implementation will have no way of knowing...

Better phrasing?

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 17 Feb 2010 12:59:03 -0800

> A GENERAL purpose implementation will have no way of knowing...

Irrelevant.  rbldns is still a legitimate DNS server.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 17 Feb 2010 13:03:40 -0800

> Irrelevant.  rbldns is still a legitimate DNS server.

It is not however a general purpose DNS server, because it is deliberately restricted to serving records which the implementer a-priori knew or assumed that would never need truncation.

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 17 Feb 2010 13:06:26 -0800

On Wed, Feb 17, 2010 at 1:03 PM, Nicholas Weaver
<[email-masked]> wrote:
> It is not however a general purpose DNS server,

Irrelevant.  draft-ietf-dnsext-dns-tcp-requirements does not limit
itself to "general purpose DNS servers".

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 17 Feb 2010 13:11:02 -0800

> itself to "general purpose DNS servers".

How about

"Unless the implementer or deployer can a-priori determine that responses will NEVER exceed 512B of UDP..." and just leave it at that?

There is really NO excuse for a DNS server implementation to not support TCP.  Adding in proper TCP support to a DNS authority takes at most a couple of man-hours of work.  (Speaking as I just added in TCP to my evil-ugly-little server...  True, it doesn't answer things the same way, but...)

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 17 Feb 2010 17:47:24 -0500

On Wed, Feb 17, 2010 at 12:12:41PM -0800, Matthew Dempsky wrote:

> gets to decide unobservable implementation details.  

I think that claim is rather strong.  Surely the implementation
details are in fact observable at least by the operator who wants to
turn on the feature.  The text as it stands just says what features an
implementation needs to offer to operators who choose to use the
implementation, if that implementation is going to be said to conform
to the text.

Note that there are no protocol police.  There is nobody who can force
any implementation actually to implement a given detail of the
protocol.  We rely on market forces, contracts, and that sort of thing
for the pressure to cause the implementation.  There are RFCs that
are, bluntly, market failures.

Nevertheless, your opposition is noted as a part of this LC. 

> There's no way

That argument does not address the reasons, outlined in the draft, why
TCP is an important part of DNS servers.  I understand you don't
accept those arguments, but your rejection would be easier to swallow
if you offered an argument why you think those arguments are wrong.

Best regards,

A
-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 17 Feb 2010 15:23:26 -0800

On Wed, Feb 17, 2010 at 2:47 PM, Andrew Sullivan <[email-masked]> wrote:
> turn on the feature.

That's irrelevant to the matter of interoperability.

> The text as it stands just says what features an

This I-D is intended for Standards Track, and not Best Community
Practices.  As such, it should limit itself to matters of
interoperability, rather than suggesting feature sets that operators
should look for in the implementations they use.

> Note that there are no protocol police.

Indeed, only protocol vigilantes like rfc-ignorant.org.

> Nevertheless, your opposition is noted as a part of this LC.

Thank you.

> if you offered an argument why you think those arguments are wrong.

I'm sorry, if you could state exactly which argument or arguments you
had in mind, I will respond specifically to them.

My overall stance is that TCP support for authoritative servers is not
universally required for interoperability, and by RFC 2119, the
blanket use of the term "MUST" is therefore incorrect.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 17 Feb 2010 15:50:20 -0800

> should look for in the implementations they use.

TCP is needed for interoperability when responses are over 512B, due to the nature of the Internet being full of middleboxes and firewalls which put limits on UDP traffic in general (>10% in measurements), and DNS UDP traffic in particular (>1% in measurements).

Yes, it would be great to have a magic wand to make the brokenness go away, but as this brokenness is reality, it is necessary to work around it.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Feb 2010 16:05:50 -0800

>That's irrelevant to the matter of interoperability.

That statement is wrong. If an implementation cannot do X, then a user of that implementation cannot interoperate in an environment where X is required.

>should look for in the implementations they use.

That is a creative interpretation of what a Standards Track RFC should do. It is not supported by current practice in the IETF.

>Indeed, only protocol vigilantes like rfc-ignorant.org.

The "only" is wrong. There are many users (in this case, operators) who want to know whether or not software they are using conforms to a particular RFC. They are not, to use your insult, "protocol vigilantes": they are the people who make the Internet work for end users. If you don't care about them, that's fine, but many of us do.

--Paul Hoffman, Director
--VPN Consortium

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 17 Feb 2010 19:12:44 -0500

Note to all: I hereby encourage, as moderator, everyone participating
in this thread to self-rate-limit, because I think we're in danger of
overheating the discussion.

> That's irrelevant to the matter of interoperability.

Your position is noted for the purposes of the WGLC.  That's actually
part of the open question before us.  Others may disagree with your
conclusion.

> should look for in the implementations they use.

And the draft includes an argument about why interoperability is
better served if all authority servers _can_ support TCP.  What is an
open question is whether the WG agrees: that's what the WGLC in effect
means.  You have registered your disagreement with that claim.  It is
duly noted.  I think it would be good if you thought about limiting
your further remarks on this issue, unless you have a new argument on
this matter to offer.

> had in mind, I will respond specifically to them.

The arguments in the draft, which try to make the case why TCP is
needed.  If you seriously read the draft and cannot see in it those
arguments, then we may have a serious problem indeed.  Please state as
much clearly, in that case.  This is not the same as seeing the
arguments and not agreeing with them because you think they draw wrong
conclusions or are otherwise flawed.  If you instead feel the latter
way, then please state that instead.

> blanket use of the term "MUST" is therefore incorrect.

I cannot accept this interpretation.  The 2119 requirement is for
interoperating with the protocol as defined by the document, not for
interoperating _at all_ with the protocol (since if that were the
case, 2119 standards language could never be made stronger). 

Best,

A

-- 
Andrew Sullivan
[email-masked]
Shinkuro, Inc.

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 17 Feb 2010 16:15:27 -0800

On Wed, Feb 17, 2010 at 3:50 PM, Nicholas Weaver
<[email-masked]> wrote:
> TCP is needed for interoperability when responses are over 512B,

Yes, but not all authoritative DNS servers need to send responses that
are over 512B, thus blanket requiring all authoritative DNS servers to
support TCP is not necessary for interoperability, and as per RFC
2119, using "MUST" to describe that requirement is incorrect.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 17 Feb 2010 17:55:26 -0800

> 2119, using "MUST" to describe that requirement is incorrect.

Then would something to the effect of:

Unless either an implementation or deployment can know a-priori that all responses will always be less than 512B, TCP support MUST be included.

be acceptable???

If not, why not?

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 17 Feb 2010 18:12:54 -0800

>Unless either an implementation or deployment can know a-priori that all responses will always be less than 512B, TCP support MUST be included.

Because it is confusing. I think Matthew is the only WG member so far making the request; so far, others have been disagreeing with him. A typical reader of the document could not figure out how "an implementation or deployment can know a-priori...".

--Paul Hoffman, Director
--VPN Consortium

---

From: David Conrad <[email-masked]>
Date: Wed, 17 Feb 2010 19:04:57 -0800

On Feb 17, 2010, at 4:15 PM, Matthew Dempsky wrote:
> are over 512B,

This isn't a particularly useful argument.  It is trivial to come up with scenarios where any particular subset of any protocol can be specified as an input constraint, implying any subset of a protocol would be compliant.  If a TCP implementation can be guaranteed to never receive an RST, would an implementation that doesn't have RST be considered a full TCP implementation?

I don't really get the point of this discussion.  The fact rbldns doesn't support TCP and hence would be considered to support a subset of modern DNS would have zero impact on anyone.  What problem are you trying to solve?

Regards,
-drc

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 17 Feb 2010 21:29:53 -0800

> Unless either an implementation or deployment can know a-priori that all responses will always be less than 512B, TCP support MUST be included.

Yes, wording to that effect is acceptable to me.

There was already similar wording in the -00 and -01 drafts, but it
was removed from -02.  I'd be happy to see it returned as well.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 18 Feb 2010 07:09:53 +0000

> Date: Wed, 17 Feb 2010 21:29:53 -0800
> From: Matthew Dempsky <[email-masked]>
> 
> > Unless either an implementation or deployment can know a-priori that
> > all responses will always be less than 512B, TCP support MUST be
> > included.
> >
> > be acceptable???
> 
> ...

i'd like it to say "be 512B or smaller".  there's nothing wrong with 512B.
so, this is a "<=" not a "<" comparison.

---

From: Tony Finch <[email-masked]>
Date: Thu, 18 Feb 2010 13:52:54 +0000

> record less than about 100 bytes long.  It knows it will never return

rbldns also doesn't implement most of RFC 1034 and 1035. Does that mean
most of the requirements in those documents should be downgraded?

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
GERMAN BIGHT HUMBER: SOUTHWEST 5 TO 7. MODERATE OR ROUGH. SQUALLY SHOWERS.
MODERATE OR GOOD.

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 18 Feb 2010 10:33:50 -0500

I support MUST implement for TCP.

Donald
=============================
 Donald E. Eastlake 3rd
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

On Mon, Feb 15, 2010 at 6:18 PM, Olafur Gudmundsson <[email-masked]> wrote:
> Dear Colleagues,
>
> This message starts a Working Group Last Call for "DNS Transport over TCP -
> Implementation Requirements"
> update RFC1034 and RFC1123. The docoument states in clear modern standards
> language the TCP requirements for implementations.
>
> Please send a message to namedroppers that you have reviewed the document
> and whether you support it.
>
>    Olafur
>
>

---

From: Fernando Gont <[email-masked]>
Date: Thu, 18 Feb 2010 16:03:56 -0300

Nicholas Weaver wrote:

> (Rationall:  Timeout on idle connections should be dynamic in
> practice, so it should be expressed as such. The server should be
> allowed to limit the number of outstanding connections from any
> particular client, although there should be a default minimum limit)

+1

Kind regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Alex Bligh <[email-masked]>
Date: Sat, 20 Feb 2010 11:59:58 +0000

> http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-dns-tcp-requirements/

Technical

> 1.  Introduction

I think this suggests that TCP is currently only used for zone transfers
and oversized transfers. Suggest "is typically used".

> 3. Discussion
> ...
>    Worse still,
>    some devices deliberately refuse to handle DNS packets containing
>    EDNS0 options.

I think you should be clear you are referring to middleboxes here, rather
than simply a client or server which does not support EDNS0, as no
amount of making TCP compulsory will fix ancient deployed clients/servers.

>    This document therefore RECOMMENDS that the application-level idle
>    period should be of the order of TBD seconds.
>
>    Servers MAY allow dormant connections to remain open for longer
>    periods, but for the avoidance of doubt persistent DNS connections
>    should generally be considered to be as much for the server's benefit
>    as for the client's.  Therefore if the server needs to unilaterally
>    close a dormant TCP connection it MUST be free to do so whenever
>    required.

Apart from the missing TBD, there is a subtle rewording going on. The
original said:

      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.

That implies to me me that the server SHOULD wait *at least* a period
of the order of 2 minutes. Waiting 10 or 50 minutes would be fine,
at least as long as the server did not "need" to close the dormant
connection to reclaim resources.

Your first para suggests that the application should close the dormant
connection whether it needs to reclaim resources or not. However, you
go on to modify this with a second paragraph, which says they
MAY keep it open for longer. I understand the last line of the
second paragraph at all; what is the normative value of "MUST be free to"
other than a disguised "MAY"?

What I think you are saying is that there is still no upper bound,
but a well behaved client might choose to leave the connection
open for the benefit of the server as well as the client, but no one
should take umbrage if the server closes it.

I would also suggest that rather than referring to an "application-level
idle period" you actually specify what the server may/should do.

I would try something like this:

	A client MAY close a connection at any time when no further
	response is requested from the server. A client MAY choose to leave
	a dormant connection open either for a set period of time or
	indefinitely; such an action is as much for the benefit of the
	server as the client, as repeated bring up and tear down of
	connections may increase server load. A server MAY unilaterally
	close a connection which has been dormant for at least [5] seconds,
	whether to reduce socket congestion or for other reasons. Nothing
	in this section is intended to alter the meaning of any TCP RFCs.
	For the purpose of this paragraph, a dormant connection is one on
	which no application layer traffic has traversed in either
	direction (i.e. ignoring transport layer keep-alives).

I am against "of the order of seconds". I think it needs a number of
some sort. It is far less problematic to specify a number if it is
clear that this is a minimum idle time, and there is no problem
waiting longer; the current draft is ambiguous in this respect.

Nits:

> 1.  Introduction

"The TCP" seems odd, though perhaps technically correct. Drop "the"?

>    Whilst this document makes no specific recommendations to operators
>    of DNS servers, it should be noted that failure to support TCP (or
>    blocking of DNS over TCP at the network layer) may result in
>    resolution failure and application-level timeouts.

I think the last "and" should be an "or" or an "and/or".

> 4.  Transport Protocol Selection
> ...
> An exception may be made for proprietary stub resolver
> implementations.

Subject to nroff limitations, I think this exception is only an exception
to the third bullet immediately preceding it, so probably should be
appended to that.

> 7.  Security Considerations
> ...
>    The vast majority of TLD authority servers and all but one of the
>    root name servers already support TCP and the author knows of no
>    evidence to suggest that TCP-based DoS attacks against existing DNS
>    infrastructure are commonplace.

Change "already" to "at the time of writing"

-- 
Alex Bligh

---

From: Alex Bligh <[email-masked]>
Date: Sat, 20 Feb 2010 12:04:27 +0000

> 	direction (i.e. ignoring transport layer keep-alives).

"is one which no application-layer traffic has traversed"

And apologies for making it look like I thought Olafur wrote the draft
not Ray.

-- 
Alex Bligh

---

From: William Allen Simpson <[email-masked]>
Date: Mon, 22 Feb 2010 16:36:22 -0500

> document and whether you support it.
The document needs too many edits to go forward.  Section 5 needs to be
more completely specified.

OTOH, I support in particular the statement:

    All DNS implementations MUST support both UDP and TCP transport.