Lesson plan
-----------

Title: DNS session 1

Time available: 2 hours
Students: CEDIA Track 1, approx 40 students. English not first language.

General objective: To understand overall purpose and structure of DNS

Specific objectives:
After the lesson, the learner will be able to:
1. Explain the need for DNS and outline the hierarchical structure
2. List common RRs and explain their usage
3. List the three roles (resolver, cache, authoritative)
4. Configure a resolver in Unix and issue queries using 'dig'

Resources:
Computer lab with Linux installed (using default bind-9.2.1-16 installation)
PC projector with presentation available
Whiteboard

Time	Teaching Point (/ Learner Activity)

0:00	Introduce self - where I work
	Usual points about stopping me if I am not understood or am
	speaking too fast.
	Name badges visible.

[slides]
0:05	Computers connect using IP addresses. Why do we need names?
	- they are easier to remember
	- computers may need to be moved and renumbered. Physical location
	  tied to subnet.
	Old solution: hosts.txt (/etc/hosts)
	Doesn't scale:
	- size of single file
	- single point of administration
	- consistency
	- out-of-date information

0:10	DNS is a distributed database for holding name to IP address
	(and other) information.
	Distributed:
	- shares the administration
	- shares the load
	Robustness and performance achieved through
	- replication
	- caching
	DNS is a critical piece of Internet infrastructure; most Internet
	applications cannot function without it; and yet is transparent
	to most users

0:15	DNS is hierarchical
	Example: yahoo.com, www.tiscali.co.uk
	- gives globally unique names
	- administered in zones - portions of the tree
	- you can give away (delegate) control of part of the tree
	  underneath you.
	Example: isoc.org, isocws.isoc.org, t1.isocws.isoc.org

0:25	A domain name (like www.tiscali.co.uk) is the KEY to look up
	information
	The result is one or Resource Records (RRs)
	There are different types of RRs
	- A, PTR, MX, CNAME, TXT, SOA/NS (describe)
	You can ask for the specific type you want, or ask for 'any'
	RRs associated with the domain name.

0:30	Possible responses:
	- positive (found RRs)
	- negative (definitely no RRs matching your query)
	- servfail (cannot find the answer)

0:35	Special key domain for PTR in-addr.arpa / ip6.arpa usage
	Reverse DNS quite important because many systems expect reverse
	and forward DNS to match, or will refuse to connect

QUESTIONS?

0:40	DNS is client-server (necessary to work across a network!)
	Requests/responses are normally sent in UDP packets, port 53
	Occasionally TCP virtual circuits, also port 53
	(for very large requests, e.g. zone transfers from master to slave)

0:45	There are three roles:
		(app)
		  v
		resolver -> cache -> authoritative server
	(outline the roles)
	The *same* protocol used for resolver -> cache and
	cache -> authoritative server.
	It is possible that a machine can perform two roles (i.e. be cache
	for some queries and authoritative for other queries; still distinct
	roles at different times). NOT RECOMMENDED, see later

0:55	ROLE 1: THE RESOLVER
	- a piece of software which formats a DNS request into a UDP
	packet, sends it to a cache, decodes the answer, and returns it
	to the application
	- usually a shared library (e.g. libresolv.so under Unix) since
	so many applications need it
	- every client needs a resolver, e.g. every Windows workstation
	has one. So important to know even if you are not a Unix admin.

1:00	How does the resolver find the cache?
	- It has to be configured with it statically (or through some
	other configuration mechanism, e.g. DHCP)
	- Must configure with the *IP address* of the cache (why?)
	- Good idea to configure more than one cache, in case the first
	one fails

1:10	How to choose which cache(s) to configure in the resolver?
	- We must have *permission* to use it
	- Nearby cache minimises round-trip time
	- Nearby cache can save bandwidth on your external link
	- Prefer a reliable cache, perhaps under our own control

1:15	Resolver can also be configured with default domain(s)
	- if "foo.bar" fails then retry query as "foo.bar.mydomain.com"
	- saves typing but adds confusion
	- usually best avoided

1:20	Show Unix /etc/resolv.conf format

1:25	Testing DNS
	- just stick www.yahoo.com in a web browser? Not a good test!
	- 'dig' is a client which just makes DNS queries and displays
	  the results. Better than 'nslookup', 'host' because it gives
	  the raw information

1:30	dig syntax:
		dig foo.bar. [a]
		dig foo.bar. mx
		dig @1.2.3.4 foo.bar. mx
	Trailing dot prevents any default domain being added.
	Interpreting the results.

EXERCISES:
	- configure Unix resolver
	- use dig:
		- A
		- other (e.g. MX)
		- non-existent answer
		- reverse lookup: long way, and -x
	- use tcpdump to show queries being sent to cache