RFC 1034 - An insight into the 1980's

-->

If you think that RFC make dry reading, maybe just maybe you just haven't given them enough of a chance yet. Today, I begin reading my first RFC, I choose RFC 1034 and I can genuinely say that I've found much more interesting than I was expect, in fact I've struggled to put it down (though I suspect that says more about me than RFCs) . RFC 1034 was written 1987 (before I was even born) and offers an insight to a world before DNS and how its designed envisioned DNS's future use. Below are my notes on the RFC so far (this is likely to be the first collection of notes out of 3). Sorry for the bullets but its my preferred way to take notes

-->

I've located the Request for comments (RFC) relating to DNS from the following page http://www.zoneedit.com/doc/rfc/. The RFC that I am going to begin with reading is RFC 1034. This RFC is developed in November 1987 and it titled “Domain Names – Concepts & Facilities”

-->

Historical Context

• Originally per host file in /etc/hosts for hostname to IP address mapping was updated via FTP.
• The bandwidth required to update this per host file was proportional to number of host squared, hence exponential grow of hosts mean new system was required
• The first operational packet switching network was the Advanced Research Projects Agency Network (ARPANET)
• When changes to the per host file were make, they took along time to propagate to all hosts

Common Ideas from Proposed Solutions

• Hierarchical name space with the hierarchy corresponding to organisations structures
• Using a full stop “.” to mark the boundary between hierachy levels

DNS Design Goals

• Consistent name space where names do not include network identifiers or addresses
• Distributed management with local caching
• Minimising attempts to collect consistent copies of entire database as this is not scalable
• Source (not client) control tradeoff between cost, speed and accuracy of caches
• All data associated with a name is tagged with a type
• Name server translations should be independent of communication system that carriers them
• The system should be useful across a wide spectrum of hosts

Usage Assumptions

• Initially total database size is proportional to number of hosts but this will grow in time
• System wide data will change slowly, subnet wide data will change rapidly
• Each organisation is responsible for its own domains including providing redundant name servers
• Clients use trusted name server before name server outside the “trusted set”
• Availability is more important than consistency so its ok that updates are not simultaneous
• Believe old data when new data is not yet avaliable
• Copies of translations are distributed with time-outs for refreshing, the distributor sets time-out value
• When a name server is presented with a query that can only be answered by some other server, either a recursive (name server asks another server to do query) or iterative (name server returns address of another name server to ask instead). The iterative approach is preferred but the recursive approach is still an option
• All data originates from master files keep on hosts that use the DNS
• All master files are updated by local sysadmin and all master files are text files that are read by a local name server
• User programs access name servers through standard programs called resolvers
• The standard format of master files allows them to be exchanged between hosts
• Sysadmin provides zone boundaries, master files of data, updates of master fules and refreshing policies
• DNS provides standard formats for resource data, standard method of querying the database, standard methods for name server to refresh local data from foreign name servers

DNS & Resource Records (RR)

• The names in the name space will have a tree structure and RR hold the data associated with each name
• Each node and leaf on the DNS tree has a set of information associated with it and a DNS query aims to extract this information
• A DNS query includes the name of interest and the type of information that is required

Name Servers

• These are server programs which hold information about the DNS tree structure and information set
• A name server may cache information on DNS tree structure or information associated with particular names
• In general, a name server has complete information from a subset of the DNS tree leaves and then pointers to other name server that can be used to get information on the other areas of the DNS tree
• A name server has authority for the area of the DNS tree for which it has complete information
• Authotitative information is organized into units called zones

Resolvers

• Resolvers are programs that extract information from the name servers in response to client queries
• All resolvers must have access to at least one name server
• Typically a resolver is a system routine that is accessible to user programs

DNS from a client prospective

• DNS is accessed via a procedure call to the local resolver
• The DNS consists of a single tree and the user can request information from any section of the tree

DNS from the resolvers prospective

• DNS is composed of an unknown number of name servers
• Each name server hold at least one piece of information from the DNS tree
• The DNS tree is static

DNS from the name servers prospective

• DNS is divided into zones
• The name server has local copies of some zones
• The name server must periodically refresh its zones from master copies in local files or foreign name server

