Subject: Re: [dnsext] Editor needed

From: [email-masked]
Date: Tue, 8 Sep 2009 04:50:50 +0000

On Fri, Aug 28, 2009 at 11:29:01PM +0200, [email-masked] wrote:
> >   "DNS Servers MUST support all mandatory standards track transports,
> >    which at the date of publication of this RFC means both UDP and
> >    TCP, though this list may be added to (or subtracted from) in the
> >    future."
> > 
> > then let's say that, else it is no more clear than it was before.
> 
> TCP support is NOT currently mandatory.
> 
> See '6.1.3.2 of RFC 1123:
> 
>   "DNS resolvers and recursive servers MUST support UDP, and SHOULD 
> support TCP"
> 
> We had significant discussion with the IESG when RFC 5625 was in last call 
> over this question. 
> 
> Ultimately 5625 says "MUST support TCP" for proxies, on the basis that if 
> your client supports TCP, and the recursor supports TCP, it's damned rude 
> of the middle-box sat in the path to sit their refusing to talk to either.
> 
> Ray

	and what is said about authoriatiative servers?
	or did the august IESG folks forget about them?

--bill

---

From: Mark Andrews <[email-masked]>
Date: Tue, 08 Sep 2009 15:41:39 +1000

> 	or did the august IESG folks forget about them?

Bill stop trolling.

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

---

From: David Ulevitch <[email-masked]>
Date: Thu, 10 Sep 2009 23:04:28 -0700

On 8/28/09 7:36 AM, Paul Hoffman wrote:
> At 1:40 PM +0100 8/28/09, George Barwood wrote:
>> Actually I think Andrews suggestion is too strong.
>>
>> I think TCP should be mandatory only for authorities that generate
>> responses in excess of 512 bytes.
>
> Does this make sense from an operational standpoint? That is, assume
> that I am an authority who today doesn't emit responses in excess of
> 512 bytes, and I set up a system that will *only* do UDP, and a later
> improvement to DNS (like DNSSEC, but there could be others) would
> cause me to emit responses that are now longer. I will then have a
> broken system. I should now update the system to also, but I don't
> actually have to (the problems are for other people, not me), and so
> I now have an operationally broken system that looks OK to me.
 >
> We may be better off telling people that they need to support UDP and
> TCP from the beginning.

There is no connection between this statement and the scenario offered. 
  MUST'ing TCP is unnecessary and will cause more people to continue to 
violate the RFCs as the RFCs diverge further and further away from 
operational realities.

-David

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 16 Sep 2009 07:44:28 -0700

At 11:04 PM -0700 9/10/09, David Ulevitch wrote:
>There is no connection between this statement and the scenario offered.  MUST'ing TCP is unnecessary and will cause more people to continue to violate the RFCs as the RFCs diverge further and further away from operational realities.

This is silly. The purpose of standards is to tell people what they need to do. The fact that some implementations don't do something doesn't mean that we can't fix the standard if we need to.

There is disagreement about whether or not TCP is a MUST here, but it feels like most people who have commented think that it is. We should change the standard to match what the WG feels.

--Paul Hoffman, Director
--VPN Consortium

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 16 Sep 2009 09:37:33 -0700

> There is disagreement about whether or not TCP is a MUST here, but it feels like most people who have commented think that it is. We should change the standard to match what the WG feels.

Looking through this email thread, here's my count of people who have
weighed in on their stance on whether TCP support should be
unilaterally mandatory:

  For: Bill Manning, Mark Andrews, Andrew Sullivan(?), Paul Hoffman(?)

  Against: Dean Anderson(?), George Barwood, Paul Vixie, Ray Bellis,
David Ulevitch, myself.

  Unclear: Alex Bligh, Florian Weimer

---

From: David Conrad <[email-masked]>
Date: Wed, 16 Sep 2009 10:10:55 -0700

On Sep 16, 2009, at 9:37 AM, Matthew Dempsky wrote:
>> There is disagreement about whether or not TCP is a MUST here, but  
>> it feels like most people who have commented think that it is. We  
>> should change the standard to match what the WG feels.
>

Not sure what 'unilaterally' means in this context, but I believe TCP  
support should be mandatory.

Regards,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Wed, 16 Sep 2009 17:26:52 +0000

> From: David Conrad <[email-masked]>
> Date: Wed, 16 Sep 2009 10:10:55 -0700
> 

several of us think TCP support should be coupled to a server's ability to
generate UDP replies with the TC bit turned on.  in the absence of any TC=1
responses on UDP, i think that TCP should be optional.  in the presence of
any TC=1 responses on UDP, i think that TCP should be mandatory.

note that if we end up with an improved semistateless TCP, i'll say that it
ought to be mandatory and that it ought to be the first transport tried.  i
am answering the current TCP question using only the current TCP technology.

david, in that context and on that spectrum, where do you sit?

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 16 Sep 2009 10:29:34 -0700

> support should be mandatory.

As opposed to TCP should only be mandatory for servers that send UDP
responses with the TC flag set.

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 16 Sep 2009 10:41:49 -0700

