Hi Peter,
It is a little bit of both, I think. Yes, I use relative labels already
in my own system internally (now as 0xFF, but I'm planning to move to
0x40). It works and it works very well. However, I'm planning to add DNS
UPDATE to my DNS services, so that my customers can use it in their
routers too. When adding DNS UPDATE, I also will allow them to use
relative labels when connecting to my DNS servers. Then, the labels are
not solely internally used anymore, because external users can use them
when adding/updating/deleting records using DNS UPDATE.
If I just randomly pick a relative label byte, say 0x45, and this isn't
standardized, years later somebody standardizes 0x45 for another
purpose, even when many people wrote software for my 0x45, we get very
weird situations. I would like to avoid that, because the web is full
with those non-standardized problems. (E.g. I'm planning to build a DNS
editor that only uses port 53 too).
If I got that right, then I think the proposal might benefit from being
reframed as a draft to aims at assigning this label type, and maybe
simply naming its purpose as "indicating a relative name within a
confined system only". That way, all interop problems go away.
This seems a possible way to go. If I understand correctly, I have to
see "confined system" as just my DNS system. The other ways seems to be
addressing all interop problems. I'm fine with investigating both
options.
Ben
Peter Thomassen schreef op 2024-07-23 08:11:
Hi Ben,
Welcome to DNSOP! :-)
Your proposal reads like you'd like to add relative names to the DNS
protocol. Reading this thread, however, I realize that you'd simply
like to use the 0x40 label type *within the confines of your system*,
and are asking to this added to the DNS Label Types registry [1] so
that your use won't collide with any conflicting future.
So, it seems to be an entirely internal thing, except a reserved label
type would prevent adverse effects in the future.
If I got that right, then I think the proposal might benefit from being
reframed as a draft to aims at assigning this label type, and maybe
simply naming its purpose as "indicating a relative name within a
confined system only". That way, all interop problems go away.
[1]:
https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-10
Best,
Peter
PS: That said, the protocol has no concept of relative names; names are
just 1:1 mappings of nodes in a tree. I get it that one might take
other perspectives, but those are not DNS perspectives. Keeping track
of how the user entered data therefore is not really the DNS's problem;
your storage layer could use some other datastructure "around" the DNS
data to represent that information. -- I wouldn't mind a label type
assignment as described above, though.
On 7/21/24 11:50, Ben van Hartingsveldt 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
--
Like our community service? 💛
Please consider donating at
https://desec.io/
deSEC e.V.
Kyffhäuserstr. 5
10781 Berlin
Germany
Vorstandsvorsitz: Nils Wisiol
Registergericht: AG Berlin (Charlottenburg) VR 37525
_______________________________________________
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
