The solution is to allow computer users to describe entities using symbolic names instead of numbers. That is, you can refer to something by name. You could say this was the earliest development in "Human-Computer Interfaces".
In this subject, we are mostly interested in the names that people use
for computers in a network. For example, at Bendigo we (in the IT
department) have followed a long tradition of naming our computers
after local flora. Thus we have ironbark,
redgum, greybox, etc, not to mention
bindi, poa, capeweed and lots
more.
Each of these computers can also be identified by its numeric IP address. However, it is much more convenient for us to use its name, and let software perform the mapping to IP addresses when needed.
Such mappings are carried out by a directory service, and in the case of mapping machine names to IP addresses, the directory service is the Domain Name System (DNS).
hosts.txt file, used to map
names to addresses, to include the new name. This is called a flat name
space and works fine when everything is nice and small. It has one big
problem...
It doesn't scale.The solution is to adopt a scheme used naturally by humans in all sorts of fields of endeavour: the hierarchical structure.
Hierarchies have been used since forever to manage complex structures: businesses, armies, bureaucracies, street addresses and computer filesystems. They are one thing that seems to come completely naturally to us.
In the Internet, we say that we allocate names from a hierarchical name space.
In such a system, a name only has to be unique within a local context, or group of names, a context (or domain) name only has to be unique among other domain names at the same level in the hierarchy, etc.
Rules:
bindi.bendigo.latrobe.edu.au.
Domain_name TTL Type Class Value
SOAANS
IN", for
Internet
sheoak is a name server for the zone
bendigo.latrobe.edu.au. This means that if I want to look
up a particular IP address in that zone, I can ask
sheoak.Exactly which server is responsible for a particular zone is specified in start of authority (SOA) RRs. An SOA RR specifies, for the particular name server, the zones for which it has authority. It also has the email address of the site administrator, a unique serial number and various other bits and pieces.
A server also usually has several NS RRs, giving the names of machines which run a nameserver for the specified domain.
A resolver is a library function[1] which queries the nameserver when called from a user program. It can check the local cache of names and, if necessary, request a RR from a nameserver (caching the response). In other words, a resolver is software which asks a nameserver for information.
[1] Such as is built-in to
gethostbyname(3)
{query domain name, type, class}
The server responds with one or more appropriate RRs. It also sends an
ADDITIONAL INFORMATION section, which contains extra RRs which the
resolver will probably find useful. For example, if a resolver queries
for a particular NS RR, the server will return it, plus an additional
type A RR giving the IP address of the name server specified in the
main body of the reply.DNS queries and responses are encapsulated in UDP datagrams. DNS is an excellent example of an application where the reliable, connection-oriented transport mechanism of TCP is not required. If a resolver does not receive a reply from a nameserver, it usually either tries again, or tries the next nameserver for the same domain.
The most common DNS query is of type A, where the resolver is required to map a domain name to an IP address. Some typical type A RRs look like:
ironbark 86400 IN A 149.144.21.60 redgum 86400 IN A 149.144.21.3 bindi 86400 IN A 149.144.20.82
ironbark IN MX 10 ironbark
IN MX 20 redgum
IN MX 40 sheoak
This is called a PTR RR. Performing reverse lookups is much harder than normal forward address lookups.60.21.144.149.in-addr.arpa
[Previous Lecture]
[Lecture Index]
[Next Lecture]
