IETF 120 deleg

Charter overview

Presenter: chairs

Today's discussion should be focused on requirements. A requirements doc MUST beadopted before solution work can be adopted.

Requirements draft

Presenter: tale

Draft link: https://datatracker.ietf.org/doc/draft-wirelela-deleg-requirements/

Proposed a set of hard and soft requirements. This has been discussed on the mailing list (dd, not deleg).

Hard Requirements

• must not disrupt existing registration model
• must not change current namespace semantics
• must not negatively impact "most" DNS software
• must be able to secure delegations with DNSSEC
• must support updates to delegation information as easily as NS records

Soft Requirements

• should facilitate using new DNS transports
• should clarify how to contact a SAP
• should minimize transaction costs (server overhead, packet overhead, etc.)
• should enable an operator to manage DNS service more completely
• should allow for mapping to NS-based delegation
• should be easily extensible like EDNS(0) is
• should support an in-band means for child to signal to parent that parent-side records related to the child should be updated
  -- more recent discussion result

We tried to focus on core design values; not a lot of writing about where the ideas came from or specific implementations. Let us know if we need more verbiage to explain why any given text is there.

Big discussion point: disagreement over "must not change current anmespace semantics". What we meant was "existing DNS zones would continue to work the way they currently work". New text has been proposed, see slide number oops-the-slide-authors-did-not-put-slide-numbers.

Another discussion point: the child to parent backtalk could potentially be addressed using the Generalied DNS Notifications draft in dnsop.
- Question to the WG: should this soft requirements remain in the draft?

Doc is at https://github.com/moonshiner/draft-wirelela-deleg-requirements

Seeking adoption.

WG discussion

Roy: what allows DS aliasing? This is missing from the requirements.
- Tale: this was in an attempt to maximize the "allow complete management" requirement value
- Paul: aliasing should not be in this draft

Rick: I liked the distinction between hard and soft requirements. Was anything left out (/s)? Also, would be good to capture the non-goals: hard, soft, and left-out.
- Tale: we are open to expanding (please let us know if we missed something)

Wes: Impressed with the immediate WG progress (and also perhaps scope-creep). The WG should consider what is more appropriate for dnsop versus deleg.

Wes: back compat is fascinating. Declaring a MUST for continuing to support NS is going to be challenging.
- Tale: I look forward to having DELEG-only zones, this is not about "NS is always required"

Paul: I do not think the WG should create a document that forces operators to not have communication channels.

Jim: this list of requirements looks about right. Is there anything we have missed?

Joe: back compat is part of "deployability" but we should specifically state that it is incrementally deployable (meaning that we will not require a flag day)
- Tale: great point, would welcome text

Delegation aliasing

Presenter: Paul Hoffman

This is about requirements for the aliasing protocol (not the requirements for transports or other topics). This is also a rough guess and not necessarily a draft to be published, but a good starting point.

For aliasing support on the parent side:
- MUST be able to specify multiple target servers for aliasing
- MUST be able specify expected transports for target servers
- MIGHT be able to specify keys for secure transports
- MIGHT be able to specify address records for target servers

For aliasing support on the child side:
- the pointed-to server MUST be able to specify all authoritative records for the child zone (no limiting this server more than what NS record use would)
- pointed-to server MIGHT be able to re-point to different authoritative servers to some depth N
- pointed-to server MIGHT be able to indicate the list of names that it serves (so resolvers can pre-populate delegation records)

WG discussion

Ben: I would like to see in-bailiwick addressed

(multiple chat and mic line) the last requirement looks an awful lot like cache poisoning...

Lars-Johan: can you compile the list of the requirements even if it is not a doc?
- Chairs: sure, in the WG GitHub

Joe: are we pointing at names, or pointing at servers?
- Paul: maybe we need a requirement for terminology

Ondřej: be very careful with the mistakes of the past

Signaling Transports

Presenter: Paul Hoffman

• MUST be able to specify multiple types of transports for any of the NS records (DoT, DoQ, Do53 -- DoH was left out due to discussion in dprive)
• MUST be able to specify expected transports for the NS records
• MIGHT be able to specify public keys for secure transports (see question below bullets)
• MIGHT be able to specify address records for NS records

Open-ended question: what trust models should we support? DNSSEC? PKIX? Others? Only one blessed solution?

WG Discussion

Joe: I get where the list of transports from, but why leave something out without a reason rather than only leave things out when we have a good reason to? (why DoH was left out)

DKG: I am wondering why we are going to do aliasing before we do transport signaling? Aliasing seems harder.
- Paul: because that's how the charter landed

Ray: This is not going to be one key per zone, right? We may need one per name server
- Paul: correct

Ben: I am ok with DoH not being in the list despite being sad about it.

Ben: we do have proposals for aliasing that show we will get concrete before long.

Warren: is it not harder to detect DNS traffic over DoH than DoT or DoQ?
- Paul: I was an author and I'm still not convinced of that
- (continued discussion but no decision resulting)

(g)TLD registry Perspective

Presenter: Jim Galvin

gTLDs are active in both the IETF and ICANN communities. gTLDs are also subject to "consensus policies" which are similar to Internet Standards but with enforcement.

The "DELEG must not disrupt existing registration model" requirement is good. To inform that:
- EPP is used to provision gTLD zone files -- if you change this, there will be a lot of software that needs to change
- RR types are restricted in gTLD zone files that means jany new RR type would require work on our side (restrictions can be changed by community input)

WG Discussion

