Building/compiling BIND 4.9.3 for Windows NT

To automate the build run the file buildallnt.bat... then run the
file install.bat in the contrib\winnt-dist directory (i.e. step 10 below)...
or to build BIND manually follow these steps...

NOTE: For installing binaries only skip to set 10...

1)  Run         bind\compat\lib\makemc.bat
2)  Build       bind\compat\lib\lib44bsd.mak
3)  Build       bind\res\resolve.mak
4)  Build       bind\named\named.mak
5)  Build       bind\named\ndc.mak
6)  Build       bind\named\xfer.mak
7)  Build       bind\tools\nslookup\nslookup.mak
8)  Build       tools\instsrv.mak    (Win NT Service installer)
9)  Copy        all *.exe's to bind\dns-dist
10) Run         bind\contrib\winnt-dist\install.bat (To install it all)
11) Run         bind\contrib\winnt-dist\mkdist.bat (To package it via PKZIP)

NOTE: You will now have to modify the database files installed by the
install.bat program and also the named.boot file (boot file) installed in
the WinNT home directory.  Also see the bind operations guide (bog.wri)
in the system32 directory.

****YOU MUST ****** modify the directory line in the named.boot or named.ini 
(it will accept either name)... and change the single slash to double slashes
ie. c:\var\named becomes c:\\var\\named


Possible Enhancements:

There are many enhancements that could be done to this port. We encourage 
everyone who plans to enhance this code to contribute as much of their 
enhancements as possible back into the mainline code stream.  This has 
the benefit of making BIND under Windows NT better for everyone.

Here is a partial list of possible enhancements.

(DONE) - * GUI control panel version of the ndc (bind control program).
(DONE - needs to be integrated if possible) * GUI installation program.
* GUI interface to nslookup.
* A Setup Wizard to help with setting up database files.
* An SNMP module for remote monitoring.
* Port of Eventlib to Windows NT
* Some Integration with Microsoft's dynamic name service for PCs WINS.
   (The Samba tool suite includes nmbd a Netbios Name service that 
    acts as a WINS server, and can probably be used to better under
    stand what is going on with WINS.) Also anybody care to elaborate
    exactly how this should work.. ie does the wins get its info from the dns
    or vice versa...
* PORTS of additional software such as dig, dnsquery, host, named_lint
   and other supporting tools.

Any one wishing to undertake these or other significant enhancements should 
coordinate with either:

   kahn@drcoffsite.com or schueman@access.digex.net

Note: Greg Schueman is out of the country in Japan
till some time this summer...


Mailing list:

A mailing list dedicated to this Windows NT port of bind 4.9.3 has been 
created by Larry Kahn... anyone wishing to join should send an email message
to 
	listserv@drcoffsite.com 

and in the body of the message put:

	subscribe bindnt your name

Your subscription email address will be the one from which the mail was 
received.

General discussion, problems encountered, or suggestions for this port 
should be addressed to this mailing list.


NOTE: Unless your peers on this list wish to help with configuration 
issues, do not expect significant assistance, as these sorts of problems
are better addressed to the bind-users list, or the appropriate news
groups. A good resource for resolving BIND database problems is the O'Reilly
Associates' DNS and BIND book.  

Another good resource is the web page set up by Randall G. at Telemark systems.
http://www.telemark.net/~randallg/ntdns.htm

Problems unrelated to the Windows NT port will be forwarded to the 
bind-workers mailing list.  Also people downloading this version of BIND will 
not automatically be placed on this mailing list.



Contributors:
Viraj Bais       provided the initial Windows NT port of BIND Beta 24.
Laurence G. Kahn provided a number of fixes to the Windows NT Beta 24 port
                 and the initial nslookup port. Also added the new
                 code to lookup all interfaces in an NT box and bind to them.
                 kahn@drcoffsite.com, Also did the Beta27 port...
