<div dir="ltr">Good point !! Kind regards.</div><div class="gmail_extra"><br><div class="gmail_quote">On 12 September 2014 07:48, Carsten Strotmann <span dir="ltr"><<a href="mailto:carsten@strotmann.de" target="_blank">carsten@strotmann.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">Hello David,<br>
<br>
David Carlier wrote:<br>
</span><span class="">> it is compile setting via configure ...<br>
<br>
</span>I occasionally build installation packages of DNS servers for Unix<br>
systems (Linux, BSD, Solaris, MacOS X).<br>
<br>
Every compile time option can create a new package. Each combination of<br>
compile time options will create a new package etc etc.<br>
<br>
So for BIND 9.9.x I have<br>
<br>
plain<br>
without DNSSEC<br>
with Response Rate Limiting<br>
with DLZ<br>
with XML<br>
without DNSSEC with RRL<br>
without DNSSEC with DLZ<br>
without DNSSEC with XML<br>
with DNSSEC, XML and DLZ<br>
without DNSSEC, but with XML and DLZ<br>
....<br>
<br>
As a package maintainer I have a choice of enabling everything (but that<br>
is what administrators dislike for performance and security reasons), or<br>
selectively enable / disable compile-time features.<br>
<br>
Compile time options are great for people who build the software from<br>
source (or Gentoo users).<br>
<br>
Compile time options can be a package maintainers nightmare.<br>
<br>
One of the design goals of BIND 10 and now Bundy is to have less compile<br>
time decisions and more run-time dynamic loading through modules.<br>
<br>
With the modularization in Bundy, a package maintainer can enable all<br>
modules, and the user/administrator can decide which modules to load at<br>
runtime.<br>
<br>
For these reasons I would prefer a geolocation module.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Carsten<br>
</font></span></blockquote></div><br></div>