VPN-DNS-rapport: wat erin moet staan om het reproduceerbaar te maken

„DNS is kapot“ is een conclusie, en het is niet een conclusie waarop een helper kan handelen. Het bruikbare deel van een rapport is de vorm van de fout: welke naam, via welke resolver, met welk antwoord. Drie details maken van een klacht iets reproduceerbaars, en alle drie zijn veilig te delen zodra de privéonderdelen zijn hernoemd. Wat volgt is het minimum dat een VPN-DNS-rapport nodig heeft voordat iemand kan helpen.

Een categorie van naam, geen vonnis

Begin met de naam zelf en classificeer hem: openbaar, intern, kort, volledig gekwalificeerd of door één specifiek suffix bediend. Een interne naam die faalt terwijl openbare namen oplossen wijst op resolverselectie en niet op bereikbaarheid. Als elke naam faalt, wijst dat op het pad naar de resolver, en dat is een ander onderzoek met ander bewijs. De categorie draagt de diagnose, en de exacte string kan worden verborgen.

Zeg of de fout vereist dat de tunnel actief is, of dat hij optreedt nadat die is losgekoppeld. Een naam die alleen breekt terwijl de VPN actief is, impliceert de configuratie per verbinding, terwijl een naam die na het loskoppelen breekt achtergebleven toestand impliceert. Rapporten laten dit meestal weg en vragen zich dan af waarom de eerste suggestie niet helpt.

Noteer het resolverpad

Een query naar een expliciet gekozen server en de gewone opzoeking van een applicatie zijn verschillende experimenten. Zeg welke van de twee de fout veroorzaakte, want een handmatige query naar een werkende server bewijst alleen dat de server werkt. De opdrachten hieronder scheiden het systeempad van een directe vraag.

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

De statusuitvoer noemt de servers per verbinding en de routingdomeinen, namelijk waar split DNS wordt besloten. De getent-aanroep volgt hetzelfde pad als de applicatie, inclusief de nsswitch-volgorde. De directe query omzeilt beide en test één server geïsoleerd. Meld welke van de drie faalde en welke slaagde, en de lezer hoeft het pad niet meer te raden.

Vermeld de gecontroleerde vergelijking

Verander één variabele en zeg wat er veranderde. Dat openbare namen oplossen terwijl interne falen is een selectieprobleem; dat elke naam een time-out krijgt is een padprobleem; en een privénaam die naar een openbaar adres oplost is een lek naar de verkeerde resolver. Twee van die drie hebben niets te maken met of de tunnel actief is. Een rapport dat beweert dat alle queries kapot zijn, bevat meestal een vergelijking die nooit is uitgevoerd.

Scheid resolutie van aflevering. Wanneer de naam oplost en de site toch faalt, is de DNS-fase geslaagd en het rapport zou dat moeten zeggen, want de volgende stap is een route of een listener en niet een resolver. Dat ene onderscheid bespaart vaker een ronde vragen dan welk logfragment dan ook.

Verberg de naamruimte, behoud de relaties

Interne namen kunnen worden vervangen, zolang de vervangingen de structuur behouden. Koppel elke afzonderlijke server en elk suffix aan een stabiel label, en houd die koppeling buiten de gedeelde kopie. Elke interne host door dezelfde plaatsaanduiding vervangen vernietigt precies het bewijs dat het rapport nodig heeft, omdat de lezer niet meer kan zien dat het ene suffix wel oploste en het andere niet. Dezelfde regel geldt voor adressen: behoud de prefixrelaties en wijzig de hostbits als het beleid dat vereist.

Stuur het record via het geverifieerde kanaal en laat weg wat de diagnose nooit nodig heeft. Wachtwoorden, privésleutels en ongerelateerde bedrijfsnamen maken geen deel uit van een DNS-vraag. Wat de lezer nodig heeft, is de foutcategorie, het resolverpad, de exacte fout en de ene vergelijking die je hebt uitgevoerd.