expose Dns_server.update_data #350
Conversation
| * Dns.Packet.Update.update list Domain_name.Map.t -> | ||
| ( Dns_trie.t * (Domain_name.Set.elt * Dns.Soa.t) list, | ||
| Dns.Rcode.t ) | ||
| result |
There was a problem hiding this comment.
there's need for a docstring describing the semantics -- and what will be done, what won't be (e.g. authentication).
also, the return value should be described in detail -- what the second projection is supposed to contain, etc.
I also wonder what the operation for a DNS server should be -- so once an update_data has been performed, there may be need to notify secondary servers -- how's this supposed to happen? and with your cap'n'proto work, how do you notify the other servers when a DNS update is performed?
|
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 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 |
Yep, I think
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 |
CHANGES:
* dns-client (lwt, mirage): depend on happy-eyeballs-{lwt,mirage} instead of
duplicating the code. This requires happy-eyeballs 1.1.0, and now the same
Happy_eyeballs_{lwt,mirage}.t is used for DNS (connecting to the nameserver)
and for the application (connecting to a remote host)
(@dinosaure @hannesm mirage/ocaml-dns#346)
* server: improve API documentation (@hannesm
1a80bd4080e597687152cf351d035ef5f00c5946
000ae02dfc477d91c05891e3891a447328ae448a)
* server: add a `packet_callback` to `handle_packet` and `handle_buf`
(@RyanGibb mirage/ocaml-dns#349)
* server: expose `update_data` (@RyanGibb mirage/ocaml-dns#350)
* resolver: b root name server IP change (@hannesm mirage/ocaml-dns#348)
* secondary server [mirage]: avoid infinite loop in connect (avoids SYN floods)
(@hannesm @reynir mirage/ocaml-dns#347)
* resolver, dns_zone: use consistently `Log` instead of `Logs` (@palainp mirage/ocaml-dns#342)
For out-of-band updates with the same semantics as DNS UPDATE. I've experimenting with a capnproto interface that uses this function.