IETF Logo Mail Archive

[DNSOP] Re: Introducing Relative Label for DNS

Ondřej Surý <ondrej@isc.org> Mon, 22 July 2024 15:33 UTC

Return-Path: <ondrej@isc.org>
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 C45F3C15107A for <dnsop@ietfa.amsl.com>; Mon, 22 Jul 2024 08:33:39 -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=pass (1024-bit key) header.d=isc.org header.b="Szjt5ilD"; dkim=pass (1024-bit key) header.d=isc.org header.b="iE0upuYa"
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 XHwJ44v9H5Zq for <dnsop@ietfa.amsl.com>; Mon, 22 Jul 2024 08:33:36 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.2.50]) (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 15C66C14F602 for <dnsop@ietf.org>; Mon, 22 Jul 2024 08:33:35 -0700 (PDT)
Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.2.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id B4F903AB26F; Mon, 22 Jul 2024 15:33:35 +0000 (UTC)
ARC-Filter: OpenARC Filter v1.0.0 mx.pao1.isc.org B4F903AB26F
Authentication-Results: mx.pao1.isc.org; arc=none smtp.remote-ip=149.20.2.31
ARC-Seal: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1721662415; cv=none; b=PI7tIxNcSqVCJgnyKoVaVPHprWqGkp2meqOqty1Hfi3ajWg3Ep8pY7BFTcoDJIhmqrAVhfFIZ3hRDOAHMZ5wFdUAOWxz+XaybFnw5V5z8hODBQsZ4WseqcuXeBwV96UioHiIMcNOojvlMsO8QARLK7OKTuLRzSveLgAWubVBO+k=
ARC-Message-Signature: i=1; a=rsa-sha256; d=isc.org; s=ostpay; t=1721662415; c=relaxed/relaxed; bh=emrR/kFT0tOaG0r89yqxtlhuCFW83HbzIyN6QSWOwo0=; h=DKIM-Signature:DKIM-Signature:Mime-Version:Subject:From:Date: Message-Id:To; b=a7vFaky+xlxadzcwgL2nkCIPz7Mo5aqYKS0bz20xcuG95Yb8Mh5p8VnKfgELHtymvsDqiUzaOAFQBNWp7pk9y/3x1Dnp9LWpGldbh8POEKK0NFy0dRDdZPrEicJ/kLhsNDxGo4SV3ruurb+a2QMJqt5hVWS/Sr00V7byZ2n2DUg=
ARC-Authentication-Results: i=1; mx.pao1.isc.org
DKIM-Filter: OpenDKIM Filter v2.10.3 mx.pao1.isc.org B4F903AB26F
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1721662415; bh=mlOcUSPagcDNVotOTngV/pCynB4JREP5ksqLMEWjaRw=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=Szjt5ilDw2U+CnYFRBhd4cCYWDzWsMVeuISJURYZDdXWWZk74q0UUKItawR8DiETO Z4Ss1xoHp72Le5i/aYW+ACDOpeWIf6OFCxf3Pj9F7WJPyhk+SolnwbX4rhQFIp9F7/ pZdov9Om7ExTcM+9jY5fsPy/2BbVUlKMFr/0MQB8=
Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id AF3D6E60680; Mon, 22 Jul 2024 15:33:35 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id 882BEE60BBB; Mon, 22 Jul 2024 15:33:35 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org 882BEE60BBB
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1721662415; bh=emrR/kFT0tOaG0r89yqxtlhuCFW83HbzIyN6QSWOwo0=; h=Mime-Version:From:Date:Message-Id:To; b=iE0upuYaBNYtWsQImGdt41gLUR+0BGr7hSbYSoK1tILErMtEqMTSdzOmjtJ3GgpjW 8qpdOVsv8KmMqbHNsTM0Unv4GxlrQmfy1W8QiDlkKSOHjtDRzVqJOpPQVKC6V1U7Ih 2vnXE4Whbs8UmnpQAo6+1Xs+WdkX9/BjMn8Cf+8E=
Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavis, port 10026) with ESMTP id Hev496tKPcYZ; Mon, 22 Jul 2024 15:33:35 +0000 (UTC)
Received: from smtpclient.apple (46-13-206-123.customers.tmcz.cz [46.13.206.123]) by zimbrang.isc.org (Postfix) with ESMTPSA id CBD51E60680; Mon, 22 Jul 2024 15:33:33 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\))
From: Ondřej Surý <ondrej@isc.org>
In-Reply-To: <81C445E0-5C5C-4325-825C-9A9FBCA66F73@strandkip.nl>
Date: Mon, 22 Jul 2024 08:33:17 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <E33C6C7C-D1B4-493F-91BD-EF776E760705@isc.org>
References: <690B1EDE-7DCF-4E33-9688-97295F9D842D@gmail.com> <81C445E0-5C5C-4325-825C-9A9FBCA66F73@strandkip.nl>
To: Joe Abley <jabley@strandkip.nl>
X-Mailer: Apple Mail (2.3774.600.62)
Message-ID-Hash: MJSZYPCPLZ7IXGM4JQAQ5GEJTPHQEG32
X-Message-ID-Hash: MJSZYPCPLZ7IXGM4JQAQ5GEJTPHQEG32
X-MailFrom: ondrej@isc.org
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
CC: Ben van Hartingsveldt <ben.vanhartingsveldt=40yocto.com@dmarc.ietf.org>, dnsop@ietf.org
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/JhsjgGzgrlC7FwhzuGmg7442ub4>
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>

> On 21. 7. 2024, at 16:44, Joe Abley <jabley@strandkip.nl> wrote:
>> I see this as a UI issue.  A (secure) dynamic update client can elect to append the zone name (from that section of the message) where there is no ending dot.  In a zone file, $ORIGIN can be used at will (but doing so for each name would be overkill).
> 
> To be honest the whole idea of relative names feels like it has caused nothing but trouble. I'm not sure why we would want to encourage more of it.

With my DNS implementor hat, I am fully with Joe. This is bad idea, and it solve problem that doesn't exist in the protocol itself. And we should not solve the presentation layer and provisioning layer by modifying the protocol. Sorry, but we need **less** complexity in DNS, not more complexity.

Ondrej
--
Ondřej Surý (He/Him)
ondrej@isc.org

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

v2.37.1 | Report a Bug | By Email | System Status