DNSGSD [/?] [/SERVERIP address] [/SERVERPORT port]


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.

The database

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 "zones". Each "zone" is stored in its own database file, in a Data/ 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 Data/@example.com..


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.)

For A and AAAA questions, DNSGSD will look for name→address mappings in the database. For PTR 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".

For NS and 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 "additional data".

Note: 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 make 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.

DNSGSD synthesizes 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.

Note: 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 mechanism.

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.

Example RUN file

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:

Command-specific options

The Internet Utilities are © Copyright Jonathan de Boyne Pollard. "Moral" rights are asserted.