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

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.

At 16:42 +0100 3/5/03, Alexis Yushin wrote:
>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
>
>
>Once Edward Lewis wrote:
>>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/>
>>

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
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: 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: [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: Edward Lewis <[email-masked]>
Date: Wed, 5 Mar 2003 16:00:58 -0500

Ah.