Joe Abley schreef op 2024-07-21 23:44:
On 21 Jul 2024, at 15:54, Edward Lewis <eppdnsprotoc...@gmail.com>
wrote:
I don’t think there’s any good to come from shrinking an in-memory
size of the zone this way. Saving space, sure, but I don’t think the
cost in code complexity will favorable.
This sounds right to me.
Oh, I just now see the "in-memory" word in this citation. Yeah, I don't
say a DNS server has to keep the \x40 in memory. It may replace all
\x40's directly before loading it into memory. It is the same in my
system. In the database everything is stored with or without \x40, but
everything is converted to absolute when loaded into the memory of the
DNS server.
I see this as a UI issue. A (secure) dynamic update client can elect
to append the zone name (from that section of the message) where there
is no ending dot. In a zone file, $ORIGIN can be used at will (but
doing so for each name would be overkill).
To be honest the whole idea of relative names feels like it has caused
nothing but trouble. I'm not sure why we would want to encourage more
of it.
Extended labels aren't used by everyone. Mostly, because almost none of
them are defined, or the one that was defined, Binary Labels, was
deprecated. I definitely will use relative labels, as I already use them
now, but I want to do this in a standardized way. If \x40 is registered,
I will use \x40. If I use it and it will be registered by somebody else
for another purpose, my system is not compliant anymore. I'm okay with
adding more sections to the draft that tell considerations for using
this label. For example, software that supports it, can always use it in
record names, because record names don't have anything to do with record
types. For record data, like compression we can allow it for all types
in RFC 1035 and think about how to handle it with unknown types or types
outside RFC 1035.
After all, I still think we have to add this label. If that means I
should add some "Don't use this label, except when you totally know what
you are doing.", sure.
Joe
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
