Subject: [dnsext] compression in UPDATE

From: Paul Vixie <[email-masked]>
Date: Mon, 09 May 2011 15:50:46 +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?

---

From: Brian Wellington <[email-masked]>
Date: Mon, 9 May 2011 11:33:52 -0700

> 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

---

From: Tony Finch <[email-masked]>
Date: Mon, 9 May 2011 19:30:04 +0100

> therefore my question: does any UPDATE initiator actually use compression?

BIND's nsupdate tool compresses owner names and names in the RDATA of RFC
1035 RR types. This is consistent with RFC 3597, which makes sense.

I don't think RFC 2136 needs to forbid compression; it just needs to say
that records (owner names and RDATA) are compared after they have been
decompressed and the RDLENGTH adjusted to match.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in
Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5
or 6 later. Rough or very rough. Occasional rain. Moderate or good,
occasionally poor.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 09 May 2011 18:57:36 +0000

> From: Brian Wellington <[email-masked]>
> Date: Mon, 9 May 2011 11:33:52 -0700
> 

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.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 09 May 2011 20:26:28 +0000

> Date: Mon, 9 May 2011 16:03:59 -0400
> From: Edward Lewis <[email-masked]>
> 
> 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.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 9 May 2011 16:03:59 -0400

>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.)

Having been involved in a few "clarification" documents I'm not all 
that eager to see any more lines in the sand redrawn. ;)  It's never 
pain-free.  Recently I privately offered to write a document to cover 
over all the dead types and got no statements of support.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

Now, don't say I'm always complaining.
Wait, that's a complaint, isn't it?

---

From: Brian Wellington <[email-masked]>
Date: Mon, 9 May 2011 13:41:03 -0700

> to the world's supply of UPDATE messages and i am loathe to declare it

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

---

From: Mark Andrews <[email-masked]>
Date: Tue, 10 May 2011 08:16:56 +1000

In message <[email-masked]>, Brian Wellington
 writes:
> 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 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsext
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]