This is the full narrative for the talk on subdomains, or more specifically, on creating subdomains.

Firstly I intend to give you an overall picture of the DNS structure and it's role including outlining some of the other components of DNS, such as Name Servers, Domain Names and Delegation. From here I shall talk about the place within this structure of subdomains, how they work, what they do and how we go about creating them.

Now as most of you probably know already, subdomains are an integral part of the Domain Name System (or DNS) setup. The DNS was a system that was setup to enable us humans to interpret an address oh a machine or a host through a name instead of a number. For instance, instead of saying that you had connected to machine 192.112.35.4, you would be able to say that you were connected to a name, eg. the NIC.

The DNS is a distributed database, allowing local control of segments of the overall database and yet data from each segment is available across the network through a client-server scheme. Name Servers comprise the server half of DNS' client server structure and they are actually programs. Name servers contain information about a portion of the database and make it available to clients called Resolvers, therefore making any local section of the database available to any other part of the overall structure.

The structure of the DNS database is very similar to that of a DOS or UNIX file system. This structure can be imagined in the shape of an inverted tree, with the root at the top. In UNIX the root is symbolised as a back slash, "/", in DNS it is symbolised as a null label (""), but is written as a single dot "." in text. Each node in the tree represents a partition or a new segment in the database structure, or a directory, as you would refer to it in a file system. In DNS, the directories are called Domains. Each domain or directory can be further divided to create Subdomains within the DNS, just in the same way as directories are divided into subdirectories in a file system.. Subdomains like subdirectories, are drawn as children of their parent node.

Every domain is named, like every directory, and it's name gives it's relative identity to its parent domain. This is similar to a directories relative name. A domain also has a Domain Name which identifies it's position in the data base, much the same as a directories "absolute pathname" reflects its place in a filesystem.

In DNS the full domain is the sequence and order of labels from the domain to the root, with a "." (dot) separating the labels (ie reading from the bottom up the tree to the root). In a file system an absolute pathname is read from root to leaf using "/" (backslash) to separate names (ie from the top down to the directory name).

In DNS each domain can be looked after or administered by a different organisation. The ability to spread the load of administration through the DNS is the major purpose of its organisational structure and its main relevance, reflecting the need for localised coordination. Each organisation can break their domain up into a number of subdomains and spread the responsibility and admin of the subdomains to other organisations. For example the Internet's Information Network Center (INTERNIC) runs the com domain, and assigned ExNet the subdomain, exnet.com.

In a filesystem directories contain files and are sometimes said to contain subdirectories too. Likewise domains can contain both hosts and other domains; ie their subdomains. Domain names are used as indexes in the DNS database. You might think of data in DNS being attached to a domain name.

Each host on a network has a domain name, pointing to information about the host. This info may include IP addresses, or info about mail routing etc. Making names within a hierarchical structure eliminates the danger of name collisions, when two domains have been named the same. Whatever a domain is called, it should not conflict with other domain names , since domain names have their own unique domain attached to the end. Caroline will talk to you a little later about the actual process of securing a domain name.

Now that you know a little about the structure of the DNS, I will briefly try to explain how DNS works, before explaining the creation of Subdomains. As I've already said the DNS is basically a database of host information, and you have seen a little of the client-server architecture within which DNS works. Now let me give you a broader definition of the aspects of DNS...

Domain Name Space:

Each unit of DNS's distributed database is indexed by a name. These names are essentially just paths in the large inverted tree, called the Domain Name Space. So effectively all domains and subdomains (ie all nodes within DNS structure) are found within the Domain Name Space.

Domain Names:

Each node in the tree is labeled with a single name. The label can be up to 63 characters in length. Domain names are always read from the node toward the root, ie up the tree. The full domain name of any node is the sequence of labels on the path from that node to the root. DNS requires that sibling nodes, nodes that are children of the same parent, be named uniquely. This restriction guarantees that a domain name uniquely identifies a single node in the tree. The restriction should not be an inconvenience however as it applies only to sibling names, not all nodes on the tree. The same restriction applies to a UNIX file system.

Domains:

