DNSFSD
[/?]
[/SERVERIP address]
[/SERVERPORT port]
[/DOMAIN string]
DNSFSD is a server dæmon that provides fixed-data content DNS service, that does not use a database to look up its response. It provides opaque name service and name service for dotted-decimal names. It serves clients with two-way mappings between IP addresses and domain names, and with one-way mappings from oft-used but non-existent domain names to IP addresses. It calculates the domain names from the IP addresses directly.
Such a service has three major uses and one minor one:
Anonymity: Sites that wish to hide details of their internal machines from the world can use DNSFSD to do so.
Handling large uniform IP address ranges: Sites that wish to serve up address↔name mappings for large uniform ranges of IP addresses (such as an ISP's address range for its DHCP or dial-up customers) can use DNSFSD to do so.
Preventing badly written local server softwares from becoming everyone's problem: Sites that have badly-written servers for Internet services that erroneously think that reverse lookup is a security measure can use DNSFSD to prevent such servers from having an impact on those servers' clients in the world at large.
Fixing badly written softwares: DNSFSD is one of the ways of addressing the problem with client softwares that erroneously look up dotted numeric names in the public DNS database.
The mappings that DNSFSD provides are as follows:
DNSFSD provides a bidirectional mapping between all IP addresses and a set of dummy domain names.
It does this first by answering PTR and "*" queries for names
of the form a.b.c.d.in-addr.arpa., where the first four
labels are numbers in the range 0 to 255, and names in the form
n.n.n.n.n.n.n.n.n.n.n.n.n.n.n.n.n.n.n.n.n.n.n.n.n.n.n.n.n.n.n.n.ip6.arpa.
where the "n" labels are hexadecimal digits. The dummy name is formed by
replacing in-addr.arpa. or ip6.arpa. with a
domain suffix. By default, this suffix is itself
in-addr.arpa. or ip6.arpa., but this can be
overridden with the /DOMAIN option.
To provide the mapping in the other direction, it answers A,
AAAA, and "*" queries for those dummy names, mapping them
back to the IP addresses.
DNSFSD provides a unidirectional mapping between all "dotted-decimal IP address" domain names and the IP addresses that they resemble.
It does this by answering A, AAAA, and "*"
queries for names of the form a.b.c.d., where the four labels
are numbers in the range 0 to 255. The IP addresses returned are the
addresses whose human-readable forms those domain names resemble, a.b.c.d
for A queries and 0::a.b.c.d for AAAA queries.
For any other types of queries for the aforementioned domain names, DNSFSD provides empty resource record sets, indicating that the name exists but no records of the appropriate type exist. For any other domain names, DNSFSD will return a "no such name" response, with the following exceptions:
For the domain name localhost. DNSFSD will return the IP
address 127.0.0.1 for A queries, the IP address ::1 for
AAAA queries, and empty resource record sets for all other
queries.
For the domain name in-addr.arpa. DNSFSD will return a dummy
SOA resource record for SOA queries, and empty
resource record sets for all other queries.
For the domain name domain supplied to the /DOMAIN
option DNSFSD will return a dummy SOA resource record for
SOA queries, and empty resource record sets for all other
queries.
Some examples:
By default, the IP address 10.1.2.3 will be mapped to the name
3.2.1.10.in-addr.arpa., which in turn will map back to
that IP address.
If the /DOMAIN dialup.some.isp. option is specified, the
IP address 10.1.2.3 will be mapped to the name
3.2.1.10.dialup.some.isp., which in turn will map back to
that IP address.
The domain name 10.1.2.3. will be mapped to the IP
address 10.1.2.3. The IP address will not be mapped back to that
domain name, however.
DNSFSD will answer SRV queries for the domain name
10.1.2.3. with an empty resource record set.
DNSFSD will answer MX queries for the domain name
3.2.1.10.dialup.some.isp. with an empty resource record set.
DNSFSD will answer all queries for the domain name
google.com. with a "no such name" response.
The specially constructed SOA resource records exist solely
because of a design flaw in the DNS protocol, which requires the use of such
resource records in order to convey TTL information for the empty-set and
"no such name" answers that DNSFSD yields. It is not expected in normal
practice that these resource records will be looked up themselves,
explicitly.
Moreover, it is expected in normal practice that proxy DNS
servers will discard them as cache poison.
The TTL for all information that DNSFSD publishes is fixed at 7 days.
Because the special SOA records only serve one function, only
their
"MINIMUM" fields
contain useful data. Their other fields, for database replication, DDNS
Update, and administrative contact, are given zero values. (The latter has
long since fallen into desuetude anyway.)
In normal operation, none of this information should be used by
anything. Anything that uses any information in these
SOA resource records apart from the negative/empty TTL
information is either incorrectly designed or misconfigured.
DNSFSD does not publish any resource records at all other than
PTR, A, AAAA, or SOA
resource records.
DNSFSD does not provide name service over TCP. All responses will easily fit into a 512 byte UDP packet, and hence the overhead of TCP simply isn't worth the effort.
DNSFSD 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\DNSFSD.exe chdir %_BOOT%:\Config\Apps\JdeBP\IU\DNS\ argument DNSFSD argument /serverip:127.0.0.7 argument /domain:"opaque.local."
/DOMAIN