Greg Schueman    provided the BIND Beta 26 port for NT based on Viraj and
                 Larry's work, and also the installation routines.
                 schueman@access.digex.net
Paul Wren        software.com ... the original control panel applet.. modified
                 by l. kahn for the freeware version.. and a installshield script
                 yet to be integrated... 


Changes for 15 jan 96 ... 

Ok tracked down the last cause for the waitforsingleobject() or getexitstatus()
failures (other than doing restarts in the middle of transfers)... regardless
when these occur they are now gracefully handled and the zone is resched. 
Anyway the problem was twofold (1. entercriticalsection only blocks between 
threads..ie. the same thread can enter the critical section more than once)... 
and 2)
I was trying to close all handles and closed one called

		     CloseHandle(zp->z_xferpid); 

in the endxfer function... not a problem in among itself but
then in the named_xfer which calls the endxfer there is the following code

 EnterCriticalSection(&protected_zp);
    endxfer((*proc_info).hProcess);
    /* dont try the close if the wait failed for some reason */
    /* if we have an extra handle around so be it but if the handle is bad ie wait failed not sure what close will do */
    if (dwWait == WAIT_OBJECT_0)
      {
       CloseHandle((*proc_info).hProcess);
       CloseHandle((*proc_info).hThread);
      }
    free((char *)proc_info);
    LeaveCriticalSection(&protected_zp);

well it just so happens that (*proc_info).hProcess  and zp->z_xferpid both
point to the same handle in this case... but apparently nt doesn't know that
zp->z_xferpid points to it since it is releasing the handle at this point
and at times reusing the same handle # immediately and then when I free it
again in the named_xfer routine the next time this new transfer terminates the
handle is bad... I guess you cannot just assign a handle to another variable
because apparently nt does recognize it as a handle... i.e. the docs from vc++
say:

  The created process remains in the system until all threads within 
  the process have terminated and all handles to the process and any
  of its threads have been closed through calls to CloseHandle.
  The handles for both the process and the main thread must be closed
  through calls to CloseHandle. If these handles are not needed,
  it is best to close them immediately after the process is created. 

well 

zp->z_xferpid is delclared as a HANDLE under nt so I just assumed that

  zp->z_xferpid = proc_info_copy->hProcess;

and nt would know that there were two handles open to this and not reuse
the handle id until both were closed ... well apparently NOT...


Changes for 14 jan 96 ... 

Integrated Software.coms changes to pull the directory and other settings
out of the registry instead of the named.boot file... This is to make it
easier on them every time a new version comes out.
If you want to use this option set a compile flag called REGISTRY_PATHS

Personally I think we should stick with the standard bind method of putting
stuff in the named.boot... otherwise support gets confusing.. and also all the
bind documentation references setting things here. In addition if we start with
xfrnets and directory settings in the registry what about stubs, forwarders and the variety
of other settings.. basically if we want to do it this way the entire named.boot and
should be stored in the registry with gui apps to maintain the... but again
I prefer to be compatible with the unix method... NOTE: if you set this option you
most likely will want to use their control panel applet which allows you to edit
these settings instead of the one bundled with this distribution.

What we really need in this department is a smart application that reads in the
named.boot and the database files, parses them and reports on problems and allows you
to edit things like these directives... and rewrites the files back out... leave the
files as is with unix versions but some smart system admin editting tools...


Changes for 13 jan 96 ... 

The new control panel applet ndc.cpl is thanks to paul Wren and software.com
I took theirs and modified it for the freeware version...

Also the waitforsingelobject happened once on me again only when doing 
a restart at the exact time a zone transfer was terminated... 
and the zone didn't get resheduled... I can now repro it.. 
This seems ok since the handle it is waiting on is now gone...
(we have restarted ... but the xfer is still running out there and so is
the thread waiting for it to terminate...)
but now I changed the code so no matter what even if the unlikely even 
this happens it will still go into endxfer and reschedule the zone...

