Lab 05

VirtualBox · Debian Stable · BIND9

Lokalny DNS z BIND9

Zbuduj izolowany serwer DNS dla domeny laboratoryjnej lab.test, dodaj rekordy forward i reverse, a potem sprawdź odpowiedzi narzędziami dig, nslookup i getent.

1

Cel ćwiczenia

Lab 05 jest niezależnym laboratorium. Nie wymaga Lab 04, nie korzysta z NAT, routera, DHCP ani Internetu podczas właściwej pracy. Internet może być potrzebny tylko wcześniej, do pobrania pakietów na maszynach Debian Stable.

Teoria, którą warto mieć pod ręką: DNS, diagnostyka, adresacja IPv4 oraz ARP/ICMP.

  • uruchomić lokalny autorytatywny DNS na Debianie z BIND9.
  • zbudować izolowane laboratorium bez NAT, Internetu, routera i DHCP.
  • utworzyć własną strefę lab.test przeznaczoną do testów.
  • dodać rekordy A, CNAME, NS, SOA oraz PTR.
  • sprawdzać konfigurację narzędziami named-checkconf i named-checkzone.
  • odróżniać test IP od testu DNS.
  • diagnozować sytuację: IP działa, nazwa nie.
0

Rejestracja stanu przed laboratorium

Przed instalacją BIND i zmianą sieci wykonaj ten etap na każdej VM. Na DNS SERVER zapisz dodatkowo stan usług bind9 i named oraz obecność plików, których nazwy wykorzystuje laboratorium.

STATE="$HOME/lab05-state"
umask 077
mkdir -p "$STATE"
ip -br link > "$STATE/link.before"
ip -br address > "$STATE/address.before"
ip route show table all > "$STATE/routes.before"
sudo cp -a --no-dereference /etc/resolv.conf "$STATE/resolv.conf.before"

if sudo test -e /etc/network/interfaces; then
  printf 'present
' > "$STATE/interfaces.marker"
  sudo cp -a /etc/network/interfaces "$STATE/interfaces.before"
else
  printf 'absent
' > "$STATE/interfaces.marker"
fi

# Tylko na DNS SERVER
for UNIT in bind9 named; do
  systemctl is-active "$UNIT" > "$STATE/$UNIT.active" || true
  systemctl is-enabled "$UNIT" > "$STATE/$UNIT.enabled" || true
done

for FILE in db.lab.test db.192.168.100; do
  if sudo test -e "/etc/bind/$FILE"; then
    printf 'present
' > "$STATE/$FILE.marker"
    sudo cp -a "/etc/bind/$FILE" "$STATE/$FILE.before"
  else
    printf 'absent
' > "$STATE/$FILE.marker"
  fi
done

Na hoście zapisz tryb, nazwę sieci i stan kabla wszystkich kart VirtualBox. Oczekiwany rezultat to trzy katalogi stanu oraz rozpoznany mechanizm resolvera. Snapshot może pomóc w awarii, ale nie jest backupem i nie zastępuje kopii plików.

2

Topologia i adresacja

Wszystkie maszyny podłącz do tej samej sieci VirtualBox Internal Network o nazwie lab-dns. Nie dodawaj NAT, routera, DHCP ani default gateway. Celem jest lokalny DNS w jednej podsieci.

Sieć:       192.168.100.0/24
Network:    192.168.100.0
Broadcast:  192.168.100.255
Pierwszy:   192.168.100.1
Ostatni:    192.168.100.254

CLIENT:     192.168.100.10/24
DNS SERVER: 192.168.100.53/24
SERVER:     192.168.100.20/24

Adres .53 dla serwera DNS jest tylko mnemonicznym nawiązaniem do portu DNS 53. Nie jest technicznym wymogiem.

Trzy maszyny Debian Stable pracują w jednym izolowanym segmencie Internal Network lab-dns.
3

Przygotowanie VM i pakietów

Na maszynie DNS SERVER zainstaluj BIND9 i narzędzia diagnostyczne. Na CLIENT warto mieć przynajmniej dig i opcjonalnie nslookup. Nazwy pakietów narzędziowych mogą zależeć od wydania Debiana, dlatego najważniejsze są funkcje narzędzi.

sudo apt update
sudo apt install bind9 bind9-utils dnsutils

Na DNS SERVER, po instalacji pakietu i przed edycją, zachowaj rzeczywistą konfigurację bazową. Dzięki temu rollback nie musi zgadywać zawartości pliku dostarczonego przez pakiet.

