[DNSOP] Re: Introducing Relative Label for DNS
Ben van Hartingsveldt <ben.vanhartingsveldt@yocto.com> Sun, 21 July 2024 22:34 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 C8DF1C14F61C for <dnsop@ietfa.amsl.com>; Sun, 21 Jul 2024 15:34:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level:
X-Spam-Status: No, score=-1.909 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] 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 DKw3lJ_14y1Q for <dnsop@ietfa.amsl.com>; Sun, 21 Jul 2024 15:34:18 -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) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A69B4C14F60B for <dnsop@ietf.org>; Sun, 21 Jul 2024 15:34:16 -0700 (PDT)
MIME-Version: 1.0
Authentication-Results: mx2.yocto.eu; auth=pass smtp.mailfrom=ben.vanhartingsveldt@yocto.com
Date: Sun, 21 Jul 2024 22:34:14 +0000
From: Ben van Hartingsveldt <ben.vanhartingsveldt@yocto.com>
To: dnsop@ietf.org
In-Reply-To: <ae593c42-9ed1-4772-ab35-815e6e2f0676@arobohm.de>
References: <32cb827b0875605f8fbf47ccae1d4a9c@yocto.com> <af442a04-dfc4-4c6d-9aff-b3ffae56131f@arobohm.de> <72aa8b25fb4e9c3ca644361544264325@yocto.com> <ae593c42-9ed1-4772-ab35-815e6e2f0676@arobohm.de>
Message-ID: <fe0bb6d5651ad6d1d26529248bc9f110@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: QWFE3J36ZK46OWKCRSHXZ2PEIRBQNYIM
X-Message-ID-Hash: QWFE3J36ZK46OWKCRSHXZ2PEIRBQNYIM
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/NK4Y9hCUt1ngrW1PYqTZqGNTjc8>
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 Alexander, My response is also inline: Alexander Robohm schreef op 2024-07-21 21:44: > Hi Ben, > >> - 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). > This should be made explicit. Maybe the whole draft could be something > like "Relative Names for DNS UPDATE", and precisely define a mechanism > for this particular purpose, including the new label type. Section 4 already describes that the label can only appear in the end of the FQDN, but I think it is good to add some examples to make it more clear. I don't agree on naming the whole draft to something like "Relative Names for DNS UPDATE", because the label can be used much broader than only DNS UPDATE. > >> - 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. > Overall, IMHO, this is a UI issue in the panel you are using to manage > your zones, and not something that needs to be implemented in the DNS > itself. You can already have relative names in presentation format by > not including the trailing '.', and you can store zones in any format > you want. On the wire, this just does the job of a pointer in 1 less > octet. Yes, but this is exactly the problem. In representation format is it possible, but not in wire format. Using this relative label (0x40) is actually the same as removing that dot. Note that it is different compared to compression, because compression has another goal. Let me add an example already: - `www.example.com.` <--> `\x03www\x07example\x03com\x00` - `www` <--> `\x03www\x40` Like the missing end dot in the representation format, in the wire format the \x40 byte indicates the domain name being relative. And like the representation format, you only can know the FQDN if you know in which zone this record is. A relative domain name, without a zone name to make it absolute, is useless. However, DNS UPDATE and BIND's raw binary zone files (as well as the text format) always provide this zone name, so there is no problem using relative domain names in those two cases. > > Alexander Ben > > _______________________________________________ > 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