On Wed, Sep 16, 2009 at 10:36 AM, Nicholas Weaver
<[email-masked]> wrote:
> The problems have generally been solved for all other sever communities, and
> even if they do seem to be a problem, I see methods where a
> quasi-deterministic authority (deterministically based on seed and 4-tuple,
> but looks random to everyone else) with a user-level TCP stack doesn't need
> to save the unacknowledged response, only the unacknowledged query, and can,
> if the response will fit in a packet, have a single unacknowledged query
> with NO state (by only ACK'ing the query in the response packet).

I agree that this method should be a theoretically possible solution,
and I think it would be cool to see someone implement it, but as a
matter of principle, I'd like to see at least a functioning
proof-of-concept implementation before the idea is used to justify
standards body action.

---

From: Alex Bligh <[email-masked]>
Date: Wed, 16 Sep 2009 18:50:51 +0100

>   Unclear: Alex Bligh, Florian Weimer

What I've posted to the list so far was merely a statement that
Bill's draft did not, in my view, achieve the purported aim, i.e.
making TCP mandatory (which I think is what you are calling
unilaterally mandatory).

My view, for what it is worth, is that if the server is ever going
to produce a response > 512 bytes (irrespective of EDNS support),
TCP support should be mandatory (IE it can't rely on clients
supporting EDNS to get out of it). I think it should also
be mandatory for any server supporting DNSSEC; given that it
is difficult to imagine a useful DNSSEC server where no responses
would ever be >512 bytes, the benefit of the client being permitted
to rely on TCP support outweighs the loss of some peculiar edge
cases.

As a random data point, some time back in 1999, I was pressed
to produce a DNS server which could cope with a constantly
changing zone file and several hundred thousand domains (with
mail and web hosting). Short of time, we merely hacked it
up to return a quickly constructed UDP packet with an A record
for www.<querieddomain> and an MX for <querieddomain> whatever
was sent to it (the A and MX being the same for every domain)
as no queries should have reached the server bar those for domains
on it. Naughty I know, but it worked. Even in back then,
we had a noticeable number of complaints about not supporting
TCP queries, which surprised me.

-- 
Alex Bligh

---

From: David Conrad <[email-masked]>
Date: Wed, 16 Sep 2009 11:25:45 -0700

On Sep 16, 2009, at 10:50 AM, Alex Bligh wrote:
> As a random data point, some time back in 1999, I was pressed to  
> produce a DNS server which could cope with a constantly changing  
> zone file and several hundred thousand domains (with mail and web  
> hosting).
...
> Even in back then, we had a noticeable number of complaints about  
> not supporting TCP queries, which surprised me.

If you want to talk about offenses against man and nature, back in the  
mid-80s, there was once a caching resolver that did not support UDP  
(the network stack for the system (a Univac 1100-series mainframe)  
apparently made datagram support quite challenging).  No idea when  
that server was put out of its misery.

Regards,
-drc

---

From: David Conrad <[email-masked]>
Date: Wed, 16 Sep 2009 11:29:59 -0700

> any TC=1 responses on UDP, i think that TCP should be mandatory.

Given I believe that all servers need to be able to deal with large  
responses without fragmentation, the caveat here brings no value and  
instead, leads folks to come up with servers that can't deal with the  
Internet as it continues to evolve and call those servers "standards  
compliant".

> david, in that context and on that spectrum, where do you sit?

Same place.  Support of TCP should be mandatory.

Regards,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Wed, 16 Sep 2009 18:37:58 +0000

> Date: Wed, 16 Sep 2009 11:29:59 -0700
> 

there's a Very important corner case here, which is embedded servers
tightly coupled with distributed applications, where the entire system
design calls for nontruncated responses.  the question before the WG is
whether such a server should be allowed to exclude TCP altogether on
the basis that it will never truncate its UDP output.  i think, "yes."

> Same place.  Support of TCP should be mandatory.

even in the above circumstance?  you seem to be allowing for TCP-first
client behaviour, which surprises me.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 16 Sep 2009 11:45:33 -0700

>any TC=1 responses on UDP, i think that TCP should be mandatory.

That sounds reasonable. Under this logic, TCP is mandatory to implement and support, but not mandatory to use except in the case given. Note that DNS implementation cannot predict whether or not a TC=1 response will be received, so implementing TCP is mandatory. Similarly, a middlebox cannot predict whether or not a TC=1 response will be received, so implementing TCP is mandatory.

--Paul Hoffman, Director
--VPN Consortium

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 16 Sep 2009 11:48:23 -0700

> any TC=1 responses on UDP, i think that TCP should be mandatory.

Is there really any DNS authority codebase where you can make the  
statement "all responses will ALWAYS fit into 512B"?

Because thats what this statement implies is necessary for not  
supporting TCP.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 16 Sep 2009 18:54:48 +0000

> From: Nicholas Weaver <[email-masked]>
> Date: Wed, 16 Sep 2009 11:48:23 -0700
> 

yes.

> Because thats what this statement implies is necessary for not supporting
> TCP.

right.

---

From: Wes Hardaker <[email-masked]>
Date: Wed, 16 Sep 2009 12:07:10 -0700

>>>>> On Wed, 16 Sep 2009 09:37:33 -0700, Matthew Dempsky <[email-masked]> said:

MD> For: Bill Manning, Mark Andrews, Andrew Sullivan(?), Paul Hoffman(?)

I think you can add my name to the list.  The problem is that your list
doesn't break down easily, as has been discussed.

When it comes down to it, large packets > 512 bytes simply are the way
of the future.  Both because of DNSSEC as well as IPv6 explosions, etc.
Would I care if some DNS server out there couldn't handle TCP or packets
above a certain size but it wasn't serving data above a certain size?
Probably not if that could be assured.  But in the end this data size
explosion isn't going to stop, and lets be honest: implementing TCP in a
DNS stack is not that expensive (it's in the noise compared to
everything else).

Right now, the only alternatives to supporting much of that is either
EDNS0 or TCP.  Eventually SCTP (which I agree might be a better
transport for DNS) may be a better alternative but I doubt it is now
though I understand it's deployment is catching up.

The important thing is that putting a implementation requirement doesn't
mean that operators have to use it, that manuals have to say "you should
use it" or even that it has to default to on (unless that wording is
added as well).  The important thing is that you have to give the
operators the tools they need to use the protocol, and I do believe
we're heading for a point where the impact of TCP is low and the need
for it is higher.  Thus, I think requiring implementations to support it
is simply the correct thing to do.

-- 
Wes Hardaker
Cobham Analytic Solutions

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 16 Sep 2009 12:09:53 -0700

On Wed, Sep 16, 2009 at 11:45 AM, Paul Hoffman <[email-masked]> wrote:
> That sounds reasonable. Under this logic, TCP is mandatory to implement and support, but not mandatory to use except in the case given.

My only concern with this is that I think it's overstepping the
jurisdiction of a protocol standard to dictate what software is
required to implement and support if it's not required to have it
enabled.  Supporting TCP but having it disabled is externally
indistinguishable from not supporting TCP, so it seems silly to allow
one and forbid the other.

> Note that DNS implementation cannot predict whether or not a TC=1 response will be received, so implementing TCP is mandatory. Similarly, a middlebox cannot predict whether or not a TC=1 response will be received, so implementing TCP is mandatory.

I mostly agree with this.  On the general Internet, there's certainly
the possibility of large responses requiring TC=1.

If a client somehow knew that a response would not set TC=1, then I
don't see a reason to support TCP.  However, as there's no RFC
standardizing a way for clients to be sure of this, I don't see a
reason to worry about it.

---

From: Jim Reid <[email-masked]>
Date: Wed, 16 Sep 2009 20:11:44 +0100

> statement "all responses will ALWAYS fit into 512B"?

IIUC djbdns is designed that way. It doesn't support TCP. Or EDNS. The  
author's view is that zone owners have to organise their DNS data to  
ensure it can never exceed a 512 byte response.

---

From: [email-masked]
Date: Wed, 16 Sep 2009 20:12:44 +0100

>   Against: Dean Anderson(?), George Barwood, Paul Vixie, Ray Bellis,

I don't recall making that assertion.

I _did_ say that the RFCs don't currently mandate it.

Ray

---

From: Douglas Otis <[email-masked]>
Date: Wed, 16 Sep 2009 12:15:31 -0700

On 9/16/09 11:37 AM, Paul Vixie wrote:
>> From: David Conrad<[email-masked]>

Insisting upon TCP support within typical SOHO equipment is unrealistic, 
as demonstrated in the market already.  On the other hand, SCTP with 
unreliable unordered delivery demands fewer resources to support flows 
altering PMTUs or those causing packet loss.  Should these environments 
also benefit from DNSSEC?

> client behaviour, which surprises me.

This should be SCTP first.

-Doug

---

From: Mans Nilsson <[email-masked]>
Date: Wed, 16 Sep 2009 21:32:08 +0200

> > There is disagreement about whether or not TCP is a MUST here, but it feels like most people who have commented think that it is. We should change the standard to match what the WG feels.

I'm with drc here. TCP will be needed because sometimes large UDP
packets either aren't enough or are frowned upon by
more-broken-than-most devices. I think and teach that TCP is a MUST,
but tell my students that that MUST is a matter of operationally based
opinion.  I'd like to have that opinion replaced by a solid MUST.

-- 
Måns

---

From: [email-masked]
Date: Wed, 16 Sep 2009 20:33:59 +0100

> as demonstrated in the market already.

Not at all.

Some manufacturers are now supporting TCP (via use of dnsmasq etc in their 
firmware).  Proxying DNS over TCP is far simpler than the content blocking 
features that many SOHO routers have.

The number of concurrent TCP sessions is also unlikely to cause any 
significant problems.  That seems to be the biggest argument against 
mandatory TCP support on authoritative servers.