STATE="$HOME/lab05-state"
sudo cp -a /etc/bind/named.conf.local "$STATE/named.conf.local.before-edit"

Nie zakładaj nazwy interfejsu eth0 ani enp0s3. Najpierw sprawdź rzeczywistą nazwę karty.

ip link show
ip address show
Pakiety pobierz przed odłączeniem środowiska od Internetu.
4

Statyczna konfiguracja IP i test IP

Poniższe komendy używają przykładowego interfejsu enp0s3. Podstaw nazwę ustaloną w Twojej VM.

# UWAGA: flush usuwa całą bieżącą adresację IPv4 ze wskazanego interfejsu.
# CLIENT
sudo ip addr flush dev enp0s3
sudo ip addr add 192.168.100.10/24 dev enp0s3
sudo ip link set enp0s3 up
ip address show
ip route show

# DNS SERVER
sudo ip addr flush dev enp0s3
sudo ip addr add 192.168.100.53/24 dev enp0s3
sudo ip link set enp0s3 up
ip address show

# SERVER
sudo ip addr flush dev enp0s3
sudo ip addr add 192.168.100.20/24 dev enp0s3
sudo ip link set enp0s3 up
ip address show

Na kliencie powinna być widoczna trasa connected do 192.168.100.0/24. Default gateway nie jest potrzebny.

ping 192.168.100.53
ping 192.168.100.20
Najpierw uruchom komunikację po IP, dopiero potem diagnozuj DNS.
5

BIND9 i port 53

Nazwa usługi może występować jako bind9 lub named, zależnie od systemu i pakietów. Sprawdź status realnej jednostki systemd oraz nasłuch na porcie 53.

systemctl list-units --type=service | grep -E 'bind9|named'
sudo systemctl status bind9
sudo ss -lntup | grep ':53'

ping 192.168.100.53 testuje IP i ICMP, ale nie sprawdza usługi DNS. Testem DNS będzie dopiero zapytanie dig albo nslookup.

DNS korzysta klasycznie z UDP 53 i TCP 53.
6

Deklaracja forward zone

W pliku /etc/bind/named.conf.local zadeklaruj autorytatywną strefę lab.test. Sufiks .test jest przeznaczony do scenariuszy testowych, więc dobrze pasuje do izolowanego laboratorium.

zone "lab.test" {
    type master;
    file "/etc/bind/db.lab.test";
};

Celem laboratorium nie jest rekursja do Internetu ani publiczne resolvery. Ten DNS ma odpowiadać autorytatywnie dla lokalnej strefy.

Strefa lab.test jest lokalną domeną testową, a nie publiczną domeną w Internecie.
7

Plik strefy lab.test

Utwórz /etc/bind/db.lab.test. Rekord SOA opisuje strefę i jej parametry, NS wskazuje serwer nazw, A mapuje nazwę na IPv4, a CNAME tworzy alias. Serial zwiększaj po zmianach; zapis YYYYMMDDNN jest czytelnym przykładem, nie jedyną dozwoloną metodą.

$TTL 3600
@ IN SOA ns1.lab.test. admin.lab.test. (
    2026081701
    3600
    900
    604800
    86400
)
@      IN NS    ns1.lab.test.
ns1    IN A     192.168.100.53
client IN A     192.168.100.10
server IN A     192.168.100.20
www    IN CNAME server.lab.test.
sudo named-checkconf
sudo named-checkzone lab.test /etc/bind/db.lab.test
sudo rndc reload

Jeżeli rndc reload nie działa w Twoim środowisku, użyj poprawnej jednostki systemd dla BIND9, a potem ponownie sprawdź status i port 53.

Kropka końcowa w server.lab.test. oznacza pełną nazwę FQDN.
8

Zapytania forward: dig i nslookup

Na kliencie sprawdź rekordy forward. Składnia @192.168.100.53 mówi narzędziu dig, aby zapytało dokładnie ten serwer DNS.

dig @192.168.100.53 ns1.lab.test A
dig @192.168.100.53 client.lab.test A
dig @192.168.100.53 server.lab.test A
dig @192.168.100.53 www.lab.test
dig @192.168.100.53 lab.test NS
dig @192.168.100.53 lab.test SOA
nslookup server.lab.test 192.168.100.53

Jeżeli IP działa, ale te zapytania nie działają, problem jest w usłudze DNS, konfiguracji strefy albo dostępie do portu 53.

@192.168.100.53 omija systemowy resolver i pyta wskazany serwer DNS bezpośrednio.
9

Reverse zone i PTR

