[DNSOP] Re: Introducing Relative Label for DNS

Alexander Robohm <ar@arobohm.de> Sun, 21 July 2024 21:44 UTC

Return-Path: <ar@arobohm.de>
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 EFE61C1840C6 for <dnsop@ietfa.amsl.com>; Sun, 21 Jul 2024 14:44:40 -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_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, 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=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=arobohm.de header.b="v4PInQ+U"; dkim=pass (2048-bit key) header.d=arobohm.de header.b="Syff+Xu7"
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 JYAdrBjt_qDc for <dnsop@ietfa.amsl.com>; Sun, 21 Jul 2024 14:44:35 -0700 (PDT)
Received: from mx.arobohm.de (mx.arobohm.de [85.235.66.77]) (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 BB393C1840DC for <dnsop@ietf.org>; Sun, 21 Jul 2024 14:44:34 -0700 (PDT)
Message-ID: <ae593c42-9ed1-4772-ab35-815e6e2f0676@arobohm.de>
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=arobohm.de; s=202405e; t=1721598271; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DegqCD+IkSUBGyQO5UUMQql3bRO9uOZ6UEUXbFB4ZlU=; b=v4PInQ+UpxTDLIMSfDLr9L4drZk5JTJ1RyY3R66gUkkdF7Ty9enOHK1OkgOmb/RIckgDrS 5EYSLlY7pSvHHDBA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=arobohm.de; s=202405r; t=1721598271; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DegqCD+IkSUBGyQO5UUMQql3bRO9uOZ6UEUXbFB4ZlU=; b=Syff+Xu7GTlkq5aWwwHJZvhu2uXVQI8dEOdou9M0uC5HGtpKiQM0fE2vFbYvMFqne3MHvC PSY8EWewK29Tih/tg6uETJ4UC/QJyfZ8URQQGlrTHoQd42B4aUksgah5x051y6wcBXgI7g ashTb4IefLwERtlRHFS/RCoRoQZLvCevXpRwXzqY8KpaCFLYN1foPJzlOPsRRzOtkTeG+1 C6W5kSGWROXapaA3mgfyDKFCHIqtOhKHUS97wLbZpTSc2padIn70jbRiTkpmyTiJWEnGXX GlUEZzGO+zBnXdNoj1o4M6QKW/8EGp5ScMj7i1q748aovsS+cMrL/f6vj/HQMw==
Authentication-Results: ORIGINATING; auth=pass smtp.auth=ar@arobohm.de smtp.mailfrom=ar@arobohm.de
ARC-Seal: i=1; s=202405r; d=arobohm.de; t=1721598271; a=rsa-sha256; cv=none; b=Ecwtn98L9rJyCEV78E6dBiZ51BCvXDJaL2yAmKvd3vBpd1p9AQ8wUT7uBArrgyIYbMTVSS Y8KGUW4b30FN+bdJV0fdqyqZgnmSkIS3cYqoG1UC7uykwDOEX6vpPoYA7zzQrXtNWcaXlO Ip/wRruOzdrjKys0aUggYSZmGJoZ4F1ElOkpkmbwvwQJqBtmMEUEHGARTCXYShTfkrlC3H k+nLZIx0jUmHdxJTSYtfexpYOsChQwLP5fefzV++JyEVHuAHa0HHNg5+D3ocJtln9kt6rG Qy3VNqn6IS2KRBUeVnOQbEGGELaW5YaonIk2K06YuxdiYzKyOMwYP5daIM7G/Q==
ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=ar@arobohm.de smtp.mailfrom=ar@arobohm.de
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=arobohm.de; s=202405r; t=1721598271; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DegqCD+IkSUBGyQO5UUMQql3bRO9uOZ6UEUXbFB4ZlU=; b=amJkbG8XK3dNL0OooIJr/8Ad7Z89YHzSn+T2vBDlD06p2mfoaDS6cXCiaXBS/KRSfx18uu sJjPK3dmiIr0wwn2LH6/MZh3x7FcNkKHsOFFU8AQJcc+k7TjDEkybSaxLSRC1O056KOajB StjR2Al9HR0/ZczKlbcp1FRe16zEH0ycEwPak903NZGyJ4DOdoFlTkaYnPRs52hf3KgdsK iL+rb7vF81Rmm5++fuaIghVSbDEnbuDU4BrEqo5PD0otiYiP8GzkUHwLtigHVOfqsqpJ9E hdMf2gG1AAHjXAptGjPGFrhoJW4/oZh0V8+41CM9g28vJfhA/TREHBaNquEVNQ==
Date: Sun, 21 Jul 2024 23:44:28 +0200
MIME-Version: 1.0
To: dnsop@ietf.org, ben.vanhartingsveldt@yocto.com
References: <32cb827b0875605f8fbf47ccae1d4a9c@yocto.com> <af442a04-dfc4-4c6d-9aff-b3ffae56131f@arobohm.de> <72aa8b25fb4e9c3ca644361544264325@yocto.com>
Content-Language: de-DE
From: Alexander Robohm <ar@arobohm.de>
In-Reply-To: <72aa8b25fb4e9c3ca644361544264325@yocto.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Message-ID-Hash: T6K2TND36YDOLI6MJMKQID4PCXHUCI7F
X-Message-ID-Hash: T6K2TND36YDOLI6MJMKQID4PCXHUCI7F
X-MailFrom: ar@arobohm.de
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/nzjqtuWFzLIETBysabkvVt3DB34>
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,

> - 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.

> - 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.

Alexander