Re: [DNSOP] draft-schanzen-gns and draft-ietf-dns-alt-tld

Martin Schanzenbach <mschanzenbach@posteo.de> Tue, 02 August 2022 11:53 UTC

Return-Path: <mschanzenbach@posteo.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 F0AC3C14CF09 for <dnsop@ietfa.amsl.com>; Tue, 2 Aug 2022 04:53:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.107
X-Spam-Level:
X-Spam-Status: No, score=-7.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_DNSWL_HI=-5, SPF_HELO_NONE=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 (2048-bit key) header.d=posteo.de
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 kGQaS2feN50t for <dnsop@ietfa.amsl.com>; Tue, 2 Aug 2022 04:53:53 -0700 (PDT)
Received: from mout01.posteo.de (mout01.posteo.de [185.67.36.65]) (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 4C7F3C14CF06 for <dnsop@ietf.org>; Tue, 2 Aug 2022 04:53:52 -0700 (PDT)
Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 7BD49240026 for <dnsop@ietf.org>; Tue, 2 Aug 2022 13:53:48 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.de; s=2017; t=1659441228; bh=rhIFNBvvqZ78xjJOKCLWdT/v0GXSbwWzwuKyp/Yxm6w=; h=From:To:Subject:Date:From; b=aAMA1PNxZrioGMc5npA81WRIhvqi4vzmBZ/6/WwukUli+CEzpAkWxpHe2r7ObT4JM crAFamyDoiiHOAp3EfuoODPYPZgENJS+2guDEmgsbBp+2iqNllok8VbeClky+pVEfj DFn3M5s26sJwUgsWiiq6Akl8+wQO+5whj5EFVkNxVYyfykk7hBR56aoSbahQhNWpfW 0gbUOmaQkjPgtZTaXGR1Wgmhvt6kKuF9vDgL0+M+1mQuMcTSUYKMB+/bCtMt/P+HBe z0N90uErjhdzsp+/Googq6jYTrHMjTGlV6hSw4CR85hyyzHcby4951xqwJ91+kHfq0 YJsQ352Hn1I2Q==
Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4LxtgH3h0yz9rxR for <dnsop@ietf.org>; Tue, 2 Aug 2022 13:53:46 +0200 (CEST)
From: Martin Schanzenbach <mschanzenbach@posteo.de>
To: dnsop <dnsop@ietf.org>
In-reply-to: <a86f82af-9512-8f0a-398a-73cc9b209d8a@nic.cz>
References: <91abb9ac-9d3b-87bf-5639-174581d625fd@rfc-editor.org> <a86f82af-9512-8f0a-398a-73cc9b209d8a@nic.cz>
Date: Tue, 02 Aug 2022 11:53:46 +0000
Message-Id: <1659440963-sup-4641@werkbank>
Content-Transfer-Encoding: 8bit
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg="pgp-sha256"; boundary="=-1659441226-572943-170943-1075-3-="
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/KXpDrlsm8CMi3eLT4Rk0hQcuyrc>
Subject: Re: [DNSOP] draft-schanzen-gns and draft-ietf-dns-alt-tld
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, 02 Aug 2022 11:53:58 -0000

This is not an oversight (altough I have to admin it did not occur to me
that this a valid DNS TLD at the time of writing).
You can see in Section 7.1 that we also use "www.example.org" in the
draft.
We address the namespace topic in Section 9.9.
As mentioned, the draft currently goes all-in with respect to namespace
squatting/shadowing.
The argument is this:
GNS-aware applications will likely ONLY want to resolve through GNS OR
prefer GNS over DNS OR have their own logic to decide what to do with a
given name.

GNS-unaware application always assume DNS. In that case, IF the system
admin or user configured local overrides (e.g. for .pet or example.org)
in GNS then it is the expected behaviour that those names are resolved
through GNS. It is the same as users messing with /etc/hosts or NSS.
In fact, NSS is one method of configuring this for GNS, see Appendix
A.4.

BR
Martin

Excerpts from Vladimír Čunát's message of 2022-08-02 13:32:47 +0200:
> Interesting bit: the current -gns draft even uses the .pet TLD in an 
> example, which is a TLD that actually exists in the official global DNS.