Split-DNS-fångst: säg var varje observation gjordes

Två personer felsöker samma Split-DNS-problem och får olika resolver-adresser. En använde ett sökverktyg, en fångade paket på adaptern och en tredje läste klientens egen diagnostik. Ingen av dem ljuger, och ingen beskriver samma steg. Att namnge observationspunkten förvandlar en motsägelse till en karta.

Ett uppslag, flera observationspunkter

För ett internt namn finns minst fem ställen att titta på: applikationen och det resolver-API den anropar, den gällande domänpolicyn på klienten, en fångst på adaptern eller filtret, en kontrollerad gateway-gräns och resolvern som faktiskt tar emot frågan.

Var och en svarar på en annan fråga, och ingen av dem ensam bevisar vart frågan tog vägen.

En fångst på adaptern visar paket, inte avsikt. Den säger inte vilken resolver klienten valde, och en tom fångst kan betyda ett cachat svar eller ett annat resolver-API i stället för ett tappat paket. Behandla varje observation som bevis för ett steg. Sätt sedan ihop stegen till en väg.

Klientens filter sitter mellan app och ledning

En VPN-klient med Split-DNS tillämpar domänmatchning innan paketet lämnar maskinen. Namn i det tunnlade suffixet går till den interna resolvern; allt annat går till den lokala. Filtret är policy, och policyn kan variera beroende på plattform och klientversion.

Secure Clients vägledning för Split-DNS från Cisco täcker domänmatchning och Windows-filtret, och den skiljer det en app ser när den använder det inbyggda resolver-API:t från det ett verktyg som nslookup ser. Det är just de skillnaderna som är poängen.

Börja med den gällande profilen och ett vanligt applikationsuppslag. Varje test som namnger en specifik server är en avsiktlig omväg; förklara den med klientens egen diagnostik och låt den inte bli acceptanskriteriet.

nslookup tar en annan väg än appen

nslookup bygger sin egen DNS-fråga och kan kringgå operativsystemets resolverpolicy. Det gör det till ett användbart verktyg för att ställa en bestämd fråga till en bestämd server, och ett vilseledande verktyg för att testa vad en applikation kommer att uppleva.

I Windows avgör tabellen för namnupplösningspolicy vilket suffix som använder vilken server. Att läsa den visar den policy som applikationen kommer att följa, och det är ofta den saknade biten.

Läs policyn och ställ sedan samma fråga via den vanliga resolvern:

Get-DnsClientNrptPolicy
Resolve-DnsName intranet.hq.example

Krypterade resolvers döljer frågan, inte anslutningen

En webbläsare med egen DNS-over-HTTPS-resolver är ett helt annat fall. Frågan går ut inuti TLS, så en paketfångst visar en anslutning till en resolver-adress men inte namnet som efterfrågas.

Ta först reda på webbläsarens hanterade policy och jämför den sedan med ett uppslag från operativsystemet. En webbläsare som får välja sin egen resolver kanske aldrig ser Split-DNS-policyn alls.

Samma försiktighet gäller för varje klient som levererar sin egen resolver. En fångst som identifierar fjärranslutningen är inte bevis för frågenamnet. Om du behöver namnet, hämta det från resolverns egna loggar eller från applikationens diagnostik, med de integritetsregler som gäller.

Jämför med ett märkt test

Välj ett godkänt internt namn för testet, plus ett offentligt namn utan känslig betydelse. För var och en noterar du tiden, posttypen, svaret och den policy du förväntade dig.

Där det är tillåtet, jämför resolverns mottagande med en enda snäv observation från klient eller gateway:

nslookup intranet.hq.example 10.55.0.53
Get-DnsClientNrptPolicy | Format-List

Skicka aldrig privata namn till orelaterade offentliga resolvers bara för att skapa en jämförelse, och redigera allt du delar. Till sist, skilj ett korrekt DNS-svar från tjänsteanslutningen som följer: den uppslagna privata adressen behöver fortfarande en rutt och ett applikationstillstånd.