Re: [dnsext] compression in UPDATE

Brian Wellington <brian.wellington@nominum.com> Mon, 09 May 2011 21:16 UTC

Return-Path: <brian.wellington@nominum.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8B0CE072E for <dnsext@ietfa.amsl.com>; Mon, 9 May 2011 14:16:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 4Au9yatrRmlr for <dnsext@ietfa.amsl.com>; Mon, 9 May 2011 14:16:50 -0700 (PDT)
Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by ietfa.amsl.com (Postfix) with ESMTP id 7E070E07F3 for <dnsext@ietf.org>; Mon, 9 May 2011 14:16:37 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTchZtI4GSL3RXW0y4Gbkozkvy8UjkUmc@postini.com; Mon, 09 May 2011 14:16:37 PDT
Received: from wave.ddns.nominum.com (wave.ddns.nominum.com [64.89.225.94]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by shell-too.nominum.com (Postfix) with ESMTP id 64F281B868F; Mon, 9 May 2011 13:41:03 -0700 (PDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Brian Wellington <brian.wellington@nominum.com>
In-Reply-To: <46926.1304972788@nsa.vix.com>
Date: Mon, 9 May 2011 13:41:03 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <F859DC5E-B25F-47A3-9FDC-2C63D395D258@nominum.com>
References: <46322.1304956246@nsa.vix.com> <4CBE2660-72FF-40CE-89C2-C5D1EF9469C3@nominum.com> <63636.1304967456@nsa.vix.com> <a06240800c9edf6fcfbcb@[10.31.203.194]> <46926.1304972788@nsa.vix.com>
To: Paul Vixie <vixie@isc.org>
X-Mailer: Apple Mail (2.1084)
Cc: dnsext@ietf.org
Subject: Re: [dnsext] compression in UPDATE
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsext>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 May 2011 21:16:51 -0000

On May 9, 2011, at 1:26 PM, Paul Vixie wrote:

>> Date: Mon, 9 May 2011 16:03:59 -0400
>> From: Edward Lewis <Ed.Lewis@neustar.biz>
>> 
>>> so i see.  ouch.  in fact the bind8 version of this goes well beyond
>>> RFC 3597's constraints on "known types".  i suggest that we draw a new
>>> line in the sand and require that compression be understood for all
>>> types that any now-current implementation is known to compress for.
>> 
>> I'd go the other way.  There's little harm in never compressing an outgoing
>> message (the loss is that extra octets are moved).  There's more harm in
>> compressing a type the receiver doesn't know, especially because the
>> receiver wouldn't know that there was compression in use. (Compression
>> isn't transitive, message to message, that is.)
> 
> i agree, and that was my first inclination also, but i hate breaking the
> installed base just for the sake of purity.  nsupdate is a huge contributor
> to the world's supply of UPDATE messages and i am loathe to declare it
> broken.

A few more points:

RFC 1035 (in section 4.1.4. Message compression) doesn't say anything about opcode.  UPDATE was defined later, so obviously wouldn't be mentioned there, but there's also no specific mention of QUERY, IQUERY, or STATUS; the text says "In order to reduce the size of messages".

RFC 1996 (NOTIFY) also doesn't mention compression; is anyone suggesting that compression be outlawed there as well?

RFC 3597 (unknown RR types) doesn't mention anything about opcode QUERY; I'd interpret it as defining the list of types expected to be known regardless of OPCODE.  If bind8's nsupdate is compressing types not listed by RFC3597, that sounds like a potential problem, but compressing any type listed in RFC 3597 seems safe enough.

Brian