SCTP support on the other hand, is probably a _very_ long way away.

Ray

---

From: "George Barwood" <[email-masked]>
Date: Wed, 16 Sep 2009 20:36:56 +0100

----- Original Message ----- 
From: "Matthew Dempsky" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, September 16, 2009 5:37 PM
Subject: Re: [dnsext] Editor needed

>  Against: Dean Anderson(?), George Barwood, Paul Vixie, Ray Bellis,

Just to clarify, I think server TCP support should be mandatory 
(a) If responses > 512 bytes are possible.
(b) Also for secure zones ( just to cover the possibility of DNSSEC squeaking under 512 bytes somehow ).
(c) For all non-authoritative cases ( so caches and proxies MUST support TCP, regardless ).

So the only exception is authoritative servers with no secure zones that never set TC. 
I don't see any need to force those servers to be upgraded.

There is also the client side. I think DNSSEC clients MUST support TCP,
that is they must be able to fall back to TCP after getting a truncated response.

Non-DNSSEC clients need not support TCP.

Finally, the rules for UDP support:
(1) Servers MUST support UDP ( but may truncate responses causing TCP fallback ).
(2) Stub clients need not support UDP ( but may experience problems if they do not, for historical reasons ).
(3) Other clients must support UDP.

George

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 16 Sep 2009 12:40:56 -0700

On Wed, Sep 16, 2009 at 12:11 PM, Jim Reid <[email-masked]> wrote:
> IIUC djbdns is designed that way. It doesn't support TCP.

djbdns supports TCP, it's just not enabled by default for authoritative servers.

---

From: Andreas Gustafsson <[email-masked]>
Date: Wed, 16 Sep 2009 22:49:40 +0300

Matthew Dempsky wrote:
> Looking through this email thread, here's my count of people who
> have weighed in on their stance on whether TCP support should be
> unilaterally mandatory

I think TCP support should be mandatory, or at the very least strongly
encouraged even in the case where no TC=1 responses are being sent,
for the reason that careful use of TCP can be quite useful as a part
of a resolver's anti-spoofing strategy, and is being used for that
purpose in production resolvers.

To those who say that TCP based spoofing defenses can't work because
TCP support in authoritative servers is not universal, or because it
is possible to DoS TCP, I will note that the goal of such defense
mechanisms is not to make the resolution succeed, but to make the
spoofing attack fail.  In this respect, they are no different from
DNSSEC.  If a resolver detects an attempted spoofing attack, switches
to TCP, and TCP fails, it has still succeeded in thwarting the attack.
But when TCP does work, it can do even better and provide a correct
response instead of just a SERVFAIL.
-- 
Andreas Gustafsson, [email-masked]

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 16 Sep 2009 16:11:18 -0400

Count me for making TCP mandatory to implement.
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

---

From: Jim Reid <[email-masked]>
Date: Wed, 16 Sep 2009 21:21:57 +0100

On 16 Sep 2009, at 20:36, George Barwood wrote:

> ....
> ....

This statement contradicts (a) and (c). What if an unsigned response  
doesn't fit into 512 bytes? The rough consensus here seems to be that  
there are corner cases with fragmentation that mean EDNS can't always  
be relied upon for these responses. So that pretty much leaves TCP as  
the only tool left in the box.

BTW, since a server (implementation) has no a priori knowledge of the  
data it will serve, the "if" in (a) above is redundant. Responses  
larger than 512 bytes are definitely possible, even without DNSSEC.  
All it takes is 500 bytes or so of RDATA in a TXT record.

IMO, let's make TCP a MUST and move on. This isn't going to break  
anything and may actually do some good. Of course, that change will  
mean some chunk of the installed base will violate the new spec. But  
those implementations will be doomed if/when DNS responses exceed 512  
bytes anyway. They're already failing to handle truncated responses  
properly, so where's the actual operational problem? Why worry about  
preserving backwards compatibility for them when they have no hope of  
doing something sensible with a truncated response?

I am of course worried about the impact on busy name servers of lots  
of short-lived TCP connections, particularly in their kernel network  
stacks. However that's a different problem from making TCP support for  
DNS clients and servers mandatory. One way to minimise that could be  
for the draft to say something like "try EDNS first, then fall back to  
classic UDP/512 and if that fails, then try TCP".

---

From: Florian Weimer <[email-masked]>
Date: Wed, 16 Sep 2009 20:35:03 +0000

>   Unclear: Alex Bligh, Florian Weimer

I think that TCP support already is mandatory.  But given that this is
debatable, I support making it mandatory (hopefully unambiguously this
time).

---

From: Florian Weimer <[email-masked]>
Date: Wed, 16 Sep 2009 20:44:34 +0000

> the basis that it will never truncate its UDP output.  i think, "yes."

Even if the server implements EDNS0?  A TCP-less server might not be
able to implement certain EDNS0 options due to size constraints.  If
those servers are taken seriously, there's yet another obstacle to
protocol evolution.

---

From: David Conrad <[email-masked]>
Date: Wed, 16 Sep 2009 13:54:03 -0700

> the basis that it will never truncate its UDP output.  i think, "yes."

I guess I wouldn't see this as a full DNS server, but rather a subset  
of the DNS tailored for a specific use.  Pragmatically speaking, folks  
who do stuff like this will do whatever makes business sense.   
However, it doesn't make sense to me that such an implementation can  
be called standards compliant because it wouldn't be able to support  
new 'stupid DNS tricks'.

> you seem to be allowing for TCP-first client behaviour, which  
> surprises me.

Not a goal.  I'm trying to improve the future-proofing of the DNS  
protocol.

Regards,
-drc

---

From: Jim Reid <[email-masked]>
Date: Wed, 16 Sep 2009 22:44:10 +0100

On 16 Sep 2009, at 22:15, George Barwood wrote:

> But many stub clients only need to fetch a single A/AAAA record.

That might (or might not) be true. But it's irrelevant. The client  
making this A or AAAA query *cannot* guarantee the response will be  
less than 512 bytes. If the client or application makes that  
assumption, it is broken. The protocol makes no promises that  
responses must always fit in a 512 byte UDP payload.

> They do not need to implement TCP.

Nonsense! See above.

> Think of a simple device with a single UDP application.
> It does not need DNS/TCP, or indeed TCP at all.

Nope. Even in this hypothetical (and IMO contrived) scenario, the  
client cannot assume the query will never, ever get a response that  
exceeds 512 bytes. So it'll need some way of handling truncated  
responses. EDNS might be enough, but that can't be assumed either.

Your reasoning here is like designing a ship without lifeboats because  
it'll never sink.

---

From: [email-masked]
Date: Wed, 16 Sep 2009 21:43:47 +0000

> that server was put out of its misery.

	I was a happy boy back then.
	IBM supported discontigious subnet masks too...

--bill

---

From: [email-masked]
Date: Wed, 16 Sep 2009 21:47:50 +0000

>   Unclear: Alex Bligh, Florian Weimer

	let me be clear.  I beleive there are multiple defined transports
	for DNS now and more will come.  the text of my draft is simply to
	indicate that DNS should not be considered to be treated uniformly
	in the event of divergent transports.  An operator may favor one 
	transport option over another.

	It was not and will not be in the scope of my current draft to 
	define mandatory to implement transports for DNS.

--bill

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 16 Sep 2009 15:04:03 -0700

