DNS records and name-resolution troubleshooting

In GNS3, right-click DNS1 and choose Console before typing. At the Linux shell, confirm ens3 and use only this disposable node. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.

ip -br address
sudo ip address add 192.0.2.53/24 dev ens3
sudo ip link set ens3 up
named -v
mkdir /tmp/qcs39

What you should see

DNS1 has the planned address and a writable new fixture directory.

Why this step matters

Avoiding system configuration files and standard port 53 keeps the exercise bounded.

In GNS3, right-click Client1 and choose Console before typing. At the Linux shell, inspect its interface and configure only the lab link. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.

ip -br address
sudo ip address add 192.0.2.10/24 dev ens3
sudo ip link set ens3 up
dig -v
ping -c 3 192.0.2.53

What you should see

DNS1 should reply; no Internet route is needed.

Why this step matters

A failed basic local path should be repaired before interpreting a DNS timeout.

In GNS3, right-click DNS1 and choose Console before typing. At DNS1's Bash shell, enter the complete multiline command below, including the closing QCS_FILE_END on its own unindented line. This here-document sends only the lines between its opening and closing markers into the named file. Keep the quotes around the opening marker so $TTL stays literal. A continuation prompt while entering these lines is normal; do not type the prompt. Enter no explanatory prose into the file. Use only the newly created private lab directory. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.

cat > /tmp/qcs39/named.conf <<'QCS_FILE_END'
options { directory "/tmp/qcs39"; recursion no; listen-on port 1053 { 192.0.2.53; }; listen-on-v6 { none; }; pid-file "/tmp/qcs39/named.pid"; session-keyfile "/tmp/qcs39/session.key"; dnssec-validation no; }; controls {}; zone "lab.test" { type primary; file "forward"; }; zone "2.0.192.in-addr.arpa" { type primary; file "reverse"; };
QCS_FILE_END

What you should see

The shell prompt returns after QCS_FILE_END; the file names match the next two fixtures. No system named.conf is changed.

Why this step matters

Explicit private zones and an unprivileged port avoid depending on a public resolver or competing service.

In GNS3, right-click DNS1 and choose Console before typing. At DNS1's Bash shell, enter the complete multiline command below, including the closing QCS_FILE_END on its own unindented line. This here-document sends only the lines between its opening and closing markers into the named file. Keep the quotes around the opening marker so $TTL stays literal. A continuation prompt while entering these lines is normal; do not type the prompt. Enter no explanatory prose into the file. Use only the newly created private lab directory. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.

cat > /tmp/qcs39/forward <<'QCS_FILE_END'
$TTL 60
@ IN SOA ns.lab.test. admin.lab.test. (1 60 60 600 60)
@ IN NS ns.lab.test.
ns IN A 192.0.2.53
web IN A 192.0.2.80
web IN AAAA 2001:db8:39::80
www IN CNAME web.lab.test.
@ IN MX 10 mail.lab.test.
mail IN A 192.0.2.25
QCS_FILE_END

What you should see

The shell prompt returns; the file ends with mail IN A 192.0.2.25 on its own line, with no instruction prose appended.

Why this step matters

The code block preserves each record's line boundary and trailing dots; separating prose prevents invalid extra fields.

In GNS3, right-click DNS1 and choose Console before typing. At DNS1's Bash shell, enter the complete multiline command below, including the closing QCS_FILE_END on its own unindented line. This here-document sends only the lines between its opening and closing markers into the named file. Keep the quotes around the opening marker so $TTL stays literal. A continuation prompt while entering these lines is normal; do not type the prompt. Enter no explanatory prose into the file. Use only the newly created private lab directory. After the closing marker returns the ordinary prompt, run each validation command separately. Stop on any validation error before copying the baseline. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.

cat > /tmp/qcs39/reverse <<'QCS_FILE_END'
$TTL 60
@ IN SOA ns.lab.test. admin.lab.test. (1 60 60 600 60)
@ IN NS ns.lab.test.
80 IN PTR web.lab.test.
QCS_FILE_END
named-checkconf /tmp/qcs39/named.conf
named-checkzone lab.test /tmp/qcs39/forward
named-checkzone 2.0.192.in-addr.arpa /tmp/qcs39/reverse
cp /tmp/qcs39/forward /tmp/qcs39/forward.baseline

What you should see

Both zones should validate; stop and correct actual reported errors.

Why this step matters

A correct text file is necessary but must still be loaded by the intended running process.

In GNS3, right-click DNS1 and choose Console before typing. At the ordinary nonroot shell, start the foreground server. Leave this Console occupied while using Client1. Stop on permission or listener errors. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.

named -g -c /tmp/qcs39/named.conf

What you should see

Diagnostics should show both zones loaded and the private listener active. Do not invent a successful startup if errors appear.

Why this step matters

Keeping the process visible makes its stop action unambiguous: Ctrl+C in this same Console.

In GNS3, right-click Client1 and choose Console before typing. At the Linux shell, retain complete answers including status and the responding server. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.

