VPN-ul tău împinge trei servere DNS: care răspunde?

Deschide pagina de setări după conectare și apar trei adrese DNS; întrebarea auditului este care dintre ele a tratat ultima ta interogare. Numărul singur nu răspunde la nimic, pentru că o împingere a clientului, o interfață fizică și o politică per domeniu scriu toate în aceeași vedere. Aceste intrări au domenii de aplicare diferite, iar domeniul de aplicare, nu poziția, decide cine răspunde. Începe prin a separa sursele, apoi testeaz-o pe cea care deține numele care te interesează.

De ce lista este mai lungă decât profilul tău

Un client VPN împinge adrese de resolver pentru legătura tunelului, iar sistemul de operare le ține lângă ce avea deja interfața fizică. Un router, un lease DHCP corporate, un al doilea VPN și o politică per domeniu contribuie fiecare cu propria intrare. Prin urmare, trei adrese pe pagină pot însemna trei domenii de aplicare, nu trei candidați pentru o singură sarcină. A citi numărul ca dovadă a unei scurgeri este prima greșeală a acestui audit.

În interiorul unei interfețe, clientul chiar încearcă serverele în ordine, așa că o listă ordonată nu este lipsită de sens. Ceea ce nu este o coadă este vederea unificată, unde intrările din profil, din legătura fizică și din regulile per domeniu stau una lângă alta fără o singură ierarhizare. Această distincție decide ce testezi: ordinea explică comportamentul într-un domeniu de aplicare, iar domeniul de aplicare explică restul.

DNS-ul criptat rupe imaginea din interiorul unei aplicații. Un browser sau un client de chat cu propriul resolver DNS-over-HTTPS trimite interogările complet în afara listei sistemului de operare, așa că adresele din pagina de setări descriu trafic pe care aplicația nu l-a generat niciodată. Verifică setarea de resolver a aplicației înainte de a da vina pe profil pentru un nume care a ieșit greșit.

Ce spune fiecare dintre cele trei verificări

Fiecare sursă lasă o urmă într-un loc diferit, iar nicio comandă unică nu le arată pe toate. Aceasta este maparea care merită păstrată lângă pagina de setări:

Pe un sistem care folosește systemd-resolved, resolvectl status este autoritară, pentru că raportează DNS-ul pe legătură împreună cu domeniile de rutare. macOS răspunde prin scutil --dns, care listează resolverele cu domeniu de aplicare în ordinea în care sunt încercate. Windows împarte cele două jumătăți: Get-DnsClientServerAddress pentru serverele pe interfață și Get-DnsClientNrptPolicy pentru regulile de sufix. Rulează comanda care aparține resolverului folosit efectiv, pentru că o mașină cu mediu de containere și un resolver de desktop poate avea mai mult de unul instalat.

Un resolver de rezervă care nu poate răspunde pentru zona ta

O a doua intrare există de obicei pentru disponibilitate, iar disponibilitatea funcționează doar dacă rezerva cunoaște numele. Cere unui resolver public un nume de gazdă intern și acesta returnează NXDOMAIN, sau un răspuns wildcard dintr-un domeniu de căutare care nu are nimic de-a face cu tine. Un failover pe care nimeni nu l-a verificat produce atunci o cădere exact în momentul în care este necesar.

Split DNS există pentru a împiedica asta: sufixele companiei merg la un resolver care deține zona, iar numele publice rămân pe calea implicită. Designul este solid și depinde de lista de sufixe să fie completă. Microsoft documentează politica de resolver per sufix care conduce acest lucru pe Windows, iar aceeași idee apare ca domenii de rutare în systemd-resolved și ca resolvere cu domeniu de aplicare pe macOS.

Compară zonele pentru care rezerva poate răspunde cu sufixele prezente în politică. Această comparație găsește golul înainte ca un utilizator să raporteze că un site intern a încetat să se rezolve după o schimbare de tunel.

Interogează prin politică, nu pe lângă ea

Interogează prin resolverul sistemului de operare, pentru că o interogare directă la un server ocolește politica și raportează doar ce ar spune acel server. Diferența dintre cele două răspunsuri este tot rostul:

resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53

Dacă interogarea sistemului returnează o adresă privată în timp ce interogarea directă returnează NXDOMAIN, politica funcționează, iar rezerva este punctul slab. Dacă ambele returnează același răspuns public, numele este rezolvat în afara domeniului de aplicare dorit, iar lista de sufixe este locul unde trebuie privit. Păstrează ambele ieșiri, pentru că o discuție despre resolver se încheie mai repede cu două linii decât cu o captură a paginii de setări.

Apoi exersează calea de eșec, pentru că o rezervă pe care nimeni nu a testat-o este o presupunere. Transformă resolverul preferat într-o gaură neagră pentru o interogare și urmărește ce adresă revine:

ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32

Șterge acea rută imediat ce interogarea s-a terminat, altfel următoarea persoană moștenește un mister. Dacă numele interne încă se rezolvă în acea fereastră, ceva din afara domeniului de aplicare dorit le-a răspuns. Dacă în schimb expiră, rezerva lipsește sau este delimitată corect, iar jurnalul resolverului însuși îți spune care dintre cele două a fost.

Decide: păstrează, delimitează sau elimină

Păstrează un al doilea resolver când răspunde spațiului de nume de care ai nevoie și rămâne accesibil sub profil. Delimitează-l când ar trebui să vadă un singur sufix și nimic altceva, și elimină-l când nu are nici domeniu de aplicare, nici scop documentat. O intrare fără muncă este o scurgere viitoare fără beneficiu, iar o valoare implicită a furnizorului nu este un scop.

Înregistrează rezultatul în patru coloane: sufix, resolver, interfață și proprietar. Acea linie răspunde la următoarea întrebare a auditului mai repede decât orice captură și supraviețuiește actualizării clientului care reordonează lista în tăcere.