VPN-DNS-rapport: hva som må være med for at den skal kunne gjengis

«DNS er ødelagt» er en konklusjon, og det er ikke en konklusjon en hjelper kan handle ut fra. Den brukbare delen av en rapport er feilens form: hvilket navn, gjennom hvilken resolver, med hvilket svar. Tre detaljer gjør en klage reproduserbar, og alle tre er trygge å dele når de private delene er omdøpt. Det følgende er minimumet en VPN-DNS-rapport trenger før noen kan hjelpe.

En kategori av navn, ikke en dom

Begynn med selve navnet og klassifiser det: offentlig, internt, kort, fullt kvalifisert eller betjent av ett bestemt suffiks. Et internt navn som feiler mens offentlige navn løses opp, peker på valg av resolver og ikke på tilgjengelighet. Hvis alle navn feiler, peker det på stien til resolveren, og det er en annen undersøkelse med andre bevis. Kategorien bærer diagnosen, og den eksakte strengen kan skjules.

Si om feilen krever at tunnelen er oppe, eller om den skjer etter at den kobles fra. Et navn som bare brytes mens VPN er aktivt, impliserer konfigurasjonen per lenke, mens et som brytes etter frakobling, impliserer gjenværende tilstand. Rapporter utelater dette ofte og lurer deretter på hvorfor det første forslaget ikke hjelper.

Noter resolverstien

En forespørsel sendt til en eksplisitt valgt server og en applikasjons vanlige oppslag er forskjellige eksperimenter. Si hvilken som ga feilen, fordi en manuell forespørsel til en fungerende server bare beviser at serveren fungerer. Kommandoene nedenfor skiller systemstien fra et direkte spørsmål.

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

Statusutdataene navngir serverne per lenke og rutedomenene, altså der split DNS avgjøres. getent-kallet følger samme sti som applikasjonen, inkludert nsswitch-rekkefølgen. Den direkte forespørselen omgår begge og tester én server isolert. Rapporter hvilken av de tre som feilet og hvilken som lyktes, og leseren slipper å gjette på stien.

Oppgi den kontrollerte sammenligningen

Endre én variabel og si hva som endret seg. At offentlige navn løses opp mens interne feiler, er et valgproblem; at hvert navn går i timeout, er et stiproblem; og et privat navn som løses til en offentlig adresse, er en lekkasje til feil resolver. To av disse tre har ingenting å gjøre med om tunnelen er oppe. En rapport som hevder at alle forespørsler er ødelagte, inneholder vanligvis en sammenligning som aldri ble kjørt.

Skill oppløsning fra levering. Når navnet løses og nettstedet likevel feiler, lyktes DNS-trinnet, og rapporten bør si det, fordi neste trinn er en rute eller en lytter og ikke en resolver. Den ene forskjellen sparer oftere en runde med spørsmål enn noe loggutdrag.

Skjul navnerommet, behold relasjonene

Interne navn kan erstattes så lenge erstatningene bevarer strukturen. Knytt hver enkelt server og suffiks til en stabil etikett, og hold den koblingen utenfor den delte kopien. Å erstatte hver intern vert med samme plassholder ødelegger nettopp beviset rapporten trenger, fordi leseren ikke lenger kan se at ett suffiks ble løst og et annet ikke. Samme regel gjelder adresser: behold prefiksrelasjonene og endre vertsbitene hvis policyen krever det.

Send posten gjennom den verifiserte kanalen og utelat det diagnosen aldri trenger. Passord, private nøkler og urelaterte firmanavn er ikke en del av et DNS-spørsmål. Det leseren trenger, er feilkategorien, resolverstien, den eksakte feilen og den ene sammenligningen du kjørte.