dig @192.0.2.53 -p 1053 web.lab.test. A
dig @192.0.2.53 -p 1053 web.lab.test. AAAA
dig @192.0.2.53 -p 1053 www.lab.test. CNAME
dig @192.0.2.53 -p 1053 lab.test. MX
dig @192.0.2.53 -p 1053 mail.lab.test. A
dig @192.0.2.53 -p 1053 lab.test. NS
dig @192.0.2.53 -p 1053 -x 192.0.2.80

What you should see

Answers should match the fixture; the responding server is .53#1053. Neither web nor mail services exist.

Why this step matters

All named endpoints are data relationships, not hidden working servers omitted from the topology.

In GNS3, right-click Client1 and choose Console before typing. At the Linux shell, compare each test with the same functioning authoritative server. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.

dig @192.0.2.53 -p 1053 absent.lab.test. A
dig @192.0.2.53 -p 1053 web.lab.test. MX
dig @192.0.2.53 -p 1054 web.lab.test. A +time=1 +tries=1

What you should see

The first two are DNS responses; the unused-port test does not supply a valid DNS answer.

Why this step matters

A status code and a network failure are different evidence and should not be collapsed into one error label.

In GNS3, right-click DNS1 and choose Console before typing. Press Ctrl+C in the foreground DNS Console first. At the restored shell, change only web's A from 192.0.2.80 to 192.0.2.81 and SOA serial 1 to 2; save and exit. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.

nano /tmp/qcs39/forward
named-checkzone lab.test /tmp/qcs39/forward
named -g -c /tmp/qcs39/named.conf

What you should see

The server should load the modified zone even though its A value is intentionally wrong.

Why this step matters

Syntax validation cannot know the organization's approved destination address.

In GNS3, right-click Client1 and choose Console before typing. At the Linux shell, use the same question and server as the recorded baseline. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.

dig @192.0.2.53 -p 1053 web.lab.test. A
dig @192.0.2.53 -p 1053 www.lab.test. A
dig @192.0.2.53 -p 1053 -x 192.0.2.80

What you should see

NOERROR can accompany the wrong A data; the original PTR remains unchanged.

Why this step matters

A successful protocol response can still carry an operationally incorrect record.

In GNS3, right-click DNS1 and choose Console before typing. Press Ctrl+C in the running server Console. At the shell restore the baseline file, set its SOA serial to 3, then validate and restart. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.

cp /tmp/qcs39/forward.baseline /tmp/qcs39/forward
nano /tmp/qcs39/forward
named-checkzone lab.test /tmp/qcs39/forward
named -g -c /tmp/qcs39/named.conf

What you should see

The authoritative A should again be .80; the alias, AAAA, MX, NS and PTR retain their original relationships.

Why this step matters

Restoration is completed by a query from the client, not by accepting a file-copy command.

In GNS3, right-click DNS1 and choose Console before typing. First repeat the baseline queries in Client1's Console to verify the A repair, then return to DNS1. Ticket observations are synthetic. Optional replay follows serial 3 restoration: A6 uses serials 4 fault/5 corrected, MX1 6/7, NS1 8/9. Before each edit press Ctrl+C in this foreground server Console. Change only that ticket's specified record and SOA serial. Run these commands, perform the next client step, then repeat this step with the exact corrected line and next step again. Finish the pair before moving on; no parent delegation or application server is created. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.

nano /tmp/qcs39/forward
named-checkzone lab.test /tmp/qcs39/forward
named -g -c /tmp/qcs39/named.conf

What you should see

Each corrected trial must restore the approved AAAA, MX or NS data before the next trial; author observations remain unexecuted.

Why this step matters

Independent fault/repair pairs reveal which record matters and avoid combining three faults into one ambiguous result.

In GNS3, right-click Client1 and choose Console before typing. At the shell, run these explicit questions before and after each optional ticket correction. For MX1 also inspect web's A/AAAA when the bad target is web; for NS1 inspect mail's A when the bad target is mail. Preserve status, AA flag, server and serial. On paper predict the differences instead of claiming execution. Type each line without the prompt and press Enter. Stop on a syntax error; retain the console for recovery.

dig @192.0.2.53 -p 1053 web.lab.test. AAAA
dig @192.0.2.53 -p 1053 web.lab.test. A
dig @192.0.2.53 -p 1053 lab.test. MX
dig @192.0.2.53 -p 1053 mail.lab.test. A
dig @192.0.2.53 -p 1053 mail.lab.test. AAAA
dig @192.0.2.53 -p 1053 lab.test. NS
dig @192.0.2.53 -p 1053 ns.lab.test. A
dig @192.0.2.53 -p 1053 lab.test. SOA +norecurse
dig @192.0.2.53 -p 1053 lab.test. SOA +norecurse +tcp

What you should see

Corrected values match the ticket plan; mail AAAA remains absent. A direct authoritative response is not an HTTP, SMTP or recursive-delegation success.

Why this step matters

The repeated question and dependent name lookups distinguish bad family data, a wrong MX target and misleading NS information.

In Client1's Console repeat every command from Inspect every record relationship and compare values. Then press Ctrl+C in DNS1's Console to stop only this foreground service. Stop both GNS3 nodes and retain the notes.

What you should see

All six record questions should match the planned data; record discrepancies and do not report application success.

Why this step matters

The final comparison checks collateral changes and keeps predicted behavior distinct from measured results.