<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body>
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>
</body>
</html>