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

[Ben Schwartz <[e-mail]>]

We are comparing two options, and two types of deployments:

Option A: .internal is provably nonexistent at the root
Option B: .internal is an unsigned delegation at the root

Type 1: A deployment that controls the stub's DNSSEC configuration
Type 2: A deployment that cannot customize the client's DNSSEC configuration

For Type 1, options A and B achieve the same security and functionality.  Either way, the deployment can make use of .internal as a signed or unsigned zone, by configuring stubs with a local positive or negative trust anchor.

For Type 2, "A" makes .internal empty for validating stubs, whereas "B" entrusts its contents to the recursive resolver.

The ICANN SSAC report suggests that one goal of .internal is to support devices that can function "without a priori knowledge of the network environment in which those devices are deployed".  This suggests that the SSAC intends for .internal to be usable in Type 2 deployments.

I think the working group could reasonably publish a recommendation that "root zone owners" (i.e. ICANN) who are reserving "private-use TLDs" (i.e. .internal) SHOULD use an unsigned self-delegation unless "Type 2" deployments are clearly out of scope, for the sake of compatibility with non-customized validating stub resolvers.

--Ben
________________________________
From: Roy Arends <[e-mail]>
Sent: Friday, May 2, 2025 6:20 AM
To: Working Group DNSOP <[e-mail]>
Subject: [DNSOP] Re: [EXTERNAL] Re: Call for Adoption: draft-davies-internal-tld


> On 17 Apr 2025, at 19:49, Ben Schwartz <bemasc=[e-mail]> 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
_______________________________________________
DNSOP mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]