[DNSOP] Re: Introducing Relative Label for DNS

Ben van Hartingsveldt <ben.vanhartingsveldt@yocto.com> Thu, 15 August 2024 16:03 UTC

Return-Path: <ben.vanhartingsveldt@yocto.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753D2C1519BB for <dnsop@ietfa.amsl.com>; Thu, 15 Aug 2024 09:03:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L-Zg8S8618OQ for <dnsop@ietfa.amsl.com>; Thu, 15 Aug 2024 09:03:25 -0700 (PDT)
Received: from mx2.yocto.eu (ns2.yoctodns.com [IPv6:2a01:7c8:d004:18d::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 529ADC1519BA for <dnsop@ietf.org>; Thu, 15 Aug 2024 09:03:23 -0700 (PDT)
MIME-Version: 1.0
Authentication-Results: mx2.yocto.eu; auth=pass smtp.mailfrom=ben.vanhartingsveldt@yocto.com
Date: Thu, 15 Aug 2024 16:03:07 +0000
From: Ben van Hartingsveldt <ben.vanhartingsveldt@yocto.com>
To: dnsop@ietf.org
In-Reply-To: <6098004d16486aec62112a2bb47ea3e6@yocto.com>
References: <32cb827b0875605f8fbf47ccae1d4a9c@yocto.com> <820cf87253842916310c789e92e71129@yocto.com> <6098004d16486aec62112a2bb47ea3e6@yocto.com>
Message-ID: <c8f66a76a03057ed3f1d1e09fdaa9330@yocto.com>
X-Sender: ben.vanhartingsveldt@yocto.com
Organization: Yocto
Content-Type: text/plain; charset="US-ASCII"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Spamd-Bar: ---
Message-ID-Hash: PYTE7YPZNTVXVPX3J24AQKZ6JNPAFEWT
X-Message-ID-Hash: PYTE7YPZNTVXVPX3J24AQKZ6JNPAFEWT
X-MailFrom: ben.vanhartingsveldt@yocto.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-dnsop.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [DNSOP] Re: Introducing Relative Label for DNS
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/IwJVZ7TPi_2IYGk1jX0rkTnJH18>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Owner: <mailto:dnsop-owner@ietf.org>
List-Post: <mailto:dnsop@ietf.org>
List-Subscribe: <mailto:dnsop-join@ietf.org>
List-Unsubscribe: <mailto:dnsop-leave@ietf.org>

Dear all,

Thanks for the responses I received. I got some useful feedback that 
helped me improve the drafts.

As Peter Thomassen already mentioned earlier, I was talking about a 
label type mainly for confined systems only. Except for some small 
exceptions, a record will never leave the DNS server in its relative 
form. This means that introducing it will not break current DNS, because 
the label type is only used in systems that want to use it, and systems 
should not expect other systems to support it too, so I'm really talking 
about confined systems here. I wanted to clarify that, because I didn't 
yet use that word in my drafts and there seemed some confusion about it.

After all, I still hope I succeed in registering the label at IANA. I 
still think there is usecase for it. At least, I will use it in my 
confined systems, but some others might too. However, the registration 
procedure at IANA for this registry is "Standards Action", so it seems 
to me that the IESG has to approve it too, else I would have gone for 
independent submission.

Also, when I create a new draft that adds the word "confined" to the 
text, what other things should I add, change or remove in order to 
improve it? Because some interpreted my draft differently, are there 
some texts I wasn't fully clear? Please let me know.

Thanks in advance

Ben

Ben van Hartingsveldt schreef op 2024-07-26 09:07:
> 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-leave@ietf.org
>> 
>> _______________________________________________
>> DNSOP mailing list -- dnsop@ietf.org
>> To unsubscribe send an email to dnsop-leave@ietf.org
> 
> _______________________________________________
> DNSOP mailing list -- dnsop@ietf.org
> To unsubscribe send an email to dnsop-leave@ietf.org