[DNSOP] Re: Introducing Relative Label for DNS
Ben van Hartingsveldt <ben.vanhartingsveldt@yocto.com> Tue, 23 July 2024 08:56 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 9B97FC1DFD24 for <dnsop@ietfa.amsl.com>; Tue, 23 Jul 2024 01:56:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 b0mF0Ba2SqEU for <dnsop@ietfa.amsl.com>; Tue, 23 Jul 2024 01:56:25 -0700 (PDT)
Received: from mx2.yocto.eu (ns2.yoctodns.com [136.144.225.232]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DECEC151066 for <dnsop@ietf.org>; Tue, 23 Jul 2024 01:56:24 -0700 (PDT)
MIME-Version: 1.0
Authentication-Results: mx2.yocto.eu; auth=pass smtp.mailfrom=ben.vanhartingsveldt@yocto.com
Date: Tue, 23 Jul 2024 08:56:21 +0000
From: Ben van Hartingsveldt <ben.vanhartingsveldt@yocto.com>
To: dnsop@ietf.org
In-Reply-To: <32cb827b0875605f8fbf47ccae1d4a9c@yocto.com>
References: <32cb827b0875605f8fbf47ccae1d4a9c@yocto.com>
Message-ID: <820cf87253842916310c789e92e71129@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: H2IWMK64RO57RNHESI4LZUKI4EG4RQ2J
X-Message-ID-Hash: H2IWMK64RO57RNHESI4LZUKI4EG4RQ2J
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/WNvyq0SzqN4G5t7SE_IphS9ZybM>
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, 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] Introducing Relative Label for DNS Ben van Hartingsveldt
- [DNSOP] Re: Introducing Relative Label for DNS Alexander Robohm
- [DNSOP] Re: Introducing Relative Label for DNS Ben
- [DNSOP] Re: Introducing Relative Label for DNS Ben
- [DNSOP] Re: Introducing Relative Label for DNS Mukund Sivaraman
- [DNSOP] Re: Introducing Relative Label for DNS Mukund Sivaraman
- [DNSOP] Re: Introducing Relative Label for DNS Ben van Hartingsveldt
- [DNSOP] Re: Introducing Relative Label for DNS Alexander Robohm
- [DNSOP] Re: Introducing Relative Label for DNS Ben van Hartingsveldt
- [DNSOP] Re: Introducing Relative Label for DNS Edward Lewis
- [DNSOP] Re: Introducing Relative Label for DNS Joe Abley
- [DNSOP] Re: Introducing Relative Label for DNS Ondřej Surý
- [DNSOP] Re: Introducing Relative Label for DNS Tim Wicinski
- [DNSOP] Re: Introducing Relative Label for DNS Ben
- [DNSOP] Re: Introducing Relative Label for DNS Peter Thomassen
- [DNSOP] Re: Introducing Relative Label for DNS Ben van Hartingsveldt
- [DNSOP] Re: Introducing Relative Label for DNS Ben van Hartingsveldt
- [DNSOP] Re: Introducing Relative Label for DNS Ben van Hartingsveldt
- [DNSOP] Re: Introducing Relative Label for DNS Mark Andrews
- [DNSOP] Re: Introducing Relative Label for DNS Peter Thomassen
- [DNSOP] Re: Introducing Relative Label for DNS Ben van Hartingsveldt
- [DNSOP] Re: Introducing Relative Label for DNS Q Misell
- [DNSOP] Re: Introducing Relative Label for DNS Ben van Hartingsveldt