IETF Logo Mail Archive

[DNSOP] Re: [EXTERNAL] Re: Call for Adoption: draft-davies-internal-tld

Roy Arends <roy@dnss.ec> Fri, 02 May 2025 10:20 UTC

Return-Path: <roy@dnss.ec>
X-Original-To: dnsop@mail2.ietf.org
Delivered-To: dnsop@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 830A723F8EB1 for <dnsop@mail2.ietf.org>; Fri, 2 May 2025 03:20:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (1024-bit key) header.d=dnss.ec
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7yG9-8piB81 for <dnsop@mail2.ietf.org>; Fri, 2 May 2025 03:20:24 -0700 (PDT)
Received: from mail-qk1-x729.google.com (mail-qk1-x729.google.com [IPv6:2607:f8b0:4864:20::729]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id A033D23F8EAC for <dnsop@ietf.org>; Fri, 2 May 2025 03:20:24 -0700 (PDT)
Received: by mail-qk1-x729.google.com with SMTP id af79cd13be357-7c922169051so113595685a.0 for <dnsop@ietf.org>; Fri, 02 May 2025 03:20:24 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dnss.ec; s=google; t=1746181224; x=1746786024; darn=ietf.org; h=to:references:message-id:content-transfer-encoding:date:in-reply-to :from:subject:mime-version:from:to:cc:subject:date:message-id :reply-to; bh=xiw1vBoItGblGVPQq7ra3cQXurWK2cpNh9RnYaq3rAk=; b=Yp233rI5ua8E12QkG56xrey8zilayTaZ9c6+uEHIHHelGTsPk4RDDO5ExYVDvXt4qD afHL/Ul+HIavVpVJlnoffI0Qu2A7eSXVSToHl639gOPd/OfC6UrJCJ4aMl98QMTphSAX Ytnc5u8KRECMu0cTdQjSef18fkbW8ldy1maKg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1746181224; x=1746786024; h=to:references:message-id:content-transfer-encoding:date:in-reply-to :from:subject:mime-version:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=xiw1vBoItGblGVPQq7ra3cQXurWK2cpNh9RnYaq3rAk=; b=sI0l1FsyExYfsE9TP4PZj3Z08rLQzMfKKBvfRHKCnPRnB++y71Gs17q9kAyx7plLNE Wi2b57eE9ff7bcjwB5TC6BBku/Say1rw4hFw7mZswZKmVgOiLte7a8WvsKgEaIQqnvR3 LizPVFDIzXJmk59QOCwf8Kx/VoVXNDOuwBd49LOKsnljntJuOf3aebfDCdYiwVTAepTr CwKVlgGk+3nAFOvUCSwSmjTb4/ub0Ldf4GKBLwQWn/rBLuHfnq4Il/J/xZottI06Wczg llbOfUpO30VNBt2g2o+fqcDu0Fud5OmtxrFlxNHuvzBTftbSPv35l3tcUkXtm/am3uT7 sGrA==
X-Gm-Message-State: AOJu0Yyo/sorx8RUaSSgsn5d4aquD2jLmW6NN+Vqv3vFbhVYt99ZNvS5 4mA5c0gwndQnkoUiXP8+GQI6l5XuGv9N1Amku03LtCNSgiWfZR14vfqdWHezbo3HnuMR0ntBi5B uso4=
X-Gm-Gg: ASbGnctRBMf7VQtGCvJk6bhkubr2UnN8xLILtSQ17rNNon5OtYsJfSGTObHp7vwwtGN 4yWRhWjRzGA4baNjWtQ6DhM/m65eYVDDpKzTnUfLV+EZvhpdu5TNrWaRWEFS+8M5w4W5RPEflmF XXK115bOJrxg1lDTsPXRMIF22qV36Dk9R23Hk1r9gagcrn3SAoYY2gF9VlljiptVMTfPhSGCMPO HBAfsfbxHoGW23kJBx5Rb1hZLjM+1E5PBxsv969Z6bTN+XMhpf67dEmZhuhnCLDF8Z1hO4flW1d sDFbJC7ynA+8mBI+9ID9C365ZZXk2CUGF5VfiDZRRFNsJQ==
X-Google-Smtp-Source: AGHT+IH9Jq7wPdeypoP3p0BEN3z6r8uM/E8yyapEvmlP4f3GeVSkXkyUCmiVyC56g0fTXRFe3NXHoA==
X-Received: by 2002:a05:620a:3948:b0:7c5:65ab:5001 with SMTP id af79cd13be357-7cad5b8d174mr290262685a.39.1746181223807; Fri, 02 May 2025 03:20:23 -0700 (PDT)
Received: from smtpclient.apple ([88.81.146.121]) by smtp.gmail.com with ESMTPSA id af79cd13be357-7cad23c2f61sm167868185a.25.2025.05.02.03.20.22 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 May 2025 03:20:23 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3826.600.51.1.1\))
From: Roy Arends <roy@dnss.ec>
In-Reply-To: <SA1PR15MB43700B9B2C9151FB31381082B3BC2@SA1PR15MB4370.namprd15.prod.outlook.com>
Date: Fri, 02 May 2025 11:20:11 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <866409E5-0D9A-4669-8C6E-C9D1C7BDAA21@dnss.ec>
References: <1C9E8ABA-4399-491B-A9F4-D9ACCB1BA72C@virtualized.org> <C497EC3A-A06B-4DCC-B0C8-382A3424D7D5@strandkip.nl> <SA1PR15MB43700B9B2C9151FB31381082B3BC2@SA1PR15MB4370.namprd15.prod.outlook.com>
To: Working Group DNSOP <dnsop@ietf.org>
X-Mailer: Apple Mail (2.3826.600.51.1.1)
Message-ID-Hash: VE544RZAKXEXEYFPY22IMG6ZLPZU63BV
X-Message-ID-Hash: VE544RZAKXEXEYFPY22IMG6ZLPZU63BV
X-MailFrom: roy@dnss.ec
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.9rc6
Precedence: list
Subject: [DNSOP] Re: [EXTERNAL] Re: Call for Adoption: draft-davies-internal-tld
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/5gkbp4tHvje-PBVUP1LMYbVLOsY>
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 17 Apr 2025, at 19:49, Ben Schwartz <bemasc=40meta.com@dmarc.ietf.org> wrote:
> 
> I wonder if we could use this draft, if adopted, to recommend an insecure delegation for .internal (and any future domains of this kind?) back to the root.

I assume that the intent is that an unsigned delegation for .internal in the public DNS root zone would allow local overrides for .internal domains. 

This introduces a significant security issue: Attackers can more easily spoof local .internal queries, as no cryptographic proof of authenticity exists. Deploying an unsigned delegation for .internal allows a unilateral downgrade attack on all internal namespaces.

An alternative is a Negative Trust Anchor (NTA) (RFC7646). NTAs explicitly instruct validating stub resolvers to treat a namespace (in this case, .internal) as unsigned locally. 
They are explicitly configured locally, so validation is intentionally bypassed by trusted local administrators rather than globally disabled for everyone. It clearly signals administrative intent and control.

Roy

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