Testarea DNS-ului divizat fără a scurge nume interne

Interogarea unui nume intern la un resolver public îl scurge și sare peste regula pe care voiai să o testezi. Interogarea ajunge la un server pe care nu îl controlezi, răspunsul vine dintr-un spațiu de nume care nu ar fi trebuit să îl vadă niciodată, iar rezultatul nu spune nimic despre dacă DNS-ul divizat funcționează. A testa DNS divizat înseamnă a testa calea resolverului pe care o aplicație o folosește efectiv. Acea cale este aleasă de sistemul de operare, de lista de domenii din profilul VPN și uneori de browser.

Alege două nume și prezice mai întâi ambele răspunsuri

Cere proprietarului rețelei un nume de test intern documentat și alege un nume public obișnuit care nu spune nimic despre organizație. Scrie ce ar trebui să se întâmple pentru fiecare înainte de a rula ceva: numele intern ar trebui să ajungă la resolverul tunelului și să returneze o adresă internă, în timp ce numele public ar trebui rezolvat prin resolverul pe care sistemul îl folosește de obicei. Aceste două predicții sunt testul, pentru că fără ele orice răspuns poate fi justificat ulterior. Menține perechea constantă între rulări, ca o comparație ulterioară să însemne ceva.

Verifică regulile efective, nu pe cele intenționate. Lista de domenii atașată conexiunii VPN decide ce sufixe merg la ce resolver, iar o greșeală de tipar în acea listă produce o divizare plauzibilă, dar greșită. Pe un dispozitiv administrat, folosește calea de diagnostic a administratorului, deoarece suprascrierile locale pot fi resetate prin politică la următoarea verificare.

Notează predicția lângă răspunsul observat în același tichet. Un test fără predicție nu poate eșua, iar un test care nu poate eșua nu învață nimic.

Testează calea pe care o folosește aplicația, nu un server ales de tine

O comandă care numește explicit un resolver testează doar acel resolver și nimic altceva. Îți spune dacă serverul intern răspunde, ceea ce este util, și nu îți spune dacă o aplicație trimite numele acolo. Testează mai întâi pe calea normală: rezolvă numele intern așa cum ar face-o o aplicație și apoi rezolvă numele public în același fel. Abia după aceea întreabă servere specifice pentru a afla unde comportamentul diverge.

Browserele complică imaginea, pentru că setările de DNS securizat pot ocoli complet resolverul sistemului. Un browser configurat cu propriul resolver criptat nu vede niciodată divizarea, iar defecțiunea arată ca un profil VPN stricat. Verifică acea setare înainte de a schimba tunelul.

Repetă căutarea după reconectare dacă întrebarea este restaurarea. Un răspuns din cache de dinainte de reconectare poate face o divizare restaurată corect să pară mai bună sau mai rea decât este.

Înregistrează categoria răspunsului, nu doar succesul sau eșecul

Scrie care dintre patru lucruri s-a întâmplat: o adresă internă, o adresă publică, un răspuns negativ sau o expirare. Fiecare are o semnificație diferită. Adresa internă pentru numele intern este succesul așteptat; o adresă publică pentru un nume intern sugerează că interogarea a părăsit tunelul; un răspuns negativ de la serverul autoritativ indică o înregistrare lipsă, nu o eroare de rutare; iar expirarea indică o problemă de accesibilitate sau un resolver care nu a primit niciodată interogarea. Succesul și eșecul sunt prea grosiere pentru a acționa pe baza lor.

Ia în calcul cache-ul înainte de a interpreta o interogare proaspătă lipsă, pentru că un răspuns negativ din cache arată identic cu un nume care nu există. Capturează răspunsul înainte de a șterge ceva prin controale acceptate, pentru că primul răspuns este dovada.

Interpretează cele două ramuri fără a ghici

Dacă numele intern se rezolvă corect și aplicația tot eșuează, resolverul și-a făcut treaba, iar următorii suspecți sunt rutele și permisiunile pe resursa însăși. Dacă numele privat a ajuns la un resolver public, regula de divizare nu se aplică acelei căutări, așa că revizuiește lista de domenii și orice politică a browserului împreună cu proprietarul spațiului de nume. Aceste două ramuri au proprietari diferiți și de aceea este mai important să notezi care a fost văzută decât să notezi că ceva s-a stricat.

Ascunde datele sensibile din ieșirea partajată păstrând structura: ce spațiu de nume, ce regulă, ce categorie de răspuns. Un răspuns de resolver poate conține adrese interne și nume de gazdă, iar un tichet este o casă durabilă pentru ambele.

Apoi predă rezultatul proprietarului spațiului de nume cu cele două categorii observate și numele eliminate. Este o conversație de cinci minute în loc de o săptămână de speculații.