The draft reads very different than the email message. The draft sticks to a protocol definition while the email describes a use case. This difference is significant.
Reading the draft (no use case assumed), my first question is how “www.subpage” would be encoded (referring to section 4.1’s wire format). Are both labels relative labels or just the final? What if the encoding marks the first label (deepest) as relative and the next as “ordinary”? 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. Where trouble will come is in handling unknown types, see "Handling of Unknown DNS Resource Record (RR) Types” (RFC 3597), specifically section 4 on Domain Name Compression. Prior to that document, there was much confusion of where domain names can be compressed, it was clarified that only the original set of resource records were eligible for compression because those are the only resource records “every server has to know”. (I.e., RFC 1034/1035 are the base, all others are optional add-ons.) 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. 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). Another concern as whether this would bleed into the search string issue - when and where search strings are applied. I think it is best if the server internal representations remain fully qualified (even if not the same as the on-the-wire FQDN), as well as in zone files to avoid any ambiguity. As part of that, I doubt there’s ever been a comprehensive definition of the grammar of zone files - particularly the directives. ($TTL, $ORIGIN, $GENERATE, etc.) which be useful before judging the concept of relative labels. In a binary zone file [which I have not played with], can’t compression of the initial types be done to save space - if needed? Just a passing thought. And - I understand the idea that remembering whether the label was entered “relative” is desirable, but we’ve always had a larger problem with comments. Comments in an original zone file lost once the file is loaded as a zone and then written back to disk (or whatever). Ed > On Jul 21, 2024, at 14:50, Ben van Hartingsveldt > <ben.vanhartingsveldt=40yocto....@dmarc.ietf.org> wrote: > > Dear all, > > In the recent years I started working on my own coded DNS server, because I > was done with the synchronization between BIND and DirectAdmin that broke all > the time. It resulted in a Java server that is running on 4 IPs for some > years now. Because of this, I had to read many RFCs to have it pass tests > like Zonemaster, DNSViz, IntoDNS, etc. While reading and implementing things, > I also came across some shortcomings of DNS. On advice of someone at SIDN, I > will share my draft that I published today. It solves one of the shortcomings > that DNS has in its core: relative domain names. > > I'm talking about > https://datatracker.ietf.org/doc/html/draft-yocto-dns-relative-label-00. This > draft is meant to solve the problem that we cannot use relative domain names > in the DNS system, specificly in DNS UPDATE and in binary zone files. This > also means that this draft is not meant for use with the QUERY opcode (except > for possibly AXFR and IXFR). Let me explain those two usecases. > > 1) DNS UPDATE: In DNS UPDATE it is possible to update the zone using DNS > itself. This can be used in routers when dynamic DNS is wanted, but also in > other situations. Imagine wanting to add an MX record. Using a webinterface, > you are likely able to chooses one of the following four options: > - mail IN MX 10 mx > - mail IN MX 10 mx.example.com. > - mail.example.com. IN MX 10 mx > - mail.example.com. IN MX 10 mx.example.com. > However, using DNS UPDATE you are only able to add the record with fourth > format; both record name and FQDN field have to be absolute. This means that > when I return to the webinterface, I will likely see absolute domain names, > even when I use relative domain names in my other records. My draft wants to > give the client more control over when to use relative and when to use > absolute domain names by adding a new label type. > > 2) Binary Zone Files: Since BIND 9, it is possible to save zones in a binary > format. This is possible to enable/disable using `masterfile-format`. It is > possible to convert the textual format to binary and vice versa. However, > when converting to binary, the zone file will loose the knowledge of knowing > which domain names where absolute and which where relative. This means that > converting the zone back from binary to text will likely give you a zone with > only absolute domain names. As with DNS UPDATE, this is a shortcoming of the > wire format used by DNS. > > That is why I wrote this draft. Like BIND, my own DNS system also uses binary > zone storage and in the future I'm planning to implement DNS UPDATE too. I > also believe my draft is not yet perfect. I'm not a native English speaker > and maybe just format to mention something important. That is why I want you > to give your honest opinion on this topic. Do you agree with the problem? > Does DNS need such label? Did I make a typo? Etc. > > Please let me know. > > Thanks in advance > > Ben van Hartingsveldt > > _______________________________________________ > 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
