Deprecating BIND 9.18+ on Windows (or making it community improved and supported)

[Ondřej Surý]

Hi,

we’ve been discussing the /subj for quite some time and we are either thinking about deprecating the BIND 9 on Windows completely or just handing it over to the “community supported” level.

There are couple reasons for the move:

* Neither the VisualStudio 2017 which we use nor VS2019 supports the C11 features we extensively use (stdatomic.h) which makes us to write a horrible horrible shims on top of Windows API
* No BIND 9 developer uses Windows even as secondary platform
* BIND 9 doesn’t compile on Windows 10 nor with VS2019 and that would require extensive work
* Windows now has WSL2 (https://docs.microsoft.com/en-us/windows/wsl/install-win10) that can be used to run BIND 9 natively

We think that the resources that would require us to support new Windows and Visual Studio versions would be better spent elsewhere and therefore we would like to deprecate the official support for Windows since BIND 9.18 (the next ESV, to be released in 2022), the Windows support for BIND 9.16 will be kept intact.

Now, there are two options:

a) The support will be completely dropped and the official way to run BIND 9 on Windows would be using WSL2
b) A volunteer will step up and improve the Windows implementation to support newer platforms and make it up to par with POSIX platforms.

1. Let me be absolutely clear here - we are not interested to keep the Windows port just on the life support, that would miss the point. It has been neglected for too long and if we are to keep it, there are several other areas that would need an improvement - the installer, the system integration and the build system would have to be extensively improved as well.

Thanks,
Ondrej
--
Ondřej SurÃœ (He/Him)
***@isc.org

[Timothe Litt]

This post might be inappropriate. Click to display it.

[Ondřej Surý]

Would reducing support to just the diagnostic tools be a helpful middle ground?

Not really. The tools use the same internal libraries for networking. And it would bring more complexity and not less complexity.

There’s no middle ground - it’s either making Windows the first class citizen or no citizen choice here.

Ondřej
--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.


_______________________________________________
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-***@lists.isc.org
https://li

[@lbutlr]

Post by Ondřej Surý
* Windows now has WSL2 (https://docs.microsoft.com/en-us/windows/wsl/install-win10) that can be used to run BIND 9 natively

I'd suggest this be the first listed reason as it pretty much makes all the other reasons irrelevant. OTOH, I don't have a dog in this race.
--
And she was drifting through the backyard And she was taking off her
dress And she was moving very slowly Rising up above the earth

_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[Richard T.A. Neal]

I would personally be very sad to see the end of BIND for Windows, but I don’t underestimate the challenges the ISC Team has in maintaining it.

Unfortunately I'm a VB.NET hobbyist programmer rather than a C/C++ developer so I can't speak to the usefulness of the following statement, but the latest version of Visual Studio 2019 does appear to support both C11 and C17:
https://devblogs.microsoft.com/cppblog/c11-and-c17-standard-support-arriving-in-msvc/

The installer problem is probably the easiest to fix, but I know it's a very small part of the overall headache. Caphyon offer free use of their Advanced Installer (which is what I use for WinBIND) and that can cope quite happily with installing & uninstalling running services.

The WSL2 option is an interesting one and not something I'd ever considered.

If we end up with option (a), which I suspect is the most likely outcome, I would at least like to offer to be the maintainer of the "BIND 9 on Windows via WSL2" documentation, but only if we can come up with a catchier name 😊

Richard.

-----Original Message-----
From: bind-users <bind-users-***@lists.isc.org> On Behalf Of Ondrej Surý
Sent: 29 April 2021 12:36 pm
To: BIND Users <bind-***@lists.isc.org>
Subject: Deprecating BIND 9.18+ on Windows (or making it community improved and supported)

Hi,

we’ve been discussing the /subj for quite some time and we are either thinking about deprecating the BIND 9 on Windows completely or just handing it over to the “community supported” level.

There are couple reasons for the move:

* Neither the VisualStudio 2017 which we use nor VS2019 supports the C11 features we extensively use (stdatomic.h) which makes us to write a horrible horrible shims on top of Windows API
* No BIND 9 developer uses Windows even as secondary platform
* BIND 9 doesn’t compile on Windows 10 nor with VS2019 and that would require extensive work
* Windows now has WSL2 (https://docs.microsoft.com/en-us/windows/wsl/install-win10) that can be used to run BIND 9 natively

We think that the resources that would require us to support new Windows and Visual Studio versions would be better spent elsewhere and therefore we would like to deprecate the official support for Windows since BIND 9.18 (the next ESV, to be released in 2022), the Windows support for BIND 9.16 will be kept intact.

Now, there are two options:

a) The support will be completely dropped and the official way to run BIND 9 on Windows would be using WSL2
b) A volunteer will step up and improve the Windows implementation to support newer platforms and make it up to par with POSIX platforms.