>        define mandatory to implement transports for DNS.

That's not how I understand "all transport options MUST/need to be
supported" from your draft.  Would you mind clarifying if you don't
think your statements are at odds with one another?

---

From: Paul Vixie <[email-masked]>
Date: Wed, 16 Sep 2009 23:49:14 +0000

this has been going on way longer than i can hold my breath.  enough folks
have chimed in saying that tcp should be required for full dns compliance,
that i hereby withdraw my opposition to it.  if somebody wrote a draft that
said udp and tcp are both required, edns is required, clients should try udp
first, clients are required to retry with edns on udp truncation, and to
retry with tcp on edns failure/unavailability/truncation, i'd support it.

but then there's this:

> From: "George Barwood" <[email-masked]>
> Date: Thu, 17 Sep 2009 00:29:20 +0100
> 
> Still, a stub resolver always has the option of just using the truncated
> response : it doesn't need to retry over TCP if it just wants the first A
> record.

there is no standard or published API in unix, dos, apple, or any embedded
system with which i'm familiar where the result of gethostbyname() (or any
equivilent thereof) can be "here's an address but there was truncation" and
the input to a subsequent gethostbyname() (or any equivilent thereof) can
be "listen i really want all the addresses so if you get truncation i need
you to try harder."

truncation occuring between full resolvers and (forwarders or authorities)
will cause retry, since a truncated result cannot be cached or forwarded.

truncation occuring between stub resolvers and (full resolvers or proxies)
will cause retry, since a truncated result cannot be given to an application.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Sep 2009 11:10:26 +1000

In message <[email-masked]>, Jim Reid writes:
> DNS clients and servers mandatory.

And is already covered by requiring QUERYs to be tried over UDP
first.

> One way to minimise that could be  

The correct priority should be get the required answer through
minimising the use of TCP.   All these people scared of TCP are
putting the cart before the horse.

Mark

---

From: "George Barwood" <[email-masked]>
Date: Thu, 17 Sep 2009 08:08:28 +0100

----- Original Message ----- 
From: "Paul Vixie" <[email-masked]>
To: <[email-masked]>
Sent: Thursday, September 17, 2009 12:49 AM
Subject: Re: [dnsext] Re: making TCP a MUST 

> be "listen i really want all the addresses so if you get truncation i need

Hold on.. gethostbyname actually returns a single address record doesn't it?
So the semantics is "get me an address".

Even if it didn't, or if the intended semantics is round-robin for multiple calls,
the practical reality is that you have no guaruntee of obtaining all the addresses,
since almost all proxies silently clear the TC bit. This doesn't matter in practice
for A records, since 20+ is plenty for any reasonable situation.

So non-validating stub resolvers that only support gethostbyname (and are
happy with the very mild consequences) need not implement TCP. 
I don't see any reason for the standard to forbid that.

---

From: Jim Reid <[email-masked]>
Date: Thu, 17 Sep 2009 08:56:32 +0100

On 17 Sep 2009, at 08:08, George Barwood wrote:

> gethostbyname actually returns a single address record doesn't it?

No. It returns a hostent struct which contains a list of addresses.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 17 Sep 2009 10:13:58 +0200

On Thu, Sep 17, 2009 at 08:08:28AM +0100,
 George Barwood <[email-masked]> wrote 

> Hold on.. gethostbyname actually returns a single address record

I suggest to read the man page before posting on namedroppers.

The  gethostbyname()  function  returns  a structure of type hostent
for the given host name. 

...

       The hostent structure is defined in <netdb.h> as follows:

           struct hostent {
               char  *h_name;            /* official name of host */
               char **h_aliases;         /* alias list */
               int    h_addrtype;        /* host address type */
               int    h_length;          /* length of address */
               char **h_addr_list;       /* list of addresses */
           }

---

From: Alex Bligh <[email-masked]>
Date: Thu, 17 Sep 2009 09:12:52 +0100

--On 17 September 2009 08:08:28 +0100 George Barwood 
<[email-masked]> wrote:

> since almost all proxies silently clear the TC bit

Really?

-- 
Alex Bligh

---

From: Jim Reid <[email-masked]>
Date: Thu, 17 Sep 2009 09:24:31 +0100

On 17 Sep 2009, at 00:49, Paul Vixie wrote:

> equivilent thereof) can be "here's an address but there was  
> truncation" and the input to a subsequent gethostbyname() (or any  
> equivilent thereof) can be "listen i really want all the addresses  
> so if you get truncation i need you to try harder."

Well, I suppose the WG could fix this -- assuming it did APIs -- once   
a new standard for resolver behaviour was defined.

FYI provision for a truncation behaviour control hook is already in  
libresolv for res_mkquery() and its friends.

      RES_IGNTC      Unused currently (ignore truncation errors, i.e.,  
don't
                     retry with TCP).

BTW this API has hooks for TCP and EDNS0 queries.

---

From: [email-masked]
Date: Thu, 17 Sep 2009 09:29:51 +0100

> > since almost all proxies silently clear the TC bit

Not quite.

I seem to recall seeing one proxy which actually did clear a TC bit that 
had been correctly set by the upstream recursor.

Many SOHO proxies _fail to set_ the TC bit when they truncate a packet. 
That's not the same thing.

Ray

---

From: "George Barwood" <[email-masked]>
Date: Thu, 17 Sep 2009 09:46:09 +0100

----- Original Message ----- 
From: "Jim Reid" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, September 17, 2009 8:56 AM
Subject: gethostbyname()

> No. It returns a hostent struct which contains a list of addresses.

Sorry, yes, I was completely wrong there.

I now realise that some proxies silently clear the TC bit,
which has some logic given they don't support TCP,
and others don't, which results in failure when TCP
fallback fails.

So exceeding the 512 byte limit with say 40 A records will
in practice cause severe interoperability problems, but I don't
know the percentages.

George

---

From: Alex Bligh <[email-masked]>
Date: Thu, 17 Sep 2009 09:51:11 +0100

> to rely on TCP support outweighs the loss of some peculiar edge

I should perhaps clarify this. I think TCP should be mandatory
to at least the extent above. I would not object to it being mandatory
for all servers, and if that's what the w/g wants to do, I would
support it.

-- 
Alex Bligh

---

From: [email-masked]
Date: Thu, 17 Sep 2009 08:57:40 +0000

> BTW this API has hooks for TCP and EDNS0 queries.

	So some folk have a particular usage pattern in mind before
	changing transport protocols.

	I'm interested in how many folks really believe that TCP
	should only be tried -after- UDP/TC=1 occurs.

	I'm pretty sure that for some DNS transactions, TCP is chosen
	first.

	SO.. what will the "search" order look like when there are
	more than just UDP and TCP defined as DNS transports?

--bill

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 17 Sep 2009 11:13:32 +0200

On Wed, Sep 16, 2009 at 08:44:34PM +0000,
 Florian Weimer <[email-masked]> wrote 
 a message of 12 lines which said:

> Even if the server implements EDNS0? 

I have a lot of sympathy for the idea "Every DNS server MUST be able
to serve > 512 bytes data, either with TCP or with EDNS0" but I have
the feeling that, in the real world, servers without TCP do not have
EDNS0 either.

>From the field: .FR requires a successful technical test before actual
DNS delegation and TCP is mandatory. When servers fail this test and
people complain, tests show that they almost always have no possible
alternative (such as EDNS0).

---

