[DNSOP] Re: [Ext] Re: what problem are we trying to solve, was Call for Adoption: draft-davies-internal-tld

[Brian Dickson <[e-mail]>]

Apologies for joining in after the thread is closed. (My new $dayjob doesn’t involve DNS things.)

I have a (hopefully constructive) suggestion, since so much of this very long thread covers so much familiar territory.

Could we establish some kind of informal internal-to-dnsop enumeration (I won’t call it a registry) that lists current, plus previously discussed, and proposed or under discussion names, along with high level details of DNSSEC signed/unsigned and delegation chain, and for previously discussed names, links to an appropriate mailing list reference?

The reason for this is that there may be new instances (ie names) which (eg internal. ) which might benefit from re-use of past discussions. Specifically, where the proposers can suggest in which ways their proposal resembles previous names, whether or not the past discussion of previous names resulted in some end result.

IMHO it is likely that much/most of the thread on internal mimicked home.arpa, starting from the initial proposal of just “home”.

I see the question of similarities for that was already raised, albeit not so successfully or sufficiently officially (very much also IMHO).

The specific reason, in particular, would be to gauge interest in potentially having a discussion about a standing methodology and process for specific types of names: things meant for placement under ARPA, with all that comes with it (generally policy, management, rules, etc.) specifically to slightly grease the skids for cases where adding another name under ARPA makes collective sense (to all parties directly involved, meaning ICANN proper, SSAC, IAB, the IETF, and DNSOP.)

The very few bits of metadata for a potential list/registry would likely be: whether the first delegation of a name (from the root to arpa) is signed; whether there is a second delegation (from arpa); to where it is delegated (eg as112 or something else); and whether the second delegation is signed.

IMNSHO, the case for home.arpa suggests that it probably shouldn’t be the only such delegation, specifically because its intended use is for a specific purpose, and new/different use cases should not be shoehorned into camping on it.

Brian

Sent from my iPhone

> On Jun 18, 2025, at 10:58 AM, Benno Overeinder <[e-mail]> wrote:
> 
> Hi all,
> 
> Joining in on the ongoing conversation.
> 
> In the email thread, we have seen a number of messages from DNS implementers and operators arguing that insecure delegation is required for the proper operation of validating stub resolvers.  See also RFCs 6303, 8375 and 9665, which mention insecure delegation. The new draft by Joe Abley et al. discusses this issue in general terms with regard to private namespaces.
> 
> The chairs have asked the IETF liaison to the ICANN Board of Directors to also discuss this issue with the ICANN technical community.  We hope to report back to the DNSOP Working Group during the Madrid meeting.  We would like to ask the WG not to repeat the same arguments until there is news.
> 
> Thanks,
> 
> -- Benno
> for the WG chairs and secretaries
> 
> 
>> On 17/06/2025 23:08, John R Levine wrote:
>>> On Wed, 18 Jun 2025, Mark Andrews wrote:
>>> And if the stubs are validating then the answer for 10.in-addr.arpa DS is a provable NOERROR NODATA response that says there is a delegation at that point in the tree.  That validator does NOT need to be configured to say ‘DO NOT VALIDATE THIS NAMESPACE’.
>> We're going in circles here.
>> IF you have a validating stub resolver AND it gets all of its data from the local cache AND even so it doesn't believe the cache's AD flag AND you have some locally served zones AND none of those zones are a TLD you picked yourself before .INTERNAL was reserved AND even though you're sophisticated enough to do stub resolution you don't configure local trust anchors THEN yes, the opt-outs are helpful.
>> On the other hand, if you think that's a rather narrow scenario and most systems aren't quite like that, not so much.
>> Like I said, I don't see us coming to agreement any time soon.
>> Regards,
>> John Levine, [e-mail], Taughannock Networks, Trumansburg NY
>> Please consider the environment before reading this e-mail. https://jl.ly
>> _______________________________________________
>> DNSOP mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
> 
> --
> Benno J. Overeinder
> NLnet Labs
> https://www.nlnetlabs.nl/
> 
> 
> _______________________________________________
> DNSOP mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]