Name Specification

• The term “node” is used to refer to both interior nodes and leaves
• Each node has a resource set, though this can be empty
• Each node has a label, 0 to 63 octets (an octet is 8 bits) in length
• Brother nodes may not have the same label
• The same label can be used by nodes that are not brothers
• The root label is null
• The domain name of a node (not the same as the label for a node) is the list of labels on the path from the node to the tree root
• The label that compose the domain name are read from (most specific) left to (most general) right, e.g. consider the structure of the DNS name for college computers as342.priv.queens.cam.ac.uk
• Domain names are case-insenstive
• In domain names the labels are separated by dots (.)
• A domain name ending in a dot represents a absolute/complete domain name
• A domain name not ending in a dot represents an incomplete domain name that should be completed by local software (aka relative domain name)
• The maximum domain name length is 255 octets (set of 8 bits), this includes labels and label lengths
• A domain is identified by a domain name and consists of the tree at and below that domain name
• A domain is a sub domain of another domain if it is contained within that domain
• You can test if a domain is a sub-domain of another, if the domain name is the within the end of the sub-domain e.g. cam.ac.uk is a sub-domain of uk and queens.cam.ac.uk is a subdomain of ac.uk
• Labels must follow the rules for ARPANET host names

Email

• The usually format of email addresses is localpart@maildomain, this is mapped to a domain name so that it can be looked up in the domain name tree by converting localpart into a single label (ignoring dots) then converting maildomain into a domain name (not ignoring dots) and replacing @ with a dot to form a domain name so the email address as342@cam.ac.uk will become as342.cam.ac.uk
• Domain names ( and therefore email addresses) are case insensative

Resource Records (RR)

• Each node in the tree has a set of resource information, this can be empty
• The set of resource information is composed of the set of Rrs
• Order of RRs is not significant and need not be preserved
• The owner of RR is the domain name where the RR is found, this is normally inplicit rather than being an explicit part of a RR
• The type of a RR is an encoded 16 value such as:

A – a host address

CNAME – the canonical name of an alias

HINFO – CPU & OS used by a host

MX – mail exchange for domain

NS – authoritative name server for the domain

PTR – pointer to another part of domain name space

SOA – start of zone of authority

• The class of a RR in an encoded 16 bit value such as IN – internet system or CH – Chaos System
• The TTL of a RR is the time to live of the RR, this is a 32 bit integer in seconds, this defines how long a RR can be cached for before discarding, this limit does not apply to authoritative data in zones (TTL of 0 will prevent caching)
• The RDATA of an RR contains different values depending on the type of class of the RR such as:
• If type is A and class is IN, then RDATA is a 32 bit IP address
• If type is A and class is CH, then RDATA is a domain name followed by a 16 bit octal Chaos address
• If type is CNAME, then RDATA is a domain name
• If type is MX, then RDATA is a 16 bit preference values followied by a host name willing to act as a mail exchange
• If type is NS, then RDATA is a host name
• If type is PTR, then RDATA is a domain name
• If type is SOA, then RDATA is several fields
• The structure of an RR is as follows:
• start of line gives the owner of the RR, next we list the TTL, the type and the class of the RR (dig giving results in different order)
• Domain names in RR's could point at the primary name not another alias to avoid extra indirection

Queries

• queries are carried in UDP or over TCP connection
• responses to queries are either the answer to the question, refers the requester to another set of name server or signals some error condition
• in general the resolver deals with queries on the users behalf
• DNS queries and responses have a standard format, the start is a opcode which is one for a standard query
• Then there are 4 section in a DNS query/response:
• Question – Query name and other parameters
• Answer – Carries RR's which directly answer the query
• Authority – Carries Rrs which describe other authoritative servers
• Additional – Carries Rrs which may be helpful in using the Rrs in the other sections
• A standard query specifies a target domain name (QNAME), query type (QTYPE) and query class (QCLASS)
• QTYPE field may specify a specific type, AXFR special zone transfer QTYPE, MAILB matches all mailbox related Rrs or * which (like the regular expression) matchs all RR types
• QCLASS field may contain a specific type or * to match all RR classes