Hi Edward,
My response inline:
Edward Lewis schreef op 2024-07-21 22:53:
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.
Wow, that should not be the case. I tried not to mention BIND in the
draft, because I think RFCs should written as neutral as possible, but
that could have caused the draft not to be as clear as should be.
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”?
As I mentioned earlier, section 4 says that the label can only appear in
the end. I assume (and maybe I assume incorrectly) that the readers then
understand how it works.
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.
I think we should not focus to much specificly on how BIND handles
things with $ORIGIN. I'm talking about the concept of zones in general.
For example, the DNS data in my own database is two tables, a "zones"
table and a "records" table. The zones have a "name" column, e.g.
"example.com". The records have a "zone_id" column to tell which zone
they belong to. If a record has a relative name (or "@"), or has data
with a relative domain (e.g. MX record "\x00\x0A\x02mx\x40"), my system
converts it to an absolute link when this data is pushed to the DNS
server. However, the relativeness of the DNS data is preserved in the
database, as my DNS users want too.
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.)
Compression has compression as its goal. Relative label has preserving
relativeness as its goal. Those goals are not the same. Compression may
be seen in a QUERY response. For relative labels, this should be
avoided, so preprocessing of records is advised. I agree there could be
some trouble with unknown types, but because my system only accepts
supported types at the moment, I don't see a problem there. However, I
will think about this a little bit more.
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.
No, I don't think so, because compression has its goal to compress UDP,
not make the storage smaller. Also, a binary zone file has a different
format than the DNS message, so label pointers in zone files will
definitely have other offsets than label pointers in DNS messages.
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
Ben
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
_______________________________________________
DNSOP mailing list -- dnsop@ietf.org
To unsubscribe send an email to dnsop-le...@ietf.org
