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

Title: DNS session 2

Time available: 2 hours, depending on how quickly session 1 goes
Students: CEDIA Track 1, approx 40 students. English not first language.

General objective: To understand operation of a recursive nameserver

Specific objectives:
After the lesson, the learner will be able to:
1. Describe how a caching nameserver locates other (authoritative)
   nameservers to find the answer
   (root servers, delegations/NS records, resilience/multiple auth servers
   for the same zone, caching control - TTL, SOA)
2. Show the recursive process occuring using tcpdump, and show an awareness
   of dig +trace and other tools)
3. Use dig +norec to manually walk the tree
4. Configure a caching nameserver and demonstrate its operation
   (flush cache, restrict access by IP address)

Resources:
Computer lab with Linux installed (using default bind-9.x installation)
PC projector with presentation available
Whiteboard

Time	Teaching Point (/ Learner Activity)

0:00	Recap from previous session - ask questions of students in turn:
	- why use names rather than IP numbers?
	- why not use hosts.txt file? why is DNS better?
	- what does resolver library do with a request?
	- how does resolver know where to find caching nameserver?
	- (what protocol and port?)
	- how do you choose which caching nameserver to configure?
	- list the types of resource records application might ask for
	If you are an ISP, you have to build your own caching nameservers.
	So in this session we'll learn how caching nameserver does its job;
	and how to uncover problems caused by authoritative servers!

0:15	[Slides]
	DNS is a distributed database; it is the job of a caching nameserver
	to find the right server which holds the requested information.
	Does it by following the delegation tree.

	Resource record NS: "I don't have the answer, but try here instead"
	Called a "referral"

	Eventually this process will either:
	- find a nameserver which knows the answer (positive or negative)
	- not find any working nameserver (servfail)
	- end up at a faulty nameserver - no answer, no further
	  delegation or wrong answer!

	[note: the caching nameserver might also happen to be auth server
	for the query, in which case it can answer it without asking
	any others]

0:20	How does this process start? Caching nameserver is seeded with a
	list of root servers.

0:25	Each zone has two or more authoritative nameservers for resilience.
	They are all equivalent and can be queried in any order. The first
	one to answer is used. The root servers are busy - there are about
	15 of them

0:30	Because of the load on all nameservers (esp top levels), caching
	is used. All intermediate information is cached as well as the
	final answer. Run through example:
		www.tiscali.co.uk
		smtp.tiscali.co.uk

0:40	Caches are a problem if data becomes stale. The owner of an auth
	server can control how other people caches their data:
	- TTL records on each record
	- Negative TTL in SOA
	The cache owner has little control, nor would they want it

	QUESTIONS

0:50	What sort of problems can occur when caching nameserver is walking
	the tree?
	- one auth server is down or unreachable
	- ALL auth servers are down or unreachable! => RFC2182
	- auth server is not in fact auth - lame delegation
	- inconsistencies between auth servers
	- inconsistencies in delegations
	- inappropriate parameters (e.g. TTL too short)
	They are not the fault of the caching server, but of the auth
	server. Many of these are easy to make and difficult to debug or
	cause intermittent problems, especially because of caching.

1:05	Recursion uses caching and only uses one of N servers. For debugging
	we need to prevent recursion and manually check all intermediate
	servers. dig +norec does this

1:10	Fully worked example: www.tiscali.co.uk

1:30	[Practical]
	Students to do own example(s)

[ probably moves into next day ]
2:00	Configure a caching nameserver
	- check /etc/named.conf (recursion enabled, access restr, named.root)
	- run tcpdump in another window
	- ndc start
	- change /etc/resolv.conf to point to your own nameserver
	- do same query twice: look at 'aa' flag, TTL, query time
	- 'ndc flush' can be used for testing purposes, try to avoid on
	  a live box
	- cache is authoritative for 127.0.0.1 (0.0.127.in-addr.arpa)
	Problems can be avoided by making it authoritative for RFC1918
	address space too.

2:30	Summarise with Q&A:
	- when a caching nameserver receives a request, how does it answer?
	- how does it locate the first nameservers?
	- how does it locate other nameservers?
	- how many nameservers are returned in a delegation?
	- how does it choose which one to use?
	- what does it do with the response?
	- we used dig +norec to examine the DNS tree manually. when a
	  problem occurs you can tell the auth server owner what they
	  did wrong!
	- list the problems which it may encounter while doing its job
	- how many caching nameservers should you build in your ISP?
	- what sort of hardware should you choose for a caching nameserver?