1. Let me be absolutely clear here - we are not interested to keep the Windows port just on the life support, that would miss the point. It has been neglected for too long and if we are to keep it, there are several other areas that would need an improvement - the installer, the system integration and the build system would have to be extensively improved as well.

Thanks,
Ondrej
--
Ondřej Surý (He/Him)
***@isc.org

_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bi

[Richard T.A. Neal]

I spent some time last week looking at options for running BIND under WSL on Windows Server. Unfortunately it doesn't presently look like a viable solution for the following reasons:

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.

There has been mixed success getting WSL2 to work in bridged mode, but it is not supported by MS. I expect many/most Windows server admins would not want to run something in an unsupported configuration which may suddenly stop working following a Windows Update.

At this time I don't therefore believe that running BIND via WSL or WSL2 on Windows Server is a viable reliable solution.

Best,

Richard.

-----Original Message-----
From: Richard T.A. Neal
Sent: 29 April 2021 6:41 pm
To: BIND Users <bind-***@lists.isc.org>
Subject: RE: Deprecating BIND 9.18+ on Windows (or making it community improved and supported)

<snip>
The WSL2 option is an interesting one and not something I'd ever considered.
</snip>

Richard.

_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[Ondřej Surý]

Post by Richard T.A. Neal
At this time I don't therefore believe that running BIND via WSL or WSL2 on Windows Server is a viable reliable solution.

Thanks for the analysis.

The alternative is as I outlined in the first email, somebody needs to step up
and start maintaining the BIND 9.18+ Windows version properly. FTR the
“somebody” doesn’t have to do it with their own hands.

Using mingw-w64 to compile BIND 9.18+ instead of using MSVC would be also
accepted as a contribution.

Ondrej
--
Ondřej Surý (He/Him)
***@isc.org

_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo

[Danny Mayer via bind-users]

Post by Ondřej Surý

Post by Richard T.A. Neal
At this time I don't therefore believe that running BIND via WSL or WSL2 on Windows Server is a viable reliable solution.

Thanks for the analysis.
The alternative is as I outlined in the first email, somebody needs to step up
and start maintaining the BIND 9.18+ Windows version properly. FTR the
“somebody” doesn’t have to do it with their own hands.
Using mingw-w64 to compile BIND 9.18+ instead of using MSVC would be also
accepted as a contribution.

As original developer of the Windows implementation I'd be happy to help
out and take this on. However, I would not be able to do this without
funding. If people want me to pursue this please let me know.

Danny

_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bin

[Robert M. Stockmann]

Date: Thu, 29 Apr 2021 13:35:32 +0200
Subject: Deprecating BIND 9.18+ on Windows (or making it community
improved and supported)
Hi,
we've been discussing the /subj for quite some time and we are either thinking about deprecating the BIND 9 on Windows completely or just handing it over to the "community supportedl"evel.
* Neither the VisualStudio 2017 which we use nor VS2019 supports the C11 features we extensively use (stdatomic.h) which makes us to write a horrible horrible shims on top of Windows API

Does bind 9 need C11 atomics ?
I would suggest what hardware are you running bind 9 on ? If its a
single core processor probably not, a dual core or higher i couldn't
say. If it's a 8 core Intel CPU with predictive branching , one
definitely needs C11 atomics, otherwise your Boeing 747 might disappear
from the sky. Then one could argue oh, i have this AMD multi-core CPU
which doesn't have these issues. And what about atomic problems
on a Quantum computer ? So far Quantum computers are not for sale at
Amazon, and of the Windows Quantum release on these machines the public
has no knowledge. For further background info see the section "Does the
kernel need C11 atomics?" inside the article "C11 atomic variables and
the kernel" By Jonathan Corbet, February 18, 2014
https://lwn.net/Articles/586838/

Best Regards,

Robert
--
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org ***@stokkie.net

_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[Tony Finch]