Reverse DNS dla sieci 192.168.100.0/24 używa strefy 100.168.192.in-addr.arpa. Dodaj ją w /etc/bind/named.conf.local.

zone "100.168.192.in-addr.arpa" {
    type master;
    file "/etc/bind/db.192.168.100";
};

Następnie utwórz /etc/bind/db.192.168.100.

$TTL 3600
@ IN SOA ns1.lab.test. admin.lab.test. (
    2026081701
    3600
    900
    604800
    86400
)
@  IN NS  ns1.lab.test.
53 IN PTR ns1.lab.test.
10 IN PTR client.lab.test.
20 IN PTR server.lab.test.
sudo named-checkconf
sudo named-checkzone 100.168.192.in-addr.arpa /etc/bind/db.192.168.100
sudo rndc reload

dig @192.168.100.53 -x 192.168.100.20
dig @192.168.100.53 -x 192.168.100.53
A i PTR to różne rekordy; forward lookup i reverse lookup diagnozuj osobno.
10

Systemowy resolver klienta

Nie ma jednej uniwersalnej metody konfiguracji resolvera dla każdego obrazu Debiana. Najpierw sprawdź, kto zarządza plikiem /etc/resolv.conf. Nie nadpisuj go ślepo, jeżeli jest zarządzany przez systemd-resolved lub inne narzędzie.

cat /etc/resolv.conf
systemctl status systemd-resolved
resolvectl status

Gdy systemowy resolver klienta wskazuje na 192.168.100.53, sprawdź rozwiązywanie nazw przez mechanizmy systemowe.

getent hosts server.lab.test
ping server.lab.test

getent korzysta z systemowego resolvera, a dig @192.168.100.53 pyta wskazany serwer bezpośrednio.

dig @server kończy rdzeń laboratorium; getent sprawdza systemową ścieżkę rozwiązywania nazw.
11

UDP/TCP 53 i scenariusz: IP działa, nazwa nie

DNS klasycznie używa UDP 53 oraz TCP 53. W zwykłych zapytaniach często zobaczysz UDP, ale TCP jest również częścią DNS i warto go umieć przetestować.

dig @192.168.100.53 server.lab.test A
dig +tcp @192.168.100.53 server.lab.test A
sudo ss -lntup | grep ':53'

Jeżeli z CLIENT działa ping 192.168.100.20, ale server.lab.test nie działa, nie zmieniaj adresacji IP. Sprawdź kolejno: dostęp do DNS SERVER, działanie BIND9, port 53, wynik dig @192.168.100.53 server.lab.test, resolver klienta, istnienie strefy i istnienie rekordu.

DNS to nie ping: działający ICMP nie oznacza działającej usługi nazw.
12

Kompletna diagnostyka DNS

  1. Czy wszystkie VM są w Internal Network lab-dns?
  2. Czy CLIENT osiąga 192.168.100.53 po IP?
  3. Czy CLIENT osiąga 192.168.100.20 po IP?
  4. Czy BIND9 działa na DNS SERVER?
  5. Czy port 53 nasłuchuje?
  6. Czy named-checkconf przechodzi bez błędów?
  7. Czy named-checkzone przechodzi dla obu stref?
  8. Czy dig @192.168.100.53 server.lab.test A działa?
  9. Czy resolver klienta wskazuje poprawny DNS?
  10. Czy firewall pozwala na zapytania z 192.168.100.0/24?

Firewall sprawdzaj poleceniem sudo nft list ruleset. Nie wyłączaj go automatycznie i nie używaj nft flush ruleset. Popraw politykę tak, aby serwer DNS przyjmował potrzebne zapytania z sieci laboratoryjnej.

Najpierw warstwa IP, potem port 53, dopiero potem rekordy i resolver klienta.
13

Podsumowanie testów DNS

Na końcu oddziel trzy fakty: DNS nie przydziela adresów jak DHCP, DNS nie wybiera trasy jak routing i DNS nie jest tym samym co ping. Lokalny lab.test działa bez Internetu, bo Twój BIND9 jest autorytatywny dla tej strefy.

# Forward
dig @192.168.100.53 server.lab.test A
dig @192.168.100.53 www.lab.test

# Reverse
dig @192.168.100.53 -x 192.168.100.20

# System resolver
getent hosts server.lab.test
DNS nie zastępuje DHCP, routingu ani ICMP; rozwiązuje nazwy na podstawie rekordów.
14

