[prev in list] [next in list] [prev in thread] [next in thread] 

List:       namedroppers
Subject:    Re: name compression in new records
From:       gson () ARANEUS ! FI (Andreas Gustafsson)
Date:       1997-09-10 15:36:03
[Download RAW message or body]

John Gilmore <gnu@toad.com> said:
> I agree that we should solve this issue.
> Here are some ideas that I wrote up a few weeks ago.

I have the following comments:

> Standardizing a way to solve the compression problem is better than
> the generalized approach of fetching information about each RR type by
> using the DNS protocol itself (the so-called "RR RR"), because it
> would make each DNS response (or zone transfer) self-describing with
> respect to compression.  Under the RR RR (as I understand it), if you
> get a DNS response containing an RR type that you don't understand,
> you must make additional queries before you can properly parse the
> original response.

I fully agree with you that this mythical "RR RR" is not a good
solution.  My main problem with it is that it would require every name
server to contain (and use) a full resolver; this is quite contrary to
the design of the DNS as per RFC103[45].  Just because BIND is a huge,
monolithic server/resolver combo does not mean we should force every
name server to adopt the same bad design.

As Mark Andrews so eloquently put it, "resolvers ask questions,
servers answer them, full stop."  The "RR RR" would require all
servers to ask questions, and to wait for their replies, making it
much less likely that they do their actual job of answering questions
in a timely and reliable manner.

> I am currently juggling four ideas for how to best express this.
> More ideas, or reasons to throw away some of these, are welcome.
> 
> Idea #1:
> 
> All domain names in new RDATA fields will begin at the beginning of
> the RDATA field.  Zero, one, or more domain names may appear there.
> After all the domain names, either the RDATA field will end, or a byte
> containing zero will appear.  Arbitrary data may follow this zero
> byte.

The root domain "." is represented as a single byte of zero, making it
indistinguishable from your proposed end marker.

This could be made to work in a rather perverse way (which I am by no
means actually proposing): by adding the requirement that "any
occurrence of the root domain '.'  before the terminating zero byte
MUST be compressed".  Occurrences of the root within RDATA can always
be compressed (e.g., by pointing at the terminating zero byte of the
owner name), but this "compressed" root will use two bytes where the
uncompressed root used a single byte.  Of course, this fix would be
somewhat contrary to the principle that compression is optional,
as well as to the idea that compression should actually reduce the
size of the data :-).

An alternative fix would be to use an end marker byte whose two most
significant bits have one of the reserved values 01 or 10.

A third solution (which would be my preferred one) is to use not
a terminating byte, but a prefix byte specifying the number of domain
names that follow (0 to 255).  This is not at all unlike the status
byte values 00 and 81-8F of your Idea #3.

> Idea #2:
> 
> The code space for new RRtypes is hereby partitioned.  RRtypes whose
> low-order bit is zero contain no domain names.  RRtypes whose low-order
> bit is one follow Idea #1 or Idea #3.

Why, to save a single byte for those RRs that contain no domain names?
I don't think that's worth the trouble.

> Idea #3:
> 
> RDATA fields in all new RR types will begin with a compression status byte.
> This byte will take the following values:
> 
> 	00	 - no domain names to compress in this RR
> 	01-3F	 - offset from the start of the RDATA field to
> 		   the sole domain name in the RDATA field
> 	40	 - reserved
> 	41-7F	 - offset (biased by 0x40) from the start of the RDATA field to
> 		   multiple domain names in the RDATA field, which continue
> 		   to the end of the RDATA
> 	80	 - reserved
> 	81-8F	 - one to fifteen domain names exist at the start of this
> 	           RDATA, just after the compression status byte
> 	90-FF	 - reserved
>
> This encoding could represent the compression state of all currently
> supported RR types except NAPTR.

I think this is overly complicated.  These mechanisms are only to be
used with new RR types, so there is no need to support all the domain
name placements that have occurred in the past.  We can easily impose
the restriction that all domain names occur at the beginning of the
RDATA (they may occur elsewhere, too, but then they cannot be
compressed).

> Note: This information need not necessarily appear in every rr!  

You lost me here.  I thought you wanted to avoid making separate
queries a la the "RR RR"?

> Idea #4:
> 
> CLASS byte reused for a flag?

This would be a pretty big change, and I don't quite see how this
could be made to interoperate with existing implementations.  By the
way, it's two bytes, not one.

To summarize, I think Idea #1 with a one-byte prefix count may be the
way to go (given that we can't seem to agree on the simplest possible
scheme, that of not compressing new RRs at all).

Regardless of which exact encoding scheme ends up being used for these
"new" RRs (whether it is one of yours, the trivial encoding scheme of
"no compression", Peter Koch's "local compression", the historical
encoding proposal of RFC973, or some other scheme not yet invented),
there remains the problem of how a name server determines whether a
particular RR is to be considered "new" or not.  This is the problem
I'm trying to solve by saying that we should allocate a separate range
of RR type numbers for the RRs using the new encoding - no matter what
that encoding is.
-- 
Andreas Gustafsson, gson@araneus.fi

[prev in list] [next in list] [prev in thread] [next in thread]