Changes for 12 jan 96 ... No new version increase

A bug in the instsrv.exe program for installation was brought to my attention
it was registering the eventlog key as domainnameservice... but the first time
you run (and everytime) named or ndc it reregisters the correct key as DNS so
that the messages come out with the source of DNS which is clearer...

I didn't increase the version number since it is a minor problem..


Changes for the 10 Jan. 96 version (4.9.3 Release-P1)

some minor changes to the named xfer code in ns_maint in trying to isolate 
why the waitforsingleobject is timing out... this is ok after the xfer times out and
is killed but sometimes this doesn't seem to be occuring... still looking..
it appears that nt is reusing the process handles even before the old ones are
closed.. .the only thing I can think off is that because the handles are copied
with a bcopy nt does not know that there are still handles open... changed this
code to see if it helps.. seems to be working so far...
Also serialized startxfer so that in case the problem is that one thread is in here
from addxfer and a second thread is in from endxfer ...
Sees to have fixed it... This bug has been in the produce all along... it
was some kind of a race condition or timing issue and on some machines you would
get a failure in the waitforsingleobject every 100-200 transfers on others
not until 5000-10000 transferes... I think I have it fixed now... not 100% sure..
Also tracked down the errant handles in a transfer so now all is ok in this
department..

however I have encountered a bug in the debugging
code where I got a access violation ... while logging a query... I have reported
it to the bind workers and am waiting on resolution ... I have not duplicated it..
lso changed the named-xfer code since if called with debugging or called when
running named in debug mode it would not close the trace files hence 0 length files..
I also changed it to delete the trace file if the xfer completed ok...

Changes for the 09 Jan. 96 version (4.9.3 Release)

some minor changes to the named xfer code in ns_maint in trying to isolate 
why the waitforsingleobject is timing out... this is ok after the xfer times out and
is killed but sometimes this doesn't seem to be occuring... still looking..


Changes for the 06 Jan. 96 version (4.9.3 Release)

Some changes posted the the bind workers mailing list regarding..

+ 	--- 4.9.3-p1 released ---
+ 
+ 575. [port]	Ultrix/Hesiod named responses are oversized, we were
+ 		incorrectly accepting them and then overwriting the stack.
+ 
+ 574. [port]	BSD/OS 2.1 required some ./BSD/Makefile changes.
+ 

Changes for the 05 Jan. 96 version (4.9.3 Release)

Slight changes so this version would compile under unix... cr/lf variables not
inside ifdefs's etc.

Also a slight change to the abort xfer code so that messages that are not warnings
come up ok... also frees a structure that was not being freed.

