Rdata - the actual data.
There may be any number of RRs held at each node.
The format and semantics of Rdata are determined by the type and
class.
Class is the higher level entity, it is intended to identify a
protocol family, or instance of a protocol. E.g. IN is internet,
CH is the Chaos System.
Type indicates RRs within a class, e.g. IN has MX (mail records),
A (IP address records) etc.
Rdata is 'a variable length string of octets...', the format
varies according to the Type and Class.
In other words the Rdata may be in any format! - RFCs 2163 and
1464 are examples of definitions of Rdata.
2.2.1 IPIG considerations
We should probably define a new Class of RRs for our use.
IETF maintain Class numbers, and Type numbers for the Internet class
(RFC 1700 Assigned Numbers).
I think we have a good case for a new Class (class is defined as
being for a protocol or protocol set), otherwise we'd have to
apply to have some types under the Internet class. Is there a
higher authority that could do the application - e.g. TC46 ?
Then within our class we may define a set of types of RRs,
together with their syntax and semantics.
RFC 1123 (Requirements for Internet Hosts) specifies that DNS
implementations must be robust to new RR types/classes.
As well as various pieces of policy information, there could be
RRs holding such thing as system Ids.
2.3 Queries
The format of query messages and responses is defined in the RFCs.
Basically one can query for particular class/type RRs from a
domain name (node in the name space), the response returns the
RRs (if any) together with information about the RR, e.g. is it
a cached version of the data or an authoritative version.
Since the whole RR is returned the server does not have to have
any specific knowledge about the RR syntax or semantics.
If the data is not held on the particular host that has received
the query, the query may be further pursued in either a
recursive (the query is automatically passed to another server) or
iterative (the answer suggests the next server to try) fashion.
A particular host is configured to act in one mode or another.
A query message may specify a number (16 bit) of
name,type,class triples, i.e. it may carry a large number of
queries at one time, either for more than one domain name or for many
types of records at a particular domain.
The answer message may contain a similar number of RRs in
response.
2.4 Other Information
The information in the data base is held by "name servers",
these also answer queries.
Queries are sent and answers received by "resolvers".
Both UDP and TCP protocols are used in distributing data and
servicing queries.
Data is defined in Master Files, these may be entered directly into
a server, or prepared as text files and sent (by ftp, mail etc) to
the administrator of a server for entering on the system. Master
files are prepared by the administrator of a Zone.
A primary, authoritative, version of the master file is maintained
on one server. At least one secondary version must exist on another
server, but there may be as many secondaries as desired. This builds
a certain amount of redundancy, and hence reliability into the
system.
Servers may cache information that pass through it (in satisfying
queries), the TTL value in the RR indicates how long this information
may be kept.
Servers automatically distribute secondary versions of the Master
information when the primary version changes.
Clients can identify trusted name servers to use before
accepting referrals.
Inverse queries (i.e. give me the node that contains this
RR) are optionally supported as are negative caching (information
about when an RR cannot be found).
Servers may hold copies of a master file or be caching only servers.
3.0 Software
I have not had time to do a survey of available software, so only
know what is available on some UNIX systems. I'm sure that
interfaces are equally available for MS and Mac operating systems.
Software falls into 3 catagories:
