Re: [dnsext] compression in UPDATE

Mark Andrews <marka@isc.org> Mon, 09 May 2011 22:16 UTC

Return-Path: <marka@isc.org>
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 6CABFE06CF for <dnsext@ietfa.amsl.com>; Mon, 9 May 2011 15:16:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.95
X-Spam-Level:
X-Spam-Status: No, score=-8.95 tagged_above=-999 required=5 tests=[AWL=1.649, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 nh7SmY40i9lP for <dnsext@ietfa.amsl.com>; Mon, 9 May 2011 15:16:49 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by ietfa.amsl.com (Postfix) with ESMTP id BD4E0E067B for <dnsext@ietf.org>; Mon, 9 May 2011 15:16:49 -0700 (PDT)
Received: from bikeshed.isc.org (bikeshed.isc.org [IPv6:2001:4f8:3:d::19]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client CN "bikeshed.isc.org", Issuer "ISC CA" (verified OK)) by mx.pao1.isc.org (Postfix) with ESMTPS id E3D17C94EB; Mon, 9 May 2011 22:16:35 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (drugs.dv.isc.org [IPv6:2001:470:1f00:820:ea06:88ff:fef3:4f9c]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by bikeshed.isc.org (Postfix) with ESMTPSA id 6F238216C31; Mon, 9 May 2011 22:16:35 +0000 (UTC) (envelope-from marka@isc.org)
Received: from drugs.dv.isc.org (localhost [127.0.0.1]) by drugs.dv.isc.org (Postfix) with ESMTP id 207A4E99B7F; Tue, 10 May 2011 08:16:56 +1000 (EST)
To: Brian Wellington <brian.wellington@nominum.com>
From: Mark Andrews <marka@isc.org>
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> <F859DC5E-B25F-47A3-9FDC-2C63D395D258@nominum.com>
In-reply-to: Your message of "Mon, 09 May 2011 13:41:03 MST." <F859DC5E-B25F-47A3-9FDC-2C63D395D258@nominum.com>
Date: Tue, 10 May 2011 08:16:56 +1000
Message-Id: <20110509221656.207A4E99B7F@drugs.dv.isc.org>
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 22:16:50 -0000

In message <F859DC5E-B25F-47A3-9FDC-2C63D395D258@nominum.com>, Brian Wellington
 writes:
> 
> 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 outgoin
> g
> >> 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 o
> pcode.  UPDATE was defined later, so obviously wouldn't be mentioned there, b
> ut there's also no specific mention of QUERY, IQUERY, or STATUS; the text say
> s "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, tha
> t sounds like a potential problem, but compressing any type listed in RFC 359
> 7 seems safe enough.
> 
> Brian

BIND 8's nsupdate knows about the following types. 

        { "a",          T_A },     	/* no rdata compression possible */
        { "ns",         T_NS },		/* listed in RFC 3597 */
        { "cname",      T_CNAME },	/* listed in RFC 3597 */
        { "soa",        T_SOA },	/* listed in RFC 3597 */
        { "mb",         T_MB },		/* listed in RFC 3597 */
        { "mg",         T_MG },		/* listed in RFC 3597 */
        { "mr",         T_MR },		/* listed in RFC 3597 */
        { "null",       T_NULL },	/* no rdata compression possible */
        { "wks",        T_WKS },	/* no rdata compression possible */
        { "ptr",        T_PTR },	/* listed in RFC 3597 */
        { "hinfo",      T_HINFO },	/* no rdata compression possible */
        { "minfo",      T_MINFO },	/* listed in RFC 3597 */
        { "mx",         T_MX },		/* listed in RFC 3597 */
        { "txt",        T_TXT },	/* no rdata compression possible */
        { "rp",         T_RP },		/* listed in RFC 3597 */
        { "afsdb",      T_AFSDB },	/* listed in RFC 3597 */
        { "x25",        T_X25 },	/* no rdata compression possible */
        { "isdn",       T_ISDN },	/* no rdata compression possible */
        { "rt",         T_RT },		/* listed in RFC 3597 */
        { "nsap",       T_NSAP },	/* no rdata compression possible */
        { "nsap_ptr",   T_NSAP_PTR }, /* SHOULD HAVE BEEN LISTED IN RFC 3597 */
        { "sig",        T_SIG },	/* listed in RFC 3597 */
        { "key",        T_KEY },	/* no rdata compression possible */
        { "px",         T_PX },		/* listed in RFC 3597 */
        { "loc",        T_LOC },	/* no rdata compression possible */
        { "nxt",        T_NXT },	/* listed in RFC 3597 */
        { "eid",        T_EID },
        { "nimloc",     T_NIMLOC },
        { "srv",        T_SRV },	/* listed in RFC 3597 */
        { "atma",       T_ATMA },
        { "naptr",      T_NAPTR },	/* listed in RFC 3597 */
        { "kx",         ns_t_kx },	/* listed in RFC 3597 */
        { "cert",       ns_t_cert },	/* no rdata compression possible */
        { "aaaa",       ns_t_aaaa },	/* no rdata compression possible */
        { "dname",      ns_t_dname },   /* listed in RFC 3597 */

This all being said, case sensitive, compression should be used so
that UPDATE can meet the case preservation requirements of RFC103[45].

> _______________________________________________
> dnsext mailing list
> dnsext@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka@isc.org