Hi,
On 07-10-14 20:09, Kevin Thompson wrote:
On 2014-10-07 03:44, Klaus Darilion wrote:
On 06.10.2014 19:15, Kevin Thompson wrote:
Howdy all,
I was reading the release plan[1], and I saw mentioned 'Signer - Dynamic
updates'. Could you elaborate on that?
Currently, the best method I've found for integrating ODS with a dynamic
zone on one server is the CentralNIC pattern[2] - the unsigned zone is
served by a master from a private view, injected into ODS by a DNS input
adapter, signed file goes out, and finally the signed file is served
statically by the master on a public view. This method works, but is a
little cumbersome.
I'm really hoping that what is meant by 'dynamic updates' is that ODS
would take notifies to know when the dynamic zone is changed, would
download the updates via IXFR, and then directly add/update/delete
records as needed via dynamic updates. If so, this would be huge, since
it would greatly ease integration of ODS into dynamic zones. I imagine
the similarly mentioned "Database input and output adapter" would work
the same way, but would directly update a database storing the zone.
I always thought of `Dynamic Updates` on OpenDNSSEC's roadmap to be an
inbound adapter. In other words, unsigned UPDATE messages are accepted
and applied to the zone in memory.
I don't know the time frame for this, or if this still is actually on
the road map.
I wouldn't call that "dynamic updates". This is a normal zone transfer,
using incremental zone transfer.
With dynamic updates, there is no NOTIFY with XFR, but the UPDATE is
pushed directly to the name server.
Thanks for replying.
I'm not sure I understand how ODS gets involved in this situation since
there are two communication directions to consider. When the dynamic
zone is updated by, say, some zone manager UI, how is ODS notified so
that it could push signature updates to the dynamic zone? I'm guessing
here, but would that be:
1 Zone manager sends RFC 2136 UPDATEs to dynamic zone master
2 Dynamic zone master sends RFC 1996 NOTIFYs to ODS and slaves
3 ODS receives NOTIFY, performs an IXFR to find out what changed.
So far this makes sense.
4 ODS sends UPDATEs to dynamic zone master to update signatures.
Why would ODS need to send UPDATEs back to the master to update
signatures? The zone in the master can be managed unsigned.
5 Dynamic zone master sends a RFC 1996 NOTIFY to ODS and slaves
6 ODS ignores the NOTIFY since it only contains changes it created.
These steps make the process very complicated IMO. Why not the following
scheme:
1 Zone manager sends RFC 2136 UPDATEs to dynamic zone master
2 Dynamic zone master sends RFC 1996 NOTIFYs to ODS and slaves
3 ODS receives NOTIFY, performs an IXFR to find out what changed.
4 ODS sends RFC 1996 NOTIFY to slaves.
That way, the slaves will retrieve the latest signed version of the
zone, syncing with ODS, and the zone on the master can be maintainer
unsigned.
I guess I don't understand why the zone on the master needs to know
about DNSSEC.
In the case where the change originates in ODS, for example when ODS
decides to update expiring signatures, then I'd imagine that the
sequence would be the same but starting at step 4.
Do I have that right, or have I completely misunderstood what this
proposed feature is about? Really, what I'm hoping for is to undo the
CentralNIC "split-view" pattern and have ODS directly attach to a
dynamic zone and manage it seamlessly as if it were any other automatic
zone manager.
I think the proposed feature does not match your understanding of it.
Also, the word 'Dynamic' is being used for two different things: Dynamic
UPDATE and Dynamic zones. The proposed feature is to support the Dynamic
UPDATE RFC 2136 format. OpenDNSSEC can already deal with Dynamic zones.
Best regards,
Matthijs
--Kevin
_______________________________________________
Opendnssec-user mailing list
[email protected]
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
_______________________________________________
Opendnssec-user mailing list
[email protected]
https://lists.opendnssec.org/mailman/listinfo/opendnssec-user
