Added Objectives Section

[edwardlewisicann]

Added three objectives in one section. A high level "requirements" section.

[bemasc]

This is the first I've heard of this objective for DELEG. I also haven't heard of a plan to meet this need.

For "web cookie" use cases, the essential problem is that the ultimate client doesn't perform its own iterative resolution, so any metadata about zone cuts within the name is ordinarily lost before DNS resolution results reach the browser. We could potentially develop a way for an iterative resolver to enrich its response with metadata about the zone cuts, but we haven't done that yet.

This seems like something that might be enabled by DELEG but does not need to be part of the core specification, and can be added later using SvcParams.

[edwardlewisicann]

As far as where it was discussed - at dinner tables and an obscure entry in Mattermost, it’s capture here is to bring this discussion up. What’s not in the text is that this “feature” would have helped the DBOUND WG but I didn’t want use that rationale in the draft. I used an analogy in the mattermost chat that was probably lost on most people to describe the feature. I’ll try to explain it here, in email, as there’s more room to elaborate. In real estate - buying, selling houses - there are some transactions called “arms-length”. This is when you sell your house to someone you don’t know. The alternative is when you sell your house back to yourself - like adding a new spouse to the Deed or to put the property into a financial trust that you own. What’s significant in this distinction is this - let’s say a tree on the property falls over and damages a neighbor’s house. Who gets sued (or whose insurance covers it)? If you were the owner when the tree was planted and you sell the house at “arms-length”, you are not involved, the next owner is. If you sold the house back to yourself, you still are responsible. Awkward analogy aside, how does this play into DELEG? From the web cookie situation (which I admit I am far less familiar than real estate dealings), a cookie for *.com would work for com but not it’s “arm-length” delegations, like example.com. But for something that is multi-label-depth, like perhaps compsci.math.example-edu.example., where a *.example-edu.example. cookie would apply. The/rather A problem in DBOUND (I’m familiar with the WG around 2015ish, I think there was a revival) was that the DNS gave no indication of an administrative boundary, making it impossible to demark where an administration began and ended as one traversed down tree. The hope here is to treat that. Now - whether this is a ‘first class’ issue for DELEG is an open question. On the one hand I can see this addresses via a “flag value” in DELEG. On the other hand, well, I’m open to learning other ways to treat this. It’s not something I see as a “must be done” in the foundation, but something that does need treatment. Of course…this probably ought to be discussed somewhere other than in a pull/push request (I still don’t git, err, get git language) email exchange, but here it is. From: "Benjamin M. Schwartz" ***@***.***> Reply-To: fl1ger/deleg ***@***.***> Date: Thursday, December 7, 2023 at 10:19 To: fl1ger/deleg ***@***.***> Cc: Edward Lewis ***@***.***>, Author ***@***.***> Subject: [Ext] Re: [fl1ger/deleg] Added Objectives Section (PR #21) @bemasc commented on this pull request.

________________________________ In draft-dnsop-deleg.md [github.com]<https://urldefense.com/v3/__https:/github.com/fl1ger/deleg/pull/21*discussion_r1419130224__;Iw!!PtGJab4!_TJANbbXqC-4nnKMUST35ibZI3OfeGKbYzydqUkfVjg05l-_92hUuJDa379-rrveXL4EzFVFxXlKMz2Bz2FAw0ByowtLYIE8IQ$>:

@@ -178,6 +178,16 @@ The primary goal of the DELEG records is to provide zone owners a way to signal

The DELEG record is authoritative in the parent zone and if signed has to be signed with the key of the parent zone. The target of an alias record is an SVCB record that exists and can be signed in the zone it is pointed at, including the child zone. +## Success factors + +Objectives of the DELEG design are listed in this section. The list may change over time as the mission may expand or contract. + +Objective 1 : Replace the functionality of the NS and DS resource record sets and enhance by including full transport service address information (e.g., TCP's port number), including glue records, and other information related to consulting a different DNS server. The purpose of this objective is to support seamless modification of the DNS protocol. + +Objective 2 : Expose the role of DNS operations, enabling a zone administrator to make use of multiple DNS providers who may have different operational policies. This supports having multiple providers for resoliency and stability in steady state and the ability to transition from one provider to another during a transitional state. The purpose of the objective to identify DNS operators enables the use of security credentials to automatically update delegation information, such as new name servers, new DNSSEC keys, etc. + +Objective 3 : Denote when the delegation is an administrative boundary, that is, a delegation to a different zone administration. The purpose of this objective is to support applications that need to know whether to extend security policies to a subzone, such as web cookies. This is the first I've heard of this objective for DELEG. I also haven't heard of a plan to meet this need. For "web cookie" use cases, the essential problem is that the ultimate client doesn't perform its own iterative resolution, so any metadata about zone cuts within the name is ordinarily lost before DNS resolution results reach the browser. We could potentially develop a way for an iterative resolver to enrich its response with metadata about the zone cuts, but we haven't done that yet. This seems like something that might be enabled by DELEG but does not need to be part of the core specification, and can be added later using SvcParams. — Reply to this email directly, view it on GitHub [github.com]<https://urldefense.com/v3/__https:/github.com/fl1ger/deleg/pull/21*pullrequestreview-1770405898__;Iw!!PtGJab4!_TJANbbXqC-4nnKMUST35ibZI3OfeGKbYzydqUkfVjg05l-_92hUuJDa379-rrveXL4EzFVFxXlKMz2Bz2FAw0ByowsaxBLKMA$>, or unsubscribe [github.com]<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/ADS2IKSLCU6WHU4UF26BDQDYIHM6XAVCNFSM6AAAAABALBWF5WVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTONZQGQYDKOBZHA__;!!PtGJab4!_TJANbbXqC-4nnKMUST35ibZI3OfeGKbYzydqUkfVjg05l-_92hUuJDa379-rrveXL4EzFVFxXlKMz2Bz2FAw0Byows-2xJFMQ$>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[edwardlewisicann]

Between github, the traditional DNSOP mail list, Mattermost's chat room and possibly other channels, I'm no longer certain where to add this comment.

Perhaps another reason for DELEG to denote when a delegation is made across an administrative boundary lies in the recent thread on QNAME minimization, when to use it and when to drop it. The problem seems that in some use cases, like DNS reputation lists, QNAME minimization has a harmful effect compared to the usual query-response use case. Trying to address that is complicated then by IPv4 reverse map and then IPv6 reverse map delegation use cases. It might prove to be helpful when a resolver can count down levels of administrations, not levels of zones or labels, to know when to "drop" QNAME minimization. This is just a thought, but it seems that the debate over when to use minimization is circling around knowing what administration (level) is being queried.

[paulehoffman]

These objectives seem long-winded relatie to the conciseness of the rest of the text in the document. Maybe this can be dropped until after the -00 appears, and see if it is still needed then.