Varför din /etc/hosts-post inte når VPN:ets DNS

Du lade till ett namn i /etc/hosts, anslöt VPN:et och förväntade dig att posten skulle synas för alla. Det gör den inte, och överraskningen kommer oftast med ett andra symptom: namnet slås upp på din maskin och misslyckas hos en kollega, vilket ser ut som en trasig VPN DNS-tjänst och egentligen är hosts-filen som gör precis det den är designad för. En hosts-fil är lokal namnmatchning, inte en zonuppdatering, och ingenting i en normal VPN-anslutning laddar upp den.

Hosts är en lokal överstyrning, inte en zonuppdatering

Filen är en lista med mappningar som namntjänstbibliotek konsulterar före, eller i stället för, att fråga en DNS-server. En rad som 10.40.0.20 build.corp.example ändrar vad program på den enda maskinen drar för slutsats. Den skapar ingen post, den färdas inte genom tunneln, och DNS-servern som tunneln pekar på har ingen aning om att den finns.

Därför är felet asymmetriskt. Din klient får ett svar från filen. En annan klient frågar VPN:ets DNS-server, som inte returnerar något, och programmet rapporterar att namnet inte finns. Båda maskinerna beter sig korrekt; bara en av dem har en överstyrning som den andra aldrig har sett.

Två kommandon, två olika komponenter

Det snabbaste sättet att avsluta diskussionen är att göra skillnaden synlig i två kommandon, båda körda på klienten som har hosts-posten:

getent ahosts build.corp.example
dig @10.40.0.53 build.corp.example A

Den första frågar systemets egen uppslagsväg, som på ett typiskt glibc-system läser lokala filer före DNS. Den andra skickar en DNS-fråga direkt till servern på den adressen och konsulterar inte lokala filer alls. När den första returnerar din post och den andra returnerar NXDOMAIN, har du bevisat att posten inte finns i DNS och att din maskin svarar från en lokal överstyrning.

Ordningen är konfigurerbar, och det är värt att kontrollera den innan du drar någon slutsats om en viss distribution. Titta på hosts:-raden i /etc/nsswitch.conf; hosts: files dns konsulterar filer först. Kopiera inte det exemplet över en fungerande konfiguration bara för att ändra ordningen, eftersom riktiga system ofta listar ytterligare källor och villkorade tjänsteposter som exemplet inte innehåller.

systemd-resolved grumlar testet

På ett system som använder systemd-resolved betjänar den lokala stubben också namn från hosts-databasen. Därför är en fråga till 127.0.0.53 inte ett oberoende test av fjärrservern, även om den ser ut som och beter sig som en DNS-fråga. Du kan bekräfta vad resolveraren vet och vilka servrar den skulle fråga med:

resolvectl query build.corp.example
resolvectl status

Statusutdata namnger DNS-servrarna per länk, och det är så du tar reda på om VPN-länken över huvud taget fick en resolver. Den frågan är skild från hosts-posten och är den som är värd att ställa när ett privat namn misslyckas för alla användare och inte för en.

Program kan lägga till ännu ett lager. En webbläsare med egen DNS-over-HTTPS-inställning, en container med egen resolverkonfiguration eller en körmiljö som cachar uppslag under processens hela livstid kan var och en svara annorlunda än systemet. Testa programmet du bryr dig om i stället för att anta att ett kommando beskriver varje program på maskinen.

Vad som egentligen delar ett namn genom VPN:et

Om ett privat namn ska fungera för alla behöver det en ägare som allas resolver kan nå. Det rena svaret är att publicera posten i en hanterad zon och göra den zonen upplösbar via VPN:ets avsedda DNS-väg. Då har posten en enda sanningskälla, ett granskningsspår och en livscykel, och ingen behöver komma ihåg vilken laptop som bär en lokal överstyrning.

Att distribuera hosts-filer är ett legitimt alternativ, och det är endpoint-hantering snarare än namntjänst. Om du väljer det måste filen rullas ut, versionshanteras och tas bort av det som hanterar flottan, och det bör beskrivas så i designen. ”VPN:et sköter det” är inte en beskrivning av den processen.

Dynamisk DNS-registrering är en tredje mekanism, med egna behörigheter, uppdateringsautentisering och postens livstid. Den följer inte av en hosts-post, och den följer inte heller av att en klient bara ansluter, om inte servern och klienten båda är konfigurerade för det. En post som dyker upp av sig själv är en signal om att någon har aktiverat säkra uppdateringar och en klient som registrerar sig själv, och den konfigurationen hör hemma i designposten och inte i en felsökningstråd. Om ingen kan namnge vem som äger den inställningen, behandla den automatiska posten som overifierad och håll den hanterade zonen som sanningskälla.

Ett uppslaget namn är inte en rutt

Namnmatchning och nåbarhet är åtskilda, och en inaktuell lokal mappning är det klassiska sättet att förväxla dem. En hosts-post som pekar på en adress som har flyttat kommer att fortsätta välja den inaktuella värden långt efter att DNS har rättats, och symptomet ser ut som ett routingfel på ett namn som slås upp fint.

Så när rapporten är ”namnet slås upp men tjänsten går inte att nå”, jämför systemuppslaget med en uttrycklig fråga till VPN:ets DNS-server och kontrollera sedan adressen du fick mot den som tjänsten faktiskt använder. systemd-resolved-referensen dokumenterar de lokala källor den konsulterar, och det är kartan du behöver för den jämförelsen.

Rätta sedan överstyrningen via dess ägare. Att ta bort en rad från din egen hosts-fil gör ingenting för de tolv laptops som fick samma rad från ett distributionsskript, och det är den versionen av problemet som folk faktiskt har.