Re: [DNSOP] [ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques] Encourage people to add to the underscore label registry (Issue #104)

Paul Wouters <paul.wouters@aiven.io> Tue, 07 November 2023 23:52 UTC

Return-Path: <paul.wouters@aiven.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 8A454C18E1A8 for <dnsop@ietfa.amsl.com>; Tue, 7 Nov 2023 15:52:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.105
X-Spam-Level:
X-Spam-Status: No, score=-2.105 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (1024-bit key) header.d=aiven.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 B5LXOIfLvjGI for <dnsop@ietfa.amsl.com>; Tue, 7 Nov 2023 15:52:42 -0800 (PST)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 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 6B245C18772B for <dnsop@ietf.org>; Tue, 7 Nov 2023 15:52:42 -0800 (PST)
Received: by mail-lf1-x132.google.com with SMTP id 2adb3069b0e04-50970c2115eso3872589e87.1 for <dnsop@ietf.org>; Tue, 07 Nov 2023 15:52:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aiven.io; s=google; t=1699401160; x=1700005960; darn=ietf.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=IwHfXM+xZi6X9k1OB2kjlVfsmQA0VDrcFn+mFsrDpnE=; b=MWs7Cjd2NXTxl2I6uaZh1VY7mu2QnpYXIvvNjVMnfOdG4X29cSraJm7n0uDswBNvUm SBmBxtaEJvt1BTHmr7YFPN4dQg0ioIec7S/iGP4WvOVzvkyy2tcGhGktT5QtlLcvUoV0 wzgDfkX8I85NVBm0Gy4+VfizLtpvi8nrzn4vg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699401160; x=1700005960; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=IwHfXM+xZi6X9k1OB2kjlVfsmQA0VDrcFn+mFsrDpnE=; b=xAhLgNxQOEIzoPJbdEq/NeKjpfssTI5dnTufOccYqlxM7kV6aYT7GHJ/yUg8tyPb9m d8kuL/TJiyuuKHSoVbL4tNGApaBghVPvKCNYp0vJ14Dm4VTnwsjck0CrTYnSRbDfTBHT zC2fQF+FDzrZw6oQP+078iA5kmvdoyrln0T3PjjaomdqFAXikuS2NFUE+TqR7WQi1FRo KQaie+YS18uB4XOehn9fGamwnqYJerV0eQWnalMj5Bar3OKQkT9FN0b7/9q3alS9tIXR hxTW07ZHxppvlqrNahcrOnbKudBO49CxhwIYxWhkyKr0r6b+3rgxGamfn6Kpzq3VwnTw JbZQ==
X-Gm-Message-State: AOJu0YxmTfOqeBcGc9Rp9gZLimHzTqQsQuHo57R5t9r8BD/V15K3/tGP c7f7RDEpiC2GMZXWkhqvO2Q116dM3BL2ZKhHFRza8r7mtUu6Ic0qwwU4ZUHFMltArdyzAO+/cKw GVO87WZgIdfXBgtQuac/y52b7JFtAf5JFzAm7QteOMZK6r93XEmFPaZ1Oop1SiXhn9genbZhS
X-Google-Smtp-Source: AGHT+IHK7vsej1mT/lHw6gGupdK/xnIG00+z2g1qOFVgfYedFsk1reW0EaEyT2tozDiPydcGk7mecg==
X-Received: by 2002:a05:6512:12d5:b0:509:4adb:1dd3 with SMTP id p21-20020a05651212d500b005094adb1dd3mr90101lfg.56.1699401160321; Tue, 07 Nov 2023 15:52:40 -0800 (PST)
Received: from smtpclient.apple (ec2-35-183-0-52.ca-central-1.compute.amazonaws.com. [35.183.0.52]) by smtp.gmail.com with ESMTPSA id i2-20020a056214020200b0067101efa98asm424246qvt.69.2023.11.07.15.52.39 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 07 Nov 2023 15:52:39 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-F4ADECC0-97ED-4A9A-8BFD-D759DC0CE252"
Content-Transfer-Encoding: 7bit
From: Paul Wouters <paul.wouters@aiven.io>
Mime-Version: 1.0 (1.0)
Date: Wed, 08 Nov 2023 00:52:28 +0100
Message-Id: <9728C132-FE50-47B7-94B7-DC432E1EF653@aiven.io>
References: <ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/104@github.com>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
In-Reply-To: <ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques/issues/104@github.com>
To: ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques <reply+AUASQ5XFVYAVXJVHEZHSJNODK6MXPEVBNHHHMH2TUQ@reply.github.com>
X-Mailer: iPhone Mail (21A360)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/VSwFYODtmMCO2tQ3YeaR9vFLeek>
Subject: Re: [DNSOP] [ietf-wg-dnsop/draft-ietf-dnsop-domain-verification-techniques] Encourage people to add to the underscore label registry (Issue #104)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Nov 2023 23:52:46 -0000

On Nov 7, 2023, at 17:34, Erik Nygren <notifications@github.com> wrote:
> 
> As discussed at the mic, we should encourage people add labels to the dns node names registry:
> 
> https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml#underscored-globally-scoped-dns-node-names
> 

So I am one of the Delegated Expert on that registry. So I have some experience with its entries.

There is a use case for people registering names in that registry to avoid clashing. Eg if Company X would have something database like at _db.example.com it would be good not to conflict with Company Y that uses the same record for another type of database service on the same prefix. If both do some service discovery via dns they might make the wrong assumption about the service they are connecting too (eg wrong vendor / product protocol).

But in our use case, there is no real conflict. We are not running a service on these dns names. It’s just the dns lookup itself that has the data.

On top of that, we encourage using known vendor name and service name so that in itself avoids conflicts. Registering these names is extra effort for companies that have no IANA relationship and it will also just pollute the underscore registry with a lot of vendor names. It might cause people to need to talk to lawyers about trademarks.

It might be good to advise the readers to check the underscore registry to avoid collisions, eg for a company that happens to be called dmarc so they can use “_dmarc-llc” or something. But I see no reason to register new entries. Eg what is the value for Aiven to add _aiven there ? The chance of another company called Aiven that also is in tech that also has services they want to validate via an _aiven prefix is about zero. And if it happens, it doesn’t actually matter if there would be two _aiven records at the customer where each one verifies one vendor/service.

Paul