[DNSOP] Re: Introducing Relative Label for DNS

[Mukund Sivaraman <[e-mail]>]

Hi Ben

I've read through the draft quickly. While I don't want you to feel
discouraged, I have a negative opinion of this idea.

(a) This draft is a little confusing without making assumptions. It
should clearly mention that the relative labels are for name
representation in DNS messages. The draft also doesn't appear to mention
relative to what other item in the message. We have such a facility
already by means of a name compression pointer.

(b) RFC 2671 is obsolete, and you should read the introduction and
section 5 in RFC 6891 about the practial problems in using extended
label types (and what happened with bit-string labels). Think of the
amount of change in deployed implementations that would be required if
the concept you're proposing has to work.

(c) Given the burden of DNS (and as you are an implementor, you must be
well aware of it), it is also pertinent to ask whether the DNS
absolutely needs a new idea to work or deliver, i.e., can we do without
it? At best, the concept you are proposing is a minor optimization. Name
pointers already compress superdomain names in owner names and names in
RDATA of RFC 1035 types. There's no pressing "need" to avoid the
absolute name.

The draft mentions a "problem", but there is not really a problem. At
most, an implementation has to perform marginally more work with no
change in time or space complexity to generate the absolute names.

I am sorry to be negative, but please consider the above items.

On Mon, Jul 22, 2024 at 08:35:39AM +0000, Ben wrote:
> > In general, what suffix is affixed to a relative label?  In printed zone
> > files, there is the $ORIGIN directive, and dynamic update specifies a
> > zone, but those are part of use cases (and are not the same, not
> > equivalent).  I say not equivalent as dynamic update needs to know what
> > zone to edit, the value isn’t intended the same way $ORIGIN is - in a
> > zone file $ORIGIN may be redefined as desired.
> I think we should not focus to much specificly on how BIND handles things
> with $ORIGIN. I'm talking about the concept of zones in general. For

$ORIGIN is from RFC 1035, for any implementation that supports master
files. It is not a BIND-specific item.

		Mukund