- New mailing list created: dd@ietf.org
- draft-dnsop-deleg: Initial draft from the proponents
-
DNSOP WG interim held about a proposal on 2024-01-30
## Reasons for better methods of DNS delegation {#reasons-for-better-methods-of-dns-delegation}
-
Limitations, Goals & Requirements for delegations - Roy Arends
- John Klensin: Could this also be used for intra-company
registrations? RA: It could be used for large organizations that
manage a bunch of delegations. JK: Interested in small and
medium also.
- Geoff Huston: What's the "bridge of trust" stuff mean? Will take
it offline for better explanation.
-
DELEG for Encrypted DNS - Manu Bretelle
-
Why I'm excited about DELEG - Ben Schwartz
- Mike Bishop: Several people in the chat asked whether downgrade
attacks have been seen in the wild. BS: We think we have; some
disagreement as to their nature, but not an important
distinction.
-
DELEG for DBOUND - Peter Thomassen
- John Levine: DBOUND failed because (1) browswers don't want the
extra RTT (this doesn't change that) and (2) how you know when
to believe this. How do we fix these problems?
## draft-dnsop-deleg - David Blacka, David Lawrence, Ralf Weber {#draft-dnsop-deleg---david-blacka-david-lawrence-ralf-weber}
-
DELEG @ Delegations BoF - David Lawrence
## Better methods of DNS delegation - Co-chairs {#better-methods-of-dns-delegation---co-chairs}
-
Open discussion
- Paul Wouters: The problem space is to deal with the inability to
update records. If you can do that, all the problems fall away.
The name server properties belong with the name server. I have
several other issues.
- Jared Mauch: Existential question if we want to preserve
backward compatibility. I don't think doing all this stuff over
DNS is long-term sustainable. We need to be careful to insure
some level of backwards compatibility. Open source libraries may
simply deprecate.
- Jim Ried: Overall good idea, concerned with some aspects. Will
be clashes regarding expectations in an eventual WG. Need to
manage those expectations. Also, registrars need to be included
in this discussion.
- Ben Schwartz: To address PW, I don't think it's possible to put
this stuff into the server zone without a performance
degradation, and therefore won't get deployment. To JM, we
should come up with a simple core and deploy it and see what we
can address; trying to map out carefully we will fail.
- Stéphane Bortzmeyer: I am not optimistic about getting this
done.
- Wes: charter definition may help contain the problems in
complexity
- Lars-Johan Liman: Well worth exploring. We should be cautious
not to focus on a single problem we want to solve. We should do
a review of the larger problem space so that we don't block
ourselves from solving other problems.
- Ted Hardie: Delegation is core to the DNS; this service mode
captures it well. But there are things not on this "3x5 card".
Let's stick to this "3x5 card" and stop, and then figure out the
next change. Don't boil the ocean. (Example: things that may be
solved by parent-child relationships (eg bank discussion) should
not be done; stick to delegation)
- Daniel Kahn Gillmor: Need to be careful not to get into the
swamp that DBOUND got into. Keep the work focused on the
delegation issue. Need to have the right people (registrars) in
the room.
- David Lawrence: Yes, happy to focus on the central problem, but
understand that we think this enables addressing other problems.
- Andrew Campling: Need to establish how many registrars are
willing to do this. Doesn't need to be all, but we do need some
reasonable deployment story.
## Charter discussion - Co-chairs {#charter-discussion---co-chairs}
-
Discussion from the mailing list
-
Recent charter wording
-
Background and Problem Space
- Jim Reid: We need to clean up scope. PH: Yes, let's do
background and problem space first.
- Geoff Huston: Background has "DNS is wonderful" bs. Just
delete that. (Others agree.)
- Benjamin Schwartz: The discussion of "updating information",
but that's cart before the horse. There is no information
(other than DNSSEC) that is updated. PH: Please send text on
how to change that first paragraph.
-
Objective and Scope
- Warren Kumari: 4th paragraph says "First use case...". Not
everyone agrees it's first. PH: OK with, "The first two use
cases are..."? WK: Sure, but if everyone is OK with the
first, that's OK.
- Ray Bellis: It says the WG will only do the first use case?
PH: First use case is aliasing, second is encrypted
transport, but they're both about delegation. RB: That needs
wordsmithing.
- David Lawrence: Could change it to "first potential use
case". Just don't state a preference. Also, "taking future
extensibility into account" is ambiguous. Better to say
"consider".
- Éric Vyncke: Move the 4th paragraph up by one. We need to
make the deliverables sequence stronger.
- Andrew Campling: It doesn't actually say that the WG must
solve the use cases. Should be clearer what the WG intends
to solve. Be specific.
- Lars-Johan Liman: Would also like to see investigation into
negative side-effects explicitly.
- Geoff Huston: Should include in the scope that we look into
the scope/nature of authority that is implied by the
solutions. PH: Yes.
- Jim Reid: Agree that we need to look into unforseen
consequences. Also, Geoff's right: Some of this may break
the DNS model a bit. I think it's better to have the WG come
up with deliverables and use cases rather than in the
charter.
- Paul Wouters: Maybe we should not assume that doing an new
RR type is the right solution. Maybe we should open that up.
WH: Maybe your comment is about deployability.
- Duane Wessels: This requires more than just DNS changes.
(e.g. EPP extensions) Should be charter be clear about those
changes? PH: Should that be in scope? DW: We should at least
acknowledge. Warren: Maybe just "WG will coordinate with
other WGs..."
-
Deliverables
- Paul: We heard that some of this is not independent and
should be moved; understood.
- Benjamin Schwartz: I find the second point confusing, and
perhaps it should be deleted. WH: The intention was to be
clear we need to get requirements from all the people in the
ecosystem. But maybe we don't need to do the brainstorming.
BS: It would be more helpful to make it non-normative. Also,
talks a lot about signalling between parent and resolver;
over-constrained.
- Mike Bishop: Similar to what we did in QUIC - second bullet
is to be sure to be aware of other folks using these
mechanisms. Not sure we need to constrain the others to be
separate RFCs. PH: We didn't intend that.
- Éric Vyncke: We need WG consensus on the first one. Suggest
publishing as an RFC so we get IETF-wide consensus.
- Paul Wouters: Like the first two points of the deliverables.
I would remove the word "encrypted"; other transport
properties are important.
- Geoff Huston: Add to deliverables, mechanisms for parent
zone to authoritatively serve delegation information.
Chairs: Please send to list.
- Andrew Campling: Rather than listing the bottom two
specifically, just say "We will do RFCs for use cases". PH:
We just did it because people focus on deliverables. And
remember, IESG may change a bit.
- Warren Kumari: Bottom 3 do read as "separate documents";
make it clear that's not required. Éric seemed to say that
we should do requirements (up to and including Last Call)
before moving on. Do we really want that? EV: We obviously
can work on solutions before requirements ship. WH: Either
way, we need shipping documents to satisfy requirements doc.
- Jim Reid: Be specific about which are going to be standards
track. Also, we need to be considering deployability
throughout design. Need to discuss potential ramifications.
PH: In the requirements doc? JR: Not committed to where.
- David Lawrence: Agree that we have to care about
consequences. Question: Which area? PH: Leave it to the
IESG.
- Warren Kumari: +1 to Jim; need to understand how this
impacts the whole system. This is very "core plumbing". WH:
Yes, we're hearing that theme.
-
Paul: Charter discussion will continue, and we've heard quite a
few changes. Let's focus list discussion on charter.
- Éric Vyncke: Can we answer the BOF questions? Is there a problem
that needs solving? Yes. Critical mass of participants? Yes.
Reasonable chance of success? Yes. It sounds like the have
answered the BOF questions.
- Question to the room: Are there people in the room willing to
work on this. (37 clicked Yes)
- Jim Reid: Are we second BOFing? What's the timing? PH: Not sure;
we'll work with the IESG. Lots of work yet to do. Warren: Yeah,
we're going to have to see, but this does seem like a successful
BOF. Will be looking for potential chairs.
- Paul Wouters: Everyone was very productive today; thanks.
- Mirja Kühlewind: I would like a poll of the "well-scoped"
question.
- "Is the scope discussed today clear enough to ask the IESG for a
WG?" 28 Yes, 21 No, 10 No Opinion
- "Do you think we can work on the ML to get a scope that is clear
enough?" 45 Yes, 1 No, 2 no opinion
- Paul Hoffman: We need discussion on the list for the charter.
Please get on the list and contribute.
- David Lawrence: "dd.org" has no relation to the list name.
- Chairs: Very successful. Thanks.