[DNSOP] Introducing Relative Label for DNS

Ben van Hartingsveldt <ben.vanhartingsveldt@yocto.com> Sun, 21 July 2024 18:50 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 C4D2AC14F738 for <dnsop@ietfa.amsl.com>; Sun, 21 Jul 2024 11:50:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_HELO_TEMPERROR=0.01, URIBL_BLOCKED=0.001, 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 NNIOzH50zigg for <dnsop@ietfa.amsl.com>; Sun, 21 Jul 2024 11:50:27 -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 RSA-PSS (2048 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E94EDC14F699 for <dnsop@ietf.org>; Sun, 21 Jul 2024 11:50:26 -0700 (PDT)
MIME-Version: 1.0
Authentication-Results: mx2.yocto.eu; auth=pass smtp.mailfrom=ben.vanhartingsveldt@yocto.com
Date: Sun, 21 Jul 2024 18:50:23 +0000
From: Ben van Hartingsveldt <ben.vanhartingsveldt@yocto.com>
To: dnsop@ietf.org
Message-ID: <32cb827b0875605f8fbf47ccae1d4a9c@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: OTEU24BTFHNWGL5ZLVU4VCUZOBHOOKVG
X-Message-ID-Hash: OTEU24BTFHNWGL5ZLVU4VCUZOBHOOKVG
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] Introducing Relative Label for DNS
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jvZ1pLWBjmdVpecfzPE38WA9las>
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,

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