NXDOMAIN përmes një VPN nuk do të thotë ndërprerje e tunelit

Është joshëse ta lexosh një kërkim të dështuar si provë se tuneli u shemb, sidomos kur emri funksiononte dhjetë minuta më parë. Përgjigja thotë diçka tjetër. NXDOMAIN është një transaksion DNS i përfunduar në të cilin një zgjidhës deklaroi se emri i pyetur nuk ekziston; një tunel i prishur zakonisht prodhon heshtje, një afat të skaduar ose një përpjekje zgjidhjeje ndaj serverit të gabuar. Versioni i argumentit pa wireshark është një kërkesë, një përgjigjës dhe një kod përgjigjeje, dhe ky triplet meriton të regjistrohet përpara çdo ndryshimi konfigurimi.

Çfarë vërteton në të vërtetë përgjigja

DNS i ndan rezultatet që klientët shpesh i bashkojnë në një dështim të vetëm. Një emër që nuk ekziston prodhon një përgjigje negative me kodin NXDOMAIN, ndërsa një emër që ekziston por nuk ka asnjë regjistrim të llojit të kërkuar prodhon një përgjigje të suksesshme me një seksion përgjigjesh bosh. Të dyja duken si diçka e padobishme për një aplikacion, dhe vetëm njëra prej tyre do të thotë që emri është i gabuar.

Ky ndryshim vendos se ku i takon riparimi. Një regjistrim AAAA që mungon në një host që ka një regjistrim A nuk është një host që mungon, dhe rihedhja e një certifikate ose rindërtimi i një tuneli për ta ndjekur harxhon të vetmen gjurmë që ishte në dispozicion. Dallimi përcakton edhe formën e vazhdimit: një problem emërtimi rregullohet në zonë, dhe një problem lloji rregullohet duke kërkuar regjistrimin e duhur ose duke pranuar se familja e adresave thjesht mungon.

Miti: një emër privat që mungon do të thotë që tuneli dështoi

Miti mbijeton sepse këto dy ngjarje vijnë kaq shpesh bashkë. Një klient lidhet me VPN, sistemi operativ mban një zgjidhës të cilit tashmë i besonte, dhe emri i brendshëm që i duhet tani pyetet në një server që nuk ka dëgjuar kurrë për zonën private. Ai server përgjigjet me ndershmëri dhe negativisht. Tuneli po e transporton paketën; përgjigja ka të bëjë thjesht me një hapësirë emrash që përgjigjësi nuk e shërben.

Rregullimet split-horizon e bëjnë këtë rutinë: i njëjti emër zone ekziston publikisht dhe brenda me përmbajtje të ndryshme, dhe vetëm zgjidhësi i brendshëm i njeh regjistrimet private. Marrja e një përgjigjeje negative që duket autoritative është pra provë për atë se cili zgjidhës u përgjigj, jo provë për gjendjen e ndërfaqes.

Dy detaje konfigurimi vendosin rezultatin. Tuneli duhet ta shtyjë ose ta zgjedhë zgjidhësin e brendshëm, dhe klienti duhet ta zbatojë atë zgjedhje në emrin që kërkohet. Një rregull për domen që emërton një prapashtesë pak më të ndryshme nga regjistrimi që shtypët do ta dërgojë kërkesën në rrugën publike, dhe përgjigja do të jetë e saktë dhe e padobishme.

Pyetni zgjidhësin e duhur me emrin e duhur

Regjistroni përgjigjësin përpara se të regjistroni verdiktin. Një kërkim që nuk tregon se cili server u përgjigj nuk mund të dallojë një problem politike nga një problem hapësire emrash, dhe të dyve u takojnë rregullime të palidhura.

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

Dy rreshtat e parë tregojnë çfarë vendosi zgjidhësi lokal dhe kë do të pyeste. Kërkimi +search riprodhon atë që bën një aplikacion kur shton një prapashtesë kërkimi, e cila shpesh është kërkesa e vërtetë dhe jo ajo e shtypur në një mjet diagnostikues. Rreshti i fundit pyet serverin e brendshëm drejtpërdrejt, duke anashkaluar politikën e klientit; nëse kjo funksionon ndërsa kërkimi i thjeshtë dështon, zona është në rregull dhe rrugëtimi i kërkesave nuk është.

Cache-i negativ shpjegon vonesën pas një rregullimi

Përgjigjet negative ruhen në cache sipas projektimit, dhe RFC 2308 përshkruan se si jetëgjatësia e cache-it negativ rrjedh nga regjistrimi i autoritetit të zonës. Rregullimi i një regjistrimi ose i një rregulli zgjidhësi nuk garanton pra një ndryshim të menjëhershëm te klienti, dhe përsëritja e një kërkimi që vazhdon të kthejë përgjigjen e cache-uar nuk provon asgjë të re. Vetëm një përgjigjës tjetër, një emër tjetër ose një cache i zbrazur prodhojnë prova të freskëta.

Zbrazni cache-in lokal, pastaj përsëritni të njëjtën kërkesë ndaj të njëjtit përgjigjës. Në sistemet që përdorin shërbimin e zgjidhësit lokal ky është një komandë e vetme; në të tjerët është një rinisje shërbimi ose një mjet platforme, dhe mjeti konkret ka më pak rëndësi sesa përsëritja më pas e një testi identik.

Ndani emrin nga rruga

Pasi emri zgjidhet në adresën private të pritur, DNS ka mbaruar si temë dhe rruga e aplikacionit bëhet pyetja e radhës. Një host që u përgjigjet kërkimeve por refuzon një lidhje ka një problem tjetër, dhe vazhdimi i rregullimit të zgjidhësve pas një përgjigjeje të saktë është mënyra se si një incident fiton tre ndryshime të palidhura. Krahasoni adresën e zgjidhur me atë në të cilën shërbimi dëgjon vërtet përpara se të supozoni se të dyja përputhen.

Ruajeni transkriptin: kërkesën, përgjigjësin, kodin dhe adresën e zgjidhur. Ai regjistrim është gjithashtu ai që e bën të verifikueshëm një raport të mëvonshëm, dhe është dallimi midis një diagnoze dhe një historie për një tunel që dukej i ngadaltë.