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

Reply via email to