[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