Testa delad DNS utan att läcka interna namn

Att fråga en offentlig resolver om ett internt namn läcker namnet och hoppar över regeln du ville testa. Frågan når en server du inte kontrollerar, svaret kommer från ett namnområde som inte borde ha sett det, och resultatet säger ingenting om huruvida delad DNS fungerar. Att testa delad DNS innebär att testa den resolverväg som en applikation faktiskt använder. Den vägen väljs av operativsystemet, av domänlistan i VPN-profilen och ibland av webbläsaren.

Välj två namn och förutsäg båda svaren först

Be nätverkets ägare om ett dokumenterat internt testnamn och välj ett vanligt offentligt namn som inte säger något om organisationen. Skriv ned vad som borde hända för vart och ett innan du kör något: det interna namnet borde nå tunnelns resolver och returnera en intern adress, medan det offentliga namnet borde lösas via den resolver som systemet normalt använder. De två förutsägelserna är själva testet, för utan dem kan varje svar bortförklaras i efterhand. Håll paret fast mellan körningar så att en senare jämförelse betyder något.

Kontrollera de faktiska reglerna, inte de avsedda. Domänlistan som är kopplad till VPN-anslutningen avgör vilka suffix som går till vilken resolver, och ett stavfel i den listan ger en trovärdig men felaktig delning. På en hanterad enhet, använd administratörens diagnostiska väg, eftersom lokala åsidosättningar kan återställas av policy vid nästa kontroll.

Skriv förutsägelsen bredvid det observerade svaret i samma ärende. Ett test utan förutsägelse kan inte misslyckas, och ett test som inte kan misslyckas lär ingenting.

Testa den väg applikationen använder, inte en server du själv valde

Ett kommando som namnger en resolver uttryckligen testar den resolvern och ingenting annat. Det berättar om den interna servern svarar, vilket är användbart, och det berättar inte om en applikation skickar namnet dit. Testa först via den normala vägen: lös det interna namnet som en applikation skulle göra och lös därefter det offentliga namnet på samma sätt. Först efter det ska du fråga specifika servrar för att hitta var beteendet skiljer sig.

Webbläsare komplicerar bilden, eftersom inställningar för säker DNS helt kan kringgå systemets resolver. En webbläsare som är konfigurerad med sin egen krypterade resolver ser aldrig delningen, och felet ser ut som en trasig VPN-profil. Kontrollera den inställningen innan du ändrar tunneln.

Upprepa sökningen efter återanslutning om frågan är återställning. Ett svar som cachats från före återanslutningen kan få en korrekt återställd delning att se bättre eller sämre ut än den är.

Registrera svarskategorin, inte bara framgång eller misslyckande

Skriv ned vilket av fyra saker som hände: en intern adress, en offentlig adress, ett negativt svar eller en timeout. Var och en betyder något annat. En intern adress för det interna namnet är den förväntade framgången; en offentlig adress för ett internt namn tyder på att frågan lämnade tunneln; ett negativt svar från den auktoritativa servern pekar på en saknad post snarare än ett routingfel; och en timeout tyder på ett nåbarhetsproblem eller en resolver som aldrig fick frågan. Framgång och misslyckande är för grova att agera på.

Ta hänsyn till cachen innan du tolkar en saknad färsk fråga, eftersom ett negativt svar i cachen ser identiskt ut med ett namn som inte finns. Fånga svaret innan du rensar något via stödda kontroller, eftersom det första svaret är beviset.

Tolka de två grenarna utan att gissa

Om det interna namnet löses korrekt och applikationen fortfarande misslyckas, gjorde resolvern sitt jobb och nästa misstänkta är rutter och behörigheter på själva resursen. Om det privata namnet nådde en offentlig resolver tillämpas inte delningsregeln på den sökningen, så granska domänlistan och eventuell webbläsarpolicy tillsammans med ägaren av namnområdet. De två grenarna har olika ägare, och därför är det viktigare att registrera vilken du såg än att registrera att något gick sönder.

Dölj känsliga uppgifter i delad utdata men behåll strukturen: vilket namnområde, vilken regel, vilken svarskategori. Ett resolversvar kan innehålla interna adresser och värdnamn, och ett ärende är ett varaktigt hem för båda.

Lämna sedan resultatet till ägaren av namnområdet med de två kategorierna du observerade och namnen borttagna. Det är ett samtal på fem minuter i stället för en vecka av spekulation.