Changes for the 03 Jan. 96 version (4.9.3 Release build 2:
01/03/96  02:32p               251,392 named.exe

A bug was found by  Hans Karl May Zimmer which was introduced by me all the
way back at beta 27... with more than one zone transfer occuring at a time I 
was incorrectly overwritting vital information... this has now been fixed..
  
Changes for the 03 Jan. 96 version (4.9.3 Release)
  
Reapplied diffs to the 4.9.3 release ... two files are all that needed manual
intervention... recompiled everything..

Changes for the 28 Dec. 95 version

A minor diff posted to the bind workers mailing list for ns_Resp.c
new named.exe and xfer.exe only.

Changes for the 25 Dec. 95 version

reporting of changes to beta 32 using diff/patch... no failures...
recompile all for new version... this is a release candidate...


Changes for the 24 Dec. 95 version

reporting of changes to beta 31 using diff/patch... no failures...
recompile all for new version... this is a release candidate...


Changes for the 23 Dec. 95 version

reporting of changes to beta 30 using diff/patch and also patches to beta 30...



Changes for the 22 Dec. 95 version


reporting of changes to beta 29 using diff/patch only 5 files needed manual
intervention...

Scheduling ok ... yeah,.... still trying to track down the failure for xfers
on a machine with a lot of ip address... found one problem and fixing..
#define FD_SETSIZE 512 added before including winsock as per found documentation
apparently MS defines this as only 64 and therefore the max sockets we could
bind and listen on was 64 and the others were being ignored... god knows what
was happening with the other FD_SET calls... maybe this was writing over memroy????
this change forced recompiling of everything since the libs changed also..

Success this change fixed being able to communicate on all bound ip addresses
(up to 512 now)... and also fixed the zone transfer problem... apparently
microsoft in its infinite wisdome when you try to add more than the limit 
(used to be 64) sockets to a fd_set ... just ignores it (bad enough) but also
writes over memory beyone the end of the socket set.. .thanks microsoft and
this was corrupting the server...


Changes for the 20 Dec. 95 version

Additional fix submitted by Mark Andrews in response to my query about the
named xfers failing on the test site with 91 ip addresses... apparently there
was a bug calculating packet sizes over 16 bit max with an htons that needed
to be changed to an ntohs... verifying the fix now... changes in ns_main.c i.e.

	htons <-> ntohs bug.
	additional debugging.

	Mark

*** ns_main.c.001	Thu Dec  7 07:34:47 1995
--- ns_main.c	Thu Dec 21 14:16:16 1995
***************
*** 851,857 ****
  			        }
  			        if ((sp->s_bufp - (u_char *)&sp->s_tempsize) ==
  					INT16SZ) {
! 					sp->s_size = htons(sp->s_tempsize);
  					if (sp->s_bufsize == 0) {
  					    if (!(sp->s_buf = (u_char *)
  						  malloc(rbufsize))
--- 851,860 ----
  			        }
  			        if ((sp->s_bufp - (u_char *)&sp->s_tempsize) ==
  					INT16SZ) {
! 					sp->s_size = ntohs(sp->s_tempsize);
! 					dprintf(5, (ddt,
! 					    "sp x%lx expecting %d bytes\n",
! 					    (u_long)sp, sp->s_size));
  					if (sp->s_bufsize == 0) {
  					    if (!(sp->s_buf = (u_char *)
  						  malloc(rbufsize))
--
Mark Andrews, CSIRO Div Maths & Stats
Locked Bag 17, North Ryde, NSW 2113, Australia.
PHONE:	+61 2 325 3148			     INTERNET: marka@syd.dms.csiro.au
UUCP: ....!uunet!syd.dms.csiro.au!marka


The current code that fetches the ip address for nt only handle a max of 62
ip addresses... one users was trying to use 91 (why)... anyway I have increased
the code here and it will handle up to 512 now... it looks like bind (a rouch
estimate will only be able to handle a max of about 412. 
Also tracked down a memory leak in xfer's where (the original port) was mallocing
a structure each time but not freeing it... made it global...
Also found a handle in the named xfer (from our server) code
that was not being closed.

Also fixed a bug
in my code where it would not fetch ip addresses correctly from 
the second nic card.

Also another go-around on the maintenance scheduling code... here is an excerpt
from a mail message from Kevin Dunlap at Attachmate...

------------------------------------------------------------------
 Yesterday, I got my mods merged into the beta version. It stayed
 up and running all night, the system didn't lockup and named's 
 memory usage looks reasonable.  We had about 865 zone transfers 
 over the night.

 I have't looked at the RFC's lately, is it legal to have a
 domain that needs refreshing in less than 50 minutes.  If it is 
 then there may a problem.   The sched_maint() only schedules the 
 timer thread to sleep for 3540*1000. Anything less than that
 appears not to get scheduled and i get the syslog message

 "sched_maint: Attemp: to rescheduling maint. from 3540 sec to 60 
 sec. ignored!"
 
 I am not sure if my changes effected this or if there is really 
 a problem in sched_maint().  I'll be looking more into this.
---------------------------------------------------------------

response: it does schedule at other increments but will not kill the running
timer thread... 

Based on this info... I Again rewrote the maintenance timer stuff this time
it should exactly mimic the unix behavior... I figured out a way to kill the
current sleeping thread when a reschedule request comes in (without the memory
leak that would be associated with using TerminateThread)... basically changed
the sleep to a waitforsingleobject that waits on an event object... if the event
gets signaled it means we want to terminate since a reschedule is occuring and a
new thread will be started up... If the timout occurs we proceed as we previously
did and reschedule the next maintenance cycle... Note however since this works
exactly like unix (quirky) sometimes a thread will get rescheduled immediately..
i.e. if you startup your server needed two secondary zone transfers (ie empty zone
files)... it may reschedule 15 mintes for the first transfer and immediately 
reschedule 900 seconds or 15 minutes for the second zone... these are in case the
zones timeout... then if they transfer ok it reschedules for 1 hour...
Hopefully this will be it for the scheduling problems... 
However if anyone can find this there is an errant handle... as shown by pmon..
when doing transfers (incomming) there is one additional handle each time 
that is not getting freed... I have been unable to track it down... 
it is strange since if it was a handle to one of the threads they shouldn't 
totally exit the system and you should still see the thread count higher...
If someone tracks this down please let me know... if you are doing a million
transfers as Kevin you will now get an extra 4 bytes lost each time... but
there probably is a limitation to the max number of open handles also and
you may hit this eventually... This problem has been in the port all along
and was worse when there were actually extra threads running...
It doesn't appear to be related to the maintenance scheduling threads but to
the zone transfer process/thread...

Changes for the 19 Dec. 95 version

From Paul Wren/software.com added ifdefs around some nt specific code
so that it would compile correctly with xstats turned off.

Changes for the 16 Dec. 95 version

There was a problem in the maintenance scheduling in that it is for some reason
called multiple times (i.e. every time after a zone transfers etc.) and we
would as a result get multiple threads running all waiting a specified amount of
time to activate the maintenance alarm... this tended to grow if you transfer
zones alot as one user was doing... making it look like a memory leak... most
people did not see this problem.. I have fixed this by using a status variable in
a critical section so only one thread is ever waiting to perform maintenance..
This a a version of beta 27 without the addition fixes sent to the bind workers
list since these had some bugs relating to intermittant cname lookup failures
and problems with debugging on the the validataion stuff..., Also fixed a race
condition in the new maintenance stuff describe above...


Changes for 08 dec 95 version

many changes this is a report of bind 4.9.3 beta 27 for limited distribution..
also back to vc++ 2.2 getting ready for bet28/release....

I used diff with the context switch to determine the differences between
beta 26 and beta27 and applied these to nt using patch.. however just about
every file needed some manual intervention... Also some of the changes caused
compiler warnings under nt and some types needed to be changed... 
I also looked and doing this by determining the changes from beta26 to the nt
port and redoing these changes to beta27.. however the amount of change was
greater.. and I didn't keep the original port of beta 26 and the one on vixie
now is slightly different...

I had significant problems with vc++ 4.0 (cannot mix and match stuff that
uses 2.0 and 4.0 runtime, it would crash, and debugging would go into assembler
instead of walking over code, as the /Tp option did not work... For this
reason I'm back to vc++ 2.2 for now...


Changes for version 05 dec 95 version.

the fix for wks records (Nov 4th version) 
while working ok under nt did not work under other os's
thanks to Paul Vixie (vix.com)and Paul Wren (software.com) 
for help identifying and resolving on this problem..

This fix is only for compatability to compile this version of bind on non NT
platforms and really does not address an NT intel problem so you may not wish 
to upgrade to it... 

i.e.

From Paul ...

You're right, but it's not NT's problem.  In the compat/ntmisc.c file, the
getservent() function manually parses the SERVICES file in the
system32/drivers/etc, and returns the port as "(short)atoi(cp)" which is in
machine-byte-order.  Then when db_glue.c does a ntohs() on it, it gets
scrambled but ONLY if the machine byte order is not equal to network byte
order. 

So the "real" solution probably should be that on line 273 of ntmisc.c where
it does:

	serv.s_port = (short)atoi(cp);

we should say instead:

        serv.s_port = htons((short) atoi(cp));

so that getservent() acts like BSD, and put db_glue.c back the way it was.

-- Paul@software.com

--------------------------------------------------------------------------

CHANGES for compiling under VC++ 4.0

WARNING fstat without the _ no longer works... I had to add some defines
in portability.h to resolve this... microsoft basically said since the documentation
states fstat not _fstat  that I'm out of luck... hopefully there were no 
other such changes that will make code fail... the function still works 
(fstat) but just returns an error condition... (in a small test case fstat
still works???)

new .mdp files as well as makefiles... 


CHANGES for the Windows NT port of BIND Beta 26 11/09/95

The named xfers were not getting updated correctly when they terminated and
hence secondaries zones would become stale eventually
Thanks to Kevin Dunlap for finding this... in addition for synchronization
(just in case) critical sections were added around the code manipulating the
zp zone variables as originally specified by vbais... A new debug message
was added for the nt vesion so you can verify that your zone was loaded correctly.
For those of you running secondary servers... I'm suprised you missed this..
it would only affect you when downloading zones... once the zone was downloaded 
if you stopped and restarted the server you were ok... 

Only named.exe was regenerated you can just copy the new one over the old one..
the only two source changes were in ns_maint.c and ns_main.c


CHANGES for the Windows NT port of BIND Beta 26 11/04/95

1. WKS records did not work correct as some dirctory paths were not 
expanded.  Related to this the resolv.conf (in our case \winnt\resov.ini
also did not work.  And a bug was found related to this in the stock bind
code that incorrectly converted port numbers to host format. So that 
information from the WKS records was rejected.  L. Kahn
All new executables are generated. Just copy over the old ones... no 
reinstall is necessary.


CHANGES for the Windows NT port of BIND Beta 26  10/15/1995

1. fixed the binding so that the server will now bind to all relevent ip
addresses instead of just 0.0.0.0 otherwise some queryies would come in
on one ip address and go out on another causing some nslookup programs to fail...
The server will not bind to a RAS ip addresses since this causes problems if the
interface goes down and comes back up.  Even so everything works ok if the server binds
to other ip addresses... you can still do queries on the ras interface, also if you 
have only ras it should bind to the msloopback ip addresses... It has been tested
to work correctly with subnet masks and also multiple ip addresses on one nic card,
or across multiple cards.

2. also fixed some miscelaneous bugs with attempts to set null variables.

3. Also fixed problem with recvfrom failure with error 10040 wsamsgsize
   BUFSIZ was declared as only 512 in stdio.h but it is 1024 on most unixes...
 

- Larry


CHANGES for the Windows NT port of BIND Beta 26  10/15/1995


Many Windows NT Beta 24 port modifications were applied to the Beta 26 code
base, semi-automatically via CVS merge facilities.  Only five files
required manual intervention.  Many type inconsistencies and minor build
or configuration problems were fixed under Visual C++.  Also, a number of
minor bugs were corrected.

This release still needs additional testing, and at least one site is 
running it as a primary DNS server in production, so this gives us some 
confidence that the port is fairly close to a "production-use" version.

-Greg

Addendum: Type Changes

10/10/1995 Greg Schueman from the files: named/db_defs.h, named/ns_defs.h


File: db_defs.h: (was type u_int32_t)
      int32_t d_ttl;          /* time to live */

File: ns_defs.h: (was type u_int32_t)
      int32_t z_refresh;      /* refresh interval */
      int32_t z_expire;       /* expiration time for cached info */
      int32_t z_minimum;      /* minimum TTL value */

File: ns_defs.h: (was type int)
      u_int           dq_dfd;         /* datagram file descriptor */


