Changes from -00 to -01
Next updates planned
Open Issues
Resolver implementors agree that there needs to either know the address
of or know there is no address for a nameserver. DELEG gives us a chance
to add new types of delegation, not to get rid of names, but to add
nameless servers as an option where only addresses are needed.
The current draft options for getting addresses:
Proposed addition to delegation is the second option in DIRECT above.
There is no replacement or removal of existing DELEG mechanisms.
Note: names are not necessary when there's no secure transport or the
authentication for the secure transport does not rely on the name.
Ben Schwartz: we should be consistent about whether nameservers are
"hosts" in the DNS sense: are their identities IP addresses or domain
names? It's confusing to have both concepts. I think we should embrace
that nameservers do not have names.
Wes Hardaker: there isn't a clearly understood need for nameless
servers, so does it matter if we cannot add it later if there's no need
for it at all?
David Lawrence: Suggestion: for INCLUDE, don't use addresses until DELEG
check fails (have not spoken with coauthors yet)
Philip Homburg: If we add this, it will only work for DIRECT
(inconsistency).
Joe Abley: transition from NS to DELEG is already confusing enough, as
is glue. We will also be in this transitional state longer than DNSSEC
(room boos, lol). Let's keep it as simple as possible.
Petr Špaček: Not having a name means there's no implication the child
can override anything (prefer this over inconsistency)
Joe Abley: SERVFAIL and name error are both problematic. REFUSED would
be matter (or even NOTIMPL).
Warren Kumari: prohibiting delegation to a nameless IP address will come
back and bite us.
Jim Reid: we need better triaging flow for deciding, per suggestion, if
they are useful for DELEG work. The recent list discussions don't seem
to be productive.
Philip Homburg: the intersting part of DELEG is the INCLUDE mode, DIRECT
doesn't give us anything new, but INCLUDE we need to work around SVCB
limitations.
Erik Nygren: it will be problematic in supporting both mdoes (DELEG and
NS) we need to be mindful of.
Ben Schwartz: if outsourcing nameserver operations, use INCLUDE (which
definitely supports names). If using DIRECT, you do not outsource to
avoid problems with pinned features of a zone the outsoruced provider
cannot dynamically change.
John Levine: stale glue will not be a problem with nameless servers
anymore, but on the other hand, synthesizes names make more
opportunities to screw things up. I agree with Ben, and I like nameless
addresses and consistency on that.
Q Misell: I prefer NOTIMPL as the error code for DE=0 but no DELEG
Florian: I'm fine with moving priming queries to a different draft, but
we need to at least say "we are punting this but it is allowed"
Philip: poitn of delegating to names is so there can be A/AAAA records.
INCLUDE approach means we are replacing role of A/AAAA records.
Petr: NXDOMAIN is the only option. Anything else will cause problems
because NXDOMAIN can be cached and the others cannot.
Mark: Nameless servers will remove the ability for operators to validate
zone data, which is something we haven't been doing as 1034 requires,
but still, nameless servers sets us up for failure.
(Note: the chat is very active on the topic of correct error type for
DE=0 but no DELEG with no clear consensus)
Peter: I don't think NOTIMPL makes sense when the problem really is that
part of the namespace is just not reachable. Separately, I think it's
fine to indicate a zone cut by faking NS records.
Karl Dyson: without names, we cannot synthesize NS records.
Florian: I have a draft that uses RESINFO to advertise support for
DELEG, what do the authors think of incorporating this into the base
draft?
We are here because existing delegations have limited functionality, so
we are trying to provide more without breaking existing delegations. As
an RRtype reviewer, I foresee problems with this that aren't just "DELEG
is a new RRtype".
Suggested exension: Authoritative Delegation Type (ADT) records that
exist only at delegation points. This is because one RRtype (DELEG)
won't fit all. The SRV authors thought they solved advertising services,
yet we also have SVCB now. We can avoid DELEG3, and shoe horning
everything into TXT or DS records by assigning a range of types, of
which DELEG is the first.
Proposal: separate document that defines this range that the existing
base protocol then consumes one point from that range.
Éric Vyncke: I think this idea is nice, but I don't think (as AD) this
WG charter includes it. Let's talk.
TODO: non-ASCII^^ for Éric done ;-) thank youuu!
Paul Hoffman: 4033-4035 breaks out changes to protocol versus new
features, so I think separate documents make sense for clarity for later
readers.
Joe Abley: I'm confused about why allocating new code points solves
problems...
Jim: this is an interesting idea, but (see discussion of proper home
above)
Petr: the value of this proposal is preventing the confusion around
DNSSEC again in the future by pre-communicating the semantics of future
defined collection of DELEG* types.
Viktor Dukhovni: resolvers will struggle with knowing which NSEC proof
to present when it si ambiguous whichs ide of parent/child split the
records live on. We do want that clarity. However, I don't think it
makes sense to have a large range of parent-side record types, maybe
five would be sufficient (because we can't just have one large bucket
for RRtypes that may live in different places).
Philip: it seems reasonable, but it worries me because it might be
repeating the SRV v. SVCB mistake. We are assuming that DELEG2, DELEG3
will look similar to DELEG such that a resolver can use the predictable
range for anything meaningful.
Ondřej Surý: it makes sense that this does not belong in DELEG WG as
this is more useful generally for "these are parent-side records" not
just "these are parent;side delegation records"
Ulrich Wisser: this doesn't sound at all about code points but defining
a set of records with a shared set of properties (and the code range is
irrelevant, why do we need consecutive type numbers?)
Petr: at first, most zones will have no DELEG and therefure need
NSEC(3), not sure this gets us much
Q Misell: I think this is a good idea to avoid having to redefine "oh,
and this type also needs all these same properties". Let's pick a
reasonably large number for the range.
1) Do we see a need for allocating such a range
2) 2) if so, how big should the range be. Those are questions for us to
discuss on the mailing list.
The draft currently assumes SVCB semantics and that when a resolver sees
DELEG with INCLUDE type, it queries the target name with type SVCB.
However, some have objected to use of SVCB here.
SVCB has the benefit of sharing DELEG record format and being recognized
by DNS software. However:
The alternative is a new RRtype that defines exactly what is needed that
SVCB doesn't cover. This gives flexibility to match the semantics of
DELEG whether DELEG remains sVCB-based or not. However:
Viktor: SVCB has a key registry of 64k, why can't we just introduce new
keys with the needed semantics?
Ben: I disagree with every point in this analysis. I don't have a strong
opinion on what RRtype to use, but these arguments aren't the right ones
for making this decision. Priorities are useful and I think it's a
mistake to drop that here. Example: lower priority delegations to a
third party that enables "we prefer to handle in house except for when
they are overloaded or unreachable, shed to third party". Also, whenever
TLS or QUIC are used by the DNS, you want the properties of SVCB where
properties of TLS and QUIC are being defined.
Erik: Agree with Ben, we should keep the registry and semantics the
same. But should the target of the INCLUDE be the same type? No, I think
a new type there makes sense to accommodate for variations. This will
also make synthesis easier.
Wes: this has a clear demonstration of need. Just because we are going
to change some things doesn't mean we can't reuse the rest. We should
maximize reuse.
Philip: the further DELEG wanders from SVCB,t he harder this is going to
get to manage, so I think a different type makes sense (keeping the two
types, DELEG and new type we chase, in sync as much as possible)
Viktor: posing question: are the semantics of SVCB appropriate?
Base protocol authors: you get the feedback you need? (yes from Dave)
Roy's draft will need discussion (range of RR types)
Reminder: Petr's point about determining needed mechanisms first, then
we can define semantics that support what we are trying to accomplish
(let's not get too buried in SVCB analysis until we know what we need
from the RR type)