Subject: Re: Q1 followup - arguements against "MUST NOT" language

From: Edward Lewis <[email-masked]>
Date: Wed, 5 Mar 2003 09:43:56 -0500

Also, what do you mean by "use" ;)

I'm leaning towards "MUST NOT compress domain names in the RDATA 
sections when assembling and transmitting a message."  (Includes 
dynamic update request messages when using this wording.)

1) Bytes compressed away in a SIG message are miniscule compared to 
the signature.

2) A response won't have many NXT's anyway (unlike NS records which 
may be numerous in a referral).

3) Assuming EDNS0 is going to enlarge the minimum maximum message 
size from 512, what's a few extra bytes.

At 13:40 -0500 2/12/03, Scott Rose wrote:
>The general consensus is that name compression in RDATA is A Bad Thing (tm),
>but there are some differences on the wording for the spec:
>
>Sub-Question:  What are the arguments against using the terms (1)"MUST NOT
>use name compression on DNS names in the RDATA on sending over the wire"
>(paraphrasing here) over (2)"SHOULD NOT use name compression on DNS names in
>the RDATA..."?
>
>Notes:
>     A.  (1) is the strength of the wording used in the unknown-rrs draft.
>There would be consistency.
>
>
>
>Scott
>
>
>
>
>--
>to unsubscribe send a message to [email-masked] with
>the word 'unsubscribe' in a single line as the message text body.
>archive: <http://ops.ietf.org/lists/namedroppers/>

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: "Scott Rose" <[email-masked]>
Date: Wed, 5 Mar 2003 10:43:48 -0500

That seems to be the prevailing winds - MUST NOT compress DNS names in the
RDATA (paraphrase).  Basically, change the DNSSEC specs to keep in line with
the unknown-rrs draft and namedroppers discussion.

Scott

---

From: Alexis Yushin <[email-masked]>
Date: Wed, 5 Mar 2003 16:42:30 +0100 (CET)

I think that we should try to keep the standards as uniform as possible.
Making million exceptions to the rules is the ultimate Bad Thing (tm).

I dont see why name compression in RDATA is necessary a bad thing, I do
see that making different rules for different RR RDATA complicates the
standards, implementation and definitely introduces more potentional
interoperability issues.

Alexis

---

From: Edward Lewis <[email-masked]>
Date: Wed, 5 Mar 2003 10:59:05 -0500

The "bad thing" is that each RR becomes some form of a special case. 
I.e., you have to know (upon receipt) where a domain name sits in the 
RDATA.  Having written resolver code and DNSSEC verification code, 
it's a pain.  Not only do you have to know where to find the possible 
compression, you have to write to a new buffer that is expanded, 
possibly in the middle.

If you compress in a RR than is unknown to a receiver, then the 
receiver stands no chance at achieving any DNSSEC validation of the 
data.  'Course, once again, validation oughta be end-to-end, so maybe 
that's a non-issue.

---

From: Greg Hudson <[email-masked]>
Date: 05 Mar 2003 10:57:27 -0500

> standards, implementation and definitely introduces more potentional

Allowing name compression in a new RDATA type breaks old caches, because
you can no longer treat the RDATA as an opaque value.  You have to know
its structure so that you can uncompress the name before you cache it
and return it to a future client.

We can't retroactively disallow compression in old RDATA types, or at
least, it wouldn't help much; old DNS software sticks around for a long
time, so software would still have to handle it essentially forever.

So we're stuck with different rules for different RR types.

