Subject: Re: (Almost final) Agenda for dnsind/dnssec in Oslo

From: [email-masked]
Date: Mon, 28 Jun 1999 12:44:47 +1000

> 	No, as global compression *may* cause case conversion, we
> 	can't use EDNS to say we know about this RR and hence use
> 	global compression unless we also state that all domain
> 	names in RRs that are to be locally compressed MUST be down
> 	cased.  Also there is no definition of exactly how to arrive
> 	at the same bit patten given that you can have a LCP (local
> 	compression pointer) -> LCP -> label.  Also there are cases
> 	where using a LCP will make the resulting wire form larger
> 	than the uncompressed form, do we use LC or not?
	
	I forgot to mention that some of these issues preclude the
	use of master files for the transport of zones between servers
	or even between signing software and servers from different
	vendors (I assuming here that the way LC is done by a vendor
	will be consistent between the server and the signer, this is
	not always a safe assumption).

	Mark
--
Mark Andrews, Internet Software Consortium
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Peter Koch <[email-masked]>
Date: Mon, 28 Jun 1999 16:57:54 +0200

Version -05 of the local compression draft should be announced soon (also at
http://www.TechFak.Uni-Bielefeld.DE/~pk/dns/draft-ietf-dnsind-local-compression-05.txt)

> > 	compression pointer) -> LCP -> label.  Also there are cases

By mandating "optimal" compression and usage of the earliest occurence of
a possible target, pointer chains like above are now implicitly disallowed.

> > 	than the uncompressed form, do we use LC or not?

The only case I see is a terminating zero octet as a compression target.
Section 6 forbids this case. Anything else has at least a one character top
level domain resulting in three octets ('1', <tld>, '0'), which is less than
a pointer. Maybe I missed something?

> 	not always a safe assumption).

Although I believe this can be solved for local compression this item should
be considered in general. In the chain <text format> -> <wire format> --(AXFR)->
<text format> -> <wire format>, which reflects the data path BIND and probably
others use, can one assume that both <wire format> representations are
identical? Is the <wire format> unambiguously derived from the <text format>?
At least for TXT RRs differences may exist, should the input "string" exceed
255 characters.

-Peter

---

From: [email-masked]
Date: Tue, 29 Jun 1999 08:14:41 +1000

> a pointer. Maybe I missed something?

	Bit string labels.

> At least for TXT RRs differences may exist, should the input "string" exceed

	If you have a TXT example where the two wire formats differ it is a
	bug and I would like to see it so it can be fixed.
	Mark

---

From: [email-masked]
Date: Wed, 30 Jun 1999 12:18:16 +1000

> At least for TXT RRs differences may exist, should the input "string" exceed
	These is still the issue that we can't use EDNS to say that we can
	use global compression as the case may change as the result of using
	a global compression pointer.

	Mark