Privat DNS fungerar i VPC:n men inte över VPN:en
Ett privat namn som löses ut i EC2 men inte över VPN:en är ett problem med resolvervägen. Läs felformen innan du redigerar zonposten.
Ett privat namn löses ut från en EC2-instans men inte från en laptop som är ansluten via VPN:en, och zonen ser korrekt ut i konsolen. Instinkten är att redigera posten, vilket nästan aldrig är problemet. Posten svarar någon; den svarar bara inte din laptop. Det som skiljer de två anroparen åt är vilken resolver de frågar, och om den resolvern har en stödd väg in i VPC:ns DNS-vy.
Jag börjar med att bevisa att posten finns och lägger resten av tiden på frågevägen. Det är separata system, och de fallerar på olika sätt.
Läs felformen innan du ändrar något
Tre utfall betyder tre olika saker, och en enda fråga skiljer dem åt: kör dig för namnet mot den resolver som klienten faktiskt använder.
| What you see | What it usually means | First thing to check |
|---|---|---|
| SERVFAIL, or a timeout after several seconds | No path to the resolver, or the resolver cannot reach AWS | Route to the endpoint and the security policy on port 53 |
| NXDOMAIN from a resolver that did answer | The resolver replied, but the zone is not in its view | Zone association or the forwarding rule for that namespace |
| A public address for an internal name | Split DNS is not in effect for this client | Which resolver the client is configured to use |
En timeout är ett uttalande om nätverket. NXDOMAIN är ett uttalande om DNS-vyn. Ett offentligt svar är ett uttalande om policyn. Den som redigerar en zonpost medan det råder timeout kastar bort det enda användbara beviset i fallet.
Varför VPC:ns plus-två-adress inte är en fjärrresolver
CIDR-plus-två-adressen är en lokal tjänst för resurser inne i VPC:n. AWS dokumenterar att vidarebefordran av frågor från lokala nätverk, eller från en annan VPC:s DNS-servrar, direkt till den adressen inte stöds och kan ge instabila resultat.
Det betyder inte att ett experiment aldrig verkar fungera. Det betyder att beteendet inte är ett kontrakt som du kan lägga i ett helpdesk-skript. Den stödda riktningen är en inkommande Resolver-endpunkt: ett adresspar inne i din VPC, nåbart från nätverket du kontrollerar, som tar emot frågor som kommer utifrån AWS.
Bygg vägen i den ordning som fallerar rent
Tre hopp måste finnas, och varje hopp har sitt eget sätt att fallera.
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesVidarebefordraren behöver en väg till slutpunktsadresserna genom VPN:en, och returvägen måste också fungera. För konventionell DNS på port 53 svarar slutpunkten över UDP och TCP, så båda protokollen måste vara tillåtna, och båda måste överleva en tillståndskänslig inspektion i mitten.
Kontrollera sedan DNS-vyn separat. En privat hostad zon är bara synlig för de VPC:er den är kopplad till, eller genom en medveten delningsordning. En nåbar slutpunkt gör inte i sig själv varje privat zon upplösbar i sin upplösningskontext.
En utgående slutpunkt tjänar motsatt riktning och svarar inte på en fråga som kommer in från din laptop.
Verifiera från båda ändarna
Fråga från klienten mot vidarebefordraren och sedan från vidarebefordraren mot slutpunkten. Om klienten fallerar medan vidarebefordraren lyckas ligger gapet mellan de två.
Om båda fallerar, titta på säkerhetspolicyn på slutpunkten och på källadressen den faktiskt ser. En vidarebefordran bakom NAT presenterar NAT-adressen i stället för laptopens VPN-adress, och den skillnaden räcker i sig för att släppa frågan. Om båda lyckas men applikationen ändå fallerar kan applikationen använda en annan resolver än den du testade.
Håll de offentliga och privata namnrymderna åtskilda med avsikt. Split DNS är en policy du konfigurerar, inte en bieffekt av att en enskild uppslagning råkar returnera data.
Vad jag inte skulle göra
Jag skulle inte lägga till en NAT-regel som fick en enskild uppslagning att fungera och kalla det en design.
Jag skulle inte peka varje fjärrklient mot plus-två-adressen för att ett test en gång returnerade en post. Och jag skulle inte vidga slutpunktens säkerhetspolicy till hela VPN-poolen när en enda vidarebefordran behöver åtkomst. Kör organisationen redan en godkänd vidarebefordran inne i VPC:n, läs den designen först, för den andra slutpunkten du lägger till är den som ingen dokumenterar.