Captura Split-DNS: spuneți unde a fost făcută fiecare observație

Două persoane diagnostichează aceeași problemă Split-DNS și obțin adrese de resolver diferite. Una a folosit un instrument de căutare, alta a capturat pachete pe adaptor, iar a treia a citit diagnosticele clientului însuși. Niciuna nu minte și niciuna nu descrie aceeași etapă. Numirea punctului de observație transformă o contradicție într-o hartă.

O căutare, mai multe puncte de observație

Pentru un singur nume intern există cel puțin cinci locuri de privit: aplicația și API-ul de resolver pe care îl apelează, politica de domeniu efectivă pe client, o captură pe adaptor sau pe filtru, o limită de gateway controlată și resolverul care primește efectiv interogarea.

Fiecare răspunde la o altă întrebare, iar niciunul singur nu dovedește unde a ajuns interogarea.

O captură pe adaptor arată pachete, nu intenție. Nu spune ce resolver a ales clientul, iar o captură goală poate însemna un răspuns din cache sau un alt API de resolver în locul unui pachet aruncat. Tratați fiecare observație ca dovadă despre o singură etapă. Apoi asamblați etapele într-o cale.

Filtrul clientului stă între aplicație și cablu

Un client VPN cu Split-DNS aplică potrivirea domeniilor înainte ca pachetul să părăsească mașina. Numele din sufixul tunelat merg la resolverul intern; tot restul merge la cel local. Filtrul este politică, iar politica poate varia în funcție de platformă și de versiunea clientului.

Ghidul Split-DNS al Secure Client de la Cisco acoperă potrivirea domeniilor și filtrul Windows și separă ceea ce vede o aplicație când folosește API-ul de resolver nativ de ceea ce vede un instrument precum nslookup. Exact aceste distincții sunt esența.

Începeți de la profilul efectiv și de la o căutare obișnuită a aplicației. Orice test care numește un server explicit este un ocol deliberat; explicați-l cu diagnosticele clientului însuși și nu lăsați să devină criteriul de acceptare.

nslookup urmează o cale diferită de cea a aplicației

nslookup își construiește propria interogare DNS și poate ocoli politica de resolver a sistemului de operare. Asta îl face util pentru a pune o întrebare anume unui server anume, și înșelător pentru a testa ce va experimenta o aplicație.

În Windows, tabelul politicii de rezolvare a numelor decide ce sufix folosește ce server. Citirea lui arată politica pe care o va urma aplicația, iar aceasta este adesea piesa lipsă.

Citiți politica și apoi puneți aceeași întrebare prin resolverul obișnuit:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Resolverele criptate ascund interogarea, nu conexiunea

Un browser cu propriul resolver DNS-over-HTTPS este un caz complet diferit. Interogarea iese în interiorul TLS, așa că o captură de pachete arată o conexiune către o adresă de resolver, dar nu numele care este întrebat.

Stabiliți mai întâi politica gestionată a browserului, apoi comparați-o cu o căutare a sistemului de operare. Este posibil ca un browser căruia i se permite să își aleagă propriul resolver să nu vadă deloc politica Split-DNS.

Aceeași prudență se aplică oricărui client care își aduce propriul resolver. O captură care identifică conexiunea la distanță nu este dovadă despre numele interogării. Dacă aveți nevoie de nume, luați-l din jurnalele resolverului însuși sau din diagnosticele aplicației, cu regulile de confidențialitate aplicabile.

Comparați cu un test etichetat

Alegeți un nume intern aprobat pentru test, plus un nume public care nu poartă nicio semnificație sensibilă. Pentru fiecare, notați ora, tipul de înregistrare, răspunsul și politica așteptată.

Unde este permis, comparați recepția din resolver cu o singură observație îngustă a clientului sau a gateway-ului:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

Nu trimiteți niciodată nume private către resolvere publice fără legătură doar pentru a crea o comparație, și redactați tot ce partajați. În final, separați un răspuns DNS corect de conexiunea la serviciu care urmează: adresa privată rezolvată are încă nevoie de o rută și de o autorizare a aplicației.