From: Jim Reid <[email-masked]>
Date: Thu, 17 Sep 2009 10:24:49 +0100

> 	more than just UDP and TCP defined as DNS transports?

IMO, the time for that discussion is when a viable alternative to UDP  
and TCP emerges. It's not clear we're at that point.

---

From: [email-masked]
Date: Thu, 17 Sep 2009 10:40:29 +0000

> and TCP emerges. It's not clear we're at that point.

	ok... lets just work with the subset of two, UDP and TCP.

	when, if ever, is it ok to try TCP first?

	under what condtions is it ok to flip transports (UDP->TCP, TCP->UDP)

	is truncation the only requirement to consider changing transports?

--bill

---

From: Jim Reid <[email-masked]>
Date: Thu, 17 Sep 2009 11:56:20 +0100

> when, if ever, is it ok to try TCP first?

(a) when the application knows in advance that truncated responses or  
EDNS fragmentation is highly likely or certain
(b) when DNS over TCP is considered "safer": ie less prone to spoofing
(c) when an application knows it's going to make lots of queries and a  
permanent connection to some server is a better choice. IIRC netstat  
does this because it tends to do loads of reverse lookups.

> under what condtions is it ok to flip transports (UDP->TCP, TCP->UDP)

Whenever the circumstances change and make the other transport the  
better choice: for instance when route flapping for an anycast address  
starts or stops.

> is truncation the only requirement to consider changing transports?

Nope.

---

From: Florian Weimer <[email-masked]>
Date: Thu, 17 Sep 2009 13:26:43 +0000

> the feeling that, in the real world, servers without TCP do not have

This is fine because it's not an obstacle to EDNS0-based protocol
evolution.

If servers support EDNS0 and have relatively small packet size limits
because they do not support TCP (or EDNS0 with large buffers), adding
additional EDNS0 options could mean that they could not implement
these extensions.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 18 Sep 2009 07:12:53 +1000

> 	when, if ever, is it ok to try TCP first?

I wouldn't even try a UPDATE that was bigger that 512 over anything
other than TCP.  I would recommend that all UPDATEs go over TCP
especially if you are using IP as the authenticator for allowing
the update.

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 16 Sep 2009 10:36:25 -0700

Add me in the "TCP MUST" category.

The fear of TCP is, IMO, unjustified.

The problems have generally been solved for all other sever  
communities, and even if they do seem to be a problem, I see methods  
where a quasi-deterministic authority (deterministically based on seed  
and 4-tuple, but looks random to everyone else) with a user-level TCP  
stack doesn't need to save the unacknowledged response, only the  
unacknowledged query, and can, if the response will fit in a packet,  
have a single unacknowledged query with NO state (by only ACK'ing the  
query in the response packet).

---

From: [email-masked]
Date: Tue, 22 Sep 2009 15:50:10 +0100

Now might be a good time for Matthew to summarise the responses again...

Ray

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 22 Sep 2009 15:04:44 -0700

On Tue, Aug 25, 2009 at 3:47 PM, Andrew Sullivan <[email-masked]> wrote:
> One of the milestones on the Charter that we've been waiting to send
> to our AD is a document that clarifies that TCP transport is mandatory
> for DNS.

I think section 6.1.3.2 of RFC 1123 is quite clear that UDP support is
required whereas TCP support is only recommended.  As such, I think
it's inappropriate to publish a document to "clarify" that TCP support
is required, when it is unambiguously not.

I'm not strongly opposed to requiring support for TCP (or whatever
else) in new DNS protocol extensions, but those extensions need to be
designed to be interoperable with implementations conforming to
existing standards.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Sep 2009 10:04:39 +1000

> designed to be interoperable with implementations conforming to

Did you bother to read past the first paragraph of section 6.1.3.2
of RFC 1123?

Do you understand that if you fail to follow a SHOULD then you are
in the wrong if it causes operational problems not those following
or depending on the SHOULD?

You do understand that the DNS is designed to fallback to TCP and
that this is NORMAL.

I can think of examples, in closed highly controlled envirionments,
where not following the SHOULD would be appropriate for a vendor.
The Internet however is not such a environment.

I can't see a way a vendor of products designed to be used on the
Internet could in good concience ship a product that fails to follow
the SHOULD in question.  That a vendor sell/shipping products
intended to be used on the Internet could in good concience say
"none of our customers will ever need to send or receive answers
bigger than 512 bytes".  A vendor doesn't have access to that
knowledge.  Operators might but vendors don't.

Clearly there are vendors which don't care about their customer
because they are shipping such products which they have been clearly
advised not to ship.

I actually think RFC 1123 got it wrong because there were already
records that could be larger than 512 bytes (TXT) so the entire
rational which allowed the SHOULD rather than MUST was invalid.

Mark

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 22 Sep 2009 17:09:51 -0700

> or depending on the SHOULD?

And what would those operational problems be?

If I don't allow AXFR transfers and don't send truncated responses to
queries, what in RFC 1123 permits a client to send a TCP query to my
server?

> You do understand that the DNS is designed to fallback to TCP and

It's designed to fallback to TCP after a UDP query results in a
truncated response or to support AXFR.

> knowledge.  Operators might but vendors don't.

Protocols don't distinguish between vendors and operators.  Protocols
document how conforming implementations communicate.  If it's okay for
an operator to run a server without TCP support, it's okay for an
implementor  to ship an implementation without TCP support.

It's the operator's responsibility to ensure his server software fits
his requirements.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Sep 2009 12:47:52 +1000

In message <[email-masked]>, Matthe

> It's the operator's responsibility to ensure his server software fits

So you expect Mums and Dads to know that they need to workout whether
the recursive servers built into SOHO routers (yes they are recursive
servers) support TCP/DNS or not.  What a ludicrous position to take.

Seat belts were not a MUST when car were first built.  In fact they
hadn't even been designed.  They are now.  This is a similar change.
Get over it.

Mark

---

From: [email-masked]
Date: Wed, 23 Sep 2009 03:06:02 +0000

> designed to be interoperable with implementations conforming to

	hum...  did you read the whole thing?

first off, the use of the terms MUST, SHOULD, MAY pre-date the current usage.

this is what RFC 1123 sez:

         *    "MUST"

              This word or the adjective "REQUIRED" means that the item
              is an absolute requirement of the specification.

         *    "SHOULD"

              This word or the adjective "RECOMMENDED" means that there
              may exist valid reasons in particular circumstances to
              ignore this item, but the full implications should be
              understood and the case carefully weighed before choosing
              a different course.

---
                 However, it is also clear that some new DNS record
                 types defined in the future will contain information
                 exceeding the 512 byte limit that applies to UDP, and
                 hence will require TCP.  Thus, resolvers and name
                 servers should implement TCP services as a backup to
                 UDP today, with the knowledge that they will require
                 the TCP service in the future.

            By private agreement, name servers and resolvers MAY arrange
            to use TCP for all traffic between themselves.  TCP MUST be
            used for zone transfers.

            A DNS server MUST have sufficient internal concurrency that
            it can continue to process UDP queries while awaiting a
            response or performing a zone transfer on an open TCP
            connection [DNS:2].
[page 76]

--bill

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 22 Sep 2009 20:10:14 -0700

> servers) support TCP/DNS or not.  What a ludicrous position to take.

So you expect Mums and Dads to care what the IETF says their home
thingamajig should do?

