Din VPN skjuter ut tre DNS-servrar: vilken svarar?

Öppna inställningssidan efter anslutning och tre DNS-adresser listas; revisionsfrågan är vilken som hanterade din senaste fråga. Enbart antalet svarar inte på något, eftersom en klientputt, ett fysiskt gränssnitt och en princip per domän alla skriver i samma vy. Posterna bär olika omfång, och det är omfånget, inte positionen, som avgör vem som svarar. Börja med att skilja källorna åt och testa sedan den som äger namnet du bryr dig om.

Varför listan är längre än din profil

En VPN-klient skjuter ut resolveradresser för tunnellänken, och operativsystemet håller dem bredvid det som det fysiska gränssnittet redan hade. En router, en företags-DHCP-lease, en andra VPN och en princip per domän bidrar var och en med sin egen post. Tre adresser på sidan kan därför betyda tre omfång i stället för tre kandidater för en uppgift. Att läsa antalet som bevis på en läcka är det första felet i denna revision.

Inom ett gränssnitt försöker en klient faktiskt sina servrar i ordning, så en ordnad lista är inte meningslös. Det som inte är en kö är den sammanslagna vyn, där poster från profilen, den fysiska länken och regler per domän står sida vid sida utan en enda rangordning. Den skillnaden avgör vad du testar: ordningen förklarar beteendet inom ett omfång, och omfånget förklarar allt annat.

Krypterad DNS bryter bilden inifrån en applikation. En webbläsare eller chattklient med egen DNS-over-HTTPS-resolver skickar frågor helt förbi operativsystemets lista, så adresserna på inställningssidan beskriver trafik som appen aldrig genererade. Kontrollera appens egen resolverinställning innan du skyller profilen för ett namn som blev fel.

Vad var och en av de tre kontrollerna säger

Varje källa lämnar sitt spår på en annan plats, och inget enskilt kommando visar dem alla. Detta är mappningen som är värd att ha vid inställningssidan:

På ett system som använder systemd-resolved är resolvectl status auktoritativ, eftersom den rapporterar DNS per länk tillsammans med routningsdomänerna. macOS svarar via scutil --dns, som listar resolvrar med omfång i den ordning de provas. Windows delar de två halvorna: Get-DnsClientServerAddress för servrar per gränssnitt och Get-DnsClientNrptPolicy för suffixreglerna. Kör kommandot som hör till den resolver som faktiskt används, för en maskin med containerruntime och en skrivbordsresolver kan ha mer än en installerad.

En reservresolver som inte kan svara för din zon

En andra post finns vanligtvis för tillgänglighet, och tillgänglighet fungerar bara om reserven känner till namnen. Fråga en offentlig resolver om ett internt värdnamn och den returnerar NXDOMAIN, eller ett jokerteckensvar från en sökdomän som inte har något med dig att göra. En failover som ingen kontrollerade ger då ett avbrott precis i det ögonblick den behövs.

Split DNS finns för att förhindra det: företagets suffix går till en resolver som håller zonen, och offentliga namn stannar på standardvägen. Designen är solid, och den beror på att suffixlistan är komplett. Microsoft dokumenterar resolverprincipen per suffix som driver detta på Windows, och samma idé dyker upp som routningsdomäner i systemd-resolved och som resolvrar med omfång på macOS.

Jämför de zoner som reserven får svara för med de suffix som finns i principen. Den jämförelsen hittar luckan innan en användare rapporterar att en intern webbplats slutade slås upp efter en tunneländring.

Fråga genom principen, inte förbi den

Fråga genom operativsystemets resolver, eftersom en direkt fråga till en server kringgår principen och bara rapporterar vad den servern skulle säga. Skillnaden mellan de två svaren är hela poängen:

resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53

Om systemfrågan returnerar en privat adress medan den direkta frågan returnerar NXDOMAIN, fungerar principen och reserven är den svaga punkten. Om båda returnerar samma offentliga svar, slås namnet upp utanför det omfång du avsåg, och suffixlistan är stället att titta på. Spara båda utdata, för en resolverdiskussion avgörs snabbare med två rader än med en skärmbild av inställningssidan.

Öva sedan felvägen, för en reserv som ingen testat är ett antagande. Gör den föredragna resolvern till ett svart hål för en fråga och se vilken adress som kommer tillbaka:

ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32

Radera den vägen så snart frågan är klar, annars ärver nästa person ett mysterium. Om interna namn fortfarande slås upp i det fönstret har något utanför det avsedda omfånget svarat på dem. Om de i stället får tidsutgång saknas reserven eller så är den korrekt avgränsad, och resolverns egen logg berättar vilken av de två det var.

Bestäm: behåll, avgränsa eller ta bort

Behåll en andra resolver när den svarar på namnrymden du behöver och förblir nåbar under profilen. Avgränsa den när den bara ska se ett suffix och inget annat, och ta bort den när den varken har ett omfång eller ett dokumenterat syfte. En post utan arbete är en framtida läcka utan nytta, och en leverantörsstandard är inte ett syfte.

Registrera resultatet som fyra kolumner: suffix, resolver, gränssnitt och ägare. Den raden svarar på nästa revisionsfråga snabbare än någon skärmbild, och den överlever klientuppdateringen som tyst ordnar om listan.