Document: FSC-0069
Version:  001
Date:     13-Dec-1992

                              A Proposal
                 A FidoNet (FTN) Domain Name Service
                            Robert Heller
                            Locks Hill BBS

Status of this document:

     This FSC suggests a proposed protocol for the FidoNet(r) community,
     and requests discussion and suggestions for improvements.
     Distribution of this document is unlimited.

     Fido and FidoNet are registered marks of Tom Jennings and Fido


The purpose of this FSC is to describe my ideas for migrating
FidoNet(r) networks from a "static" nodelist to a domain based
nameserver type of address resolution scheme.  This document does
not propose a definitive scheme, only one posible scheme.  Other
schemes are posible - this document just presents one as a starting
point for discussion.

1. Introduction

In this document I plan to present a simple domain nameserver scheme
for FidoNet(r) networks.  This scheme could be implemented easily,
since no new connection protocols would be needed and in fact little
new software would be needed.

Nameserver queries would be implemented as File Requests for magic
filenames.  The files would contain the information needed to perform
the desired address resolution. These files would be built by the
nameserver in advance by an off-line process.  That is, they would be
pre-computed - the querying node would not be left hanging on the line
while the nameserver went off and did a database lookup.

2. Addresses

A domain nameserver based FidoNet would use three levels of
addressing: virtual (most abstract), logical, and physical (least

2.1 Virtual Addresses

A node has 1 or more virtual addresses, one of which is it primary
address and the others are aliases.  A virtual address is a totally
symbolic address and is formatted just like an InterNet address:


where node is the node's name and domain is a domain specification and
can have any number of [sub-]* domains.  For example, my system could
have a virtual address of:

The node and domain segment strings consist of letters (upper and
lower case are equivelant), digits, dash (-), underscore (_), and
dollar sign ($) characters and must begin with a letter. 

Virtual addresses generally convey no geographical or routing
information.  They are intended purely for human convience purposes -
they are really little more and a node name, with some added

2.2 Logical Addresses

A node can 1 or more logical addresses, although having only 1 is
preferable. A logical address is exactly an existing 3-4D FidoNet(r)




A logical address is used by mail packers and mail routers.  It is the
addresses exchanged in YooHoo/2U2 packets and live in the Type-2
packet headers.

2.3 Physical Addresses

A node has exactly one physical address.  In FidoNet(r), this is
typically the telephone number assigned by the telephone company.  (It
is posible that some nodes have something else as a "physical"
address, for example a point which is connected to its bossnode via a
LAN connection or a hardwired COM port.)  A multi-line BBS typically
has one line for FidoNet(r) connections or multiple logical and
virtual address, at least one per line.  The physical address is used
by the mailer program to actually make a connection.

3. The Domain Database

The domain database would consist of four ASCII text files, probably

     1) The domain table.  This text file maps between virtual
        addresses and logical addresses.  It also defines aliases
        as well and lists nameservers.

     2) The mail-exchanger table.  This text file describes the
        prefered netmail routing.  For each domain tail, it lists
        one or more node names that handle incoming mail for
        those domain tails.  This file only uses virtual
        addresses.  Its data is consulted by high-level mail
        routers, that take out-bound mail messages and combines
        them into bundles that are later packed into mail packets
        (which are routed to logical address fetched from the
        domain table).

     3) The capability file.  This file describes any extra
        services or capabilities a node might provide.  This
        includes (but is certainly not limited to):  gateway
        services (to other FTN or to non-FTN networks),
        alternitive low-level connection protocols (i.e. UUCP,
        SLIP, etc.), and file echos (SDS, SDN, etc.).  This file
        is meant as a catch-all for misc. optional information
        that might be usefull.

     4) The nodelist segment file. This file contains the mapping
        from logical address to physical address, and is in fact,
        a presnt-day NodeList file, except it is a "sparce"
        nodelist.  That is, it only describes the nodes at the
        immediate level of the nameserver and nodes at the level
        above and below the nameserver.

3.1 Format of the domain table file.

The domain table file contains 1 or more lines of text.  Lines
starting with a semi-colon (;) are comments and are ignored when this
file is processd.  Each non-comment line contains two or more fields
separated by commas:


The first field is a field type keyword.  The field types defined are
(case is not important):


   Defines the default domain tail to append to domain names in the
rest of the file.  Domain tail must begin with a dot (.).  Any
subsequent domain names that do end in a dot will get the specified
domaintail appended before further processing.


   Defines a domain server for domaintail.  Domain is the virtual
address of the server node and preference is a preference value, a
number giving a relative value when looking for a server to contact.
A higher number means this is a better node to try and a lower number
means this is a backup server.  The preference gives a ranking for
multiple servers for a given domain tail.


   Defines that domain1 is an alias for domain2.  


   Defines default values to use in subsequent ADDRESS lines.  Region
and net lines are effectivly interchangable and are used for
documentary reasons.


   Defines the logical address for domain.  The logical-address can be
missing fields.  Missing fields are supplied from prior ZONE, REGION,
and NET lines.  Node and point numbers cannot be defaulted.

3.1.1 Sample domain table.

