9.3.0beta3 on Windows Feedback
mayer at gis.net
Fri May 14 13:28:17 UTC 2004
Wesley, sorry about the delay in responding, I'm swamped.
At 12:16 PM 5/11/2004, Wesley Griffin wrote:
>9.3.0beta3 looks to be mostly working on Windows.
>Below are some notes I made. If it looks like I'm doing something
>against the recommended procedures then please let me know.
>Compiled on XP Professional with the Feb 2003 Platform SDK and Visual
>Studio .NET 2003. Using the environment shells provided by the dev
>tools, compilation went pretty smoothly.
>One suggestion, can the libdns.mak file be changed to look at C:\OPENSSL
>for the OpenSSL libraries? The installation instructions for OpenSSL
>already suggest that for an installation location, and it would mean not
>being tied to a relative reference of ../../openssl-0.9.6k.
That's been an issue for a while. With the versions of OpenSSL constantly
I needed to come up with general solutions that will figure out what the
available is (or ask) and then set it up properly.
>It also turns out that libdns would not link correctly until gdi32.lib
>was added to the list of libs on the LINK command.
>Once I added gdi32.lib, I didn't see any compilation or link errors.
That's odd, since neither VS 6.0 nor VS.Net needed it. Can you use depends to
see which dll requires it? gdi32 is a graphics library. so only BINDInstall
>Deployment was to Windows Server 2003 (Enterprise Edition, although I
>doubt that matters). Without any additional software (i.e. OpenSSL or
>Perl). It turns out I had to copy the MFC71.DLL and MSVCR71.DLL to the
>server to get BINDInstall to run.
Looks like that version changed the requirements from M*70.DLL to M*71.DLL
which is what's in the configuration. Again can you check using depends?
Does named require them?
>Once installed named, dig, rndc-confgen, rndc, and dnssec-keygen ran
>I had to manually reset the named account password to something. I'm not
>sure if the account had the password created or not, but the ISC BIND
>service would not start until I had reset the password in the user
BINDInstall creates the account with the password you provide.
You also need need to set up the permissions on the directory where the
files live so that named can read and write the various files.
>dnssec-signzone generated a keyset- and dsset- file but didn't generate
>a signed zone file, instead leaving a zero length .tmp file in the
>directory. Here's the event log output for dnssec-signzone:
>Faulting application dnssec-signzone.exe, version 0.0.0.0, faulting
>module ntdll.dll, version 5.2.3790.0, fault address 0x0001d61b.
>The application, C:\WINDOWS\System32\dns\bin\dnssec-signzone.exe,
>generated an application error The error occurred on 05/11/2004 @
>12:07:34.808 The exception generated was c0000005 at address 77F5D61B
You'll have to run the debugger to figure that one out. It doesn't like a
with the locking (WaitForCriticalSection).
>named-checkconf and named-checkzone don't seem to be working. Neither of
>them report any errors in deliberately typo-ed conf and zone files. (I
>discovered this because I had a typo in the conf and zone file and they
>were only caught when starting named. There is not event log output when
>running these from the command line.
They're supposed to be identical with what named uses when it loads
the configuration files. File a bug report.
>However, on restart I get this entry multiple times in the event log:
>Reporting queued error: faulting application named-checkzone.exe,
>version 0.0.0.0, faulting module ntdll.dll, version 5.2.3790.0, fault
>For both named-checkzone.exe and named-checkconf.exe.
Why does this sound more like a Microsoft bug?
>Finally, dnssec-makekeyset and dnssec-signkey are still being built and
Shouldn't they be?
More information about the bind-workers