(There was a proposal for inventing a new type of self-contained, "local
compression" for use in new RR types, but that was nixed by the working
group as too complicated for such a small gain.  Bernstein has suggested
that we would do better to use a simple generic compression algorithm on
DNS packets, but short of a full protocol rev, the transition issues
associated with that approach are probably too difficult.  Plus, I
haven't seen any measurements backing up the claim.)

---

From: Alexis Yushin <[email-masked]>
Date: Wed, 5 Mar 2003 17:09:14 +0100 (CET)

>compression, you have to write to a new buffer that is expanded, 

Yes, I understand this sort of a bad thing, but that's a bit too late
to fix it if we dont want to introduce an entirely new protocol. Now you
basically suggest to introduce *additional* special rules (and I could live
with it if it would solve the historical issues in the protocol) to help
particular implementation.

I strongly believe we should stay uniform on handling domain names,
either forbid domain name compression at all (since the connectivity
improved over years and we're not saving anything with it) or leave it
as is.

I think that clear standard has priority over implementation simplicity.

Alexis

---

From: Edward Lewis <[email-masked]>
Date: Wed, 5 Mar 2003 11:15:53 -0500

>particular implementation.

I think I don't understand.  I'm advocating a return to what 1035 
said, not any additional rules.  RFC 1035 says that just a few types 
are subject to compression.  The DNSSEC specs overstepped their 
bounds in saying that the new RRs were also subject to compression.

>improved over years and we're not saving anything with it) or leave it

The problem is that "as it is" is 'broken and inconsistent.' ;)

>I think that clear standard has priority over implementation simplicity.

The problem is that the standards are not clear, they are 
self-conflicting.  That's the issue, not really the implementation 
thing.  2535 should not break 1035 in any way, okay, not in this way.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                          +1-703-227-9854
ARIN Research Engineer

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 5 Mar 2003 09:09:22 -0800 (PST)

> data.  'Course, once again, validation oughta be end-to-end, so maybe 

It is an issue even assuming end-to-end validation.  If you compress
in a RR than is unknown to a receiver, and that receiver in turn sends
the compressed RR to a final receiver as part of a newly constructed
DNS message, the compressed names are corrupted because the locations
the compression pointers point to are now part of different DNS
message and contain different data.

This is not just a question of breaking DNSSEC validation, but of
the interoperability of the basic DNS protocol.
-- 
Andreas Gustafsson, [email-masked]

---

From: [email-masked]
Date: Thu, 06 Mar 2003 08:00:00 +1100

> the unknown-rrs draft and namedroppers discussion.

	The MUST NOT is to prevent the case of the letters in the label
	being changed and thereby causing signature comparision to fail.

	Potentially it could be compressed if you added additional
	restrictions to the current compression algorithim to also
	check the case of labels when looking for compression pointer
	targets.

	The actual requirement is that the case of the labels be
	preserved.  Not compressing domain names in the rdata is a
	way to achieve that.
 
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Edward Lewis <[email-masked]>
Date: Wed, 5 Mar 2003 16:00:58 -0500

Ah.

---

From: [email-masked] (Andreas Gustafsson)
Date: Wed, 5 Mar 2003 13:47:14 -0800 (PST)

> 	being changed and thereby causing signature comparision to fail.

No, the canonicalization specified in RFC2535 section 8.1 (and revised
in unknown-rrs section 7) will keep that from happening.

The real problem is that the record would be corrupted by servers that
attempt to treat it transparently, as I just explained in my message
to Edward Lewis.
-- 
Andreas Gustafsson, [email-masked]

---

From: [email-masked]
Date: Thu, 06 Mar 2003 09:43:05 +1100

> attempt to treat it transparently, as I just explained in my message

	There are multiple issues.

	With old clients that don't under the RR format you have to
	preserve case and not compress.  This allows the records
	to be treated as a opaque blob for cache and verification.

	With new clients that understand the RR format you still
	have to preserve the case but you could, if wanted to provide
	signaling to the server, use a compression pointer if
	the suffix pointes to had the *same* case as the original
	suffix.  The records in this case are not treated as
	opaque blobs and verification works.

	The requirement is that the case be preserved.  How you achieve
	that is a secondary matter.  Outlawing compression is one
	way.

	Mark

---

From: Ólafur Guðmundsson <[email-masked]>
Date: Thu, 20 Mar 2003 17:26:04 -0500

>         that is a secondary matter.  Outlawing compression is one

Not compressing against the QNAME is another.
In this case all compression pointers would only point to
Answer, Authority and additional sections.

         Olafur