VPN-DNS-verslag: wat dit moet bevat sodat dit herhaalbaar is

“DNS is stukkend” is ’n gevolgtrekking, en dit is nie een waarop ’n helper kan optree nie. Die nuttige deel van ’n verslag is die vorm van die fout: watter naam, deur watter resolver, met watter antwoord. Drie besonderhede maak ’n klag herhaalbaar, en al drie is veilig om te deel sodra die private dele herbenoem is. Wat volg, is die minimum wat ’n VPN DNS-verslag nodig het voordat iemand kan help.

’n Kategorie van naam, nie ’n uitspraak nie

Begin met die naam self en klassifiseer dit: publiek, intern, kort, volledig gekwalifiseer, of deur een spesifieke agtervoegsel bedien. ’n Interne naam wat faal terwyl publieke name oplos, wys op resolver-keuse eerder as op bereikbaarheid. Elke naam wat faal, wys op die pad na die resolver, wat ’n ander ondersoek met ander bewyse is. Die kategorie dra die diagnose, en die presiese string kan verberg word.

Sê of die fout vereis dat die tonnel op is, of ná dit ontkoppel gebeur. ’n Naam wat net faal terwyl die VPN aktief is, impliseer die per-skakel-konfigurasie, terwyl een wat ná ontkoppeling faal, oorblywende toestand impliseer. Verslae laat dit gewoonlik weg en wonder dan waarom die eerste voorstel nie help nie.

Teken die resolver-pad aan

’n Navraag wat na ’n eksplisiet gekose bediener gestuur word, en ’n toepassing se gewone opsoek is verskillende eksperimente. Sê watter een die fout veroorsaak het, want ’n handmatige navraag na ’n werkende bediener bewys net dat die bediener werk. Die opdragte hieronder skei die stelselpad van ’n direkte vraag.

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

Die status-uitvoer noem die per-skakel-bedieners en die roeteringsdomeine, wat is waar split-DNS besluit word. Die getent-oproep volg dieselfde pad as die toepassing, insluitend die nsswitch-orde. Die direkte navraag omseil albei en toets een bediener in isolasie. Rapporteer watter van die drie gefaal het en watter geslaag het, en die leser hoef nie meer na die pad te raai nie.

Noem die beheerde vergelyking

Verander een veranderlike en sê wat verander het. Publieke name wat oplos terwyl interne faal, is ’n keuseprobleem; elke naam wat tyd uitloop is ’n padprobleem; en ’n private naam wat na ’n publieke adres oplos, is ’n lek in die verkeerde resolver. Twee van daardie drie het niks te doen met of die tonnel op is nie. ’n Verslag wat beweer dat alle navrae stukkend is, bevat gewoonlik ’n vergelyking wat nooit gedoen is nie.

Skei oplossing van aflewering. Wanneer die naam oplos en die webwerf steeds faal, het die DNS-stadium geslaag en die verslag moet dit sê, want die volgende stap is ’n roete of ’n luisteraar eerder as ’n resolver. Daardie enkele onderskeiding spaar meer dikwels ’n ronde vrae as enige log-uittreksel.

Verberg die naamruimte, behou die verwantskappe

Interne name kan vervang word, solank die vervangings die struktuur bewaar. Karteer elke afsonderlike bediener en agtervoegsel na ’n stabiele etiket, en hou daardie kartering uit die gedeelde kopie. Om elke interne gasheer met dieselfde plekhouer te vervang, vernietig juis die bewyse wat die verslag nodig het, want die leser kan nie meer sien dat een agtervoegsel opgelos het en ’n ander nie. Dieselfde reël geld vir adresse: behou die voorvoegsel-verwantskappe en verander die gasheer-bisjies as beleid dit vereis.

Stuur die rekord deur die geverifieerde kanaal en laat weg wat die diagnose nooit nodig het nie. Wagwoorde, private sleutels en onverwante maatskappyname is nie deel van ’n DNS-vraag nie. Wat die leser nodig het, is die foutkategorie, die resolver-pad, die presiese fout en die een vergelyking wat jy gedoen het.