DNSRCPD
[/?]
[/OSTRACISE number]
[/LARGEUDP[+|-]]
[/LOCALHOST[+|-]]
[/DECIMAL[+|-]]
[/IMPLICITALL0[+|-]]
[/IMPLICITALL1[+|-]]
[/IP6ADDR[+|-]]
[/CACHE number]
[/UDPPROXYSOCKETS number]
[/TCPPROXYSOCKETS number]
[/TCPSERVERSOCKETS number]
[/TTLPOSITIVEMAX number]
[/TTLEMPTYMAX number]
[/TTLEMPTYDEFAULT number]
[/TTLNEGATIVEMAX number]
[/TTLNEGATIVEDEFAULT number]
[/SERVERIP address]
[/SERVERPORT port]
[/CLIENTIP address]
[/CLIENTPORT port]
DNSRCPD is a caching DNS proxy server dæmon that attempts to fully resolve all queries sent to it. It queries content servers for the information that is required, starting from the root servers and working its way downwards in a fashion that is designed to avoid spoofing. In order to prevent contacting the same content servers repeatedly, it maintains a cache of previously obtained information.
DNSRCPD expects to be a client of content servers, which of course do not provide recursion by their very nature. For the benefit of DNS content servers whose authors have not yet realised that the RD bit is superfluous it sets the RD bit to 0 in all queries that it transmits.
DNSRCPD will discard all DNS/UDP traffic from clients that it does not recognize as authorized. See client authorization for details, and note that client authorization is not a substitute for proper IP address choice and router configuration.
DNSRCPD will …
The remaining queries, properly formatted ones with only one question that are asking about Internet-class data, it will answer from its cache, issuing back-end queries as necessary to populate that cache.
DNSRCPD normally determines the addresses of all content servers to contact by querying the public DNS, starting from the root content servers and working its way down through the chains of referrals. Individual subtrees of the DNS hierarchy can, however, be pruned away from the public DNS by explicitly overriding the lists of DNS servers for the top of those subtrees.
This is done using per-domain overrides. Before querying the DNS for the list of content servers for a domain domain DNSRCPD checks for a file named "Content\@domain" relative to its working directory. If the file exists and can be opened for reading, its contents are used in preference to the information held in the public DNS database.
The IP addresses of the root content servers, which are the only pieces of configuration information that DNSRCPD requires, are provided using this same mechanism. The IP addresses of the root DNS content servers are listed in the file "Content\@".
An override file comprises a list of IP addresses in big-endian dotted-decimal text form, one per line. This corresponds to the output of the DNSGETNS command, which can be used to generate such files from the contents of the public DNS database. For example, the following commands will regenerate the list of root content servers:
[c:\Config\Apps\JdeBP\IU]dnsgetns /b+ . > Content\Temp [c:\Config\Apps\JdeBP\IU]move Content\Temp Content\@
DNSRCPD will ostracise all content servers whose IP addresses are in the
list of addresses passed to the /OSTRACISE option. It
will discard any such addresses both when reading from a content server
location file and when using the delegation information in the DNS
database itself.
The primary purpose of the /OSTRACISE option is to prevent
proxying loops being created, whereby DNSRCPD ends up querying either
itself or a forwarding proxy DNS server that is upstream (i.e. closer to
the DNS client) of it, resulting in queries looping around a chain of
proxy DNS servers forever.
These loops can be created in two ways:
The delegation data in the DNS database for some domain lists an IP address that happens to be that of a local proxy DNS server.
A content server location file lists (perhaps because it was automatically generated from the delegation information published in the DNS database) an IP address that happens to be that of a local proxy DNS server.
Therefore the /OSTRACISE option should be used, and provided
with a list of the IP addresses on which DNSRCPD itself and all of the
forwarding proxy DNS servers upstream of it are listening.
Unlike other resolving proxy DNS servers, when determining the addresses
of all content servers to contact, DNSRCPD respects client-side aliases.
If a domain name is a client-side alias, DNSRCPD will substitute the
target name before looking for the NS resource record set.
For example, if the following resource records are cached
news.openwatcom.org. IN CNAME news.scitechsoft.com. news.scitechsoft.com. IN CNAME scitechsoft.com. scitechsoft.com IN NS ns1.zoneedit.com. scitechsoft.com IN NS ns2.zoneedit.com.
then, when determining the addresses of the news.openwatcom.org.
content DNS servers, DNSRCPD will follow the alias chain and use
the NS resource record set for scitechsoft.com..
This behaviour is an augmentation to the query resolution mechanism that
is commonly employed by other resolving proxy DNS servers (albeit
one that is still consistent with RFC 1034 section 5.3.3 step 2
nonetheless). Other resolving proxy DNS servers will not follow the alias
chain when determining the addresses of all content DNS servers to
contact, but instead will take news.openwatcom.org. as having
an empty NS resource record set.
The DNSRCPD behaviour is to follow client-side alias chains wherever they
occur, in a fashion that makes the internal operations of the server
consistent with what is seen in the DNS database as the result of DNS
queries. The same list of intermediate server names is obtained when an
explicit NS query for news.openwatcom.org. is
resolved as when query resolution has to determine the addresses of all of
the news.openwatcom.org. content DNS servers and issues an
implicit NS query.
Furthermore, the list of content DNS servers produced by DNSGETNS (which
also follows such client-side alias chains when performing the
NS resource record lookup, because it employs the normal
database query mechanism which always follows client-side alias chains)
will be the same as the list of content DNS servers used by DNSRCPD.
This consistency and identity are not the case for the common mechanism.
In order to avoid poisoning DNSRCPD discards all records returned from content servers which it deems to be outside of that server's bailiwick at the time. DNSRCPD will reject information returned from a server about names not within the domain for which it was originally referred to that server in the first place.
Thus the only content servers from which DNSRCPD will accept information about any particular domain are the content DNS servers for that domain and for each of the content DNS servers in the chain of referrals that was used to reach them, all of the way back to the root content DNS servers.
This means that referrals to DNS content servers whose intermediate names
are not in the referring content server's domain will cause extra A
queries to be sent in order to retrieve the necessary "glue" from trusted
sources, starting from the root DNS servers if necessary. Because modern
DNS proxy servers are gradually all adopting this same anti-poisoning
rule, it is highly recommended that DNS content servers be within the same
parent domain as the domain that they are themselves serving, in order to
prevent this extra DNS traffic from being necessary. (This will also
eliminate the possibility of
mutual gluelessness
that can occur with "out-of-zone" DNS servers.)
DNSRCPD regards the entire domain name namespace tree below a given point as being in the bailiwick of the content servers listed in the per-domain override files. These servers have effective control over the entirety of their respective portions of the namespace that will be seen by all clients of DNSRCPD. In particular, the root servers listed in "Content\@" have effective control over the entire domain name namespace (apart from those portions that have been pruned away).
One should not include the IP addresses of content servers that one has no reason to trust, therefore. It is recommended that one only add overrides pointing to content servers within one's own organisation. The only servers that one is forced to trust unreservedly are the root content servers.
DNSRCPD 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\DNSRCPD.exe chdir %_BOOT%:\Config\Apps\JdeBP\IU\DNS\ argument DNSRCPD argument /serverip:127.0.0.2 argument /ostracise:127.0.0.2;127.0.0.8;0.0.0.0
/OSTRACISE