BIND issueshttps://gitlab.isc.org/isc-projects/bind9/-/issues2019-06-05T18:29:42Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1064Adding --enable-pthread-rwlock broke Windows build2019-06-05T18:29:42ZMichał KępieńAdding --enable-pthread-rwlock broke Windows build!1397 broke the Windows build:
https://jenkins.isc.org/view/BIND_Parameterized/job/bind9-parameterized-win2012-x64/306/console
(Here is a build of the same commit as above, but with !1397 reverted: https://jenkins.isc.org/view/BIND_Par...!1397 broke the Windows build:
https://jenkins.isc.org/view/BIND_Parameterized/job/bind9-parameterized-win2012-x64/306/console
(Here is a build of the same commit as above, but with !1397 reverted: https://jenkins.isc.org/view/BIND_Parameterized/job/bind9-parameterized-win2012-x64/307/console)
This needs to be fixed before 9.15.1 is tagged (i.e. within the next week).BIND 9.15.1Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1114GeoIP2 support breaks compilation on Windows2019-07-03T16:53:20ZMichał KępieńGeoIP2 support breaks compilation on Windows```
c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2017\lib\dns\include\dns\geoip.h(110): error C2016: C requires that a struct or union has at least one member [c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-...```
c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2017\lib\dns\include\dns\geoip.h(110): error C2016: C requires that a struct or union has at least one member [c:\cygwin64\home\jenkins\workspace\bind9-master-win2012-x64-vs2017\lib\ns\win32\libns.vcxproj]
```
https://jenkins.isc.org/job/bind9-master-win2012-x64-vs2017/247/BIND 9.15.2https://gitlab.isc.org/isc-projects/bind9/-/issues/1245named.exe crashes when attempting to use a statistics channel2022-09-01T13:27:02ZMichał Kępieńnamed.exe crashes when attempting to use a statistics channelOn Windows, trying to fetch any data from a `named` instance configured with a `statistics-channel` causes a crash. The problem is caused by lack of proper libxml2 initialization and it seems we have been missing some code all along, th...On Windows, trying to fetch any data from a `named` instance configured with a `statistics-channel` causes a crash. The problem is caused by lack of proper libxml2 initialization and it seems we have been missing some code all along, though for some reason I cannot trigger the bug with older BIND for Windows releases even though `statistics-channel` was introduced in 2008 and the lines of libxml2 code which I believe to be the culprit (the ones we are not currently executing in `named` while we should) have been added earlier, in 2003. BIND 9.11.4 is the first ISC release where I can trigger the problem, but as there are some further oddities involved[^1], I lack the time to investigate every bit of this problem in detail, but we are definitely doing something wrong.
[^1]: BIND 9.11.2 for Windows was built and linked against libxml2 2.9.1, then 9.11.3 moved to 2.9.6, but 9.11.4 reverted to 2.9.1...October 2019 (9.11.12, 9.14.7, 9.15.5)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1310Fix system tests on Windows after merging libuv work2019-11-29T07:48:12ZMichał KępieńFix system tests on Windows after merging libuv workMerging !2528 broke a significant number of system tests on Windows.
In Jenkins, the following tests failed (I only performed one run so far):
- `autosign`
- `digdelv`
- `dnssec`
- `keepalive`
- `legacy`
- `mirror`
- `mkeys`
- ...Merging !2528 broke a significant number of system tests on Windows.
In Jenkins, the following tests failed (I only performed one run so far):
- `autosign`
- `digdelv`
- `dnssec`
- `keepalive`
- `legacy`
- `mirror`
- `mkeys`
- `nsupdate`
- `padding`
- `pipelined`
- `rpz`
- `rrl`
- `statistics`
- `stub`
- `synthfromdnssec`
- `tkey`
- `upforwd`
- `wildcard`
- `zero`
See: https://jenkins.isc.org/view/BIND_Parameterized/job/bind9-parameterized-win2012-x64/353/console
I also did one test run in GitLab CI[^1] and the failed tests were those listed above + the `pending` system test.
Some notes:
- The `zero` system test alone takes some 15-20 *minutes* to complete on Windows. I recall having issues with this test when I was first trying to add Windows to GitLab CI. From what I recall, the issue was that a significant number of queries are sent during that test and Windows is just unable to keep up with logging at `-d 99`. I initially worked around it by putting `named.args` files in place that did *not* include `-d 99` because all those logs are not really needed in that test. However, I eventually came up with a different fix (!2398) that seemed to be good enough until now. Perhaps decreasing logging verbosity is what we will need in the end? I have not yet investigated why that test takes so long to complete with current *master*.
- In the `nsupdate` test, `named` hangs in weird ways - both in Jenkins and GitLab CI, I had to "intervene" by killing binaries manually or else the test was stuck. FWIW, I have not yet tried running that test on its own, it was always run as part of the whole test suite.
**While we can skip a single development release on Windows, releasing BIND 9.16.0 will require sorting all these issues out.**
[^1]: !2556 is a prerequisite for *any* system test to work in GitLab CIDecember 2019 (9.11.14, 9.14.9, 9.15.7)https://gitlab.isc.org/isc-projects/bind9/-/issues/1566Prevent tools from using ports which clash with named instances in system tests2020-02-05T10:03:13ZMichał KępieńPrevent tools from using ports which clash with named instances in system testsWindows is affected by #905 and #925, too:
- https://gitlab.isc.org/isc-private/bind9/-/jobs/571917
- https://gitlab.isc.org/isc-private/bind9/-/jobs/572857
Since `isc_net_getudpportrange()` on Windows [returns][1] a hardcoded rang...Windows is affected by #905 and #925, too:
- https://gitlab.isc.org/isc-private/bind9/-/jobs/571917
- https://gitlab.isc.org/isc-private/bind9/-/jobs/572857
Since `isc_net_getudpportrange()` on Windows [returns][1] a hardcoded range of ports, the simplest solution is to raise `ISC_NET_PORTRANGELOW` to something like 32768.
[1]: https://gitlab.isc.org/isc-projects/bind9/blob/9c5547b1185a7b780554145ce28368d53ebe621f/lib/isc/win32/net.c#L248-262February 2020 (9.11.16, 9.14.11, 9.16.0, 9.16.0-S)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1742Logging is broken on Windows2020-04-08T13:28:32ZMichał KępieńLogging is broken on Windows3a24eacbb619b89eacf87281b4d1a73e68c19471 (!3321) seems to be the
culprit.
Last scheduled *master* pipeline for which Windows (mostly) worked:
https://gitlab.isc.org/isc-projects/bind9/pipelines/38307
- https://gitlab.isc.org/isc-pro...3a24eacbb619b89eacf87281b4d1a73e68c19471 (!3321) seems to be the
culprit.
Last scheduled *master* pipeline for which Windows (mostly) worked:
https://gitlab.isc.org/isc-projects/bind9/pipelines/38307
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/802733
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/802734
First scheduled *master* pipeline for which Windows is broken:
https://gitlab.isc.org/isc-projects/bind9/pipelines/38401
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/804958
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/804959
I narrowed it down to 3a24eacbb619b89eacf87281b4d1a73e68c19471 by
testing the merge requests merged between these two scheduled pipelines.April 2020 (9.11.18, 9.16.2, 9.17.1)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1698Converting isc_log to RWLOCK broke Windows2020-03-24T04:47:48ZOndřej SurýConverting isc_log to RWLOCK broke WindowsThe !3229 broke Windows system tests - the tests are stuck indefinitely. See https://gitlab.isc.org/isc-projects/bind9/-/jobs/777703 (ondrej/msvc-stuck-v1 branch) as example vs https://gitlab.isc.org/isc-projects/bind9/-/jobs/777784 (on...The !3229 broke Windows system tests - the tests are stuck indefinitely. See https://gitlab.isc.org/isc-projects/bind9/-/jobs/777703 (ondrej/msvc-stuck-v1 branch) as example vs https://gitlab.isc.org/isc-projects/bind9/-/jobs/777784 (ondrej/msvc-stuck-v2 branch).
There's nothing really obvious, but converting the rwlocks to native Windows SRWLock doesn't help, so it must be a way how we are using the locks on Windows.April 2020 (9.11.18, 9.16.2, 9.17.1)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1669"kasp" system test is failing consistently on Windows2020-04-09T06:50:14ZMichał Kępień"kasp" system test is failing consistently on WindowsThe same four checks always fail on Windows:
```
kasp1.log-I:kasp:check next key event for zone step2.algorithm-roll.kasp (570)
kasp1.log-I:kasp:error: bad next key event time 20909 for zone step2.algorithm-roll.kasp (expect 21600)
kasp...The same four checks always fail on Windows:
```
kasp1.log-I:kasp:check next key event for zone step2.algorithm-roll.kasp (570)
kasp1.log-I:kasp:error: bad next key event time 20909 for zone step2.algorithm-roll.kasp (expect 21600)
kasp1.log:I:kasp:failed
--
kasp1.log-I:kasp:check next key event for zone step5.algorithm-roll.kasp (594)
kasp1.log-I:kasp:error: bad next key event time 24513 for zone step5.algorithm-roll.kasp (expect 25200)
kasp1.log:I:kasp:failed
--
kasp1.log-I:kasp:check next key event for zone step2.csk-algorithm-roll.kasp (618)
kasp1.log-I:kasp:error: bad next key event time 20916 for zone step2.csk-algorithm-roll.kasp (expect 21600)
kasp1.log:I:kasp:failed
--
kasp1.log-I:kasp:check next key event for zone step5.csk-algorithm-roll.kasp (642)
kasp1.log-I:kasp:error: bad next key event time 24519 for zone step5.csk-algorithm-roll.kasp (expect 25200)
kasp1.log:I:kasp:failed
--
kasp2.log-I:kasp:check next key event for zone step2.algorithm-roll.kasp (570)
kasp2.log-I:kasp:error: bad next key event time 20956 for zone step2.algorithm-roll.kasp (expect 21600)
kasp2.log:I:kasp:failed
--
kasp2.log-I:kasp:check next key event for zone step5.algorithm-roll.kasp (594)
kasp2.log-I:kasp:error: bad next key event time 24559 for zone step5.algorithm-roll.kasp (expect 25200)
kasp2.log:I:kasp:failed
--
kasp2.log-I:kasp:check next key event for zone step2.csk-algorithm-roll.kasp (618)
kasp2.log-I:kasp:error: bad next key event time 20962 for zone step2.csk-algorithm-roll.kasp (expect 21600)
kasp2.log:I:kasp:failed
--
kasp2.log-I:kasp:check next key event for zone step5.csk-algorithm-roll.kasp (642)
kasp2.log-I:kasp:error: bad next key event time 24564 for zone step5.csk-algorithm-roll.kasp (expect 25200)
kasp2.log:I:kasp:failed
--
kasp3.log-I:kasp:check next key event for zone step2.algorithm-roll.kasp (570)
kasp3.log-I:kasp:error: bad next key event time 20936 for zone step2.algorithm-roll.kasp (expect 21600)
kasp3.log:I:kasp:failed
--
kasp3.log-I:kasp:check next key event for zone step5.algorithm-roll.kasp (594)
kasp3.log-I:kasp:error: bad next key event time 24539 for zone step5.algorithm-roll.kasp (expect 25200)
kasp3.log:I:kasp:failed
--
kasp3.log-I:kasp:check next key event for zone step2.csk-algorithm-roll.kasp (618)
kasp3.log-I:kasp:error: bad next key event time 20943 for zone step2.csk-algorithm-roll.kasp (expect 21600)
kasp3.log:I:kasp:failed
--
kasp3.log-I:kasp:check next key event for zone step5.csk-algorithm-roll.kasp (642)
kasp3.log-I:kasp:error: bad next key event time 24545 for zone step5.csk-algorithm-roll.kasp (expect 25200)
kasp3.log:I:kasp:failed
```
I am not sure how long this has been going on because another Windows-specific issue (!3184) has been masking this problem.
@matthijs: I have not yet looked at this problem closely, please take a look if you have some time. Keep in mind that the `kasp` test takes a lot more to run on Windows than on Unix systems (about 15 minutes; yes, you read that right). We will need to get this fixed before tagging or else we will have trouble producing release tarballs (as CI pipelines will not be able to pass).April 2020 (9.11.18, 9.16.2, 9.17.1)https://gitlab.isc.org/isc-projects/bind9/-/issues/1755Tune the Windows build, so we can use /WX (equivalent of -Werror)2020-04-29T11:30:40ZOndřej SurýTune the Windows build, so we can use /WX (equivalent of -Werror)Currently, Windows build files have "Level3" set for the warning. We need to fix the Windows code and also fine-tune the warning level, so we can actually use `/WX` option that would break the build if there's a warning on Windows.Currently, Windows build files have "Level3" set for the warning. We need to fix the Windows code and also fine-tune the warning level, so we can actually use `/WX` option that would break the build if there's a warning on Windows.May 2020 (9.11.19, 9.11.19-S1, 9.14.12, 9.16.3)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1899TCP Accept Refactoring broke Windows2020-06-08T12:19:30ZOndřej SurýTCP Accept Refactoring broke WindowsThe !3320 that got merged to master broke TCP connections on Windows. This needs to be fixed on master (before we release next 9.17.2) and also before we merged the backport to the BIND 9.16 branch.The !3320 that got merged to master broke TCP connections on Windows. This needs to be fixed on master (before we release next 9.17.2) and also before we merged the backport to the BIND 9.16 branch.June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/1867Fix the system tests on Windows2020-07-14T12:50:33ZOndřej SurýFix the system tests on WindowsNow, that the BIND 9 builds on Windows again, we need to fix the system tests:
```
$ & sh.exe runall.sh $TEST_PARALLEL_JOBS
/bin/bash: ./run.sh: No such file or directory
[...]
/bin/bash: ./run.sh: No such file or directory
I:System test...Now, that the BIND 9 builds on Windows again, we need to fix the system tests:
```
$ & sh.exe runall.sh $TEST_PARALLEL_JOBS
/bin/bash: ./run.sh: No such file or directory
[...]
/bin/bash: ./run.sh: No such file or directory
I:System test result summary:
I:Found 0 test results, but 95 tests were run
```June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/1774Get Windows builds working again2020-05-29T12:31:25ZMichał KępieńGet Windows builds working againThe following discussion from !985 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_125128): (+1 comment)
> Fair enough, but there is a ton of `#if _MSC_...The following discussion from !985 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/985#note_125128): (+1 comment)
> Fair enough, but there is a ton of `#if _MSC_VER ...` conditional blocks
> still out there. Something to address in a separate issue? (Or when we
> try to fix Windows builds?)June 2020 (9.11.20, 9.11.20-S1, 9.16.4, 9.17.2)https://gitlab.isc.org/isc-projects/bind9/-/issues/1988bad output rndc dnssec -status on Windows2020-07-16T07:03:47ZMatthijs Mekkingmatthijs@isc.orgbad output rndc dnssec -status on WindowsThe following discussion from !3780 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3780#note_144605): (+1 comment)
> This looks fine to me, though I started a p...The following discussion from !3780 should be addressed:
- [ ] @michal started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/3780#note_144605): (+1 comment)
> This looks fine to me, though I started a pipeline including Windows
> system tests that I would like to complete successfully before merging
> this MR:
>
> https://gitlab.isc.org/isc-projects/bind9/pipelines/45755August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2031Windows crashes with netmgr-based statschannel2020-07-27T21:33:09ZMichał KępieńWindows crashes with netmgr-based statschannelThe following crash happened in the `statistics` system test for both
Windows builds (Release and Debug) in a [pipeline][1] run for
f27c0c32572aad530514700ab2033f20c897c3f4:
```
16-Jul-2020 21:34:32.694 c:\builds\isc-projects\bind9\lib\...The following crash happened in the `statistics` system test for both
Windows builds (Release and Debug) in a [pipeline][1] run for
f27c0c32572aad530514700ab2033f20c897c3f4:
```
16-Jul-2020 21:34:32.694 c:\builds\isc-projects\bind9\lib\isc\buffer.c:76: REQUIRE((((b) != ((void *)0)) && (((const isc__magic_t *)(b))->magic == (0x42756621U)))) failed
```
Given that:
- I have not seen such crashes before,
- a pipeline ran for d8e6b32a18e6d4cc17830af237c00899de1c4912 did not
trigger these crashes,
- the only code-related MR merged between the last successful pipeline
and the first crashing one was !3847,
there is a fair chance that !3847 introduced a Windows-specific bug (or
a generic one that is simply easier to trigger on Windows).
@each: assigning you as the author for !3847, please take a look.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/pipelines/46984August 2020 (9.11.22, 9.11.22-S1, 9.16.6, 9.17.4)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/1919Fix documentation install on Windows2020-09-03T10:09:46ZOndřej SurýFix documentation install on WindowsCurrently the `libisc.vcxproj` contains stuff like this:
```
echo Copying the ARM and the Installation Notes.
copy ..\COPYRIGHT ..\Build\Release
copy ..\README ..\Build\Release
copy ..\HISTORY ..\Build\Release
copy readme1st.txt ..\Buil...Currently the `libisc.vcxproj` contains stuff like this:
```
echo Copying the ARM and the Installation Notes.
copy ..\COPYRIGHT ..\Build\Release
copy ..\README ..\Build\Release
copy ..\HISTORY ..\Build\Release
copy readme1st.txt ..\Build\Release
copy index.html ..\Build\Release
copy ..\doc\arm\*.html ..\Build\Release
copy ..\doc\arm\Bv9ARM.pdf ..\Build\Release
copy ..\CHANGES ..\Build\Release
if Exist ..\CHANGES.SE copy ..\CHANGES.SE ..\Build\Release
copy ..\FAQ ..\Build\Release
```
As we currently don't build the documentation on Windows and we don't store it in git, I think the right way forward is to cherry-pick the artifact files from the `docs` build into the Windows zip file.September 2020 (9.11.23, 9.11.23-S1, 9.16.7, 9.17.5)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2015Shutdown crash on Windows: lib\isc\netmgr\netmgr.c:275: INSIST(r == 0) failed2020-09-30T15:57:30ZMichał KępieńShutdown crash on Windows: lib\isc\netmgr\netmgr.c:275: INSIST(r == 0) failedFirst observed in a scheduled pipeline run for
1dd265df8f5540c3c89d92ff9b364994bf96138d:
https://gitlab.isc.org/isc-projects/bind9/-/jobs/1014592
I am only making the issue confidential out of abundance of caution as
the crash seems to...First observed in a scheduled pipeline run for
1dd265df8f5540c3c89d92ff9b364994bf96138d:
https://gitlab.isc.org/isc-projects/bind9/-/jobs/1014592
I am only making the issue confidential out of abundance of caution as
the crash seems to be caused by a [call][1] to `uv_loop_close()`
returning a non-zero value.
[1]: https://gitlab.isc.org/isc-projects/bind9/-/blob/1dd265df8f5540c3c89d92ff9b364994bf96138d/lib/isc/netmgr/netmgr.c#L274October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Witold KrecickiWitold Krecickihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2328Windows system tests fail after Network Manager refactoring2020-12-02T22:41:41ZMichal NowakWindows system tests fail after Network Manager refactoringNearly all system test on Windows [fail](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1335899) after https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4444:
```
01-Dec-2020 20:24:00.891 c:\builds\isc-projects\bind9\lib\isc\n...Nearly all system test on Windows [fail](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1335899) after https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/4444:
```
01-Dec-2020 20:24:00.891 c:\builds\isc-projects\bind9\lib\isc\netmgr\netmgr.c:2053: unexpected error:
01-Dec-2020 20:24:00.891 socket() failed: Unknown error
01-Dec-2020 20:24:00.891 c:\builds\isc-projects\bind9\lib\isc\netmgr\netmgr.c:178: REQUIRE(result == 0) failed
01-Dec-2020 20:24:00.891 exiting (due to assertion failure)
```December 2020 (9.11.26, 9.11.26-S1, 9.16.10, 9.16.10-S1, 9.17.8)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2555journal test fails on Windows2021-03-22T10:46:56ZMichal Nowakjournal test fails on WindowsThe newly added `journal` system test [fails](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1553451) on Windows on `v9_16`:
```
S:journal:2021-03-04T19:27:15-0800
T:journal:1:A
A:journal:System test journal
I:journal:PORTRANGE:8800 - ...The newly added `journal` system test [fails](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1553451) on Windows on `v9_16`:
```
S:journal:2021-03-04T19:27:15-0800
T:journal:1:A
A:journal:System test journal
I:journal:PORTRANGE:8800 - 8899
I:journal:starting servers
I:journal:check outdated journal rolled forward (dynamic) (1)
I:journal:check outdated empty journal did not cause an error (dynamic) (2)
I:journal:check outdated journals were updated or removed (dynamic) (3)
I:journal:failed
I:journal:check updated journal has correct RR count (dynamic) (4)
I:journal:failed
I:journal:check new-format journal rolled forward (dynamic) (5)
I:journal:check new-format empty journal did not cause error (dynamic) (6)
I:journal:check new-format journals were updated or removed (dynamic) (7)
I:journal:check outdated up-to-date journal succeeded (ixfr-from-differences) (8)
I:journal:check outdated journal was updated (ixfr-from-differences) (9)
I:journal:failed
I:journal:check journal with mixed headers succeeded (version 1,2,1,2) (10)
I:journal:check journal with mixed headers was updated (version 1,2,1,2) (11)
I:journal:failed
I:journal:check journal with mixed headers succeeded (version 2,1,2,1) (12)
I:journal:check journal with mixed headers was updated (version 2,1,2,1) (13)
I:journal:failed
I:journal:check there are no journals left un-updated (14)
I:journal:failed
I:journal:check journal downgrade/upgrade (15)
I:journal:check max-journal-size works after journal update (16)
I:journal:failed
I:journal:check max-journal-size works with non-updated journals (17)
I:journal:check journal index consistency (18)
I:journal:exit status: 7
I:journal:stopping servers
I:journal:pytest not installed, skipping python tests
R:journal:FAIL
E:journal:2021-03-04T19:27:25-0800
```
Starting with this test failing:
```
I:journal:check outdated journals were updated or removed (dynamic) (3)
I:journal:failed
```
It's `changed.db.jnl` file has the `;BIND LOG V9` version header but `;BIND LOG V9.2` is expected (as happens on Unix).March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/issues/2519named won't start on Windows2021-03-02T14:41:07ZMichal Nowaknamed won't start on WindowsNearly all Windows [system tests fail](https://gitlab.isc.org/isc-projects/bind9/-/pipelines/64375) on `main` since February 19 like this:
```
S:acl:2021-02-22T20:20:39-0800
T:acl:1:A
A:acl:System test acl
I:acl:PORTS:5322,5323,5324,5325...Nearly all Windows [system tests fail](https://gitlab.isc.org/isc-projects/bind9/-/pipelines/64375) on `main` since February 19 like this:
```
S:acl:2021-02-22T20:20:39-0800
T:acl:1:A
A:acl:System test acl
I:acl:PORTS:5322,5323,5324,5325,5326,5327,5328,5329,5330,5331,5332,5333,5334
I:acl:starting servers
I:acl:Couldn't start server C:/builds/isc-projects/bind9/Build/Release/named.exe -D acl-ns2 -X named.lock -m record,size,mctx -c named.conf -d 99 -g -U 4 -T maxcachesize=2097152 >named.run 2>&1 & echo $! (pid=2678)
I:acl:failed
kill: 2678: No such process
I:acl:starting servers failed
R:acl:FAIL
E:acl:2021-02-22T20:20:56-0800
```
I'll investigate further.March 2021 (9.11.29, 9.11.29-S1, 9.16.13, 9.16.13-S1, 9.17.11)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2514Windows 10 Insider Dev fails to resolve DoH queries against BIND2021-03-29T12:31:49ZtriaticWindows 10 Insider Dev fails to resolve DoH queries against BIND<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please do *NOT* report it here, but send an
email to [security-officer@isc.org](security-officer@isc.org).
-->
### Summary
I cannot get DNS over HTTPS in BIND to work with Windows 10 Insider Dev, whereas I have no problems with Unbound. Unbound returns the full chain for my letsencrypt tls certificate whereas BIND does not, which may explain it.
### BIND version used
BIND 9.17.10-1+ubuntu20.10.1+isc+1-Ubuntu (Development Release) <id:>
### Steps to reproduce
Install Windows 10 Insider (Dev channel) and attempt to resolve queries against a BIND DoH server configured with a letsencrypt (or similar) certificate.
### What is the current *bug* behavior?
DNS resolution fails.
### What is the expected *correct* behavior?
DNS resolution should succeed.April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Artem BoldarievArtem Boldariev