[DNSOP] Re: Introducing Relative Label for DNS

[Ben <[e-mail]>]

Hi Mukund,

Thank you for your response. My reponse is inline:

Mukund Sivaraman schreef op 2024-07-22 09:19:
> 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.
I'm aware that my first draft was little bit confusing, compared to what 
I said in one of my emails. I'm planning to update my draft to address 
those confusions. Also, compression pointer has a totally different 
purpose in my opinion.
> 
> (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.
Noted (again) :D
> 
> (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.
I agree it doesn't have to be needed for everyone. Also, not everything 
always has to be implemented by every software. (I mean, I would like if 
it is the case, but I don't expect all software to have all the relevant 
standards implemented.) In my opinion, this draft is clearly a provided 
way to handle relative domains if people want to, but if the software 
doesn't support it (and it is totally possible some implementers choose 
not to support it), you have to fallback on using absolute domains.
> 
> 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.
It isn't a problem for people that don't need it. I need it, so I see 
problem. It is totally optional to implement this draft, so complexity 
is only for the implementers that want to touch it. Also, I don't think 
it will be more complex than O(n), as far as I know.
> 
> I am sorry to be negative, but please consider the above items.
Don't be sorry. I respect your honest feedback. :D
> 
> 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.
I thought it was BIND-specific, but because everybody loved that zone 
format, it got standardized by a section in RFC 1035.
> 
> 		Mukund
Ben
> 
> _______________________________________________
> DNSOP mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]