Re: [dnsext] compression in UPDATE

Brian Wellington <brian.wellington@nominum.com> Mon, 09 May 2011 18:33 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 EE601E08AA for <dnsext@ietfa.amsl.com>; Mon, 9 May 2011 11:33:55 -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 Egmmdu+0Ki3y for <dnsext@ietfa.amsl.com>; Mon, 9 May 2011 11:33:55 -0700 (PDT)
Received: from exprod7og107.obsmtp.com (exprod7og107.obsmtp.com [64.18.2.167]) by ietfa.amsl.com (Postfix) with ESMTP id BAC56E0791 for <dnsext@ietf.org>; Mon, 9 May 2011 11:33:53 -0700 (PDT)
Received: from shell-too.nominum.com ([64.89.228.229]) (using TLSv1) by exprod7ob107.postini.com ([64.18.6.12]) with SMTP ID DSNKTcgzkTVEq34ZtaHXLBDq1njHSiU56tDu@postini.com; Mon, 09 May 2011 11:33:54 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 07A1F1B8659; Mon, 9 May 2011 11:33:53 -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: <46322.1304956246@nsa.vix.com>
Date: Mon, 9 May 2011 11:33:52 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <4CBE2660-72FF-40CE-89C2-C5D1EF9469C3@nominum.com>
References: <46322.1304956246@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 18:33:56 -0000

On May 9, 2011, at 8:50 AM, Paul Vixie wrote:

> this is a possible RFC 2136 errata.  2136 does not mention compression at
> all, which is an oversight, it ought to have said "compression shall not
> be used".  in the absence of such a statement i believe that implementors
> of UPDATE responders have decompressed any of the RR types they understand,
> which is fine under the robustness principle but may create the misleading
> expectation that all types are understood and that compression is supported.
> 
> therefore my question: does any UPDATE initiator actually use compression?

It's possible I'm misunderstanding the question, but wouldn't compression be expected?  None of the implementations I'm familiar with conditionalize name compression based on opcode, so any types which can be compressed in QUERY responses could also be compressed in UPDATE requests.

nsupdate appears to be compressing both owner names and names in rdata, for example.

Brian