DNSZSD
[/?]
[/ACCESSLEVEL number]
socket
DNSZSD provides DNS service over TCP, accepting DNS queries on its input and sending DNS responses on its output. If no socket is specified as an argument, it uses its standard input and standard output for input and output. Otherwise, it uses the named socket, which it closes when it has finished with it. The IP address and TCP port number on which DNS service is thus provided is determined by its parent process, not DNSZSD itself. Conventionally, the port number is 53 and the IP address is one that is reachable by Internet at large.
DNSZSD is designed to be spawned on demand by TCPSRUN. It can also be spawned by INETD, although the control of client access levels based upon the client's IP address, which TCPSRUN does, will be unavailable as a consequence.
Where client access is denied, DNSZSD simply exits immediately, closing the socket. With any other access level, normal DNS service is provided.
DNS over TCP service can be used for two things: so-called "zone transfer" service and publication of DNS data that are too large to fit into DNS/UDP datagrams.
With the Internet Utilities, both are uncommon requirements. Since the General-purpose Content DNS Server has "large UDP" support as standard, it is fully capable of serving up to 64KiB DNS/UDP responses, which is the same size limit as DNS/TCP service. So one doesn't gain from DNS/TCP support in that respect.
Similarly, "zone transfer" is an inferior form of DNS database replication, that is actually incapable of transferring some database content. See the user guide for how to replicate a DNS database with the Internet Utilities. Again, one really shouldn't be using "zone transfer" and so one doesn't require DNS/TCP service for that reason, either.
DNSZSD will refuse service on the same grounds (q.v.) as the General-purpose Content DNS Server does, with one exception: Unlike the General-purpose Content DNS Server, it will not refuse "zone transfer" requests (which have no meaning for DNS/UDP service). However, it will only do so for authorized clients.
Clients are individually authorized for "zone transfer" service by adding
a file named after the client's IP address, in bigendian hexadecimal form,
to the Slaves/ subdirectory of the server's current
directory. The simple existence of the file authorizes service.
Conversely, the non-existence of the file (or indeed the subdirectory)
denies authorization.
So, for examples, the existence of the Slaves/7F000001 file
authorizes "zone transfer" service to IP address 127.0.0.1, and the
existence of the Slaves/FED00000000000000000000000000001 file
authorizes "zone transfer" service to IP address FED0::0001.
It is a deliberate design feature that a separate file has to be created
for every individual authorized IP address, and that there is no system
for blanket authorizing ranges of IP addresses. It is intentional that a
DNS/TCP service that has been configured to blanket authorize a lot of IP
addresses make this apparent with a large number of files in its
Slaves/ subdirectory. (Of course, it is a simple exercise in
command scripting to create multiple files for a range of IP addresses.
The intent is make blanket authorizations obvious, not
difficult.)
DNSZSD uses, and should be configured to share, the exact same DNS database files as the General-purpose Content DNS Server (q.v.). It serves up the same data, responding to ordinary requests in the same way (indeed, using the very same database engine).
DNSZSD answers "zone transfer" queries only for zone apices.
A "TCPService.RUN" run file, for DNSZSD to be spawned by TCPSRUN, would typically look similar to:
program %APPS%\JdeBP\IU\Bin\DNSZSD.exe argument DNSZSD argument %3
TCPSRUN itself would be invoked under RUNSVC, the Service Manager in the OS/2 Command Line Utilities version 2.2, with a run file similar to:
program %APPS%\JdeBP\IU\bin\TCPSRun.exe chdir %_BOOT%:\Config\Services\%1 argument TCPSRun argument 0.0.0.0 argument domain argument TCPService.RUN