No more support for windows

Thu Jun 10 15:19:09 UTC 2021

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 at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20210610/b5570ea9/attachment.htm>