[DNSOP] Re: Introducing Relative Label for DNS

[Ben van Hartingsveldt <[e-mail]>]

Hi Alexander,

Thank you for your response.

- The DNS UPDATE RFC redefines the question section as the zone section. 
This means that the DNS server already doesn't extract the target zone 
from the record name, but from the zone section. A relative record 
should therefore be added to the zone mentioned in the zone section.
- The label indicator only can appear in the end, so 
"selector._domainkey[relative-label-here]". The zone name has to be 
known from context, but that is the case for DNS UPDATE (zone section) 
and also for binary zone file (file name and file header).
- It is not about if a program can or cannot make a FQDN of something 
relative. It is about the control of the user using that program to be 
able to choose if a record is added with relative/absolute domain names.

I'm aware of that section, but because the label isn't used with QUERY 
opcodes (except for maybe AXFR and IXFR), I don't see a big problem 
implementing it. Maybe there could be a way to let the client know that 
the server has support for it or introduce some new error.

I will update the references to RFC 2065 and RFC 2671 in the next 
version.

Ben

Alexander Robohm schreef op 2024-07-21 19:17:
> Hi,
> 
> I have read your draft and have a few questions:
> - How does the server receiving the UPDATE decide where too put it? The
>   draft, AFAICT, doesn't specify what domain should be appended to the
>   relative label to fully qualify it.
> - How are multi-label relative names handled? (say selector._domainkey)
> - Is this really necessary when the software generating the UPDATEs can
>   fully qualify the names for you?
> 
> For the last point, consider section 5 of RFC 6891:
>    Extended label types are extremely difficult to deploy due to lack 
> of
>    support in clients and intermediate gateways, as described in
>    [RFC3363], which moved [RFC2673] to Experimental status; and
>    [RFC3364], which describes the pros and cons.  As such, proposals
>    that contemplate extended labels SHOULD weigh this deployment cost
>    against the possibility of implementing functionality in other ways.
> 
> You should also check your citations - [RFC2671] links to RFC 2119, and
> RFC 2065 was obsoleted in 1999.
> 
> Alexander Robohm
> 
> 
> Am 21.07.2024 um 20:50 schrieb Ben van Hartingsveldt:
>> 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 -- [e-mail]
>> To unsubscribe send an email to [e-mail]
> 
> _______________________________________________
> DNSOP mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]