Make Your Own DNS Server — And Block Adverts Across a Network
A practical Linux project that makes DNS, networking and security visible.
Open a website and you see a page. What you do not see is the collection of requests that helped assemble it: requests for images, fonts, video, analytics and advertising services.
What if students could watch some of that activity happening — and decide which domain lookups their network should answer?
That is where Pi-hole becomes interesting.
It can block requests to many advertising and tracking domains across devices using it for DNS. But its greatest value in a computing lesson is the opportunity to investigate a service that normally works quietly in the background.
The aim is to build something useful, observe its behaviour and explain the evidence.
1. DNS: the question before the connection
DNS stands for Domain Name System. Among its jobs is finding IP addresses associated with names such as www.example.com.
A browser needs an address to establish a connection to a server. DNS helps it find one. The subsequent web connection is a separate operation. [1]
An address-book analogy is useful: looking up somebody's telephone number and making the call are different actions.
For students, that distinction matters. A DNS server does not normally download the webpage on the browser's behalf.
There is also more to DNS than one name matching one address. An A record provides an IPv4 address; an AAAA record provides an IPv6 address. A name can have multiple records, and answers can change.
The first question I would ask is:
If a computer cannot look up a website's address, does that necessarily mean its internet connection has failed?
That question becomes much easier to answer once students operate their own DNS service.
2. What Pi-hole actually does
Pi-hole provides a local DNS service with filtering. In a typical installation, permitted queries that cannot be answered locally are forwarded to a configured upstream DNS resolver. Pi-hole also caches answers for reuse. [2]
For blocked domains, it supplies a blocking response instead of the normal address. Its default NULL mode returns 0.0.0.0 for an A query or :: for an AAAA query. Other blocking modes exist. These are unspecified addresses, not the address of an alternative advert server. [3]
This is often called DNS sinkholing.
Imagine a fictional webpage whose main content comes from one domain while an advertising script comes from another. If the advertising domain is blocked, the browser cannot obtain its normal address through Pi-hole. The main page may still load.
Pi-hole filters domain lookups. It does not inspect each image or video and decide whether it is an advert.
That explains both its usefulness and its limitations.
3. Why this makes a strong computing project
My preference in practical teaching is to give students something they can change, measure and explain. A working service gives technical vocabulary a purpose.
Pi-hole brings together several ideas relevant to GCSE and A-level Computer Science, including OCR H446:
| Concept | Practical question |
|---|---|
| Client-server systems | Which device asks the question, and which service answers it? |
| IP addressing | Why must clients be able to find the DNS server reliably? |
| DNS | What information does an A or AAAA query request? |
| DHCP | How can a device discover which DNS server to use? |
| Caching | Why might a repeated lookup avoid an upstream request? |
| Security | What can filtering prevent, and what can bypass it? |
| Testing | What evidence would demonstrate that our rule caused a change? |
Installing software is the beginning. The deeper learning comes from predicting what should happen and investigating what actually happens.
4. Choose a small, manageable starting point
For this project, use:
- A Raspberry Pi or another small computer running a currently supported Linux distribution.
- Reliable power and storage.
- A network connection; Ethernet is convenient for a service that should remain available.
- A Windows or Linux computer for testing.
- Access to the router's settings if you later extend the project across your own network.
Pi-hole does not require a Raspberry Pi. Its prerequisites currently list modest minimum resources: 512 MB RAM and 2 GB free storage, with 4 GB recommended. Check the supported operating systems and versions before preparing the host. [4]
A Linux virtual machine on a Windows computer is another possible teaching arrangement. It needs a network configuration that makes it reachable from the test client, usually a bridged or external network adapter. The host computer and virtual machine must remain running while clients depend on them.
For a first investigation, I would use one test client, then expand after verifying the results. Work on a network you own or have permission to administer.
5. Install Pi-hole and establish a baseline
Give the server a predictable address
Arrange a stable LAN address, for example through a router DHCP reservation. Pi-hole's documentation requires a static address or reservation. [4]
For the examples below, assume:
| Device | Illustrative IPv4 address |
|---|---|
| Router | 192.168.1.1 |
| Pi-hole | 192.168.1.10 |
| Test computer | 192.168.1.50 |
These are examples, not settings to copy blindly. Use addresses appropriate to your own network and avoid conflicts.
Use the official installation instructions
Update the host using its operating system's normal process. Then follow the current Pi-hole installation guide. One documented method downloads the installer before running it: [5]
wget -O basic-install.sh https://install.pi-hole.netReview the downloaded script before running it with administrator privileges:
sudo bash basic-install.shDuring setup, select the appropriate network interface and an upstream resolver. For a short, agreed classroom investigation, enable sufficient logging to see the test queries. Record the final dashboard address and login details.
On a typical default setup, the web interface is available at:
http://192.168.1.10/admin/Use the address and port reported by your installation if they differ. Set a strong administration password; the current command is: [6]
sudo pihole setpasswordKeep this first installation simple. Use the initial blocklist offered during setup and check that it has loaded. Adding numerous extra lists immediately makes it harder to explain why something was blocked.
Query Pi-hole directly
Before changing the computer's normal DNS settings, explicitly send it a test query.
On Windows:
nslookup example.com 192.168.1.10On Linux, where dig is installed:
dig @192.168.1.10 example.com A
dig @192.168.1.10 example.com AAAARecord the answer and check that the request appears in Pi-hole's query log. If it does not, investigate connectivity, the service and local firewall rules before proceeding.
This confirms that Pi-hole can answer an explicitly directed query. It does not yet prove that the browser or the rest of the network uses it.
6. The clearest experiment: block, observe, restore
Rather than starting with an unfamiliar advertising domain, use a harmless, predictable target: example.com.
Step A: Record the unblocked response
Run the direct query above. Save the result and note the query-log entry.
Step B: Add one exact rule
In Pi-hole's domain management interface, add example.com as an exact denied domain. Ensure the rule is enabled and applies to the test client, normally through the default group.
Menu labels can vary between releases. The important choice is an exact domain rule rather than a broad regular expression.
Step C: Repeat the same query
Run the identical command again. In default NULL mode, the answer should now contain 0.0.0.0 for A or :: for AAAA, and the log should identify the query as blocked. [3]
Step D: Remove the rule and retest
Remove the temporary denial, then repeat the query and confirm that normal resolution returns. If an answer persists, allow relevant cache entries to expire and retest.
| Stage | Predicted observation |
|---|---|
| Before denial | Normal DNS answer |
| Exact denial active | Blocking response and blocked log entry |
| Temporary denial removed | Normal resolution restored after any relevant caching |
The table describes expected behaviour, not measurements already collected.
Ask students to explain why the evidence supports a causal link. What stayed constant? What changed? Why is restoring the original result useful?
Also ask whether blocking example.com necessarily blocks every subdomain. An exact rule matches the specified name; it is not automatically a wildcard rule.
7. Let one device use Pi-hole normally
Record the test device's original DNS configuration. In its network settings, set its DNS server to the Pi-hole address, taking account of any separately configured IPv6 DNS servers.
Then try a lookup without specifying a server:
nslookup example.comCheck which server answers. Browse a few agreed websites while watching the query log.
The browser may use a different DNS path from the command-line tool, particularly if secure DNS is configured. Treat the log as evidence: did the browser's requests actually arrive?
If testing fails, restore the original DNS settings — often automatic settings supplied by the router — and reconnect the device. Keep that rollback available throughout the investigation.
8. Extend filtering across the network
Once one client works, configure your router's LAN DHCP settings to advertise Pi-hole as the DNS server. Renew client leases or reconnect devices, then verify requests from several clients. Pi-hole's post-install guide describes this arrangement. [7]
Some routers instead forward client DNS requests themselves. This can work, but Pi-hole may identify the router as the requester rather than each individual device.
Do not assume that changing a router's WAN DNS setting is equivalent to configuring what LAN clients receive. Check the router's own documentation.
If the router cannot advertise a custom DNS server, Pi-hole can provide DHCP. That is a separate configuration task: disable the router's DHCP service before enabling Pi-hole's replacement, and record the original settings. Avoid accidentally operating two competing DHCP servers. [7]
Two details deserve particular attention:
A public secondary DNS server can bypass filtering. Clients do not universally treat the second address as an emergency-only option. For filtered redundancy, use a second working Pi-hole rather than assuming an unfiltered resolver will remain unused.
IPv6 needs consideration too. Clients may receive IPv6 DNS information separately. Ensure the DNS resolvers advertised for both protocols match your intended setup. Looking up an AAAA record through Pi-hole's IPv4 address is valid; the query's transport and the address type being requested are different things.
Check for forwarding loops as well. If the router forwards queries to Pi-hole, Pi-hole should not send those same queries back to the router as its upstream resolver.
9. Watch the requests — but interpret them carefully
Open an agreed webpage and inspect the query log. You may see names associated with content delivery, analytics, advertising and background activity.
Ask:
- Which requests appear when the page opens?
- Which were blocked, cached or forwarded?
- Which names remain unfamiliar?
- What happens when the browser is closed?
An unfamiliar domain is not automatically malicious. A familiar-looking name is not proof of safety. Background apps and operating system services also generate requests.
Nor is the DNS log a complete browsing history. It records domain queries that reached Pi-hole, not full HTTPS URLs or the contents of pages. Caching can mean a page visit produces no fresh lookup, while background activity can produce lookups without a person opening a page.
For teaching, I would use a dedicated test device and agreed activities. Pi-hole offers privacy settings that hide domains, hide clients or reduce recorded detail further. Avoid publishing identifiable query logs in screenshots. [8]
10. What does “25% blocked” really mean?
Suppose a fictional observation period contains:
Total DNS queries = 8,000
Blocked DNS queries = 2,000
Blocked query percentage = (blocked queries / total queries) x 100
Blocked query percentage = (2,000 / 8,000) x 100 = 25%That tells us about the share of recorded DNS queries blocked during that period.
It does not establish that 25% of internet traffic was advertising, that 25% of bandwidth was saved or that pages loaded 25% faster.
A small background service can repeatedly retry a blocked name. A video stream can transfer a large amount of data after relatively few lookups.
This makes an excellent data-literacy exercise: what does the counter measure, and what additional measurements would justify a stronger claim?
11. Why some adverts remain
Pi-hole works well when unwanted content uses domains that can be blocked separately from useful content.
When adverts and wanted material share a hostname, domain filtering cannot reliably distinguish between them. YouTube adverts are a familiar example: blocking relevant video-serving domains can also break the videos. [9]
Pi-hole also does not tidy up every empty advert space in a page. Browser extensions can operate within the browser and make decisions that a DNS filter cannot.
Filtering can also be bypassed when a device or application uses another resolver. DNS over HTTPS can send lookups to an external provider rather than the local DNS service; Mozilla documents this interaction with local filtering policies. [10]
VPNs, explicit DNS settings and some privacy services can also change the path. Investigate those settings on the agreed test client instead of assuming the router controls every lookup.
12. Troubleshooting is part of the lesson
| Symptom | Useful next check |
|---|---|
| Explicit query to Pi-hole times out | Check its address, service, client reachability and DNS firewall rules. |
| Explicit queries work, but browsing creates no log entries | Check browser secure DNS, VPNs, client DNS settings and caching. |
| Only some devices are filtered | Check DHCP leases, manual settings and separately advertised IPv6 DNS. |
| A useful feature stops working | Reproduce it, inspect recent blocked queries, and test a narrow allow rule. |
| Websites appear to fail when the Pi-hole host stops | Restore the previous DNS configuration and confirm whether DNS availability caused the failure. |
More blocklists do not automatically produce a better setup. A false positive — a useful domain blocked by mistake — can break logins, embedded media or other features.
The response should be specific: identify the relevant domain, test the explanation and make the smallest justified exception.
13. Security includes the service you have just created
Domain filtering can reduce access to some known unwanted or harmful destinations when suitable lists are used. It does not replace software updates, careful account security or endpoint protection.
Keep the operating system and Pi-hole updated, protect administration access and retain a configuration backup. The Pi-hole command reference documents update commands; container installations require their own image-update workflow. [6]
Keep DNS and administration access restricted to the intended local network. Do not forward public internet traffic to DNS port 53 or expose the dashboard for this exercise.
There is also an availability lesson. Once other devices depend on your DNS service, switching it off can disrupt name resolution even while broadband remains connected.
Building infrastructure creates a responsibility to keep it available — or provide a clear way to recover.
14. Take the investigation further
Compare cached and forwarded queries
Repeat a permitted lookup and inspect its status in the log. DNS answers are cached for a time governed by their TTL, or time to live. Caches exist at several levels, including the client and resolver. [1]
Use several observations before claiming a speed improvement. A changing query time alone does not prove which cache was responsible.
Compare devices
Use a Windows computer, a Linux computer and an iPad as clients. Do they reach the same DNS service? What background requests differ? Use anonymised observations rather than judging users by their devices' traffic.
Add a local DNS name
Create a local record for a laboratory web server, using a name within home.arpa, such as labserver.home.arpa. Then test name resolution separately from loading its webpage. Use the server's real LAN address.
Explore recursion with Unbound
For a later project, Pi-hole's official Unbound guide explains how to add a local recursive resolver. That creates a useful comparison between forwarding to an upstream provider and resolving through the DNS hierarchy. It is an extension, not a requirement for the first lesson. [2]
15. The real success is being able to explain it
Adverts provide the initial motivation. The lasting educational value is understanding the service behind the effect.
A student who can explain why one query was blocked, another was forwarded and a third never reached Pi-hole has moved beyond following installation instructions.
They are connecting addressing, protocols, caching, security and evidence.
At Hemel Private Tuition, this is the kind of practical investigation I value: a useful system that gives students reasons to ask better questions. For GCSE and A-level learners, including OCR H446 students, it offers a way to connect networking theory with decisions they can observe and justify.
Build the server. Follow a query. Change one rule. Then explain exactly what happened.
