This is the Service Version of the Filter program previously posted. The Service version of DNS Filter not only requires the WinpkFilter from NT Kernel Resources (free for personal use) but also the NT Service Control from Microsoft (freely available). So far it has been tested on Server 2000 and Windows Vista.
It consists of 2 programs; one is the actual service, and the other to load and manage the Service. Although the service can install itself, the management program is needed to store a couple of parameters. Because the Service runs in Session 0, the Registry values must be placed in the Registry in a location that allows System access. Because the management program runs in Session 1 or more, it has no actual interaction with the service. It deals entirely with the Service Manager (services.msc). I used to use the System Tray for interaction between a service and the desktop, but that is now difficult to do with Session Isolation. I also used to use the Dart Service Control (which I prefer), but that requires the user to purchase a license.
J.A. Coutts
Note: DNSFilSvc was designed to be run in Development mode as well as a Service. To compile the service, change the IsService flag to True. In order to get the logging routine to function on Server 2000, I had to manually create the DNS sub-directory in the Logfiles directory. Server 2000 would not automatically create it.
Addendum: I finally got the low level filtering in WinpkFilter working. This allowed me to only process Port 53 UDP requests, thereby reducing the amount of code needed and theoretically reducing system resources required. The problem turned out to be bad type declarations in the sample code provided.
Bug Fix 11/12/2013: A bug was discovered that randomly allowed some duplicated queries to get through the filter. A fixed length buffer (128 bytes) was maintained to receive incoming query names. This string information was of variable length, but always ended in a null character. When the name was added to the string array, VB only recognized up to the null character. If the previous query was longer than the current one, extra characters got left behind in the fixed length buffer. For example, if "12345678.com" was followed by "123456.com", what was shown in the buffer was "123456.com m", which of course did not compare to what was already in cache. This was corrected by clearing the fixed length buffer after every query. At the same time, table updates were sped up by maintaining an end of cache pointer.
It consists of 2 programs; one is the actual service, and the other to load and manage the Service. Although the service can install itself, the management program is needed to store a couple of parameters. Because the Service runs in Session 0, the Registry values must be placed in the Registry in a location that allows System access. Because the management program runs in Session 1 or more, it has no actual interaction with the service. It deals entirely with the Service Manager (services.msc). I used to use the System Tray for interaction between a service and the desktop, but that is now difficult to do with Session Isolation. I also used to use the Dart Service Control (which I prefer), but that requires the user to purchase a license.
J.A. Coutts
Note: DNSFilSvc was designed to be run in Development mode as well as a Service. To compile the service, change the IsService flag to True. In order to get the logging routine to function on Server 2000, I had to manually create the DNS sub-directory in the Logfiles directory. Server 2000 would not automatically create it.
Addendum: I finally got the low level filtering in WinpkFilter working. This allowed me to only process Port 53 UDP requests, thereby reducing the amount of code needed and theoretically reducing system resources required. The problem turned out to be bad type declarations in the sample code provided.
Bug Fix 11/12/2013: A bug was discovered that randomly allowed some duplicated queries to get through the filter. A fixed length buffer (128 bytes) was maintained to receive incoming query names. This string information was of variable length, but always ended in a null character. When the name was added to the string array, VB only recognized up to the null character. If the previous query was longer than the current one, extra characters got left behind in the fixed length buffer. For example, if "12345678.com" was followed by "123456.com", what was shown in the buffer was "123456.com m", which of course did not compare to what was already in cache. This was corrected by clearing the fixed length buffer after every query. At the same time, table updates were sped up by maintaining an end of cache pointer.