Raport DNS prin VPN: ce să includeți ca să fie reproductibil

„DNS-ul este stricat” este o concluzie și nu este o concluzie pe baza căreia un ajutor să poată acționa. Partea utilă a unui raport este forma defecțiunii: care nume, prin care resolver, cu ce răspuns. Trei detalii transformă o plângere în ceva reproductibil, iar toate trei pot fi partajate în siguranță după ce părțile private sunt redenumite. Urmează minimul de care are nevoie un raport DNS prin VPN înainte ca cineva să poată ajuta.

O categorie de nume, nu o sentință

Începeți cu numele în sine și clasificați-l: public, intern, scurt, complet calificat sau deservit de un anumit sufix. Un nume intern care eșuează în timp ce numele publice se rezolvă indică selecția resolverului, nu accesibilitatea. Dacă toate numele eșuează, asta indică calea către resolver, ceea ce este o altă anchetă cu alte dovezi. Categoria poartă diagnosticul, iar șirul exact poate fi ascuns.

Spuneți dacă defecțiunea necesită tunelul ridicat sau apare după ce acesta se deconectează. Un nume care se rupe doar cât timp VPN-ul este activ implică configurația pe legătură, în timp ce unul care se rupe după deconectare implică o stare rămasă. Rapoartele omit de obicei acest lucru și apoi se întreabă de ce prima sugestie nu ajută.

Înregistrați calea resolverului

O interogare trimisă unui server ales explicit și căutarea obișnuită a unei aplicații sunt experimente diferite. Spuneți care dintre ele a produs defecțiunea, deoarece o interogare manuală către un server funcțional dovedește doar că serverul funcționează. Comenzile de mai jos separă calea sistemului de o întrebare directă.

resolvectl status --no-pager
getent hosts host.internal
dig +short host.internal @10.20.30.53

Ieșirea de stare numește serverele pe legătură și domeniile de rutare, adică unde se decide split DNS. Apelul getent urmează aceeași cale ca aplicația, inclusiv ordinea nsswitch. Interogarea directă le ocolește pe ambele și testează un singur server izolat. Raportați care dintre cele trei a eșuat și care a reușit, iar cititorul nu mai trebuie să ghicească calea.

Indicați comparația controlată

Schimbați o variabilă și spuneți ce s-a schimbat. Faptul că numele publice se rezolvă în timp ce cele interne eșuează este o problemă de selecție; faptul că fiecare nume expiră este o problemă de cale; iar un nume privat care se rezolvă la o adresă publică este o scurgere către resolverul greșit. Două dintre aceste trei nu au nimic de-a face cu starea tunelului. Un raport care susține că toate interogările sunt stricate conține de obicei o comparație care nu a fost niciodată executată.

Separați rezolvarea de livrare. Când numele se rezolvă și site-ul tot eșuează, etapa DNS a reușit și raportul ar trebui să spună asta, pentru că pasul următor este o rută sau un listener, nu un resolver. Această singură distincție economisește mai des o rundă de întrebări decât orice fragment de jurnal.

Ascundeți spațiul de nume, păstrați relațiile

Numele interne pot fi înlocuite, atâta timp cât înlocuirile păstrează structura. Asociați fiecare server și sufix distinct cu o etichetă stabilă și țineți acea mapare în afara copiei partajate. Înlocuirea fiecărui host intern cu același substituent distruge exact dovada de care are nevoie raportul, pentru că cititorul nu mai poate vedea că un sufix s-a rezolvat, iar altul nu. Aceeași regulă se aplică adreselor: păstrați relațiile de prefix și schimbați biții hostului dacă politica o cere.

Trimiteți înregistrarea prin canalul verificat și lăsați afară ce nu are nevoie niciodată diagnosticul. Parolele, cheile private și numele de companii fără legătură nu fac parte dintr-o întrebare DNS. Cititorul are nevoie de categoria defecțiunii, calea resolverului, eroarea exactă și singura comparație pe care ați făcut-o.