DNSGSD is a server dæmon that provides general content DNS service over UDP, using a database to look up its responses.
DNSGSD does not provide name service over TCP. Any responses that do not fit into a UDP packet will be truncated. However, DNSGSD provides "Large UDP" support as standard. If a client indicates that it can accept large DNS/UDP responses, then no truncation will occur up to the size of the largest response acceptable to the client.
DNSGSD uses a database to answer queries. It does not write to this database at any point. That is the task of the DNS database compiler.
The database is divided into
Each "zone" is stored in its own database file, in a
subdirectory off the dæmon's current directory. The file name is
the domain name of the zone apex, with '@' prepended. So, for example,
the database file with the zone apex
example.com. will be
DNSGSD will …
The remaining queries, properly formatted ones with only one question that are asking about Internet-class data, it will answer from its database. The first thing that DNSGSD does is determine which "zone" the domain name in a question belongs to. Once DNSGSD has determined the "zone", it will answer using the data from that zone.
Irrespective of question type, if the domain name of a question is below the "bottom edge" of a zone, i.e. below a delegation point, DNSGSD returns a referral answer.
Similarly, irrespective of question type, if the domain name of a question is a client-side alias, i.e. a chain record in the database, DNSGSD adds the client-side alias information to the response, substitutes the target of the alias, and treats the question from then on as if it were asking about that alias. It will repeat this procedure for up to 100 client-side aliases. Server-side aliases, i.e. alias entries in the database, are of course invisible to clients. Indeed, they are largely invisible to DNSGSD, to which server-side aliases are simply links by two separate names to the same sets of database records. (Server-side aliases are turned into links by the DNS database compiler.)
AAAA questions, DNSGSD will look for
name→address mappings in the database. For
questions, it will look for address→name mappings. Both mappings
will result from host records in the database. In either case,
it will serve up the opposite mapping as "additional data" in the
response, if it also exists in the "zone".
MX questions, DNSGSD will look for
mailhub and nameserver records in the database. For
SRV questions, it will look for service records. In
all three cases, because the DNS protocol requires it, it will split the
record contents into the intermediate domain name information, returned as
"answer data", and the actual target IP address information, returned as
The DNS protocol does not currently provide a mechanism for transferring
the priority and weight information of nameserver records, and the
weight information of mailhub records. If clients wish to obtain
this information, it should be published as service records. The
various tools in the Internet Utilities, at least, can be configured to
SRV resource record lookups for these services.
For other question types, DNSGSD will look for explicit data records in the database that match that query type.
DNSGSD will return empty resource record sets for domain names that exist but that don't have any data of the requested type. It will return "no such domain" answers for domain names not in its database, including domain names for which no enclosing "zone" can be found.
The DNS protocol has to employ a bodge to transfer TTL information for
empty resource record sets and "no such name" answers. This bodge
involves the use of a
SOA resource record, which DNSGSD
obtains from the apex of the containing "zone". It ajusts the TTL of this
record, as transmitted in the response, to reflect the TTL of the empty
set, or the "no such name" error.
SOA resource records from negative,
empty, znxfr, ddnsup, and person records in
the DNS database, using them to fill in
the various fields in
SOA resource records.
If a record of a given type is not present, DNSGSD will default to zeroes.
The only field of a
SOA resource record that carries meaning
for the Internet Utilities general content DNS service is the "MINIMUM"
field. The "MNAME" field has no meaning, since the general content DNS
service is a read-only service that does not update the database, and does
not provide dynamic DNS update service. The "RNAME" field has long since
fallen int desuetude anyway. And the "SERIAL", "REFRESH",
"RETRY", and "EXPIRE" fields have no meaning because the Internet
Utilities does not use BIND's "zone transfer" DNS database replication
DNSGSD implements scheduled changeovers. It will ignore any database records whose expiry dates have passed, or whose inception dates have yet to arrive. For records that expire sooner than their marked TTL values woutd otherwise indicate, it will decrease the TTLs in the responses that it transmits, to ensure that all cached data in proxy DNS servers expires at the same time that the database records themselves expire.
DNSGSD 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\DNSGSD.exe chdir %_BOOT%:\Config\Apps\JdeBP\IU\DNS\ argument DNSGSD argument /serverip:0.0.0.0