Closed RyanGibb closed 6 months ago
I'm really uncertain about the semantics this should have, in terms of notifying other servers (since the notification mechanism is not exposed via API as far as I know, a potential client could use this proposed update_data
and get out-of-sync name servers).
Maybe one path is to refactor the handle_packet function, but I just looked into it, and there's as well the incremental zone transfer support (update_trie_cache), and the notification mechanism.
On the other hand, we can move along and just merge it -- there's already the handle_update
exposed, and with_data
. Maybe there just needs to be more clear documentation at these functions.
I'm really uncertain about the semantics this should have, in terms of notifying other servers On the other hand, we can move along and just merge it -- there's already the
handle_update
exposed
Yep, I think handle_update
has the same issue.
and with your cap'n'proto work, how do you notify the other servers when a DNS update is performed?
I haven't added this yet, but one option would be to propagate all updates over the RPC interface Though this might be a bit wasteful if the prerequisite conditions aren't met. If I'm reading the code correctly handle_update
should return an Error
if they aren't met, so we could forward the updates conditional on an Ok
result.
For out-of-band updates with the same semantics as DNS UPDATE. I've experimenting with a capnproto interface that uses this function.