Korta interna namn misslyckas på VPN: suffixet du aldrig ser
Ett kort namn fungerar bara därför att ett söksuffix kompletterar det. Jämför det fullständiga och det korta namnet för att skilja ett suffixgap från ett resolverfel.
Det korta namnet fungerade på kontoret och misslyckas på VPN, medan det fullständiga namnet löses utan problem. Inget är trasigt. Ett bart namn som intranet är inte ett fullständigt namn; klienten lägger till ett suffix från sin söklista och frågar efter resultatet. Om VPN-profilen inte levererar det suffixet slutar den välbekanta korta formen att existera.
Det är hela myten. DNS gick inte sönder, sökpolicyn ändrades.
Ett bart namn är inte ett namn
När du skriver en enda etikett måste resolvern bestämma vad den ska fråga efter. Den prövar namnet som det anges och lägger sedan till poster från söklistan en i taget tills något svarar. På Linux styr resolv.conf den ordningen med inställningarna search och ndots. På Windows gör suffixlistan och policyn för namnmatchning detsamma. Ta bort suffixet och resolvern har inget att lägga till.
Ett fungerande kort namn är därför bevis på en policy, inte bevis på en frisk DNS-server.
Vad suffixlistan och resolveradressen var för sig gör
Dessa två blandas ständigt ihop. Resolveradressen säger vem man ska fråga; suffixlistan säger vilket namn man ska fråga om. En VPN kan ge dig en privat resolver utan suffix, eller ett suffix med fel resolver. Bara ett av dessa fel ser ut som ett DNS-avbrott.
Kontrollera dem separat, eftersom att reparera det felaktiga kostar ett supportfönster.
| What you see | Likely cause |
|---|---|
| Full name resolves, short name fails | Suffix or search list missing |
| Neither resolves | Resolver unreachable or wrong domain rule |
| Both resolve, resource fails | Route or service permission |
Tre symtom, tre olika ansvariga.
Testa det fullständiga namnet först
Fråga efter administratörens dokumenterade fullständigt kvalificerade namn, inte en gissning. Ett fungerande FQDN bevisar att resolvern är nåbar och att posten finns, vilket tar bort hälften av de möjliga orsakerna med en enda fråga. Använd ett verktyg som visar vilken server som svarade, så att du inte läser ett cachelagrat resultat.
Håll testet privat. Att skicka interna varianter till en offentlig resolver avslöjar namn och testar en policy som ingen avsåg.
Var rättelsen hör hemma
Korrigera ägarprofilen eller hanteringssystemet som genererar den. En manuell ändring av den lokala resolverkonfigurationen försvinner oftast vid återanslutning, eller gäller för varje nätverk som maskinen ansluter till, vilket är värre.
På Windows, granska den effektiva policyn i stället för kryssrutan du minns. Get-DnsClientNrptPolicy visar de namnmatchande regler som faktiskt gäller.
På macOS skriver scutil --dns ut resolverkonfigurationen per avgränsat gränssnitt, inklusive de sökdomäner som VPN:en skickade.
På Linux, läs search-raden i /etc/resolv.conf, men kontrollera om en VPN-klient har skrivit om den. Om filen hanteras, redigera sanningskällan i stället för den renderade filen. En inaktuell search-rad kvar från ett tidigare nätverk är en vanlig orsak.
Vad du bör spara med profilen
Spara det korrigerade fullständiga namnet, suffixlistan och resolveradressen bredvid klientprofilen. Nästa person som rapporterar att intranetsidan ligger nere kan jämföra tre kända värden i stället för att börja på en tom sida.
Och om bara den korta formen misslyckas, säg det i ärendet. Den meningen sparar resolverteamet en eftermiddag.