VPN-DNS-rapport: vad den bör innehålla för att kunna återskapas

”DNS är trasigt” är en slutsats, och det är inte en slutsats som en hjälpare kan agera på. Den användbara delen av en rapport är felets form: vilket namn, genom vilken resolver, med vilket svar. Tre detaljer gör ett klagomål reproducerbart, och alla tre är säkra att dela när de privata delarna har bytt namn. Det följande är det minimum som en VPN-DNS-rapport behöver innan någon kan hjälpa.

En kategori av namn, inte en dom

Börja med själva namnet och klassificera det: offentligt, internt, kort, fullt kvalificerat eller betjänat av ett visst suffix. Ett internt namn som misslyckas medan offentliga namn löses upp pekar på val av resolver och inte på nåbarhet. Om alla namn misslyckas pekar det på vägen till resolvern, och det är en annan undersökning med andra bevis. Kategorin bär diagnosen, och den exakta strängen kan döljas.

Säg om felet kräver att tunneln är uppe eller inträffar efter att den kopplas från. Ett namn som bara bryts medan VPN är aktivt tyder på konfigurationen per länk, medan ett som bryts efter frånkoppling tyder på kvarvarande tillstånd. Rapporter utelämnar ofta detta och undrar sedan varför det första förslaget inte hjälper.

Anteckna resolvervägen

En fråga som skickas till en uttryckligen vald server och ett programs vanliga uppslag är olika experiment. Säg vilken som gav felet, eftersom en manuell fråga till en fungerande server bara bevisar att servern fungerar. Kommandona nedan skiljer systemvägen från en direkt fråga.

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

Statusutdata namnger servrarna per länk och routningsdomänerna, det vill säga där split DNS avgörs. getent-anropet följer samma väg som programmet, inklusive nsswitch-ordningen. Den direkta frågan kringgår båda och testar en server isolerat. Rapportera vilken av de tre som misslyckades och vilken som lyckades, och läsaren slipper gissa vägen.

Ange den kontrollerade jämförelsen

Ändra en variabel och säg vad som ändrades. Att offentliga namn löses upp medan interna misslyckas är ett urvalsproblem; att varje namn får timeout är ett vägproblem; och ett privat namn som löses till en offentlig adress är en läcka till fel resolver. Två av dessa tre har ingenting att göra med om tunneln är uppe. En rapport som hävdar att alla frågor är trasiga innehåller oftast en jämförelse som aldrig kördes.

Skilj upplösning från leverans. När namnet löses och webbplatsen ändå misslyckas har DNS-steget lyckats och rapporten bör säga det, eftersom nästa steg är en rutt eller en lyssnare och inte en resolver. Den enda skillnaden sparar oftare en runda frågor än något loggutdrag.

Dölj namnrymden, behåll relationerna

Interna namn kan ersättas så länge ersättningarna bevarar strukturen. Koppla varje enskild server och varje suffix till en stabil etikett, och håll den kopplingen utanför den delade kopian. Att ersätta varje intern värd med samma platshållare förstör precis det bevis rapporten behöver, eftersom läsaren inte längre kan se att ett suffix löstes och ett annat inte. Samma regel gäller adresser: behåll prefixrelationerna och ändra värdbitarna om policyn kräver det.

Skicka posten genom den verifierade kanalen och utelämna det som diagnosen aldrig behöver. Lösenord, privata nycklar och orelaterade företagsnamn ingår inte i en DNS-fråga. Det läsaren behöver är felkategorin, resolvervägen, det exakta felet och den enda jämförelse du gjorde.