VPN-DNS-rapport: hvad den skal indeholde for at kunne gengives

„DNS er i stykker“ er en konklusion, og det er ikke en konklusion, en hjælper kan handle på. Den brugbare del af en rapport er fejlens form: hvilket navn, gennem hvilken resolver, med hvilket svar. Tre detaljer gør en klage reproducerbar, og alle tre er sikre at dele, når de private dele er omdøbt. Det følgende er det minimum, en VPN DNS-rapport skal indeholde, før nogen kan hjælpe.

En kategori af navn, ikke en dom

Begynd med selve navnet og klassificér det: offentligt, internt, kort, fuldt kvalificeret eller betjent af ét bestemt suffiks. Et internt navn, der fejler, mens offentlige navne slår op, peger på valg af resolver frem for på rækkevidde. Hvis alle navne fejler, peger det på stien til resolveren, og det er en anden undersøgelse med andre beviser. Kategorien bærer diagnosen, og den præcise streng kan sløres.

Sig, om fejlen kræver, at tunnelen er oppe, eller om den sker, efter den kobles fra. Et navn, der kun brækker, mens VPN er aktivt, implicerer konfigurationen per link, mens et, der brækker efter afbrydelse, implicerer resttilstand. Rapporter udelader det ofte og undrer sig så over, hvorfor det første forslag ikke hjælper.

Registrér resolverstien

En forespørgsel sendt til en eksplicit valgt server og et programs almindelige opslag er forskellige eksperimenter. Angiv, hvilken der gav fejlen, fordi en manuel forespørgsel til en fungerende server kun beviser, at serveren virker. Kommandoerne nedenfor adskiller systemstien fra et direkte spørgsmål.

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

Statusoutputtet angiver serverne per link og routingdomænerne, hvilket er hvor split DNS bliver bestemt. getent-kaldet følger samme sti som programmet, inklusive nsswitch-rækkefølgen. Den direkte forespørgsel omgår begge og tester én server isoleret. Rapportér, hvilken af de tre der fejlede og hvilken der lykkedes, og læseren skal ikke længere gætte på stien.

Angiv den kontrollerede sammenligning

Ændr én variabel og sig, hvad der ændrede sig. At offentlige navne slår op, mens interne fejler, er et valgproblem; at hvert navn får timeout er et stiproblem; og et privat navn, der slår op til en offentlig adresse, er en lækage til den forkerte resolver. To af de tre har intet at gøre med, om tunnelen er oppe. En rapport, der hævder, at alle forespørgsler er i stykker, indeholder normalt en sammenligning, der aldrig blev kørt.

Adskil opløsning fra levering. Når navnet slår op, og webstedet stadig fejler, er DNS-trinnet lykkedes, og rapporten bør sige det, fordi næste trin er en rute eller en lytter frem for en resolver. Den ene skelnen sparer oftere en runde spørgsmål end noget loguddrag.

Slør navnerummet, behold relationerne

Interne navne kan erstattes, så længe erstatningerne bevarer strukturen. Knyt hver særskilt server og suffiks til en stabil etiket, og hold den kobling ude af den delte kopi. At erstatte hver intern vært med samme pladsholder ødelægger netop det bevis, rapporten har brug for, fordi læseren ikke længere kan se, at ét suffiks slog op og et andet ikke. Samme regel gælder for adresser: behold præfiksrelationerne, og ændr værtens bit, hvis politikken kræver det.

Send posten gennem den verificerede kanal, og udelad det, diagnosen aldrig har brug for. Adgangskoder, private nøgler og uvedkommende firmanavne er ikke en del af et DNS-spørgsmål. Det, læseren har brug for, er fejlkategorien, resolverstien, den præcise fejl og den ene sammenligning, du kørte.