Kur një përdorues thotë se “interneti nuk punon”, por aplikacionet që përdorin adresa IP vazhdojnë të komunikojnë, problemi shpesh nuk është lidhja fizike. Në shumë raste, shkaku është DNS. Të kuptosh si të diagnostikosh probleme DNS është një aftësi bazë për çdo administrator rrjeti, teknik supporti ose kandidat që përgatitet për role networking dhe sisteme.
DNS, ose Domain Name System, përkthen emra si `server.company.local` apo `www.example.com` në adresa IP. Pa këtë përkthim, përdoruesi mund të ketë akses në rrjet, por nuk mund të hapë faqe, shërbime cloud, serverë emaili ose burime të brendshme vetëm duke përdorur emrat e tyre. Diagnostikimi i saktë kërkon një proces të strukturuar, jo hamendësim.
Filloni duke dalluar problemin DNS nga problemi i lidhjes
Hapi i parë është të verifikoni nëse pajisja ka lidhje IP funksionale. Në Windows, përdorni komandën `ipconfig`; në Linux, përdorni `ip addr` ose `ip a`. Kontrolloni nëse kompjuteri ka një adresë IP të vlefshme, maskë rrjeti, gateway të parazgjedhur dhe adresë DNS të konfiguruar.
Më pas, testoni komunikimin me një adresë IP të njohur. Për shembull, `ping 8.8.8.8` mund të përdoret për të kontrolluar nëse pajisja arrin një host në internet. Nëse ping ndaj IP-së funksionon, por `ping google.com` nuk zgjidh emrin ose jep gabim, dyshimi kryesor bie mbi DNS.
Ky test nuk është absolut. Disa hoste ose firewall-e bllokojnë ICMP, pra një ping i pasuksesshëm nuk do të thotë automatikisht se hosti është i paarritshëm. Megjithatë, krahasimi midis testimit me IP dhe testimit me emër është një pikënisje shumë e dobishme. Në laboratorët e rrjeteve, kjo ndarje ndihmon të mos humbet kohë duke kontrolluar switch-e, kabllo ose routing kur problemi është vetëm rezolucioni i emrit.
Si të diagnostikosh probleme DNS me nslookup
Mjeti më praktik për verifikimin fillestar është `nslookup`. Ai ju tregon nëse serveri DNS përgjigjet dhe çfarë adrese IP kthen për një emër të caktuar.
Në Windows ose Linux, provoni komandën:
`nslookup google.com`
Rezultati duhet të tregojë serverin DNS që po përdoret dhe adresën ose adresat IP të kthyera për domenin. Nëse shfaqet mesazhi “DNS request timed out”, “server failed” ose “non-existent domain”, duhet të kuptoni ndryshimin mes tyre.
“DNS request timed out” zakonisht tregon se klienti nuk po merr përgjigje nga serveri DNS. Shkaku mund të jetë serveri i paarritshëm, porta UDP 53 e bllokuar, një firewall, konfigurim i gabuar i gateway-t ose ngarkesë e lartë në DNS server. “Non-existent domain”, i njohur edhe si NXDOMAIN, do të thotë se serveri është përgjigjur, por emri i kërkuar nuk ekziston në zonën përkatëse. Ndërsa “server failed” sugjeron që serveri DNS ka hasur problem gjatë përpunimit të kërkesës, shpesh për shkak të forwarder-ëve, zonave të dëmtuara ose problemeve me DNSSEC në mjedise të caktuara.
Për të testuar një server specifik DNS, përdorni:
`nslookup google.com 8.8.8.8`
Në një rrjet biznesi, zëvendësoni adresën publike me IP-në e DNS serverit të brendshëm. Kjo ju lejon të krahasoni rezultatin e serverit të kompanisë me një resolver tjetër. Nëse emri zgjidhet me DNS publik, por jo me DNS të brendshëm, problemi është shumë më i lokalizuar: serveri i brendshëm, zona DNS, forwarder-i ose politika e rrjetit.
Kontrolloni konfigurimin e klientit
Një konfigurim i pasaktë në një workstation mund të krijojë një incident që prek vetëm një përdorues. Për këtë arsye, para se të kontrolloni serverin DNS, verifikoni parametrat e klientit.
Në Windows, `ipconfig /all` shfaq adresat e DNS serverëve, suffix-in DNS dhe mënyrën si është marrë konfigurimi. Nëse kompjuteri merr parametrat përmes DHCP, kontrolloni nëse scope-i DHCP shpërndan adresat e sakta DNS. Një adresë e vjetër, një IP e gabuar ose një server që nuk është më aktiv mjafton për të shkaktuar dështim të rezolucionit.
Në Linux, konfigurimi mund të vijë nga NetworkManager, DHCP, `systemd-resolved` ose skedari `resolv.conf`, në varësi të distribucionit. Mos supozoni se ndryshimi manual i `resolv.conf` është gjithmonë zgjidhje e qëndrueshme. Në disa sisteme, ai skedar krijohet automatikisht dhe ndryshimet humbasin pas rinisjes së shërbimit ose pajisjes.
Gjithashtu, kontrolloni renditjen e DNS serverëve. Nëse serveri i parë është i paarritshëm, përdoruesi mund të përjetojë vonesa të gjata edhe kur serveri i dytë funksionon. Kjo nuk është një ndërprerje e plotë, por për përdoruesin duket si rrjet i ngadaltë ose aplikacion që “ngec”.
Verifikoni cache-in DNS dhe emrat lokalë
DNS përdor cache për të reduktuar kërkesat dhe për të përshpejtuar përgjigjet. Ky mekanizëm është i dobishëm, por mund të krijojë probleme kur një rekord ndryshon dhe klientët vazhdojnë të përdorin adresën e vjetër.
Në Windows, pastroni cache-in e klientit me:
`ipconfig /flushdns`
Më pas rifilloni testin me `nslookup` ose provoni të hapni shërbimin përkatës. Në Linux, mënyra e pastrimit varet nga shërbimi aktiv. Për shembull, sistemet që përdorin `systemd-resolved` mund të pastrojnë cache-in përmes komandave të këtij shërbimi.
Mos harroni se cache mund të ekzistojë në më shumë se një nivel: te shfletuesi, sistemi operativ, DNS resolver-i lokal, firewall-i ose DNS serveri i kompanisë. Nëse një ndryshim DNS nuk reflektohet menjëherë, kontrolloni TTL-në e rekordit. Një TTL i lartë ul kërkesat ndaj serverit, por vonon përhapjen e ndryshimeve. Një TTL shumë i ulët ofron fleksibilitet, por rrit ngarkesën e kërkesave. Zgjedhja varet nga shërbimi dhe niveli i tolerancës ndaj ndryshimeve.
Për mjedise të brendshme, kontrolloni edhe skedarin `hosts`. Një hyrje e vjetër në këtë skedar ka përparësi ndaj kërkesës normale DNS dhe mund të drejtojë përdoruesin drejt një adrese të gabuar. Ky është një problem i zakonshëm në pajisje ku janë bërë teste, migrime serverësh ose konfigurime manuale.
Kontrolloni zonën DNS dhe llojin e rekordit
Nëse problemi prek një emër të vetëm, fokusi duhet të kalojë te rekordi DNS. Një rekord A lidhet me një adresë IPv4, ndërsa AAAA me IPv6. Rekordi CNAME krijon alias për një emër tjetër, MX përdoret për email dhe PTR shërben për reverse lookup.
Për shembull, nëse aplikacioni përdor `app.company.local`, kontrolloni nëse ekziston rekordi A ose CNAME, nëse adresa IP është e saktë dhe nëse rekordi është krijuar në zonën e duhur. Një rekord mund të duket i saktë në server, por të mos replikohet në një DNS server tjetër në një mjedis me Active Directory.
Në rrjetet me Windows Server dhe Active Directory, replikimi i zonave DNS është kritik. Nëse një domain controller ka rekordin e ri dhe një tjetër nuk e ka, përdoruesit mund të marrin rezultate të ndryshme sipas DNS serverit që përdorin. Testoni emrin drejtpërdrejt ndaj secilit server DNS për të gjetur mospërputhjen.
Reverse DNS duhet kontrolluar kur shërbimet kërkojnë verifikim të adresës IP, si disa sisteme emaili, log-e sigurie ose mekanizma autentikimi. Një forward lookup funksional nuk garanton që reverse lookup është gjithashtu i konfiguruar saktë.
Kontrolloni portat, firewall-in dhe forwarder-ët
Kërkesat DNS përdorin zakonisht UDP portën 53, por mund të përdorin TCP 53 për përgjigje të mëdha, zone transfer ose raste të veçanta. Nëse firewall-i lejon vetëm UDP, disa kërkesa mund të dështojnë në mënyrë të çrregullt. Kjo krijon një problem më të vështirë për t’u identifikuar, sepse rezolucioni funksionon për disa emra dhe dështon për të tjerë.
Në një DNS server të brendshëm, kontrolloni nëse forwarder-ët janë të disponueshëm. Forwarder-i është serveri ku DNS-i juaj dërgon kërkesa për zona që nuk i administron vetë. Nëse forwarder-i është i gabuar ose i paarritshëm, emrat e brendshëm mund të funksionojnë, ndërsa domenet publike jo.
Duhet të kontrolloni edhe routing-un nga DNS serveri drejt internetit, jo vetëm nga klienti drejt DNS serverit. Një klient mund të arrijë serverin DNS pa problem, ndërsa vetë serveri DNS nuk mund të arrijë forwarder-in e konfiguruar.
Ndërtoni një metodë që mund ta përsërisni
Diagnostikimi profesional nuk fillon me ndryshime të rastësishme në konfigurim. Filloni me simptomën, testoni lidhjen IP, provoni rezolucionin e emrit, identifikoni DNS serverin aktiv dhe më pas izoloni nëse problemi është te klienti, rrjeti, serveri apo rekordi DNS.
Mbani shënim emrin që dështoi, kohën e incidentit, serverin DNS të përdorur, mesazhin e gabimit dhe rezultatin e testimit me një resolver alternativ. Këto të dhëna janë të vlefshme në një intervistë teknike, në një laborator CCNA ose në një incident real pune, sepse tregojnë se po veproni me metodë.
Në Connect Academy, skenarë të tillë trajtohen në laboratorë praktikë, ku teoria e DNS lidhet me konfigurime reale të klientëve, serverëve dhe shërbimeve të rrjetit. Aftësia për të izoluar shkakun e një problemi është ajo që e kthen njohurinë e komandave në kompetencë profesionale.
Herën tjetër që një emër nuk zgjidhet, mos e trajtoni DNS-in si një “kuti të zezë”. Ndiqni rrugën e kërkesës nga klienti te serveri, nga zona te rekordi dhe nga serveri te forwarder-i. Me këtë disiplinë, edhe një incident i paqartë bëhet një proces teknik që mund ta verifikoni dhe ta zgjidhni.