;; Domain table for Network 999 (N_Luna) of zone 444 (the Moon)
;; (c) Copyright 2001 Network 999
;; Our default domain
;; Our zone
;; Our Net
;; Our NC, Jim
;; Our NEC, Sally
;; Our namesevers
;; Note empty domaintail - the default is used
;; Out of net nameservers
;; Our Zone nameserver
;; Our IC nameserver
;; Use the IC nameserver for non-fidonet addresses
;; Nodes
;; Out of net addresses

Some notes about the above - the underscores (_) are part of the names
and do not indicate spaces.  The case mixing is stylistic and is an
aid to readablity.  The above is a net level domain table. It also
includes nameserver definations for higher levels, so nodes in N_Luna
net can perform address resolutions to out of net addresses.

3.2 Format of the mail exchanger table file.

The mail exchanger table file contains 1 or more lines of text.  Like
the domain table lines starting with a semi-colon (;) are comments and
each non-comment line contains a list of three comma-separated values:


Where domaintail is a domain suffix of a posible mail address, domain
is the virtual-address of a node that handles the domain suffix's
mail, and preference is a preference value (higher number is more
prefered than a lower number).

3.2.1 Sample mail exchanger table file

;; Mail exchanger table for Network 999 (N_Luna) of zone 444 (the Moon)
;; (c) Copyright 2001 Network 999
;; Local mail can go via either the NC or NEC, with the NC
;; getting a higher preference,,100,,90
;; Out of zone mail goes through the zone gates,,50,,50,,50,,50,,50,,50

Some notes about the above - undefined domain tails don't have a
defined mail exchanger - this will a node trying to send such mail to
do a nameserver call to get mail exchanger and any other info needed.
( The above is probably unrealistic - a more realistic mail exchanger
 table might have a default mail gateway.  And/or a zone-local
inter-network nameserver.)

3.3 Capability file.

The capability file lists virtual-address and any extra services it
might provide.  Semi-colon (;) in column one means a comment.  The
non-comment lines are of the format:


Where virtual-address is a node's virtual address.  There can be any
number of lines with the same virtual-address.  The keyword:value
pairs accumulate (as if there was only one very long line for that

3.3.1 Sample capability file.

;; Capability file for Network 999 (N_Luna) of zone 444 (the Moon)
;; (c) Copyright 2001 Network 999

3.4 The NodeList Segment File.

The nodelist segment file is just a FTS-0005 nodelist file, except it
is "sparce", that is, it only contains just enough info to translate
the logical addresses in the corresponding domain table file.

4.0 Nameserver Implementation.

Nameservers would be implemented by using the existing file-request
methods presently in existance.  Five magic filenames would be setup:

   DNSDTABL   - Domain table file
   DNSMXTBL   - Mail Exchanger table file
   DNSCAPAF   - Capability file
   DNSNODEL   - NodeList segment file
   DNSALL     - An archive file containing all four of the files.

All a nameserver would need to do would be to provide these five
files, probably in some sort of commonly acceptable archive format.
The real filenames should have some sort of predictable, but unique
name probably based on the level of the nameserver and the number of
the zone, region, or network the nameserver serves.

4.1 Nameserver Levels.

Nameservers would exist at various levels:

     1) At the zone level.  The zone level nameserver(s) would
        supply information for the current zone level nodes,
        regional level nameservers, and would also have
        information about the zone level nameservers in all other

     2) At the regional level.  The regional level nameservers
        would supply information for the current region level
        nodes (indpendent nodes), the current zone nameserver(s)
        (up level), and network level nameservers.  In some
        smaller zones, the region level *might* be skipped. The
        RC also makes the regional level domain info available to
        each of the region's independent nodes.

     3) At the network level.  The network level nameservers
        would supply information about the current network level
        nodes (regular nodes), and the current regional
        nameserver(s).  Also, the NC delivers or makes available
        the network level domain info to each of the nodes in the
        local network.

(If the regional level is skipped, the network nameservers would
contain entries for zone level nameservers and zone level
nameserver(s) would contain network nameserver info instead of
regional nameserver info.)

5.0 Database Updates and Management.

Each node gets the network (region for independents) level info. These
updates are handled much the way nodediffs get handled at present. The
existing nodediff structure is really a generic text file difference
editor and should work for any sort of text file. If the node needs
additional info for regular connections, it is up to the node's sysop
to schedule regular file requests to the nameservers that supply the
additional info needed.  (This might require a cascade of requests,
depending on nameserver dependencies - posibily a "make" like utility
could be used to generate the requests.) A compiled database would be
a merge of the data files a node gets from its NC (or RC for
independents) and any additional info the node fetches.

Because the information supplied at each level only relates to that
level and the levels just above and below, updates are mostly local in
nature.  There is no need to pass detailed network level info to the
RC.  All that is needed is for the NC to pass the local info, merged
with the regional nameserver info to the network's nameservers and
pass the network's nameserver info to the RC.  Likewise the RC only
needs to merge the regions indepent node info with the network
nameserver info (passed up from the NCs) and zone level nameserver
info (passed down from the ZC) and pass this to the regional
nameservers and to pass info on the region's nameserver(s) to the NCs.
Things are much the same at the zone level, except the ZCs pass their
own zone level nameserver info to each other.  Nothing like the full
nodelist ever gets passed around.

6.0 Final Thoughts.

This document is by no means complete. It is intended as "food for
thought".  I hope that the members of the FTSC and others will read
this and think about these ideas and maybe even setup experimental
nameservers and see how it goes.  I expect lots of feedback.

Robert Heller