This is not needed. Additionally when answers are returned the zone is not
known.
This is true of both stub resolvers and non validating recursive resolvers.
As for your MX example one could use existing DNS compression mechanisms on the
wire and when storing the record if desired by using an offset into the owner
name
of the record. For unknown record types one would also have to record the
original
case of the owner name and this is also desirable to known types. None of this
however requires a RFC to do. This is not worth it for saving a few bytes in a
DNS message.
e.g. storage
MX
<07>example<03>com<00> 0<02>mx<c000><13-bits-of-upper-case-flags>
some other now defined type that the server knows
<07>example<03>com<00>
<start-of-rdata><09>example01<c000><13-bits-of-upper-case-flags><rest-of-rdata>
We do something similar in BIND for case preservation of owner names. The
data is all in lower case and we restore the upper case before doing case
sensitive DNS name compression on the answer.
As for using the new label in UPDATE you would need to know that the server
supports the label type. Remember for types that it knows about it will be
decoding the name to prevent garbage being inserted.
Mark
> On 26 Jul 2024, at 02:07, Ben van Hartingsveldt
> <ben.vanhartingsveldt=40yocto....@dmarc.ietf.org> wrote:
>
> Dear all,
>
> Today, I released a new version of the draft:
> https://datatracker.ietf.org/doc/html/draft-yocto-dns-relative-label-02. I
> replaced the term "record" with "resource record", updated the reference to
> the EDNS RFC, and added an Acknowledgements section.
>
> @Peter Thomassen: Is it possible to make some list with all interop problems
> for this draft? With such list, I can look for ways to address them; or that
> I conclude to reframe the draft to be for confined systems only.
>
> Ben
>
> Ben van Hartingsveldt schreef op 2024-07-23 08:56:
>> Dear all,
>> Today, I released a new version of the draft:
>> https://datatracker.ietf.org/doc/html/draft-yocto-dns-relative-label-01. I
>> tried to clarify things a little bit more, added some examples and fixed
>> some references.
>> Ben
>> Ben van Hartingsveldt schreef op 2024-07-21 18:50:
>>> 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
>
> _______________________________________________
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-le...@ietf.org
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