A domain is simply a subtree of the domain name space. A domain's domain name is the same as the domain name of the root node of the subtree. That just means that the name of the domain is the same as the name of the node at the top of the tree. Any domain name within the subtree is considered part of the domain. Since a domain name can be in many subtree's a domain name can alsdo be in many domains. Effectively therefore, a domain is just a subtree of the domain name space. Remember though that the domain names are simply indexes in the DNS database, and they indicate the presence of a host. So the domain names are names of those hosts. A domain contains all the hosts who are within that domain. These hosts are normally related logically through some kind of organisational or geographical affiliation. They will not necessarily be grouped in terms of networks or addresses. You might find 10 different hosts, all from different networks and maybe even different countries under the same domain.

Top Level Domains

The original top level domains divided the Internet domain name space organisationally. There were seven main top level domains; com, edu, gov, mil, net, (networking organisations) org and int (international orgs eg NATO). These top level domains were all fairly US orientated, but with the development of the Internet the designers of DNS allowed for geographical designations too. New top level domains were reserved for individual countries, for instance Malta as you know has mt. This does not always stop problems however as the Ukraine are currently contesting the domain uk, which is presently affiliated with the United Kingdom.

Delegation:

One of the key points in the design of the hierarchical structure of DNS' system is to spread administration for domains. This is achieved through delegation. Delegating domains is a lot like delegating tasks at work. An organisation administrating a domain can divide it into subdomains. Each one of those subdomains can be delegated to a new organisation. This means thet the organisation who is delegated the subdomain, becomes responsible for the administration of of all the data in that subdomain. They can freely change the data and even split their subdomain into more subdomains and delegate those. So the term delegation, refers to assigning responsibility for a subdomain to another organisation.

Now that we've been through some of the main aspects of the DNS structure and defined their roles individually, lets now go on to discuss how and when we create subdomains.

The first thing to bear in mind when you decide to create subdomains, is to maintain an organised structure within your domain. An important part of this structure, is the allocation of names to your child domains. The management of subdomains, or "parenting", as it is often known as, relies on maintaining good relationships between the name server authoritative for the domain and it's subdomains. In other words ensure that the delegation between the parent and child is current and correct.

Good parenting is essential to the success of a network, as the naming service becomes critical to navigating between sites. Incorrect delegation to a child domain might render that sight unreachable and the loss of connection to a parent domain's name server can leave a site unable to reach any hosts outside the local domain.

Another attribute to good parenting is to know when to make the decision to become a parent. Well far be it from me to tell you, but there are some guidelines to enlighten you through this potentially difficult decision. Some of the most common reasons are...

You are thirty something...

The need to delegate or distribute management of the domain to a number of organisations. Remember the idea of being able to spread the administration through the structure of DNS.

The large size of you domain may encourage you to break it up into smaller subdomains. Dividing your domain may make it easier to maintain and manage and offload the nameservers for the domain.

Another reason to create subdomains may be the need to distinguish hosts organisational affiliation by including them in particular domains.

Once the decision has been made to create subdomains you must decide how many to have, and what to call them. The answers will decide the organisational affiliation of your subdomains, for example if your organisation has 4 branches or offices you may decide to delegate 4 subdomains.

You may have a choice between dividing your subdomains into a few large subdomains, or create more smaller subdomains. A few larger subdomains makes for less work in the parent domain because there is not so much delegation to keep track of. However you end up with larger subdomains, which require more memory and faster name servers and the administration is not distributed as far. Implementing site level subdomains may force unrelated groups at a site to share a single name space and a single point of admin.

Alternatively delegating many smaller subdomains can cause problems for the administrator of the parent domain. Every time a subdomain adds a nameserver the delegation data changes. This results in more administrators and more relationships for the parent administrator to maintain and more overall organisation to look after. On the other hand subdomains are smaller and easier to maintain and it allows for closer management of subdomain data. ExNet does not control any subdomains, as it is probably only worth delegating them on the ratio of 1 to every hundred machines.

Therefore you must weigh the pros and cons of the few large subdomains or the many smaller subdomains. There is probably a natural divide in your organisation, depending on whether you run your networks at the site level or decentralised networks that manage everything themselves. Some basic rules that could help you decide how to carve up your domain.

Don't forge your organisation into weird and wonderful domain structures. Decentralised autonomous operations demand different domains---that's the "raison d'etre" of DNS.

The structure of your domain should mirror the structure of your organisation, especially its support structure.

