No more support for windows

[Timothe Litt]

On 09-Jun-21 18:46, Richard T.A. Neal wrote:
> Evan Hunt wrote:
>
>>> 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.
> 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.

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!

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.

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.)

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.

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. 

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.

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.)

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.

I don't have a need for BIND (except the tools) under Windows, so I'm
not volunteering to implement this.

FWIW.

Timothe Litt
ACM Distinguished Engineer
--------------------------
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210610/af626d66/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210610/af626d66/attachment-0001.bin>