Post by Robert M. Stockmann
Does bind 9 need C11 atomics ?

Yes. BIND used to have its own atomic implementation but that kind of code
is tricky and arcane, so it's better to use the standard implementations
in the C library.

It is not just a matter of the hardware BIND runs on: atomics rely on
memory barriers that the compiler needs to know about, so that it does not
move code out of a critical section when reordering things for
optimization. And BIND is always multi-threaded and pre-emption can
happen at any time even on a single CPU.

Tony.
--
f.anthony.n.finch <***@dotat.at> https://dotat.at/
champion the freedom, dignity, and well-being of individuals

_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

[Ondřej Surý]

Hey,

just a follow-up with a recent real life example.

I’ve spent few days hunting a problem on Windows that got introduced by a fix to outgoing UDP selection code. While having bugs in normal (and this was really one-liner), it’s abnormal to not have tools for debugging the problem. Here’s the (incomplete) list of things that would have to be fixed:

1. Automatic crashdump collection in our CI - it should work, but it simply doesn’t and it also ignores the crashdump collection on the Hyper-V Windows Server 2016 I am using for building and debugging Windows binaries

2. Automatic crashdump processing - we need full backtrace printed for all the threads, both in the CI and as a “cookbook” for developers.

3. The build system rewrite - currently, the build system is this horrible hybrid of Perl that generated MSVC solution files (ninja-build or cmake would be sane alternatives)

4. Improvements like this: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5020 <— the new networking stack uses libuv where we setup listening on each netmgr thread, on Windows, we currently limit this to **single thread**. This branch is an attempt to use WS2 API to make Windows work same as the rest of platforms, but it fails horribly. It’s beyond our capacity to pursue this any further.

Currently, working on Windows feels like landing on an alien planet with failing lifesupport and finding these strange large eggs in the cavern while having Sigourney Weaver on the team.

Ondrej
--
Ondřej SurÃœ (He/Him)

Post by Ondřej Surý
Hi,
we’ve been discussing the /subj for quite some time and we are either thinking about deprecating the BIND 9 on Windows completely or just handing it over to the “community supported” level.
* Neither the VisualStudio 2017 which we use nor VS2019 supports the C11 features we extensively use (stdatomic.h) which makes us to write a horrible horrible shims on top of Windows API
* No BIND 9 developer uses Windows even as secondary platform
* BIND 9 doesn’t compile on Windows 10 nor with VS2019 and that would require extensive work
* Windows now has WSL2 (https://docs.microsoft.com/en-us/windows/wsl/install-win10) that can be used to run BIND 9 natively
We think that the resources that would require us to support new Windows and Visual Studio versions would be better spent elsewhere and therefore we would like to deprecate the official support for Windows since BIND 9.18 (the next ESV, to be released in 2022), the Windows support for BIND 9.16 will be kept intact.
a) The support will be completely dropped and the official way to run BIND 9 on Windows would be using WSL2
b) A volunteer will step up and improve the Windows implementation to support newer platforms and make it up to par with POSIX platforms.
1. Let me be absolutely clear here - we are not interested to keep the Windows port just on the life support, that would miss the point. It has been neglected for too long and if we are to keep it, there are several other areas that would need an improvement - the installer, the system integration and the build system would have to be extensively improved as well.
Thanks,
Ondrej
--
Ondřej SurÃœ (He/Him)

[Danny Mayer via bind-users]

Post by Ondřej Surý
Hey,
just a follow-up with a recent real life example.
1. Automatic crashdump collection in our CI - it should work, but it simply doesn’t and it also ignores the crashdump collection on the Hyper-V Windows Server 2016 I am using for building and debugging Windows binaries

If you build the binaries in debug mode does it give you the crashdump
collection? Hard to know without looking at the sources.

Post by Ondřej Surý
2. Automatic crashdump processing - we need full backtrace printed for all the threads, both in the CI and as a “cookbook” for developers.

What happens on Unix? If this is not out-of-the-box then you have to use
the microsoft tools to do that.

Post by Ondřej Surý
3. The build system rewrite - currently, the build system is this horrible hybrid of Perl that generated MSVC solution files (ninja-build or cmake would be sane alternatives)

When the build system was written, around 2001, there were not a lot of
alternatives. I was used to writing TCL but not a lot of people knew
that language. Perl was the popular choice. Today that would need to be
worth revisiting.