Jim (Reid): There may be some other concerns as well. DELEG may also complicate takedown requests as an example.
- Jim (Galvin)

John: My impression is that the process to do this would be similar to what we have done before. It makes sense to keep down-stream costs in mind, but it's worth noting that any change is expensive, so big versus small is not a big deal.
- Jim: I agree.

Rick: +1 to Jim -- also, many of us support this because DELEG opens new options for registrars including a better avenue to support DNSSEC (right now many do not because it complicates their front-end portals too much, where DELEG will make this easier).

Paul: note that ccTLDs will run faster than this, and having first deployers will make adoption faster for others. This is a great reaosn to have the core protocol followed by extenstions (faster arrival at end to end working examples).

Not at the zone cut

Presenter: Willem Toorop

Where should we put the new extensible delegation info? The answer affects ease of deployment, which software are affected and how, and even the requirements.

Currently, at the parent side of the zone cut, but it could be elsewhere in the zone. Two examples form the hackathon at IETF 118 show potential differences
- draft-wesplaap-deleg-00
- draft-homburg-deleg-incremental-deleg-00

The zone cut makes the child authoritative (if "com." signs "example.com." then verifiers would consider that BOGUS, with exceptions). DELEG could end up being another exception if the delegation information is not stored in a separate zone (example: "example._deleg.com.").

Using a separate zone also makes third-party zone relationships easier (just use a CNAME, see slides for example).

Would this not double the queries however? Not if the zone is signed (can use NSEC(3) to confirm _deleg.com. does not exist). Otherwise, yes.

In summary: moving away from the zone cut means name servers and signers can remain the same as DELEG is adopted by resolvers, CNAME and DNAME can be reused for aliasing, and can be done with no additional overhead for signed zones.

Paul Vixie said at a discussion panel that putting DS records at the zone cut was a mistake.

WG Discussion

Tale: I still prefer to be at the parent side of the zone cut because this proposal increases the complexity of the graph and makes DELEG look like an add-on when it should eventually "grow up" to be the way of doing things. I also do not see how DS caused measurable problems as it is.
- Willem: DS works now, the poitn is how long it took to make it work.

Joe: This idea is both really ugly and really good. It only looks wrong because we are trained to think in terms of zone cuts.

Ben: How would you avoid doubling the query load on unsigned zones that lack DELEG information?
- Willem: broadening support circle to the authoritative server will help work around this

??? -- missed namem sorry --: reserving "_deleg" ......
- Willem, oh, this is a good idea

Roy: I do not think this overhead is worth it considering that DELEG will not be the last time delegation is invented (think NSEC versus NSEC3 and already proposed NSEC4/NSEC5)
- Willem: No, you do not need more over head (multiple queries) if the authoritative server is supporting this.

Open mic

Chairs to the group: is something missing from what has been raised?

Paul: I know there are people concerned that these current requirements make NS records are forever versus not. Let's just not talk about NS records now and then revisit later (or be more explicit about the intended long-term).

Eric: Is there anything addressing requirements for consistency (or lack thereof) between NS and DELEG?

Jim: We should positively ack that we do not expect authoritative servers to do additional processing.

Ben: Would appreciate people's thoughts on the intersection of DELEG and a draft I have been working on in dnsop in a similar space.
- Chairs: note that this group still needs to define its requirements before we can discuss solutions

Mark: I don't see DELEG living in an unsigned zone. We should require it be in a signed zone.
- Shane, direct response in chat: how does the resolver know if a zone is signed if it has not already queried the parent?

Mark: I would rather see DELEG done right than done fast (no tconcerned with how quicky we get DELEG-0capable resolvers deployed).

Andrew: we need a better story for NS co-existance. We have people saying both "looking forward to replacing it" and "let's not talk about it".
- Joe: We can do both (excited to replace and willing to co-exist). Incentivising adoption as well as supporting the right tail of adopters.
- Andrew: agreed, I just want to make sure we are actively saying something and not ignoring this

Florian: Would be nice if the req docs would say how conformance is measured so a reader would know who was not part of the discussions here.

parent-only-record-signalling

Presenter: Roy Arends

This documents DNSSEC protocol changes needed to accommodate "Parent-Only" records. This is distinct from the DELEG draft to generally support other future "Parent-Only" records that may come up later that may need to change this without changing DELEG.

Tl;DR: set aside a range of RR types for parent-side only use, specify a secure signal, and propose changed needed to support it.

This is not a new idea:
- draft-peetterr-dnsop-parent-side-auth-types (2020)
- draft-pwouters-parental-rrtype (2024)

WG Discussion

Paul: I'm still on the fence about whether we need to sub-class parent only RR types. I wrote another draft taking another approach where there would be only record-agnostic changes to make this work.
- (the other draft is here: https://datatracker.ietf.org/doc/draft-pwouters-ds-uplifting/)

Jim: We should think of "DELEG" as a mechanism and not necessarily an RR type specifically since we do not know what the solution will end up being.

Chairs: Next Steps

The DELEG Requirements doc is currently an I-D. Show of hands on whether we should adopt?

Results:
- Yes: 51
- No: 0
- No opinion: 11
- Participants: 114

Paul: can we finish this requirements doc before IETF 121 so that we can spend the next meeting working on actual solutions? Meaning: doc is adopted and passes WGLC before November
- Warren: I am entertained by this optimism
- Tale: I think this is practical, actually. There does not seem to be much controversy in the room.
- Andrew: then we should probably have an interim meeting
- Warren: agreed, an interim is a good idea