<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
<p>You might want to consider using the BIND9 docker image. With
docker and kubernetes which has an internal load balancer you can
run this on any Windows platform and don't need anything special.
You point to the IP address of the kubernetes load balancer and it
takes care of where to find the docker named image. This is
separate from the utilities like dig. Setting up the configuration
and the zones is a little more work but you won't need to worry
about keeping uptodate on the Windows images.</p>
<p>Danny<br>
</p>
<div class="moz-cite-prefix">On 6/10/21 10:19 AM, Timothe Litt
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:c419461b-9bcb-38b8-bd24-7ccf5151d4a3@acm.org">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
On 09-Jun-21 18:46, Richard T.A. Neal wrote:
<blockquote type="cite"
cite="mid:%3CLO2P123MB411051538277A9CF7A7824EDB3369@LO2P123MB4110.GBRP123.PROD.OUTLOOK.COM%3E">
<pre class="moz-quote-pre" wrap="">Evan Hunt wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">My understanding is BIND will still run fine under WSL; it's only the native Visual Studio builds that we're removing.
For people who want to run named on windows, WSL seems like the best way to go.
</pre>
</blockquote>
</blockquote>
<pre class="moz-quote-pre" wrap="">Sadly no. To quote myself from an earlier email on this topic:
There are two versions of WSL: WSL1 and WSL2. Development has all but ceased on WSL1, but WSL1 is the only version that can be installed on Windows Server 2019.
Microsoft have not yet confirmed whether WSL2 will be available for Windows Server vNext (Windows Server 2022, or whatever they name it).
Even if WSL2 is made available for Windows Server 2022 it has some serious networking limitations: it uses NAT from the host, so your Linux instance gets a private 172.x.y.z style IP address, and that IP address is different every reboot. Proxy port forwarding must therefore be reconfigured on every reboot as well.
Personally I'm comfortable with the decision that's been made and I understand the logic. Saddened, like saying goodbye to an old friend, but comfortable.
Richard.
</pre>
</blockquote>
<p>As I suggested early on, it would be great if the tools could
somehow be available as native binaries. Sounds like there's
progress there - thanks Evan!<br>
</p>
<p>As for running a BIND server, all things considered it seems to
me that the simplest approach is to create a bare-bones VM
running Linux. Run that on the windows server (use VMware,
VirtualBox) If the only things running in that machine are
named, a firewall, a text editor, logwatch, and backups, there's
really not much effort in keeping that machine running. Just
remember to do a distribution update once in a while (e.g. dnf
update/apt-get, etc). You might want to keep SeLinux/Apparmor,
but with no other services, it may not be worth the effort. You
can tailor Linux distributions down to a very minimal set of
services. It's often done for embedded applications. You can
even do the backups by snapshoting the VM.<br>
</p>
<p>You can update the zone files via UPDATE. You can update the
config (and zone files if you like) in the VM, or via an
exported directory from the Windoze host. (E.g. VirtualBox does
this trivially.)</p>
<p>This would completely eliminate the complexity of dealing with
the Windows networking stack - the Linux machine (and named)
just see an ethernet adapter (or two, or...) on the host's
network. (Mechanically, the VM's "adapter" injects and
retrieves raw ethernet packets into the driver stack very close
to the wire.) No NAT or proxy (unless you want it, in which
case it can be static.) And whatever kernel features/networking
libraries ISC uses are just there - no porting.<br>
</p>
<p>I haven't measured performance, but I do run my Linux machines
in VirtualBox VMs (mostly hosted on a Linux server, but some on
Windows). I haven't run into issues - but then I'm not a big
operator. I do use CPUs (and IO) with hardware virtualization
support. <br>
</p>
<p>In any case, the workload on ISC would be zero - unless they
choose to provide the VM (there are portable formats). That
work might be something that someone who wants a Windows
solution could afford to sponsor. The biggest part would be
scripting packaging from the selected distro and a test system.
Plus a bit of keeping it up-to-date. And documentation.
Optionally, someone might want to do some
configuration/performance tuning - but most of that is what ISC
does anyway inside the VM. Again, the work would seem to be
something that the Windows community could donate and/or
sponsor.</p>
<p>It might even be the case that ISC could use the same VM as
part of its test suite - many CI engines are using that approach
to get wide coverage with minimal hardware. (The CI folks, like
GitHub Actions, GitLab, etc spin up a VM, install the OS and
minimal packages, then run your tests.)<br>
</p>
<p>I confess that this is a practical approach - it won't satisfy
those who insist on a "pure" windows solution. (Though I bet if
you looked inside their routers, storage, phone systems, and
certainly cars there'd be Linux purring away under the hood...)
Nor anyone who thinks that the status quo is ideal or that only
a "no effort" solution is acceptable. Anyhow, it's not an
attempt to start a religious war or to prolong the debate on
what ISC does. It assumes BIND won't support windows, that WSL
is imperfect, and that an alternative to complaining might be
helpful... Feel free to
s/Linux/(Solaris|FreeBSD|VMS|yourfavorite/g.<br>
</p>
<p>I don't have a need for BIND (except the tools) under Windows,
so I'm not volunteering to implement this.<br>
</p>
<p>FWIW.<br>
</p>
<pre class="moz-signature" cols="72">Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. </pre>
<p><br>
</p>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Please visit <a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a> to unsubscribe from this list
ISC funds the development of this software with paid support subscriptions. Contact us at <a class="moz-txt-link-freetext" href="https://www.isc.org/contact/">https://www.isc.org/contact/</a> for more information.
bind-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:bind-users@lists.isc.org">bind-users@lists.isc.org</a>
<a class="moz-txt-link-freetext" href="https://lists.isc.org/mailman/listinfo/bind-users">https://lists.isc.org/mailman/listinfo/bind-users</a>
</pre>
</blockquote>
</body>
</html>