Subject: RE: I-D ACTION:draft-iab-dns-choices-00.txt

From: "Christian Huitema" <[email-masked]>
Date: Sun, 17 Oct 2004 09:33:06 -0700

[ Moderators note: Post was moderated, either because it was posted by 
   a non-subscriber, or because it was over 20K.  
   With the massive amount of spam, it is easy to miss and therefore 
   delete relevant posts by non-subsrcibers. Please fix your 
   subscription addresses. ]

Having a document like that is very useful, and the arguments are well
put, but I find three weaknesses in this version: unsubstantiated claims
about TCP, too much emphasis on wild cards in the analysis of the "name
prefix" solution, and a failure to acknowledge the potential desire of
implementers to avoid the IETF process.

Throughout the document, there are claims that having large records or
large record sets increases the risk of using TCP, which is true, and
that using TCP would be a catastrophe, which is dubious. In the draft,
the main argument against TCP for DNS is one of server performance. The
draft says that a TCP based operation causes 3 times more traffic, but
this is merely three types as many packets, not bytes. It also says that
the server load will be much increased, since processing UDP packets is
"much simpler". However, the TCP code paths are much optimized in modern
servers, and there is little performance penalty of serving a request
over TCP versus UDP. 

TCP has other advantages. Commercial load balancing solutions in large
server farms are designed for TCP, not UDP. The three way handshake in
TCP enables a potent defense against denial of service attacks, and
makes some spoofing attacks much harder. In fact, this group should
probably reconsider its stance versus TCP.

The main argument against the name prefix solution is its
incompatibility with wild cards. Without going in a deep analysis of
wild card usage, I note that we have some experience with using name
prefixes for SRV records, and that the mail logs are not full of
complaints about incompatibility between SRV and wild cards. In most
cases, applications know exactly which domain name should be extended,
and do not need the wild card facility. The wild card problem may exist
in theory, but it is seldom encountered in practice, and there are
obvious workarounds.

The document does not discuss the role of the IETF in the record type
creation process. This is an important issue for implementers. Although
the RR type field has the same size as the TCP port numbers, they are
not allocated in the same way. RFC 2929 lists record type numbers
4096-65535 as "available for assignment", but the IANA has no "Online
Application for a User (Registered) DNS Record Type Number". In
practice, record types can only be created by "IETF Consensus", which
takes a long time. This contributes to the public perception that
creating a record type is hard. This working group should either open
the current IANA procedures, or keep them while acknowledging that
record type creation is hard.

-- Christian Huitema

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Paul Vixie <[email-masked]>
Date: Mon, 18 Oct 2004 00:09:44 +0000

> ... find three weaknesses in this version: unsubstantiated claims about TCP
> ...

you are wrong.  speaking for f-root, if we had to build a protocol control
block for each of the 5000 to 10000 queries that came in every second, and
exchange packets between our state machine and remote state machine, before
finally sending the response and reclaiming the state-memory, we'd need a
lot more hardware than we have today.  it's not the bytes, or the packets--
those we can provision easily.  it's the state-memory occupancy time that
would dominate.

i'm not saying it can't be done.  our headroom would allow this to happen
overnight... but then we'd have to start provisioning more headroom.  the
claims in this document are accurate.  tcp is more expensive than udp for
dns.  making a decision that would require all high volume nameservers in
the internet to jump curves wrt headroom and provisioning is what's "dubious".

> probably reconsider its stance versus TCP.

why stop there?  xml has a lot of advantages -- maybe dns should stop
using binary packet formats and just use html.  this would make
internationalization easier, for one thing.  for that matter, why use a
dedicated protocol for dns when we could use sunrpc, or ldap, or
SMB/CIFS, or SQL?  (note to the humour-challenged, this is Sarcasm on
my part.)

---

From: Robert Elz <[email-masked]>
Date: Tue, 19 Oct 2004 00:05:18 +0700

Date:        Mon, 18 Oct 2004 00:09:44 +0000
    From:        Paul Vixie <[email-masked]>
    Message-ID:  <[email-masked]>

  | if we had to build a protocol control
  | block for each of the 5000 to 10000 queries that came in every second,

It is worse than that.   TIME_WAIT state (in addition to be required
somewhere, consuming resources - but that's probably at the client)
limits the number of TCP transactions/second between a client+server
pair (where the server port is fixed, as it is here) very severely,
it turns into just 100's a second (depending upon the packet TTLs,
and so what the MSL is).

That's insufficient for many DNS applications - which means that they'd
need to re-use connections - which means leaving connections alive on the
off chance they'll be needed again soon after.    That means that all that
state either hangs around much longer than you'd really want it to, or
the server needs to close down the connections, which means that it is the
system that ends up in TIME_WAIT, and that means a minumum of a couple of 
minutes per connection in idle state.

TCP just isn't an option for transaction services, like the DNS.

We could switch to using T/TCP, but we'd have to find something in
widespread use that actually has that available first... (and that
still means lots of connection setup).

On one of Christian's other points ...

  | The main argument against the name prefix solution is its
  | incompatibility with wild cards.

The main argument against it should be that domain names don't belong
to the IETF, they belong to whoever registered the domain, and the IETF
has no business whatever stealing names from organisations' domains.

kre

---

From: Alex Bligh <[email-masked]>
Date: Mon, 18 Oct 2004 18:39:30 +0100

--On 17 October 2004 09:33 -0700 Christian Huitema 
<[email-masked]> wrote:

> server farms are designed for TCP, not UDP.

Aside from all the other arguments per Paul and Co, this is a real false
syllogism I can't let rest.

It is true that (most) commercial load balancing solutions in large server
farms are designed for TCP not UDP; however, this is because:
(a) the most frequently used (by requirement for load sharing) protocols
    use TCP (e.g. HTTP); and
(b) Anycast is so easy it doesn't require a "commercial load balancing
    solution" the same way TCP does, because it does not need to record
    state.

Indeed your premise could more validly be used as a counter-argument:
load sharing over TCP is sufficiently difficult that large server farms
require deployment of commercial load balancing solutions to do it,
whereas effective load balancing on UDP can be deployed using far more
lightweight technology such as anycast. Thus by switching to TCP you
are increasing the cost of load-balanced DNS (by your own thesis and
apart from Paul's and Phill's observations).

Alex