DNS server: Vodič za testiranje pomoću dig, nslookup i host

Article Image

DNS server: vodič za testiranje i otklanjanje najčešćih problema

DNS server prevodi nazive domena, kao što je domain.com, u IP adrese koje računari koriste za komunikaciju. Kada DNS ne radi ispravno, korisnici mogu prijaviti da veb-sajt nije dostupan, da e-pošta kasni ili da se pojedini servisi otvaraju samo sa nekih mreža. Ovaj vodič prikazuje kako se takvi problemi sistematski ispituju pomoću alata dig, nslookup, host i journalctl.

Cilj početne dijagnostike nije samo da se utvrdi da li domen „radi“, već da se odredi gde nastaje problem: na lokalnom resolveru, u kešu, na autoritativnom serveru, u delegaciji domena, konfiguraciji zone ili na mrežnom portu 53.

Kako DNS odgovor nastaje i koje zapise treba proveriti

DNS upit obično prvo obrađuje lokalni resolver, odnosno servis ili DNS adresa podešena na računaru. Resolver može vratiti ranije sačuvan odgovor iz keša ili poslati upit rekurzivnom DNS serveru. Ako je potrebno, rekurzivni server pronalazi autoritativni server za konkretnu zonu i od njega dobija konačan odgovor.

Najčešći DNS zapisi imaju različite namene:

  • A povezuje domen sa IPv4 adresom, dok AAAA koristi IPv6 adresu.
  • CNAME predstavlja drugo ime za postojeći naziv.
  • MX određuje servere zadužene za prijem e-pošte.
  • NS navodi autoritativne DNS servere za zonu.
  • SOA sadrži osnovne podatke o zoni, serijski broj i vremenske parametre.
  • TXT se često koristi za SPF, DKIM, verifikaciju domena i druge tekstualne podatke.

TTL, odnosno Time To Live, određuje koliko sekundi resolver sme da čuva odgovor u kešu. Na primer, TTL od 3600 znači da promenjeni zapis može ostati vidljiv približno jedan sat kod resolvera koji je prethodno sačuvao staru vrednost. Zbog toga se promena DNS zapisa ne mora pojaviti istovremeno na svim mrežama.

Početna procena DNS servera iz Linux terminala

Na Debianu i Ubuntu sistemima potrebni alati najčešće dolaze iz paketa dnsutils, dok se na RHEL, Rocky Linux i AlmaLinux sistemima često koriste paketi bind-utils. Instalacija zahteva sudo ili root privilegije.

# Debian/Ubuntu
sudo apt install dnsutils

# RHEL/Rocky/AlmaLinux
sudo dnf install bind-utils

Prvi test treba izvršiti bez menjanja konfiguracije, kako bi se dobila početna referentna tačka:

dig domain.com A
nslookup domain.com
host domain.com

dig prikazuje najviše detalja, uključujući status odgovora, TTL i sekcije pitanja i odgovora. nslookup je praktičan za brzu proveru i dostupan je na različitim operativnim sistemima, dok host daje sažet rezultat pogodan za skripte i osnovnu dijagnostiku.

Status NOERROR znači da je upit uspešno obrađen, ali ne garantuje da traženi zapis postoji. NXDOMAIN ukazuje da domen ili naziv ne postoji, dok SERVFAIL obično zahteva dalju proveru autoritativnog servera, zone, DNSSEC-a ili dostupnosti mreže. Sledeći korak je poređenje odgovora različitih resolvera i direktna provera autoritativne delegacije.

Upoređivanje resolvera i provera autoritativnog servera

Ako se odgovori razlikuju između mreža ili računara, upit treba ponoviti preko više javnih resolvera. Time se može utvrditi da li je problem u lokalnom kešu ili u samoj DNS zoni:

dig domain.com A
dig @1.1.1.1 domain.com A
dig @8.8.8.8 domain.com A
nslookup domain.com 1.1.1.1
host domain.com 8.8.8.8

Ako javni resolveri vraćaju različite adrese, proverite TTL i vreme kada je zapis poslednji put promenjen. Resolver koji još ima staru vrednost može je zadržati do isteka TTL-a, dok novi upit nakon isteka treba da dobije aktuelan odgovor. Za detaljniji prikaz autoritativnog odgovora korisno je koristiti opciju +trace:

dig +trace domain.com