Once you have decided on how many subdomains or children you're going to have, you have to decide on what to call them. It may be polite to involve your future subdomain administrators in the naming process. It's nice to allow users of one domain or even outside your domain entirely to be able to guess or figure out in which domain a particular host belongs.

You may want to to establish a naming committee to best configure the allocation of your subdomains, in order to avoid any confusion. In a dynamic company the names of organisations can change frequently, therefore to name the subdomains after organisations can be disastrous, as you will not want to rename a subdomain every time an organisation changes.

Geographical names are more stable than organisational names, but sometimes the name of the place is not as well known as the company.

You should be careful not to sacrifice readability for convenience. For example two letter subdomains may be easy to type, but they can be impossible to recognise. Too many companies use cryptic, inconvenient subdomains, where simple names would be more appropriate. The general rule seems to be , the larger the company, the more indecipherable the domain names---so be alternative, and delegate sensible domain names.

Another tip is don't use existing, reserved top level domain names as subdomain names. This can cause problems. Even if it seems appropriate to use two letter abbreviations, for your international subdomains, or organisational top level domain names like "net" for your networking organisation, but this is only going to cause confusion.

So now that you, have an idea of how to appropriately divide your domain structure and what to call your subdomains, we need to look at the actual hands on process of how to set them up, and how resultingly they connect you to the rest of the Internet.

Now that you've decided that you want to create subdomains, and you've juggled with all the options of how best to delegate them, actually creating them is easy. It's a good idea to decide how much autonomy you are going to give you subdomains. It's not always true that if you're creating subdomains, you're automatically going to delegate it to another organisation.

Consider carefully how the computers and networks within your a subdomain are managed, when choosing whether or not to delegate it. It doesn't make sense to delegate a subdomain to an entity that doesn't maintain it's own hosts, for example in a large company, the personnel dept probably doesn't maintain it's own hosts or computers, the IT dept will. So while you want to create a subdomain for them, delegating the management to them will probably not work.

It is possible however to create a subdomain without actually delegating it. This is done by creating resource records that refer to the subdomain within the parents domain. For example, exnet.com has a host that stores its complete database of employee and customer records, CUTNCURL. To put CUTNCURL in the personnel.exnet.com domain, we could add records to db.exnet:

Partial contents of file db.exnet:
cutncurl.personnel IN A 192.253.253.10
IN MX 10 cutncurl.personnel.exnet.com
IN MX 100 postmanrings2x.exnet.com
employeedb.personnel IN CNAME cutncurl.personnel.exnet.com
db.personnel IN CNAME cutncurl.personnel.exnet.com

Now users can log into db.personnel.exnet.com to get to the employee database. Notice that there is no SOA record for db.personnel.exnet.com? This is because there is no need for one as exnet.com SOA record indicates the start of authority for the entire exnet.com. Since there is no delegation to personnel.exnet.com its part of the exnet.com zone.

If you do delegate however, you will need to do things a little differently.

First you will need to allocate a couple of nameservers for your subdomain. If you only allocated one, it would leave just the one point of failure, which would leave the subdomain isolated.

Next you should create a data file that includes all the records for the hosts in the domain.

Then you create a named bootfile for the primary. Now configure the primary name servers resolver.

Start up the named process on the primary name server and check for syslog errors. You can use ns lookup to check over the hosts for the subdomain.

Now set up the secondary name server. Go through the same process as you did with the primary name server setup. Start the named process and check for errors in the syslog output.

All thats left now is to delegate the domain to the new name server. Add the appropriate NS records.

A name server outside the domain is still not going to be able to look up the address of the new subdomain's name servers in order to send queries to them. The solution to this problem is to include the addresses of the new subdomains name servers in the parent domain's name servers. While these records are not strictly part of the parent domain, they are necessary for delegation to the subdomain. These addresses are called glue records. These enable a foreign server to find the address it needs by pointing it to the host that carries the records.

The last thing to do is to delegate an in-addr.arpa domain. The top level arpa domain is managed by INTERNIC. You simply fill in one of their templates and send it of to them.

Managing the delegation of subdomains is necessary, for instance if the domain grows and you want to add name servers. In this case the parents job is relevantly easy. All you do is add the NS and A records to the db.val file and remember to send a message to INTERNIC requesting that the domain be delegated to the new name server.