Zadania dla studenta

  1. Wyjaśnij, dlaczego .test jest lepszym wyborem laboratoryjnym niż prawdziwa domena publiczna.
  2. Zmień adres serwera aplikacyjnego w rekordzie A i popraw serial strefy.
  3. Dodaj alias app.lab.test wskazujący na server.lab.test.
  4. Usuń kropkę końcową z CNAME i sprawdź wynik named-checkzone.
  5. Porównaj wynik dig @192.168.100.53 server.lab.test A z getent hosts server.lab.test.
  6. Sprawdź, co się stanie, gdy klient ma wpisany błędny DNS 192.168.100.99.
  7. Dodaj rekord PTR dla klienta i wykonaj zapytanie reverse.
  8. Wykonaj ten sam test przez UDP i TCP.
  9. Udowodnij, że ping 192.168.100.53 nie testuje usługi DNS.
  10. Opisz różnicę między forward lookup i reverse lookup.
15

Scenariusze diagnostyczne

DNS Server nie odpowiada po IP: sprawdź adres, prefix, Internal Network lab-dns i ping.
IP działa, ale port 53 nie odpowiada: sprawdź BIND9, nasłuch ss i ewentualne reguły firewalla.
dig @192.168.100.53 działa, ale getent nie: sprawdź systemowy resolver klienta.
Forward lookup działa, reverse lookup nie: sprawdź strefę 100.168.192.in-addr.arpa i rekordy PTR.
Rekord A działa, ale CNAME nie: sprawdź nazwę docelową i kropkę końcową FQDN.
UDP nie działa, a TCP działa lub odwrotnie: sprawdź firewall i nasłuch usługi dla portu 53.
R

Cofnięcie BIND, stref i resolvera

Wykonaj rollback po zapisaniu wyników. Najpierw, jeszcze na działającej konfiguracji laboratoryjnej, zachowaj wynik kontroli i potwierdź, które pliki są własnością Lab 05.

sudo named-checkconf
sudo named-checkzone lab.test /etc/bind/db.lab.test
sudo named-checkzone 100.168.192.in-addr.arpa /etc/bind/db.192.168.100
systemctl list-unit-files | grep -E '^(bind9|named).service'

Na DNS SERVER wybierz wykrytą jednostkębind9 albo named, zatrzymaj ją na czas odtwarzania i przywróć named.conf.local. Pliki stref usuń tylko wtedy, gdy zapisany marker potwierdza, że nie istniały przed ćwiczeniem; w przeciwnym razie odtwórz kopię.

STATE="$HOME/lab05-state"
UNIT=bind9
sudo systemctl stop "$UNIT"
sudo cp -a "$STATE/named.conf.local.before-edit" /etc/bind/named.conf.local

for FILE in db.lab.test db.192.168.100; do
  if grep -qx present "$STATE/$FILE.marker"; then
    sudo cp -a "$STATE/$FILE.before" "/etc/bind/$FILE"
  else
    # UWAGA: usuń plik strefy tylko wtedy, gdy marker potwierdza jego wcześniejszy brak.
    sudo rm -- "/etc/bind/$FILE"
  fi
done

sudo named-checkconf
sudo test ! -e /etc/bind/db.lab.test ||
  sudo named-checkzone lab.test /etc/bind/db.lab.test
sudo test ! -e /etc/bind/db.192.168.100 ||
  sudo named-checkzone 100.168.192.in-addr.arpa /etc/bind/db.192.168.100

Odtwórz stan jednostki zapisany przed instalacją. Jeżeli używaną jednostką jest named, podstaw tę nazwę. Dla stanunot-found zatrzymaj i wyłącz nowo zainstalowaną usługę, pozostawiając pakiet do świadomej decyzji.

STATE="$HOME/lab05-state"
UNIT=bind9
ENABLED=$(cat "$STATE/$UNIT.enabled")
ACTIVE=$(cat "$STATE/$UNIT.active")

case "$ENABLED" in
  enabled|enabled-runtime) sudo systemctl unmask "$UNIT"; sudo systemctl enable "$UNIT" ;;
  disabled) sudo systemctl unmask "$UNIT"; sudo systemctl disable "$UNIT" ;;
  masked) sudo systemctl disable "$UNIT"; sudo systemctl mask "$UNIT" ;;
  not-found) sudo systemctl disable "$UNIT" ;;
  static|indirect|generated|transient|alias) : ;;
  *) echo "Nietypowy stan enabled: $ENABLED — odtwórz go świadomie" ;;
esac

case "$ACTIVE" in
  active|reloading) sudo systemctl start "$UNIT" ;;
  inactive|failed|unknown) sudo systemctl stop "$UNIT" ;;
  *) echo "Nietypowy stan active: $ACTIVE — odtwórz go świadomie" ;;
