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 -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
