DHCP and DNS lab: configure dnsmasq for a small network in your browser

This lab gives each student a small network inside an Ubuntu VM of their own: a server and two computers, pc1 and pc2, that start with no address at all. The server runs dnsmasq with nothing configured, and the student writes the one file that makes it hand out addresses and answer for the lab’s own names. Nothing is installed on the student’s computer, and a script marks the result, so you do not have to read each machine.

What students learn

How a computer gets an address and finds a name. DHCP: a range to lease from, how long a lease lasts, the router and the DNS server that the server tells every client, and a fixed address for one computer chosen by its hardware (MAC) address. DNS: answering a name from a record in the server’s own configuration, and refusing every other name, since the server has nowhere to forward it. They also see the real tools: dnsmasq on the server, dhclient and dig on the clients, ip to read the result and tcpdump to watch the conversation.

The network and the task

The server is at 10.0.10.1 and pc1 and pc2 are on the same switch, each with a fixed hardware address that the README gives. The student writes /etc/dnsmasq.d/lab.conf so that the server leases addresses from a given range for twelve hours, tells clients a given router and DNS server, always gives pc2 one given address, answers files.lab and printer.lab with given addresses and answers nothing else. The README says each figure and gives no option names and no lines of configuration.

Run it in your browser

VM labs are set as a lab task in a module, and the sample is on the lab’s page. The machine is small: one CPU, 1 GB of memory and 10 GB of disk.

  1. Add the lab. In a module you teach, add a task and choose the Ubuntu VM lab card. The page shows a short description of the machine instead of a compose file.
  2. Start from the sample. The page offers ready-made labs to start from. Choose DHCP and DNS with dnsmasq. Using a sample replaces the text, and Undo brings yours back.
  3. Publish and start your own copy. Publish, then Start. The lab’s own setup script installs dnsmasq, the DHCP client, dig and tcpdump from Ubuntu’s archive and builds the three machines the first time the VM starts, in a few seconds.
  4. Open the terminal. Open its terminal and read README.md in the home folder: it says what the server must do and gives none of the answers.

A basic lesson on this lab

DHCP and DNS Basics is a small lesson worked in this lab, which is an Ubuntu VM: each step is explained and has a Run button that types its command into the machine’s terminal and shows what it printed. A student meets the three machines and sees that the clients have no address, asks pc1 for one and gets nothing, asks the server for a name and is refused, and reads the configuration file, which is empty.

The lesson looks around and leaves the lab’s own task, writing the configuration, to the student, so it hands out no answers. It is deliberately small: it shows a teacher what a lesson worked in a lab is, and the lab does the rest. Copy it into a module of your own to change it.

How it is marked

The lab has a check. It runs on a copy of the saved machine after a fresh start, so it sees only what the student saved. It stops whatever dnsmasq was running, starts one from the saved files in /etc/dnsmasq.d, wipes both clients and has them ask again with the real DHCP client. Then it reads what happened: each client has an address in the range, the router, the DNS server and the twelve-hour lease the task asks for, pc2 has its fixed address, and the two names resolve to the right addresses while other names are refused or not found. Addresses typed by hand on the clients, a wildcard that answers every name, names put in /etc/hosts and a dnsmasq started by hand with a file that was never saved do not pass, and the first line of what the check printed says which part and why.

  1. Hand it out. Assign the lab like any task, with a due date if you want one. Each student gets a VM of their own, kept between sessions.
  2. Run the check. On a student’s row in the class list, press Run the check. It starts a copy of their saved machine that is not saved back, runs the lab’s check script as root and shows whether it passed, what it printed and when. The student is not told the result.
  3. Mark it. Read the first line of what the check printed: it names the first thing that is not right and says why. Send the work back with a reason if it needs more.

The definition on GitHub

The file is the whole lab definition, the same text the platform runs: size, setup script, README and check. Copy it and change the addresses and names, in the setup and the check together, to make your own.

Questions people ask

Does the lab need a second DHCP server or a real router?
No. The server and the clients are network namespaces joined by a virtual switch inside the student’s VM, and the router the clients are told about is only an address in the lease. There is no other DHCP server to compete with.
Can a name outside the lab be looked up?
No. The VM reaches only Ubuntu’s archive, PyPI, npm and GitHub, and the lab’s DNS server has nowhere to forward a name to, so the lab asks that anything but the two names is refused or not found.
What does the DHCP and DNS lab check?
The check starts dnsmasq from the saved files, makes both clients ask again, and reads what happened. Each client must have an address in the range, the router, the DNS server and the twelve-hour lease, pc2 must have its fixed address, and the two lab names must resolve while other names are refused.