esac

systemctl is-enabled "$UNIT" || true
systemctl is-active "$UNIT" || true
journalctl -u "$UNIT" -n 30 --no-pager

Na każdej VM odtwórz jej własne pliki sieci i resolver. Użyj lokalnej konsoli VirtualBox, bo restart sieci może zerwać SSH. Opcja --remove-destination odtwarza również zapisany typ pliku lub dowiązania resolv.conf.

STATE="$HOME/lab05-state"
if grep -qx present "$STATE/interfaces.marker"; then
  sudo cp -a "$STATE/interfaces.before" /etc/network/interfaces
else
  # UWAGA: usuń plik tylko wtedy, gdy marker potwierdza jego wcześniejszy brak.
  sudo rm -- /etc/network/interfaces
fi
sudo cp -a --remove-destination "$STATE/resolv.conf.before" /etc/resolv.conf
sudo systemctl restart networking

ip -br address
ip route show table all
cat /etc/resolv.conf
resolvectl status 2>/dev/null || true

Przywróć zapisane ustawienia kart VirtualBox i porównaj wyniki z plikami *.before. Pakiety BIND pozostają zainstalowane. Ich odinstalowanie jest osobnym, opcjonalnym zadaniem i wymaga sprawdzenia zależności; ta procedura nie usuwa innych stref, cudzych plików ani cache systemowego resolvera.

Kontynuuję Lab 06: wykonaj pełny rollback, bo Lab 06 używa innej topologii i adresacji. Kończę ćwiczenia: usuń katalogi stanu dopiero po zgodnym porównaniu adresów, tras, resolvera i usługi.

Nie odtwarzaj sztucznie początkowego stanufailed. Zatrzymaj usługę i opisz wcześniejszą awarię w raporcie; rollback nie powinien celowo ponownie psuć jednostki.

Pytania kontrolne

  1. Jaki port UDP i TCP wykorzystuje klasyczny DNS?
  2. Do czego służy rekord A?
  3. Do czego służy rekord CNAME?
  4. Czym różni się rekord PTR od rekordu A?
  5. Co oznacza finalna kropka w nazwie server.lab.test.?
  6. Dlaczego serial strefy należy zwiększać po zmianach?
  7. Co sprawdza named-checkconf?
  8. Co sprawdza named-checkzone?
  9. Dlaczego lokalny DNS lab.test nie wymaga Internetu?
  10. Czym różni się dig @server od zapytania przez systemowy resolver?

Checklist końcowy

  • wszystkie trzy VM są w Internal Network lab-dns.
  • CLIENT ma 192.168.100.10/24.
  • DNS SERVER ma 192.168.100.53/24.
  • SERVER ma 192.168.100.20/24.
  • ping po IP działa przed testowaniem DNS.
  • BIND9 nasłuchuje na porcie 53.
  • named-checkconf przechodzi bez błędów.
  • named-checkzone dla lab.test przechodzi bez błędów.
  • dig dla rekordów A, CNAME, NS i SOA zwraca oczekiwane dane.
  • reverse lookup dla 192.168.100.20 i 192.168.100.53 działa.

Najważniejsze pułapki

Błędny DNS klienta, na przykład 192.168.100.99, nie jest problemem strefy. Najpierw sprawdź, czy klient pyta właściwy serwer.

Literówka w strefie, brak finalnej kropki przy FQDN albo zły rekord to powód do użycia named-checkzone, a nie do przebudowy całej adresacji.

Lokalny DNS dla lab.test nie wymaga publicznych resolverów. Rekursja nie jest celem tego ćwiczenia.

Manifest grafik

Wszystkie grafiki wykorzystane w laboratorium znajdują się w poniższym katalogu Lab 05.

public/images/wirtualizacja/virtualbox/laboratoria/lab-05-dns/
01-topologia-lab-dns.png
02-przygotowanie-bind.png
03-adresacja-lab-dns.png
04-bind-port-53.png
05-strefa-forward.png
06-rekordy-dns.png
07-dig-forward.png
08-strefa-reverse-ptr.png
09-resolver-klienta.png
10-udp-tcp-53.png
11-ip-dziala-nazwa-nie.png
12-diagnostyka-dns.png

Skrót merytoryczny

Forward

A: nazwa → IPv4

CNAME: alias nazwy

NS: serwer nazw

SOA: dane administracyjne strefy

Reverse

PTR: IPv4 → nazwa

IPv4 reverse: in-addr.arpa

DNS: UDP 53 i TCP 53

Resolver może korzystać z cache