Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard

Keith Moore <moore@network-heretics.com> Fri, 22 July 2011 04:32 UTC

Return-Path: <moore@network-heretics.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753AC11E8075 for <ietf@ietfa.amsl.com>; Thu, 21 Jul 2011 21:32:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYwHODxzrsK4 for <ietf@ietfa.amsl.com>; Thu, 21 Jul 2011 21:32:39 -0700 (PDT)
Received: from out5.smtp.messagingengine.com (out5.smtp.messagingengine.com [66.111.4.29]) by ietfa.amsl.com (Postfix) with ESMTP id 77F2B21F85C4 for <ietf@ietf.org>; Thu, 21 Jul 2011 21:32:39 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.messagingengine.com (Postfix) with ESMTP id 8BACF209CA; Fri, 22 Jul 2011 00:32:38 -0400 (EDT)
Received: from frontend1.messagingengine.com ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 22 Jul 2011 00:32:38 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id :references:to; s=smtpout; bh=1rxuUbC47S9tne1fWrJqi284C+g=; b=a9 73EbBPc3XMr2sAw8r080CoGT0elD7qcR2RCdN6pUdDCqCEBt+rIcuxeuflYhFe4W l8fnw1Mxnc0c7lMFsLkt3P0aDpzfMr3pdn2cOSWk5vHkQXEwbBRK9vdE0v5QTfUH N1lDcPJTfaerusXtQ7aygcBh7jbE+Yay+uNTQefo4=
X-Sasl-enc: RGZoOSD2LAnAGqoxweON25NCOyPIYmRXp4jw1aEXZse+ 1311309156
Received: from [10.59.1.76] (static-71-166-174-114.washdc.east.verizon.net [71.166.174.114]) by mail.messagingengine.com (Postfix) with ESMTPA id E85B74119C7; Fri, 22 Jul 2011 00:32:33 -0400 (EDT)
Subject: Re: [hybi] Last Call: <draft-ietf-hybi-thewebsocketprotocol-10.txt> (The WebSocket protocol) to Proposed Standard
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Keith Moore <moore@network-heretics.com>
In-Reply-To: <20110722034332.8CD841212A79@drugs.dv.isc.org>
Date: Fri, 22 Jul 2011 00:32:23 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <E7507334-3515-4764-A0E7-2DA42C98ECE3@network-heretics.com>
References: <20110711140229.17432.23519.idtracker@ietfa.amsl.com> <CALiegfk0zVVRBbOP4ugsVXKmcLnryujP6DZqF6Bu_dC2C3PpeQ@mail.gmail.com> <9031.1311082001.631622@puncture> <CALiegfk_GLAhAf=yEe6hYw2bwtxEwg9aJN+f0Bm9he5QgsRavA@mail.gmail.com> <CAP992=Ft6NwG+rbcuWUP0npwVNHY_znHmXmznBQO_krMo3RT6g@mail.gmail.com> <CALiegfmTWMP3GhS1-k2aoHHXkUkB+eWqV=2+BufuWVR1s2Z-EA@mail.gmail.com> <20110721163910.GA16854@1wt.eu> <CAP992=FrX5VxP2o0JLNoJs8nXXba7wbZ6RN9wBUYC0ZSN_wbAg@mail.gmail.com> <9031.1311270000.588511@puncture> <4E28C035.6020009@necom830.hpcl.titech.ac.jp> <20110722021627.48D811211E54@drugs.dv.isc.org> <0DD53760-9B8A-4569-8C67-81421A8A24B6@network-heretics.com> <20110722034332.8CD841212A79@drugs.dv.isc.org>
To: Mark Andrews <marka@isc.org>
X-Mailer: Apple Mail (2.1084)
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 22 Jul 2011 04:32:40 -0000

On Jul 21, 2011, at 11:43 PM, Mark Andrews wrote:

>> I'm fairly convinced that in the vast majority of cases, SRV is a bad =
>> idea.  DNS is already too out of sync from hosts in many situations; SRV =
>> just makes the situation worse.  Or to put it another way, if you want =
>> to give every DNS admin the ability to impose fine-grained control over =
>> what all of the hosts named by his DNS zones can do, deploy SRV =
>> universally.  There are situations where this makes sense, but overall, =
>> giving that level of control to DNS administrators is an extremely bad =
>> idea.
> 
> What a load of FUD.  SRV records are no differnet to CNAME/MX records
> in terms of control.  We don't shy away from adding MX records for
> email or CNAME records for HTTP when CNAME is used a SRV equivalent.

SRV records at first glance like a straightforward generalization of MX records.  But in a sense, that's the problem.  One danger of SRV records is that because they are generic, people keep thinking that they should be retroactively applied to all protocols, whether it makes sense or not.  This is a huge slippery slope.  Not only is there a potential for SRV records to be applied to protocols for which they aren't well suited (which is to say, most protocols), but there will also be a temptation to use SRV to route traffic through NATs that do port mapping, by changing the ports on which those protocols operate from their defaults.  Combine this with multi-faced DNS, so that the port that a peer uses to talk to a service will vary according to from where the DNS query was made, and you get a huge mess.

A related problem is due to the tension between DNS names as hostnames, and DNS names as names for things besides hosts.   DNS started out (quite deliberately) as a system for naming only hosts, and it still reflects that heritage in several ways.   But people keep using it, understandably, to name services rather than hosts, or sometimes to use the same name both.  When a DNS name is exclusively used to associate a name with an IP address or set of IP addresses that provide a single service, that's not a problem.  But when a DNS name is used in some contexts to name a host and in other contexts to name a service, that invites problems.  When people take a DNS name that is used to name a host and then add SRV records for the same name, unless it's done very carefully, that disrupts use of that DNS name to refer to the host and protocol servers at that host.  

For email and MX records, it didn't make such a big difference because by the time MX records were in widespread use, workstations were replacing larger multiuser machines and it became natural to want to associate several hosts with a single email server and map all of them to a single email domain.   But that's a very specific use case.  MX records, in practice, really don't change the behavior of a protocol or host so much as allow domain names to be used for a purpose other than to name hosts - namely to associate email addresses from that domain with one or more SMTP servers willing to receive mail for them.  

(Even then, the problem of MX records being out of sync with the SMTP servers does exist, and used to be a significant source of mail delivery errors.)

CNAMEs are a mess for other reasons.  But at least they don't give DNS admins fine-grained control over individual protocols and services.  If the CNAME is screwed up, it's screwed up for everything associated with that domain.  That tends to call more attention to the problem.

> Note even with SRV you have fallback to A/AAAA records when no SRV
> record is present.

Right, but the DNS admin can blackhole or reroute traffic for your host by installing a SRV record that you don't want or that doesn't match reality.   Bad architecture.  There's a place for access controls and traffic filters, but it's not in DNS.

Keith