Post by Ondřej Surý
4. Improvements like this: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5020 <— the new networking stack uses libuv where we setup listening on each netmgr thread, on Windows, we currently limit this to **single thread**. This branch is an attempt to use WS2 API to make Windows work same as the rest of platforms, but it fails horribly. It’s beyond our capacity to pursue this any further.

Why is this single-threaded? The Windows code handling the incoming and
outgoing requests was always multithreaded. There was handling within
the Windows code to properly deal with the threads and locking that was
necessary.

Post by Ondřej Surý
Currently, working on Windows feels like landing on an alien planet with failing lifesupport and finding these strange large eggs in the cavern while having Sigourney Weaver on the team.

Well I had warned that there needed to be someone on the team to
properly deal with the Windows side.


Danny


_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/l

[Ondřej Surý]

Danny,

I didn’t write the email to put the blame anywhere or point fingers. I am just describing the situation.

Ondřej
--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

Post by Ondřej Surý
Hey,
just a follow-up with a recent real life example.
1. Automatic crashdump collection in our CI - it should work, but it simply doesn’t and it also ignores the crashdump collection on the Hyper-V Windows Server 2016 I am using for building and debugging Windows binaries

If you build the binaries in debug mode does it give you the crashdump collection? Hard to know without looking at the sources.

Post by Ondřej Surý
2. Automatic crashdump processing - we need full backtrace printed for all the threads, both in the CI and as a “cookbook” for developers.

What happens on Unix? If this is not out-of-the-box then you have to use the microsoft tools to do that.

Post by Ondřej Surý
3. The build system rewrite - currently, the build system is this horrible hybrid of Perl that generated MSVC solution files (ninja-build or cmake would be sane alternatives)

When the build system was written, around 2001, there were not a lot of alternatives. I was used to writing TCL but not a lot of people knew that language. Perl was the popular choice. Today that would need to be worth revisiting.

Post by Ondřej Surý
4. Improvements like this: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5020 <— the new networking stack uses libuv where we setup listening on each netmgr thread, on Windows, we currently limit this to **single thread**. This branch is an attempt to use WS2 API to make Windows work same as the rest of platforms, but it fails horribly. It’s beyond our capacity to pursue this any further.

Why is this single-threaded? The Windows code handling the incoming and outgoing requests was always multithreaded. There was handling within the Windows code to properly deal with the threads and locking that was necessary.

Post by Ondřej Surý
Currently, working on Windows feels like landing on an alien planet with failing lifesupport and finding these strange large eggs in the cavern while having Sigourney Weaver on the team.

Well I had warned that there needed to be someone on the team to properly deal with the Windows side.
Danny

_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman

[Danny Mayer]

I didn't think you were blaming anyone. I was just explaining the
history though my work on it largely stopped after 2008-9.

Danny

Post by Ondřej Surý
Danny,
I didn’t write the email to put the blame anywhere or point fingers. I am just describing the situation.
Ondřej
--
Ondřej Surý — ISC (He/Him)
My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

Post by Ondřej Surý
Hey,
just a follow-up with a recent real life example.
1. Automatic crashdump collection in our CI - it should work, but it simply doesn’t and it also ignores the crashdump collection on the Hyper-V Windows Server 2016 I am using for building and debugging Windows binaries

If you build the binaries in debug mode does it give you the crashdump collection? Hard to know without looking at the sources.

Post by Ondřej Surý
2. Automatic crashdump processing - we need full backtrace printed for all the threads, both in the CI and as a “cookbook” for developers.

What happens on Unix? If this is not out-of-the-box then you have to use the microsoft tools to do that.

Post by Ondřej Surý
3. The build system rewrite - currently, the build system is this horrible hybrid of Perl that generated MSVC solution files (ninja-build or cmake would be sane alternatives)

When the build system was written, around 2001, there were not a lot of alternatives. I was used to writing TCL but not a lot of people knew that language. Perl was the popular choice. Today that would need to be worth revisiting.

Post by Ondřej Surý
4. Improvements like this: https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/5020 <— the new networking stack uses libuv where we setup listening on each netmgr thread, on Windows, we currently limit this to **single thread**. This branch is an attempt to use WS2 API to make Windows work same as the rest of platforms, but it fails horribly. It’s beyond our capacity to pursue this any further.

