Introduction
Willow Commons already has a working community website. Before moving it, find out which address a client actually uses. A saved DNS record, an answer in a cache and a website response describe different parts of the journey.
You will use the normal site first, compare a real authority with an independent caching resolver, and change a separate practice name. The website name used by the community stays unchanged in this unit. Two HTTP backends and DNS services are prepared in isolated Linux network namespaces sharing one VM kernel.
You should be comfortable entering terminal commands, recognizing paths and switching tabs. This lab explains the DNS commands and small configuration edits it uses. No public domain account or prior BIND administration is required. Allow about 40 minutes including reading and ordinary mistakes; this is an author estimate.
Use the Working Named Site
In this step, you will read the community's existing site and save its actual programme. Begin in Community Preview, then select Warm Client. Expect the Willow Commons page, three gatherings, and an old location label. Select Download the programme and open the downloaded text. The location label is the backend's identity, not a success animation.
Read the location label near the top, then use Download the programme below the three gatherings. The pictured page is a real response from the original backend.
The preview makes a real DNS lookup and HTTP request from the selected course client. Its outer platform URL is a browser gateway; it does not mean your computer uses the course DNS. Browser refresh sends a new request without clearing the course resolver cache. Leave Fresh Client unused for now.
Switch to the Warm Client terminal. It starts in /home/labex/project/site-move/warm with its own resolver settings. pwd prints the current directory:
pwd
DNS, the Domain Name System, maps a name to an address. An A record maps a name to an IPv4 address. HTTP then uses that address and a port to request content. Here the name is site.community.test; 8081 is the HTTP port, not a DNS record value. .test is a reserved testing suffix, not a public community domain.
curl makes an HTTP request. --noproxy '*' excludes all proxy use for this request; the quotes keep the star literal. -f treats HTTP errors as failures, -s hides the progress meter, and -S still prints errors. --max-time 5 limits the request to five seconds:
curl --noproxy '*' -fsS --max-time 5 http://site.community.test:8081/
Expect HTML containing Willow Commons and old location. The terminal shows source text; the browser renders the same page. Now download the real text resource. -o programme.txt saves the response in this client's current directory:
curl --noproxy '*' -fsS --max-time 5 -o programme.txt http://site.community.test:8081/programme.txt
cat prints the saved file:
cat programme.txt
Expect all three gatherings, the step-free entrance information and Service location: old. A file's existence or HTTP status alone does not establish correct content.
If curl reports Could not resolve host, check the spelling of the name. Failed to connect means no HTTP connection was made; it differs from an HTTP 404, which means a server answered but the path was absent. Repeat the shown URL after correcting a typo. Do not change the platform DNS, /etc/hosts, or a course resolver file. If you open another terminal, use the actual Warm Client tab and cd /home/labex/project/site-move/warm before saving a file. Files and terminal working directories belong to that client; a browser download belongs to your browser.
Compare Authority and Cache
In this step, you will distinguish the source record from a temporary cached copy. Stay in Warm Client. The authoritative server owns community.test; its address is 10.94.0.2. The client's caching resolver listens on 127.0.0.1, the loopback address inside this client. The other client has a separate resolver and separate cache.
dig asks DNS a question. @10.94.0.2 selects the server explicitly. A requests an IPv4 address. +noall hides dig's usual sections and +answer shows the answer rows:
dig @10.94.0.2 site.community.test A +noall +answer
Expect a row shaped like this:
site.community.test. 120 IN A 10.94.0.10
The columns are name, TTL, class, type and address. TTL, time to live, is the number of seconds an answer may remain cached. IN is the Internet class. The trailing dot denotes a complete DNS name. Spaces and tabs may differ.
Ask the course client's resolver instead:
dig @127.0.0.1 site.community.test A +noall +answer
Its address should still be 10.94.0.10, but TTL may be lower because the earlier request populated the cache. sleep 5 waits five real seconds without changing DNS:
sleep 5
dig @127.0.0.1 site.community.test A +noall +answer
Usually the remaining TTL decreases. If the previous copy expired, the resolver asks the authority again and TTL jumps back toward 120. Reading this lab can consume the whole interval. That is normal expiration, not a broken cache. No setup-time observation window is required.
Use a separate name for the upcoming edit. It points to the same old backend but is not the community's formal site name:
dig @127.0.0.1 practice.community.test A +noall +answer
Keep the name, address and remaining TTL in view. A successful lookup does not prove a website is reachable; step 1 made the separate HTTP request. Run this step's check, then read the next step before beginning its short change-and-compare sequence.
Change a Practice Record and Let Its Cache Expire
In this step, you will validate a small record edit, load it into the authority, and see why a lower TTL cannot shorten an already cached copy. You may change only practice and the necessary SOA serial in community.zone. Keep the formal site, keep, nameserver and both websites unchanged.
First read the editing instructions below. Then, in Warm Client, query the practice name again immediately before switching tabs:
dig @127.0.0.1 practice.community.test A +noall +answer
If only a few seconds remain, wait for that interval to expire and query again while the authority still holds the original record. This renews the observation window through a real DNS request. It does not clear a cache. A fresh copy lasts up to 120 seconds; work at your own pace and use the recovery paragraph if you miss it.
Switch to DNS Desk, whose directory is /home/labex/project/site-move. Read the file:
cat community.zone
A zone is the authority's dataset for part of DNS. $TTL 120 supplies a default lifetime. practice 120 IN A 10.94.0.10 sets an explicit lifetime and address for the practice name. The SOA, Start of Authority, includes a serial version number. Increase that number when publishing a change; preserve the other SOA values. DNS lifetimes and SOA timers have different purposes. Here @ stands for the zone origin, community.test.. NS names its authoritative server, and the ns A record gives that server an address. Parentheses group the SOA fields into one record. Its existing refresh, retry, expiry and negative-cache values belong to zone administration; keep them unchanged. They are not the practice A record's TTL.
The following here-document writes the complete small zone. > replaces the file. The quoted 'ZONE' keeps $TTL literal rather than expanding it as a shell variable. The last ZONE must begin at the start of its line. Copy the whole block:
cat > community.zone <<'ZONE'
$TTL 120
@ IN SOA ns.community.test. admin.community.test. (2 60 30 3600 30)
@ IN NS ns.community.test.
ns IN A 10.94.0.2
site 120 IN A 10.94.0.10
practice 45 IN A 10.94.0.20
keep 120 IN A 10.94.0.10
ZONE
Only the practice address/lifetime and serial changed. named-checkzone validates the complete saved zone without loading it. Its first argument is the zone name; its second is the file:
named-checkzone community.test community.zone
Expect loaded serial 2 followed by OK. This is a file validation result, not evidence that the running authority loaded it. If syntax fails, read the file and restore the complete block, then check again. A malformed saved file leaves the previous running zone available until a valid reload.
sudo runs this one administrative command. The supplied narrow helper invokes BIND's real rndc reload community.test inside the course authority; it does not restart either cache:
sudo /opt/labex/site-move/reload-zone
Expect zone reload queued. Query the live authority to confirm what actually loaded. The desk itself has no course default resolver, so this diagnostic explicitly enters the authority's network namespace. ip netns exec site-authority runs only the following command in that course network:
sudo ip netns exec site-authority dig @10.94.0.2 practice.community.test A +noall +answer
Expect 45 IN A 10.94.0.20. Switch to Warm Client and query its cache:
dig @127.0.0.1 practice.community.test A +noall +answer
During the remaining original lifetime, it can still return 10.94.0.10, even with more than 45 seconds left. The new 45-second TTL applies to new copies; it does not rewrite the old cached answer. Both backends remain working while clients can legitimately disagree.
Wait for the remaining TTL you just observed, plus one second, then query again. For example, if it showed 37 seconds, sleep 38 is sufficient for that copy. The following conservative wait covers this exercise's full original 120-second maximum even if you did not note the exact value:
sleep 121
dig @127.0.0.1 practice.community.test A +noall +answer
Now expect 10.94.0.20 and a remaining TTL no higher than 45. Read the actual row; a timer finishing by itself proves nothing. Make a named HTTP request through the same client:
curl --noproxy '*' -fsS --max-time 5 http://practice.community.test:8081/programme.txt
Expect Service location: new with the complete programme. The formal site.community.test still serves the old location.
If you missed the difference: the completed result remains valid. To repeat the observation, use only practice: in DNS Desk, restore its line to practice 120 IN A 10.94.0.10 and increase the current SOA serial using nano community.zone. nano is a text editor: move with arrow keys, edit just that line and serial, press Ctrl+O, Enter to save, then Ctrl+X to exit. Validate and reload using the same commands above. Wait for the practice client's currently observed TTL to expire naturally, query it to obtain the old address at up to 120 seconds, then change only practice back to the new address/45 seconds with another higher serial, validate/reload and compare immediately. Finish with natural expiry and a real new-site request. Never reset the formal site, restart resolvers, or replace website content to repeat a window.
If you mistyped a path, use pwd and cd /home/labex/project/site-move in DNS Desk before re-reading the file. Syntax errors and wrong content are different problems: validate the file, inspect the live authority, inspect the cache, then request HTTP. Run the final check once the practice client resolves the new address.
Summary
You used a working named website, saved its complete programme, and separated authoritative data, cached DNS answers and HTTP content. You validated a scoped practice change and saw that lowering TTL does not shorten an existing cached copy. The formal community site and old backend remain available. The next unit applies this knowledge to a staged address migration.
