[DNSOP] Re: Introducing Relative Label for DNS
Peter Thomassen <peter@desec.io> Tue, 23 July 2024 08:11 UTC
Return-Path: <peter@desec.io>
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 D7BDEC14F61E; Tue, 23 Jul 2024 01:11:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.107
X-Spam-Level:
X-Spam-Status: No, score=-2.107 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=desec.io
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 tGeIcBI7DM4u; Tue, 23 Jul 2024 01:11:33 -0700 (PDT)
Received: from mail.a4a.de (mail.a4a.de [IPv6:2a01:4f8:10a:1d5c:8000::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC8F7C14F5E7; Tue, 23 Jul 2024 01:11:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=desec.io; s=20170825; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=xM9Our9HLLhjq2STGpqbqgpThp758Uhq54PKuhq2yzk=; b=k9IcteIJ/C8+5OBA8aa1aVBtYT 2AnW8xIZacFkFOA1/io8IWn/bRMjMi0m2z/oLkv9WaeeUZsduNgnBn2+tHxAiP8SGYeXpHLRT8ZY2 6OyNGZ/BCbIdVrVHcigyFUgo5RYUESrpsnzjHBs8ftuPDke5wqbL5aSz2nXPfdld88HRPA8QjKsIG 6r8uFIL6+YXvV45xuxMOr5KfBkpm5LeG5vNfc0qY31YrSIy7+2dn6cVBL+Tak91WIx/0x1Z1n4LIJ Z6qYvYB7TFsZrVKhcJM19+S5pjLueO9IamPPNcw+FzXA3HkI7K8GWta9m0n21bqEpAPLmSBjEp31i n+rDn4og==;
Received: from [69.196.93.126] (helo=[10.100.0.240]) by mail.a4a.de with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.93) (envelope-from <peter@desec.io>) id 1sWAcM-009fB5-E3; Tue, 23 Jul 2024 10:11:31 +0200
Message-ID: <080e6020-c54a-482b-bdcb-b46ee9efd109@desec.io>
Date: Tue, 23 Jul 2024 01:11:17 -0700
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: Ben van Hartingsveldt <ben.vanhartingsveldt=40yocto.com@dmarc.ietf.org>, dnsop@ietf.org
References: <32cb827b0875605f8fbf47ccae1d4a9c@yocto.com>
Content-Language: en-US
From: Peter Thomassen <peter@desec.io>
In-Reply-To: <32cb827b0875605f8fbf47ccae1d4a9c@yocto.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Message-ID-Hash: GPDANU4ZJT3SVCODXPDANHTTDXYQWRTD
X-Message-ID-Hash: GPDANU4ZJT3SVCODXPDANHTTDXYQWRTD
X-MailFrom: peter@desec.io
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/Ec_tkcqhBzKHDAtwR8JVuK_NSDw>
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>
Hi Ben, Welcome to DNSOP! :-) Your proposal reads like you'd like to add relative names to the DNS protocol. Reading this thread, however, I realize that you'd simply like to use the 0x40 label type *within the confines of your system*, and are asking to this added to the DNS Label Types registry [1] so that your use won't collide with any conflicting future. So, it seems to be an entirely internal thing, except a reserved label type would prevent adverse effects in the future. If I got that right, then I think the proposal might benefit from being reframed as a draft to aims at assigning this label type, and maybe simply naming its purpose as "indicating a relative name within a confined system only". That way, all interop problems go away. [1]: https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#dns-parameters-10 Best, Peter PS: That said, the protocol has no concept of relative names; names are just 1:1 mappings of nodes in a tree. I get it that one might take other perspectives, but those are not DNS perspectives. Keeping track of how the user entered data therefore is not really the DNS's problem; your storage layer could use some other datastructure "around" the DNS data to represent that information. -- I wouldn't mind a label type assignment as described above, though. On 7/21/24 11:50, Ben van Hartingsveldt 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-leave@ietf.org -- Like our community service? 💛 Please consider donating at https://desec.io/ deSEC e.V. Kyffhäuserstr. 5 10781 Berlin Germany Vorstandsvorsitz: Nils Wisiol Registergericht: AG Berlin (Charlottenburg) VR 37525
- [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