[dnsext] compression in UPDATE

Paul Vixie <vixie@isc.org> Mon, 09 May 2011 15:50 UTC

Return-Path: <vixie@isc.org>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 753ADE0703 for <dnsext@ietfa.amsl.com>; Mon, 9 May 2011 08:50:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 33oXL+40PJRW for <dnsext@ietfa.amsl.com>; Mon, 9 May 2011 08:50:54 -0700 (PDT)
Received: from nsa.vix.com (nsa.vix.com [IPv6:2001:4f8:3:30::3]) by ietfa.amsl.com (Postfix) with ESMTP id 1FAF9E070B for <dnsext@ietf.org>; Mon, 9 May 2011 08:50:49 -0700 (PDT)
Received: from nsa.vix.com (localhost []) by nsa.vix.com (Postfix) with ESMTP id 7D138A1019 for <dnsext@ietf.org>; Mon, 9 May 2011 15:50:46 +0000 (UTC) (envelope-from vixie@isc.org)
From: Paul Vixie <vixie@isc.org>
To: dnsext@ietf.org
X-Mailer: MH-E 8.2; nmh 1.3; XEmacs 21.4 (patch 22)
Date: Mon, 09 May 2011 15:50:46 +0000
Message-ID: <46322.1304956246@nsa.vix.com>
Subject: [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 15:50:55 -0000

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?