Ova komanda prati put od root servera, preko TLD servera, do autoritativnih servera domena. Ako se lanac prekine, obratite pažnju na NS zapise, glue zapise i dostupnost servera. Autoritativni server mora imati javno dostupnu adresu, a za svaki navedeni NS naziv mora postojati odgovarajući zapis. Poseban problem nastaje kada su NS serveri postavljeni unutar istog domena, ali njihove IP adrese nisu pravilno upisane kao glue zapisi kod registra.

Direktan upit autoritativnom serveru omogućava da se zaobiđe keš rekurzivnog resolvera:

dig @ns1.domain.com domain.com SOA
dig @ns1.domain.com domain.com A +norecurse
dig @ns1.domain.com domain.com MX

Opcija +norecurse traži direktan odgovor bez rekurzivnog traženja. Ako autoritativni server ne odgovara, proverite da li sluša na TCP i UDP portu 53, jer DNS koristi oba protokola. Veliki odgovori, DNSSEC i pojedini transferi mogu zahtevati TCP vezu.

Provera delegacije, zone i konfiguracije DNS servisa

Delegacija mora biti usklađena na više nivoa: registrar treba da pokazuje na ispravne NS servere, roditeljska zona mora sadržati odgovarajuće NS zapise, a sama zona mora biti učitana na navedenim serverima. Za poređenje autoritativnih servera koristite:

dig domain.com NS
dig @ns1.domain.com domain.com SOA
dig @ns2.domain.com domain.com SOA

SOA serijski broj treba da bude isti na svim autoritativnim serverima. Ako je serijski broj na sekundarnom serveru stariji, moguće je da replikacija zone nije uspela ili da je firewall blokirao DNS transfer. Kod BIND-a se sintaksa i sadržaj zone mogu proveriti pre ponovnog učitavanja:

sudo named-checkconf
sudo named-checkzone domain.com /etc/bind/db.domain.com

Putanja do zone zavisi od distribucije i načina instalacije. Obratite pažnju na tačke na kraju potpuno kvalifikovanih naziva, naročito u SOA, NS i MX zapisima. Na primer, mail.domain.com. predstavlja puno ime, dok zapis bez završne tačke može biti dopunjen nazivom zone i proizvesti pogrešan rezultat.

Pregled logova i potvrda mrežne dostupnosti

Kada komande vraćaju SERVFAIL ili nema odgovora, logovi često otkrivaju uzrok. Na sistemima sa systemd servis se može pronaći i pratiti pomoću journalctl:

sudo systemctl status bind9
sudo systemctl status named
sudo journalctl -u bind9 --since "30 minutes ago"
sudo journalctl -u named -f

U zapisima potražite greške kao što su neispravna sintaksa zone, nedostupan forwarder, odbijen transfer, problem sa DNSSEC validacijom ili neuspešno vezivanje porta. Ako servis radi, proverite da li zaista sluša na očekivanim adresama:

sudo ss -luntp | grep ':53'
dig @127.0.0.1 domain.com A
dig @server_ip domain.com A

Uspešan lokalni upit, ali neuspešan upit sa druge mreže, obično ukazuje na firewall, ACL pravila ili pogrešno podešene listening adrese. Nakon izmene konfiguracije prvo proverite sintaksu, zatim ponovo učitajte servis i ponovite test sa lokalnog i udaljenog klijenta.

Sistematičan pristup za pouzdan DNS

Pouzdano rešavanje DNS problema zahteva strpljivo poređenje odgovora i proveru svakog dela lanca, umesto oslanjanja na jedan test ili jedan računar. Promene treba uvoditi postepeno, uz beleženje prethodnog stanja i vremena kada je izmena napravljena.

Posebnu pažnju treba posvetiti usklađenosti autoritativnih servera, ispravnosti delegacije i očekivanom ponašanju keširanja. Kada se rezultati tumače u kontekstu TTL-a, logova i mrežne dostupnosti, uzrok problema se najčešće može precizno locirati i otkloniti bez nepotrebnih prekida servisa.

Redovna provera konfiguracije, SOA serijskih brojeva, dostupnosti porta 53 i zapisa važnih za veb i e-poštu predstavlja dobru preventivnu praksu. Tako DNS ostaje predvidiv, promene se lakše kontrolišu, a budući incidenti rešavaju se brže i sa manje rizika.

By Mreže