If you have not already done so, you should talk to Johan Ihrn.
About 8 years ago, he and a few others hammered much of the parent/child
signaling/sync issues that you and Warren
are revisiting now. There was some documentation, but it never made the IETF.
/bill
On 12August2014Tuesday, at 19:23, Olafur Gudmundsson <ogud(_at_)ogud(_dot_)com>
wrote:
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