No, they're going to buy whatever the nice kid at the local
electronics store suggests they buy.  Or they're going to buy whatever
has high reviews on Amazon.  Those aren't going to change if the IETF
suddenly changes its mind to state that TCP support is now a MUST.

I'm not saying common implementations shouldn't support TCP.  They
should.  That's why RFC 1123 says SHOULD.  I'm saying not all
implementations need to.  That's why it shouldn't be a MUST.

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 22 Sep 2009 20:15:23 -0700

>        hum...  did you read the whole thing?

I did.  Authoritative name servers that don't offer zone transfers,
don't send truncated responses over UDP, and don't engage in private
agreements with resolvers aren't required to answer queries over TCP.

If you understand 6.1.3.2 differently, please elaborate.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Sep 2009 13:58:40 +1000

In message <[email-masked]>, Matthe
w Dempsky writes:
> > servers) support TCP/DNS or not. =A0What a ludicrous position to take.
> 

Then why arn't all common implementations supporting TCP?   Either
we have not been clear enough or vendors are playing protcol lawyer
and using the SHOULD as a way to weasle out of what they should be
doing (no insult to weasles, they are crafty).  There is no real
harm in making TCP a MUST when you already support TCP.  There is
real harm in continuing to keep TCP a SHOULD as vendors and operators
do play protcol lawyer and ship/configure servers to not support
TCP when by any sensible reading of RFC 1123 that should be supporting
TCP.

We have customers that are scared to add records to RRsets because
answers will now go over 512 bytes and they may not be accepted
everywhere.  This is a direct consequence of DNS/TCP being a SHOULD
not a MUST.  Making TCP a MUST won't fix this straight away but
will in time.

Mark

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 22 Sep 2009 21:25:44 -0700

> not a MUST.  Making TCP a MUST won't fix this straight away but

If you just want to require that clients that receive truncated
responses retry their queries over TCP and that servers that send
truncated responses answer queries over TCP, I'm not strongly opposed
to that.  I'd be concerned that you will still need to worry for some
time about the deployed software base that doesn't already support
this, but if you're going to take on solving that problem, then have
at it.

However, I still think authoritative servers that don't support zone
transfers, don't send truncated responses, and don't engage in private
agreements with resolvers should not be required to respond to queries
over TCP.

---

From: David Conrad <[email-masked]>
Date: Tue, 22 Sep 2009 22:02:38 -0700

Matthew,

> agreements with resolvers should not be required to respond to queries

How do you guarantee a server isn't going to send a truncated response  
without breaking the protocol or placing a non-standard limitation on  
the amount of data that can be in an RRset (and refuse to correctly  
implement ANY queries)?

Regards,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Wed, 23 Sep 2009 05:27:10 +0000

> Date: Tue, 22 Sep 2009 21:25:44 -0700
> From: Matthew Dempsky <[email-masked]>
> ...

since clients are required to tru UDP first, i have trouble understanding
how a conforming client would ever detect or notice that a server doesn't
support TCP unless that server first truncated a UDP response.

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 22 Sep 2009 22:38:39 -0700

On Tue, Sep 22, 2009 at 10:02 PM, David Conrad <[email-masked]> wrote:
> without breaking the protocol or placing a non-standard limitation on the
> amount of data that can be in an RRset (and refuse to correctly implement
> ANY queries)?

Easy: I don't configure my name server with records that require
sending >512B responses.

For people that don't know how to ensure this, they need to play it
safe and support queries over TCP.  But that doesn't mean everyone
needs to.

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 22 Sep 2009 22:46:57 -0700

> support TCP unless that server first truncated a UDP response.

Agreed.  So why require servers that don't send truncated UDP
responses to respond to queries over TCP?

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Sep 2009 16:19:11 +1000

> Easy: I don't configure my name server with records that require

Then why do you care if TCP is a MUST or not?  Your not going to
get queries over TCP by compliant resolvers.  However by demanding
that TCP remain a SHOULD you leave everyone open to the problems
caused by implementations that don't support it and operators that
incorrectly turn it off.

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 22 Sep 2009 23:25:59 -0700

> caused by implementations that don't support it and operators that

Because then when you later want to propose to further amend the
protocol to allow clients to initiate with TCP queries, and I oppose
it because my server doesn't respond to queries over TCP, you'll argue
that it's non-compliant anyway.

Also, I'm only saying TCP support for authoritative servers that don't
support zone transfers, don't send truncated UDP responses, and don't
establish private agreements with resolvers shouldn't be required.  I
won't make the same fuss if you limit the requirement for TCP support
to servers that send truncated UDP responses.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Sep 2009 16:28:38 +1000

> responses to respond to queries over TCP?

Because people can't rely on TCP being supported when it is needed
as it is now subject to the whim of vendors and implementors that
have demonstrated that they can't be trusted to make rational
decision.

Making TCP a MUST won't hurt those that have all their answer set
fitting in 512 bytes.  Havine TCP as a SHOULD has clearly hurt those
that needed TCP to be supported.

Mark

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 22 Sep 2009 23:34:15 -0700

> that needed TCP to be supported.

So you can say "RFC XXXX requires TCP support, and you're not offering
it, therefore you're non-compliant" or you can say "your name server
is sending truncated responses, and RFC XXXX therefore requires TCP
support, and you're not offering it, therefore you're non-compliant".
What difference does it make?

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Sep 2009 16:50:42 +1000

In message <[email-masked]>, Matthew Dempsky writes:
> > Then why do you care if TCP is a MUST or not? =A0Your not going to
> > get queries over TCP by compliant resolvers. =A0However by demanding

It's already allowed, see RFC 2136.

   2.1 - Transport Issues
                             
   An update transaction may be carried in a UDP datagram, if the
   request fits, or in a TCP connection (at the discretion of the
   requestor).  When TCP is used, the message is in the format described
   in [RFC1035 4.2.2].

> to servers that send truncated UDP responses.

Which just goes to show that you have thought through all the
implications of making a server UDP only as the DNS is now much
more that just queries.

Mark

---

From: Paul Vixie <[email-masked]>
Date: Wed, 23 Sep 2009 06:48:00 +0000

> Date: Tue, 22 Sep 2009 23:25:59 -0700

note that i am in fact going to do the former, but not the latter.  that
is, if we can come up with a lightweight datagram oriented tcp then we
might want to try it first.  if the responder doesn't understand the
"lightweight option" then the initiator would remember this and go back
to UDP first, TCP only as a fallback.

but in no case would i say, if you don't support TCP at all, you're out of
spec.  not supporting TCP at all would just be another way of not
supporting the "lightweight option".

> to servers that send truncated UDP responses.

this sounds to me like the voice of reason.

---

From: Matthew Dempsky <[email-masked]>
Date: Tue, 22 Sep 2009 23:56:01 -0700

> It's already allowed, see RFC 2136.

By "queries", I meant QUERY queries.  My server doesn't accept UPDATE
queries, and clients have no reason to send them to my server, so that
requirement is irrelevant.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Sep 2009 17:06:34 +1000

In message <[email-masked]>, Matthew Dempsky writes:
> > fitting in 512 bytes. Having TCP as a SHOULD has clearly hurt those

If you set TC and don't answer queries over TCP I'll complain today
as you are in the wrong.  I've complained to Microsoft when they
did exactly that.  If you don't support a SHOULD then it is your
reponsabilty to correct problems that arise from not supporting the
SHOULD.

Mark

---

From: "Aki Tuomi" <[email-masked]>
Date: Wed, 23 Sep 2009 10:27:21 +0300

