On Aug 10, 2014, at 8:50 PM, Randy Bush <randy(_at_)psg(_dot_)com> wrote:
as the threat models seem similar why do we need two separate
mechanisms, one for NS
draft-ietf-dnsop-child-syncronization-02.txt
and one for DS
draft-ietf-dnsop-delegation-trust-maintainance-14.txt
randy
Well there are two things going on here.
1. Rules for child expressing how to indicate new trust anchor along with
acceptance rules for parent
2. Child signaling to parent please update “these types” from my zone in the
delegation information i.e. NS change or glue changes.
Warren and I started doing #1 first as that was more critical to our thinking,
once people saw that we could update
TA info with DNSSEC in place a light bulb went off and people realized much of
mundane delegation maintenance could be automated.
While pushing this through we had to fight get people to realize that there are
many different relationships between the parties that
a) operate parent DNS
b) operate DNS for child
c) child
d) Intermediary that handles transaction to create the delegation (i.e.
registrar) and processes updates from Child.
When maintaining delegation information strictly speaking only a) and b) need
to be involved but in some cases d) insists to be in the middle
and frequently forces c) to perform some manual action.
#1 tried hard to avoid expressing operational models other than polling and I
envision that a better automated model will be created
around CSYNC, which would express if there is a CDS and/or CDNSKEY for parent
to consume.
The WG told DNSOP chairs that they wanted the documents separate even when
editors volunteered to merge them.
Olafur