-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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)
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.