> -----Original Message-----
> To: IETF DNSEXT WG

Sounds like the Microsoft IIS hack, that allowed punter to send data without going thru the cumbersome TCP handshake =)

---
Aki Tuomi
Systems Specialist
TDC Oy

---

From: Mark Andrews <[email-masked]>
Date: Wed, 23 Sep 2009 17:33:56 +1000

> this sounds to me like the voice of reason.
 
But that isn't what RFC 1123 says.  Even if you were to modify RFC
1123 to say that everything other than a authoritative server MUST
support TCP you would still have operational problem because people
get it wrong today and will continue to get it wrong.  To make
serving robust it needs to be a MUST.  There is no harm in making
it a MUST.

Mark

---

From: Alex Bligh <[email-masked]>
Date: Wed, 23 Sep 2009 08:41:41 +0100

Matthew,

> to servers that send truncated UDP responses.

So, in order to fall into the group where (in your view) TCP shouldn't
be a MUST, the server has to:
a) not be recursive (or an upstream authoritative server could send it
   a response that wouldn't fit into 512 bytes)
b) not support DNSSEC (as if it did, in practical terms, at least one of
   the records it had to serve would exceed 512 bytes)
c) be able to guarantee it has no other records that if served could
   ever exceed 512 bytes (no matter how the UDP query is formed)
d) not support zone transfers; AND
e) not have any 'private agreements' with resolvers to TCP queries.

I suspect the size of the above set is small. In my earlier response
(later clarified), I stated my view that at least for DNS servers outside
this 'grey area' set (putting (e) aside), TCP should be a MUST.

The question, it seems to me is this: Is it better to just make it a MUST
for every server (which is far easier to understand - and there's nothing
stopping one running a non-compliant server), or is it better to make it a
MUST with a tiny carve-out?

What I think we shouldn't do, is carry on with it being unclear. As you
point out, the draft says "SHOULD", but as Mark et al point out, other
places then go and make this a MUST in either nearly all, or all cases
(depending on your interpretation).

Given no one has yet suggested a use-case for any server within this
'grey-area set' (I don't think many embedded applications have authoritative
nameservers, but what do I know), and the set is necessarily small, I
think probably a simple 'MUST' is the thing to do. If your objection
to this is one of principle, i.e. that this is a 'clarify' for 99.9%
of servers, but at least arguable a new requirement for 0.1%, then
perhaps we put that in the notes.

-- 
Alex Bligh

---

From: Jim Reid <[email-masked]>
Date: Wed, 23 Sep 2009 09:20:09 +0100

> requirement is irrelevant.

You have no way of knowing that. Or enforcing clients to behave in  
that way. Besides, just because a client has "no reason" to so  
something does not mean it will never, ever do that. You should be  
well aware that there is already more than enough unreasonable  
misbehaviour by DNS clients. They do all sorts of stupid things even  
though there's no reason for them to do that.

Let's stop this endless angels on pinhead debate. Make TCP mandatory.

BTW, your server will be accepting UPDATE queries unless you've got a  
firewall that's doing opcode filtering or something like that. It may  
well be ignoring or rejecting those queries because your server has no  
support for DDNS. But they will (or could) be arriving at your server.

---

From: Matthew Dempsky <[email-masked]>
Date: Wed, 23 Sep 2009 01:43:55 -0700

On Wed, Sep 23, 2009 at 1:20 AM, Jim Reid <[email-masked]> wrote:
> You have no way of knowing that. Or enforcing clients to behave in that way.
> Besides, just because a client has "no reason" to so something does not mean
> it will never, ever do that. You should be well aware that there is already
> more than enough unreasonable misbehaviour by DNS clients. They do all sorts
> of stupid things even though there's no reason for them to do that.

I didn't say my server will crash when someone tries to send it an
UPDATE query.  I just said it doesn't support UPDATE queries; i.e., I
don't promise that a client who incorrectly sends me an UPDATE query
will receive a meaningful response.

> Let's stop this endless angels on pinhead debate. Make TCP mandatory.

Right, do it by fiat.

The point of publishing a protocol standard is to document how things
work, not how you wish they worked.

> firewall that's doing opcode filtering or something like that. It may well
> be ignoring or rejecting those queries because your server has no support
> for DDNS. But they will (or could) be arriving at your server.

Fine, whatever, we have a difference in terminology.

---

From: Shane Kerr <[email-masked]>
Date: Wed, 23 Sep 2009 10:42:48 +0200

> Let's stop this endless angels on pinhead debate. Make TCP mandatory.

I tend to agree with Jim.

--
Shane

---

From: bert hubert <[email-masked]>
Date: Wed, 23 Sep 2009 11:10:42 +0200

> I tend to agree with Jim.

Me too.

---

From: Douglas Otis <[email-masked]>
Date: Wed, 23 Sep 2009 02:16:36 -0700

On 9/22/09 11:48 PM, Paul Vixie wrote:
>> From: Matthew Dempsky<[email-masked]>
>> ...

It has taken SCTP nearly a decade to gain its current level of support. 
  SCTP permits unordered delivery of DNS messages.  SCTP already allows 
unreliable message delivery (eliminating a need to buffer unacknowledged 
data).  For security, SCTP starts with a cookie exchange and provides 
associations validation tags.  SCTP also provides an auto close feature 
supporting persistent exchanges.

Many SOHO devices currently don't support DNS exchanges over TCP, as 
noted in the http://download.nominet.org.uk/dnssec-cpe/ report.  The 
reason for these devices not supporting TCP can be mitigated by 
unreliable unordered SCTP.  SCTP, in this mode, eliminates the 
complexities imposed by TCP's lack of framing, especially when 
confronting different PMTUs or a need to alter addressing.

There are also problems related to devices that attempt to analyze or 
buffer TCP data streams, where relationships between frames and DNS 
messages become obscured.  Not only will answers need to be resurrected 
through some new API, the exact order of these answers will also need to 
be retained.  Whenever a packet is lost, even assuming a replicate 
answer can be resurrected, acknowledgments may not occur at DNS message 
boundaries.  SCTP offers a clean solution.  SCTP is not a byte stream, 
it is a chunk stream, where chunks can represent DNS messages.

Changing TCP to support message framing and unreliable delivery requires 
sizable modification at the API, to say the least.  As such, it would be 
wrong to describe this protocol as TCP.  Initial proposals for SCTP were 
over UDP.  TPTB decided this protocol should be promoted to its own 
transport, SCTP.  The best course having the shortest time horizon would 
be to embrace SCTP.  Perhaps even SCTP over UDP.  SCTP's unreliable 
unordered delivery features makes it practical for SOHO equipment to 
safely and economically support DNS, DNSSEC, and jumbo frames, while 
adding their normal tweaks.  With or without DNSSEC, blind spoofing and 
reflected attack issues would also be eliminated.

-Doug

---

From: [email-masked]
Date: Wed, 23 Sep 2009 09:58:05 +0000

> requirement is irrelevant.

	selectively "cherry-picking" which parts of the DNS spec you 
	want to implement and which you want to ignore is your 
	choice.  And since there are no "interoperability" police,
	you can even call it a DNS server.  

--bill

---

From: [email-masked]
Date: Wed, 23 Sep 2009 10:13:32 +0000

