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.
Danny
On 6/10/21 10:19 AM, Timothe Litt wrote:
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.
_______________________________________________
Please 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
_______________________________________________
Please 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
