Varför en privat Route 53-zon returnerar NXDOMAIN för offentliga namn

Privata Route 53-zoner ersätter svaret för ett namn i stället för att slå samman det med den offentliga posten, och det överraskar folk i det sämsta ögonblicket. Lägg till en intern post för api.example.net i en privat zon för example.net, koppla den till en VPC, och alla andra namn under den föräldern besvaras nu bara från den privata zonen. En klient som i går kunde nå www.example.net får i dag ett negativt svar. Genomgången nedan börjar vid den misslyckade frågan och arbetar utåt till zonen som svarade på den.

Börja vid frågan, inte vid konsolen

Reproducera felet på klienten som rapporterade det, och anteckna det exakta namnet och posttypen. Ett namn som misslyckas för A kan fortfarande lösas för AAAA, och en webbläsare som försöker igen med ett cachat namn döljer vilket av de två som gick sönder. Kör frågan två gånger: en gång via den resolver klienten faktiskt använder, och en gång med spårning som kringgår den.

dig +short api.example.net
dig www.example.net +noall +comments +authority
resolvectl query www.example.net

Det andra kommandot är det viktiga. Dess statusrad och auktoritetsavsnitt namnger zonen som producerade svaret, så du kan skilja ett negativt svar från den privata zonen från en timeout, en blockerad port eller en resolver som aldrig fick frågan. resolvectl visar vilken överordnad server som tillfrågades, och det är ofta inte den resolver du antog att VPN:n skickade.

Om den spårade frågan returnerar den offentliga adressen och den vanliga inte gör det, är den offentliga posten intakt och den privata vyn svarar. Den enda jämförelsen avgör vilken halva av resten av den här sidan som gäller för dig.

Läs vilken zon som svarade

Ett svar som bär NXDOMAIN med den privata zonens SOA i auktoritetsavsnittet är ett slutgiltigt svar från den zonen, inte en misslyckad uppslagning. Route 53 Resolver valde den privata värdbaserade zonen eftersom namnet matchade, hittade sedan ingen post av den efterfrågade typen, och det dokumenterade beteendet är att returnera det negativa svaret i stället för att vidarebefordra frågan till offentlig DNS.

Valet följer specificiteten. Med flera överlappande privata namnområden vinner den mest specifika matchande zonen, och en bredare privat förälder får ingen ny chans för ett namn som den valda underzonen inte har. Vidarebefordringsregler lägger till ett lager till, eftersom en domänspecifik Resolver-regel kan slå ut kopplingen till den privata värdbaserade zonen. Lista kopplingarna och reglerna innan du drar slutsatsen att en zon är tom.

aws route53 list-hosted-zones-by-name --dns-name example.net.
aws route53 list-resource-record-sets --hosted-zone-id Z0EXAMPLEID --query "ResourceRecordSets[?Type=='A'].[Name,ResourceRecords[0].Value]"

Båda kommandona kräver inloggningsuppgifter för kontot som äger zonen, och det andra behöver zon-ID:t från det första. Ersätt det med ditt eget; platshållaren ovan är medvetet inte riktig.

Varför den privata zonen vinner

Det är kopplingen som gör zonen synlig för en VPC, och resolvern i den VPC:n är det som tillämpar den. En privat zon som inte är kopplad till den VPC som klientens trafik kommer från har ingen effekt alls, medan en koppling till fel VPC ger ett privat svar till fel population. Kontrollera kopplingslistan innan du redigerar poster, eftersom en zon kan vara korrekt och ändå osynlig.

Överlappande namnområden är den andra källan till förvirring. En privat zon för example.net och en privat zon för api.example.net matchar båda en API-fråga, och den mest specifika svarar. Det är användbart när du vill ha ett smalt internt namnområde, och farligt när den smala zonen saknar en post som den bredare har. Övervägandena för privata värdbaserade zoner i Route 53-dokumentationen beskriver både genomfallsbeteendet och regelns företräde, och de är värda att läsa innan du lägger till en andra överlappande zon.

Inget av detta ändrar den offentliga zonen. Offentliga resolvrar svarar fortfarande korrekt på de offentliga posterna, och därför ser felet ut som ett klientproblem för alla utanför VPC:n.

Välj namnområdet innan du lägger till poster

Om bara en ny familj av interna tjänster behöver privata namn, ge den en egen privat underdomän och låt den offentliga föräldern vara. Ett namn som internal.example.net kan inte skugga www.example.net, och sprängradien för en saknad post begränsas till de namn du hittade på för ändamålet. Priset är att befintliga URL:er och certifikat kanske inte matchar det nya namnet.

När offentliga och privata användare måste behålla samma värdnamn är DNS med delad vy den stödda designen, och den kräver att du underhåller posterna i varje vy uttryckligen. En bred privat zon med en enda post bevarar inte de offentliga beroendena under zonen; den ersätter dem med en zon som har en post.

Inventera namnen som ett program faktiskt anropar innan du riktar en klientpopulation mot den privata vyn. Inloggningsvärdar, värdar för statiska resurser, omdirigeringsmål och API-slutpunkter går sönder först, och de är vanligtvis utspridda över flera teams poster.

Följ resolverns väg och sedan rutten

En bärbar dator ser bara den privata vyn om dess frågor når resolvern som har kopplingen. Att redigera en hosts-fil på VPN-servern publicerar ingenting till anslutna klienter, och en klient konfigurerad med en offentlig resolver fortsätter att få offentliga svar så länge tunneln är uppe. Bekräfta resolveradressen som klienten fick och upprepa sedan frågan från klienten i stället för från servern.

När namnet har lösts upp testar du vägen till den returnerade adressen som ett eget steg, till exempel med ip route get mot adressen som frågan returnerade. Ett korrekt privat svar utan väg till adressen är ett routingproblem, och ett svar om en saknad post är ett DNS-vyproblem; att behandla dem som ett problem ger rättelser som inte håller. Låt tjänstens TLS-värdnamn och certifikatkontroller vara oförändrade, eftersom en privat adress ändrar vart anslutningen går och ingenting om vilket certifikat som är giltigt.

Avsluta med att anteckna zonen, kopplingen, resolvern och namnen du verifierade i ändringsanteckningen. Då vet nästa person som lägger till en post vilket namnområde som är auktoritativt för den klientpopulationen.