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
- [dnsext] compression in UPDATE Paul Vixie
- Re: [dnsext] compression in UPDATE Brian Wellington
- Re: [dnsext] compression in UPDATE Tony Finch
- Re: [dnsext] compression in UPDATE Paul Vixie
- Re: [dnsext] compression in UPDATE Paul Vixie
- Re: [dnsext] compression in UPDATE Edward Lewis
- Re: [dnsext] compression in UPDATE Brian Wellington
- Re: [dnsext] compression in UPDATE Mark Andrews