A Proposal
for
A FidoNet (FTN) Domain Name Service
Robert Heller
1:321/153
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
Software.
Information
-----------
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
abstract).
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:
node.domain
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:
LocksHill.DeepWoods.com.fidonet.org
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
information.
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)
address:
Zone:Net_or_Region/Node
or
Zone:Net_or_Region/Node.Point
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
compressed:
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:
field1,field2,...,fieldN
The first field is a field type keyword. The field types defined are
(case is not important):
DEFAULT,domaintail
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.
NAMESERVER,domaintail,domain,preference
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 default values to use in subsequent ADDRESS lines. Region
and net lines are effectivly interchangable and are used for
documentary reasons.
ADDRESS,domain,logical-address
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
Default,.N_Luna.moon.fidonet.org
;; Our zone
Zone,444
;; Our Net
Net,999
;; Our NC, Jim
Alias,N_Luna_Net,Jims_SpaceSuits
;; Our NEC, Sally
Alias,N_Luna_NEC,Sallys_Lunies
;; Our namesevers
;; Note empty domaintail - the default is used
NameServer,,N_Luna_Net,100
NameServer,,N_Luna_NEC,50
;; Out of net nameservers
;; Our Zone nameserver
NameServer,.moon.fidonet.org.,Moon_NS.fidonet.org.,100
;; Our IC nameserver
NameServer,.fidonet.org.,FidoNet_NS.fidonet.org.,100
;; Use the IC nameserver for non-fidonet addresses
NameServer,.,FidoNet_NS.fidonet.org.,100
;;
;;
;; Nodes
;;
Address,Jims_SpaceSuits,100
Address,Sallys_Lunies,110
Address,Moon_Rock_BBS,120
Address,Monolith_HQ,200
Address,Space1999,210
Address,LostOnTheMoon,240
Address,NorthLunaics,300
;;
;; Out of net addresses
;;
Address,Moon_NS.fidonet.org.,999/100
Address,FidoNet_NS.fidonet.org.,1:1/0
Address,naEarth_gate.moon.fidonet.org.,999/1
Address,eurEarth_gate.moon.fidonet.org.,999/2
Address,ozEarth_gate.moon.fidonet.org.,999/3
Address,saEarth_gate.moon.fidonet.org.,999/4
Address,AfricaEarth_gate.moon.fidonet.org.,999/5
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:
domaintail,domain,preference
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
N_Luna.moon.fidonet.org,N_Luna_Net.moon.fidonet.org,100
N_Luna.moon.fidonet.org,N_Luna_NEC.moon.fidonet.org,90
;; Out of zone mail goes through the zone gates
naEarth.fidonet.org,naEarth_gate.moon.fidonet.org,50
eurEarth.fidonet.org,eurEarth_gate.moon.fidonet.org,50
ozEarth.fidonet.org,ozEarth_gate.moon.fidonet.org,50
saEarth.fidonet.org,saEarth_gate.moon.fidonet.org,50
AfricaEarth.fidonet.org,AfricaEarth_gate.moon.fidonet.org,50
JupiterNet.org,Monolith_HQ.N_Luna.moon.fidonet.org,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:
virtual-address,keyword:value,keyword:value,...
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
virtual-address).
3.3.1 Sample capability file.
;; Capability file for Network 999 (N_Luna) of zone 444 (the Moon)
;; (c) Copyright 2001 Network 999
;;
Jims_SpaceSuits.N_Luna.moon.fidonet.org,Protcol:UUCP-Z,File:SDSURISC
Jims_SpaceSuits.N_Luna.moon.fidonet.org,File:PDNVIRTWIND,File:PDNVIRTREAL
Monolith_HQ.N_Luna.moon.fidonet.org,Protocol:X2500,Gateway:JupiterNet.org
Space1999.N_Luna.moon.fidonet.org,File:PDNNUKEWASTE
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.
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
zones.
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.
