Re: Deprecation notice force BIND 9.20+: "rrset-order fixed" and "sortlist"
On 01/03/2024 11:02, Jim Reid wrote: On 1 Mar 2024, at 10:37, Greg Choules via bind-users wrote: In summary, Do the hard work of traffic steering somewhere else and let your DNS resolvers deliver the chosen answer. Don't make the resolvers themselves try to do this on the basis of incomplete information. Well said Greg! Leave it to the application to decide which is the best* address in the list of addresses returned from a DNS lookup. IMO the DNS (mostly) provides name-address mapping info and it’s up to whoever receives that info to decide how it gets processed and acted on. This is not a job for BIND or other DNS servers. * For some definition of best +1 -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Email migration and MX records
SMTP is a wonderful protocol that queues messages and retries delivery for 5 days so a non-responsive email server is no issue. Just do not have a temporary solution that bounces emails since those will never arrive (the sender is notified about the bounce). Marcus On 03/01/2023 21:31, Bruce Johnson via bind-users wrote: We’re making an O365 tenant switchover for our domain (a subdomain of the arizona.edu domain) and moving from our Barracuda cloud email SMTP to the University’s tenant, but email cannot flow until the Arizona.edu O365 tenant can take over our email domain. In anticipation I set our TTL for MX records quite low before the break (150 seconds) so, but the process may take up to an hour (if everything goes well ) Will setting our mx record to a bogus address cause email to bounce on the sending end and eventually get retried later after the mx record has been properly set to the Universities main smtp MX address? Or are we approaching this in the wrong way? Basically our end result is we want to stop accepting email from anywhere until the whole process has been changed and we have established the correct route so email starts flowing correctly. As it’s been explained to me the main campus tenant cannot start accepting email for our domain until we’ve transferred the email domain between tenants, so we cannot just change the MX record in our DNS server to the University’s (a Cisco Ironport setup) -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: plugin_version
Hi Ondrej, yeah, I was kinda expecting "no guarantees", but isn't the plugin_version() function a good method candidate to enforce compatibility? I mean, isn't increasing NS_PLUGIN_VERSION when a (plugin visible) data structure changes, a good way to enforce that only compatible plugins are used? Thanks, Marcus On 15/12/2022 19:32, Ondřej Surý wrote: Hi Marcus, I am afraid that we can’t provide any guarantees about the BIND 9 internal libraries. We made a decision to drop the layers and layers of compatibility for the sake of maintainability. That said, once the release is pronounced ESV (roughly a year from initial release), we try to minimize changes to that branch, but it could still happen if needed by a security fix. As for the binary compatibility, there’s no guarantee whatsoever, I think you need to match the full version to check whether the plug-in should be loaded. Honestly, the best way how to keep the plug-in that’s useful for wider audience maintained would be to contribute it to the BIND 9 with a promise that the authors will keep helping maintaining the plug-in. (We would like to avoid the situations where the author just dumps the code on us and don’t care anymore - there’s associated maintenance cost with any new feature.) Ondrej -- Ondřej Surý — ISC (He/Him) My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. On 15. 12. 2022, at 20:10, Marcus Kool wrote: Hi, I have written a plugin for named and was wondering what the policy behind the usage of plugin_version() is and what kind of compatibility check it intends to perform. It is common for plugins to use query_ctx_t and its members fname, view, client (client.message, client.query) etc. Since these data structures may change between (patch) versions, a plugin compiled for version A can get a SEGV signal because a data structure changed and the plugin is used inside named version B. I have little experience with data structure changes of named and observed only the addition of refresh_rrset in query_ctx (somewhere between 9.16.1 and 9.16.35) which did not cause an issue since its 1-byte size did not change offsets of most members inside the query_ctx struct. In our plugin, plugin_register() checks for the major and minor version number in named_g_version so a plugin compiled with 9.16.x refuses to initialize inside a 9.18.y named process and vice versa. But I have the impression that this might not be a 100% guarantee that all is well. Because we like to release as few as possible versions of the plugin I have a second question: how can we be sure that a plugin compiled with 9.X.1 will have no issues accessing named data structures for all patch versions of 9.X? Thanks, Marcus -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users-- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
plugin_version
Hi, I have written a plugin for named and was wondering what the policy behind the usage of plugin_version() is and what kind of compatibility check it intends to perform. It is common for plugins to use query_ctx_t and its members fname, view, client (client.message, client.query) etc. Since these data structures may change between (patch) versions, a plugin compiled for version A can get a SEGV signal because a data structure changed and the plugin is used inside named version B. I have little experience with data structure changes of named and observed only the addition of refresh_rrset in query_ctx (somewhere between 9.16.1 and 9.16.35) which did not cause an issue since its 1-byte size did not change offsets of most members inside the query_ctx struct. In our plugin, plugin_register() checks for the major and minor version number in named_g_version so a plugin compiled with 9.16.x refuses to initialize inside a 9.18.y named process and vice versa. But I have the impression that this might not be a 100% guarantee that all is well. Because we like to release as few as possible versions of the plugin I have a second question: how can we be sure that a plugin compiled with 9.X.1 will have no issues accessing named data structures for all patch versions of 9.X? Thanks, Marcus -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: when does bind calls plugin_destroy ?
On 28/11/2022 22:07, Evan Hunt wrote:
On Mon, Nov 28, 2022 at 12:53:16PM +, Marcus Kool wrote:
In a test setup there are two instances of the same plugin and everything
works as expected (plugin_register is called twice - once for each view).
However, "rndc reconfig" calls plugin_register again twice but does not call
plugin_destroy...
Are you sure it's not being run?
It is run, but...
I see random behavior while I do the same test: start named with unmodified config file with 2 views (each a plugin instance), run the same 40+ queries and reconfigure. repeat: a few more queries and
reconfigure
9.16.1 rarely sees plugin_destroy at first reconfigure, 40% at the second reconfigure for the first time, 60% at the third reconfigure for the first time. Thereafter, after each plugin_register there
is a plugin_destroy.
9.18.9 never seen plugin_destroy at first reconfigure, may take up to 4
reconfigures for plugin_destroy being called. Thereafter, after each
plugin_register there is a plugin_destroy.
So, does anyone know when plugin_destroy is called and perhaps how a plugin
can detect a reconfig is done and can deallocate resources for the plugins
registered at startup?
For each view, "rndc reconfig" is supposed to create and configure a new view,
move the zones from the old view to the new one, and then destroy the one.
The destroy function for the view should clean up plugins:
| if (view->plugins != NULL && view->plugins_free != NULL) {
| view->plugins_free(view->mctx, >plugins);
| }
view->plugins_free is a pointer to ns_plugins_free(), which calls
unload_plugin() for each plugin configured in the view, and that calls
the plugin_destroy() function defined in the module.
If you have the logging level set to debug(1), you should see "unloading
plugin" in your log file when this happens.
Yes, the "unloading plugin" matches the log messages of the plugin.
--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
when does bind calls plugin_destroy ?
Hi, I am developing a plugin for Bind. The API has 4 functions: plugin_register, plugin_check, plugin_version and plugin_destroy. In a test setup there are two instances of the same plugin and everything works as expected (plugin_register is called twice - once for each view). However, "rndc reconfig" calls plugin_register again twice but does not call plugin_destroy... This surprises me since the plugin has no knowledge of the reconfig and just initializes two more instances of the plugin without destroying the two that it created during startup. So, does anyone know when plugin_destroy is called and perhaps how a plugin can detect a reconfig is done and can deallocate resources for the plugins registered at startup? Thanks, Marcus -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
