Hi Paul, > On 25 Oct 2023, at 17:20, Paul Wouters <[email protected]> wrote: > > On Oct 25, 2023, at 10:11, Paul Vixie <[email protected]> > wrote: >> > > [speaking as individual] > >> i am uncomfortable using the UPDATE RCODE for a purpose unrelated to zone >> modification. perhaps propose a new RCODE having the same message form as >> UPDATE? > > I agree.
To begin with, the DNS UPDATE is for the purpose of parent zone modification.
Secondly, I think many people may be missing the fact that using DNS UPDATE to
modify delegation information in the parent zone is not new, we’ve had this for
many years. This is not in any way a change to either protocol nor
implementation. BIND9 has had this functionality for many years (thanks Mark!).
What this draft does is to propose a mechanism for how to locate the TARGET of
the DNS UPDATE. This is needed because such information is not necessarily
available across organisational boundaries. And for this the draft leverages
from the mechanism proposed in the draft on generalized notifications.
>>> 2. No requirement for DNSSEC. Great as DNSSEC is, being able to automate
>>> the management of delegation information for *all* zones, regardless of
>>> whether the parent is signed or not, regardless of whether the child is
>>> signed or not, is an advantage.
>>
>> some years back this working group adopted a ubiquity regime for DNSSEC in
>> that all new specifications "must" expect DNSSEC to be in use and "should"
>> depend on it when in-scope functionality is needed. has that changed?
>
> I agree here as well. The longer we pretend DNSSEC is “optional” and make DNS
> the last protocol lacking simple spoof protection, the longer we put a brake
> on deployment of DNSSEC. And the longer we need to write drafts hacking
> around this.
Assuming you consider this draft an example of “hacking around a lack of
DNSSEC” I have to strongly disagree.
To begin with it works equally well with or without DNSSEC. Furthermore it is a
cleaner solution than what we currently have (i.e. child zone published CDS
and/or CSYNC and parent at some future time will get around to scan for it).
Replacing all this this with a single DNS UPDATE is something we should have
(and could have) done long before either CDS or CSYNC were invented.
The reason we didn’t was to some extent that we had higher hopes for DNSSEC
deployment rate than were justified, but primarily that we didn’t address the
question of how to figure out were to send the UPDATE when used across
organisational boundaries. Now we know more about the DNSSEC deployment rate
and we also have a proposal for locating the target for the UPDATE.
And so this draft was born.
How many parent zones do we have in the universe? Millions, most likely. How
many of these parents have deployed CDS and CSYNC scanners? Perhaps a couple of
dozen. Compared to the deployment rate of DNSSEC in general the deployment rate
of CDS and CSYNC scanners is so completely lacking that I think we, i.e. the
DNS community, should ponder the following question very seriously:
Do we really think that CDS/CSYNC scanners are the only answer we need
to the question of how to achieve full automation of delegation information
between child and parent?
If the answer is “no” then I’d love to hear more suggestions than this proposal.
Regards,
Johan
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list [email protected] https://www.ietf.org/mailman/listinfo/dnsop