> If you understand 6.1.3.2 differently, please elaborate.

	back when RFC 1123 was written, I might have been firmly 
	in your camp.  If RFC 1123 was talking about authoritative 
	servers.  But its not.  Its clearly talking about 

		RESOLVER IMPLEMENTATIONS.

	how ever, RFC 1123 authors clearly saw the impending need
	to require TCP support and said as much in the document.

	now, 20 years on, I beleive that the advice given in this 
	document is pragmatically the operational realitity for 
	most of the Internet.

	"However, it is also clear that some new DNS record
         types defined in the future will contain information
         exceeding the 512 byte limit that applies to UDP, and
         hence will require TCP.  Thus, resolvers and name
         servers should implement TCP services as a backup to
         UDP today, with the knowledge that they will require
         the TCP service in the future."

	This was the advice given in 1989.  Now is the future that
	was foreseen back then.  If you understand the text differently,
	please elaborate.

	Now - based on other parts of this thread - I surmise that you
	are going to be selective in which parts of the DNS spec you
	chose to implement.  It would help frame this discussion if
	you were clear on which CLASS, QTYPE, and RRtypes you are going 
	to -not- implement... 

--bill

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 23 Sep 2009 06:55:27 -0700

> responses to respond to queries over TCP?

Because you have broken proxies on UDP which don't speak TCP, which  
means you can bypass the brokenness by querying over TCP.

Because using TCP allows you effective security against out of path  
adversaries in a way UDP doesn't, when you have NATs etc messing up  
your port randomization.

These are both reasons why authorities MUST support TCP, even in the  
case where the authority can guarentee its responses are 512B or less  
for all queries.

---

From: Tony Finch <[email-masked]>
Date: Wed, 23 Sep 2009 14:59:15 +0100

> to servers that send truncated UDP responses.

That's an exception for a particular operational environment. RFC
requirements are about implementations. When they say an implementation
MUST implement something, that doesn't mean an operator can't turn it off.

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: Tony Finch <[email-masked]>
Date: Wed, 23 Sep 2009 15:05:22 +0100

On Wed, 23 Sep 2009, Alex Bligh wrote:
> 'grey-area set'

DNS blacklist servers.

I still think TCP should be mandatory to implement.

Tony.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 23 Sep 2009 10:19:28 -0400

> to servers that send truncated UDP responses.

It would be helpful if, instead of saying, "Don't do this," you could
take the text of the draft that is to be come a WG item, and propose
an alteration of it that provides the limited exception you propose.
Something like, MUST support TCP unless the server can guarantee that
it does not support zone transfer, can not send truncated UDP
responses, and never otherwise needs TCP.  Note that the second of
these requirements effectively means that the server MUST NOT start if
it could generate a UDP response that would need to be truncated."  Or
something like that.

Best regards,

A

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

---

From: Paul Vixie <[email-masked]>
Date: Wed, 23 Sep 2009 14:21:56 +0000

> From: Mark Andrews <[email-masked]>
> Date: Wed, 23 Sep 2009 17:33:56 +1000
> 
> But that isn't what RFC 1123 says.  Even if you were to modify RFC 1123
> to say that everything other than a authoritative server MUST support TCP
> you would still have operational problem because people get it wrong
> today and will continue to get it wrong.  To make serving robust it needs
> to be a MUST.  There is no harm in making it a MUST.

if a dedicated service operator whose high level architecture does not rely
on large messages and cannot support TCP wants to deploy a UDP-only service,
then their prospective customers ought not blow them out of the water just
because of the TCP thing.  or if an equipment or software vendor wants to
build some kind of high speed embedded hardware-assisted box that can't hold
state and so is only useful if TCP is not used and is therefore only useful
to customers who do not need to send large messages, they ought to still be
able to call what they're doing "DNS" and check the box for RFC compatibility.

some forms of DNS can be deployed successfully without TCP and if some
DNS technology <seller,buyer> pairs want to do it that way then they ought
not be penalized by the wording of the RFC's.  noone is objecting to making
an RFC that says "TCP is required if you want to implement all features and
options of DNS", but some are questioning the veracity of an RFC that would
say "TCP is required if you want to implement any subset of DNS".  can we
find a middle ground that doesn't make DNS a "package deal" for vendors and
customers?

note that no recursive service or operator or implementor would fall under
such an exclusion.  recursive service requires large message support because
many authority servers do.  therefore opendns and any similar operator MUST
support TCP even if large message support is optional in some other cases.

---

From: David Conrad <[email-masked]>
Date: Wed, 23 Sep 2009 08:32:00 -0700

On Sep 23, 2009, at 7:21 AM, Paul Vixie wrote:
> if TCP is not used and is therefore only useful

Why?

> but some are questioning the veracity of an RFC that would
> say "TCP is required if you want to implement any subset of DNS".

I don't think so.  Some are questioning whether an implementation that  
does not support TCP can truthfully be called a full, standards  
compliant implementation of DNS.  If you want to call a TCP-less  
implementation a subset of DNS, I can't see how anyone could complain.

Regards,
-drc

---

From: Olafur Gudmundsson <[email-masked]>
Date: Wed, 23 Sep 2009 11:58:26 -0400

Dear colleagues,

The chairs would like the circular arguments on this topic to come to an end.

Plan: we will work with the editor to publish a new draft that incorporates
the feedback received in this thread.
This draft will be posted around before monday next week.
Editor is checking on RFC1123 intent and ability to update that document.

If you have NEW points that you want considered for the document feel free to
post them.

The next version of the document will make a clear separations between what is
expected of implementations and what sites may (or may not) operationally do.

         Olafur & Andrew

---

From: Douglas Otis <[email-masked]>
Date: Wed, 23 Sep 2009 11:19:04 -0700

On 9/23/09 8:32 AM, David Conrad wrote:
>
> I don't think so. Some are questioning whether an implementation
> that does not support TCP can truthfully be called a full, standards

David,

It is conceivable, perhaps to limit the state held at servers or
intervening equipment of limited resource, that other alternative
transports to TCP might become employed.  Rather than being specific
about the alternative, just acknowledge a need to handle larger DNS
messages without mandating use of TCP, which could forever leave DNS
handicapped with a resource hungry transport.

RFC1123:

6.1.3.2  Transport Protocols

|--
  DNS resolvers and recursive servers MUST support UDP, and
  SHOULD support TCP, for sending (non-zone-transfer) queries.
  Specifically, a DNS resolver or server that is sending a
  non-zone-transfer query MUST send a UDP query first.  If the
  Answer section of the response is truncated and if the
  requester supports TCP, it SHOULD try the query again using
  TCP.
|--

Change to:
,---
DNS servers MUST be able to service UDP queries and SHOULD be able to
service queries over TCP or an adopted alternative transport.  A name
server MAY limit the resources it devotes to TCP queries, but it SHOULD
NOT refuse to service a TCP query just because it would have succeeded
with UDP. Servers supporting DNSSEC MUST be able to handle DNS messages
exceeding 1000 bytes over a transport other than UDP. However, a DNS 
resolver or server sending a non-zone-transfer query MUST send it either 
over UDP or the adopted alternative transport first.
'---

|--

|--

Change to:
,---
By private agreement, name servers and resolvers MAY arrange to use TCP
or an adopted alternative transports for all traffic between themselves.
A transport that supports congestion avoidance MUST be used for zone
transfers.

A DNS server MUST have sufficient internal concurrency that it can
continue to process UDP queries while awaiting a response or performing
a zone transfer over TCP or an adopted alternative transport.
'---

-Doug