Why is this single-threaded? The Windows code handling the incoming and outgoing requests was always multithreaded. There was handling within the Windows code to properly deal with the threads and locking that was necessary.

Post by Ondřej Surý
Currently, working on Windows feels like landing on an alien planet with failing lifesupport and finding these strange large eggs in the cavern while having Sigourney Weaver on the team.

Well I had warned that there needed to be someone on the team to properly deal with the Windows side.
Danny

_______________________________________________
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-use

[Richard T.A. Neal]

Could I ask if a conclusion has been reached regarding this? I know there was quite a bit of chatter in April/May but it's not clear to me whether any conclusions were reached.

If 9.16 is to be the last officially supported Windows version then have you decided yet which features from 9.17 will be backported into 9.16 and thus receive official support?

Easy example: DNS over HTTPS which I believe was initially hoped to be backported into BIND 9.16 around the April/May timeframe this year.

Thanks,

Richard.

-----Original Message-----
From: bind-users <bind-users-***@lists.isc.org> On Behalf Of Ondrej Surý
Sent: 29 April 2021 12:36 pm
To: BIND Users <bind-***@lists.isc.org>
Subject: Deprecating BIND 9.18+ on Windows (or making it community improved and supported)

Hi,

we’ve been discussing the /subj for quite some time and we are either thinking about deprecating the BIND 9 on Windows completely or just handing it over to the “community supported” level.

<snip>
_______________________________________________
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-***@lists.isc.org
https://lists.isc.o

[Ondřej Surý]

Hi Richard,

the current plan is to keep the Windows support for the lifetime of the 9.16 branch and then when 9.16 reaches-end-of-life do a snapshot of the last release and cherry-pick `dig.exe` into separate download because it was mentioned multiple times that people would like to keep dig binary. It’s going to be totally not supported, but it’s unlikely that security issue would be discovered in dig itself.

For the development branch, the June release (9.17.14) will be the last release with Windows support included. As soon as the code freeze is over, we are removing the Windows support code from main branch. And thus, next stable release 9.18 will not come with Windows as supported platform.

Ondřej
--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours.

Post by Richard T.A. Neal
Could I ask if a conclusion has been reached regarding this? I know there was quite a bit of chatter in April/May but it's not clear to me whether any conclusions were reached.
If 9.16 is to be the last officially supported Windows version then have you decided yet which features from 9.17 will be backported into 9.16 and thus receive official support?
Easy example: DNS over HTTPS which I believe was initially hoped to be backported into BIND 9.16 around the April/May timeframe this year.
Thanks,
Richard.
-----Original Message-----
Sent: 29 April 2021 12:36 pm
Subject: Deprecating BIND 9.18+ on Windows (or making it community improved and supported)
Hi,
we’ve been discussing the /subj for quite some time and we are either thinking about deprecating the BIND 9 on Windows completely or just handing it over to the “community supported” level.
<snip>
_______________________________________________
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
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-***@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-user

[Victoria Risk]

Post by Richard T.A. Neal
Could I ask if a conclusion has been reached regarding this? I know there was quite a bit of chatter in April/May but it's not clear to me whether any conclusions were reached.

We are pretty well decided that we will not support Windows with BIND 9.18. I see Ondrej replied on this point.

Post by Richard T.A. Neal
If 9.16 is to be the last officially supported Windows version then have you decided yet which features from 9.17 will be backported into 9.16 and thus receive official support?

We are not going to backport more features to 9.16 after this coming June release, because the priority is stabilizing 9.16. We want to declare 9.16 to be ‘ESV’ and put it into a more quiescent maintenance mode with the June release so users on 9.11 can migrate to 9.16.

Post by Richard T.A. Neal
Easy example: DNS over HTTPS which I believe was initially hoped to be backported into BIND 9.16 around the April/May timeframe this year.

We are probably at this point ready to announce that we have decided NOT to backport DoH to 9.16. We wanted to first check with our support customers, to see what impact this would have on them - but we feel at this point backporting DoH to 9.16 is not going to help stabilize 9.16, and 9.18 is not very far in the future, so we want to wait until 9.18 for a stable version with DoH in it.

However, we are also discussing, in response to the discussion here, creating a separate image for dig on Windows. This could be based on 9.17 and therefore could include dig for DoH. This is TBD but it seems like a reasonable possibility.

I hope this is a good compromise.

Vicky
_______________________________________________
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-***@lists.i