Wêrom't in privee Route 53-sône NXDOMAIN jout foar publike nammen

Privee Route 53-sônes ferfange it antwurd foar in namme ynstee fan it mei de publike record tegearjen, en dat ferrast minsken op it minste momint. Foegje ien ynterne record ta foar api.example.net yn in privee sône foar example.net, keppelje dy oan in VPC, en elk oar namme ûnder dat âlder antwurdet no allinnich út de privee sône. In klant dy't juster www.example.net berikke koe, krijt hjoed in negatyf antwurd. De trochgong hjirûnder begjint by dy mislearre fraach en wurket nei bûten ta de sône dy't der antwurd op joech.

Begjin by de fraach, net by de konsole

Reprodusearje de flater op 'e klant dy't it meldde, en notearje de krekte namme en it recordtype. In namme dy't foar A mislearret, kin noch wol foar AAAA oplosse, en in browser dy't in cachet namme opnij besiket, ferberget hokker fan beide stikken is. Fier de fraach twa kear út: ien kear fia de resolver dy't de klant echt brûkt, en ien kear mei in tracing dy't dy omsile.

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

It twadde kommando is it wichtige. De statusrigel en de authority-seksje neame de sône dy't it antwurd makke, sadat jo in negatyf antwurd út 'e privee sône ûnderskiede kinne fan in timeout, in blokkearre poarte of in resolver dy't de fraach nea krige. resolvectl lit sjen hokker upstream frege is, en dat is faak net de resolver dêr't jo fan oannaam dat de VPN dy stjoerde.

As de traced fraach it publike adres weromjout en de normale fraach net, is de publike record yntakt en antwurdet de privee werjeft. Dy iene ferliking beslút hokker helte fan 'e rest fan dizze side op jo fan tapassing is.

Lês hokker sône antwurde

In antwurd dat NXDOMAIN befettet en de SOA fan 'e privee sône yn 'e authority-seksje hat, is in definityf antwurd fan dy sône, net in mislearre syktocht. Route 53 Resolver keas de privee hosted sône om't de namme oerienkaam, fûn doe gjin record fan it frege type, en it dokumintearre gedrach is it negative antwurd weromjaan ynstee fan 'e fraach troch te stjoeren nei publike DNS.

De seleksje folget spesifisiteit. By ferskate oerlaapjende privee nammeromten wint de meast spesifike oerienkommende sône, en in breder privee âlder krijt gjin twadde kâns foar in namme dy't de keazen bernesône net hat. Trochstjoerregels foegje noch in laach ta, om't in domeinspecifike Resolver-regel it keppeljen fan 'e privee hosted sône oerwinne kin. List de keppelings en regels op foardat jo konkludearje dat in sône leech is.

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]"

Beide kommando's hawwe tagongsbewiis nedich foar it akkount dat de sône besit, en it twadde hat de sône-ID fan it earste nedich. Ferfange dat troch dyn eigen ID; it plakhâlder hjirboppe is mei opsetsin net echt.

Wêrom't de privee sône wint

De keppeling is wat de sône sichtber makket foar in VPC, en de resolver yn dy VPC is wat it tapast. In privee sône dy't net keppele is oan 'e VPC dêr't it ferkear fan 'e klant wei komt, hat hielendal gjin effekt, wylst in keppeling mei de ferkearde VPC in privee antwurd foar de ferkearde populaasje jout. Kontrolearje de keppelingslist foardat jo records bewurkje, want in sône kin goed wêze en dochs ûnsichtber.

Oerlaapjende nammeromten binne de twadde boarne fan betizing. In privee sône foar example.net en in privee sône foar api.example.net komme beide oerien mei in API-fraach, en de meast spesifike antwurdet. Dat is nuttich as jo in smel yntern nammeromte wolle, en gefaarlik as de smelle sône in record mist dy't de bredere hat. De oerwagings oer privee hosted sônes yn 'e Route 53-dokumintaasje beskriuwe sawol it trochfâlgedrach as de foarrang fan regels, en se binne it lêzen wurdich foardat jo in twadde oerlaapjende sône tafoegje.

Neat hjirfan feroaret de publike sône. Publike resolvers antwurdzje de publike records noch altyd korrekt, en dêrom liket de flater foar elkenien bûten de VPC as in klantprobleem.

Kies it nammeromte foardat jo records tafoegje

As allinnich in nije famylje fan ynterne tsjinsten privee nammen nedich hat, jou it dan in tawijde privee subdomein en lit it publike âlder gewurde. In namme lykas internal.example.net kin www.example.net net oerskade, en de ynfloedsirkel fan in ûntbrekkende record bliuwt beheind ta nammen dy't jo foar dat doel betocht hawwe. De kosten binne dat besteande URL's en sertifikaten miskien net by de nije namme passe.

As publike en privee brûkers deselde hostnamme hâlde moatte, is split-view DNS it stipe ûntwerp en it freget dat jo de records yn elke werjeft eksplisyt ûnderhâlde. In brede privee sône mei ien record deryn bewarret de publike ôfhinklikens ûnder dy sône net; it ferfangt se troch in sône mei ien record.

Ynfintarisekje de nammen dy't in applikaasje echt opropt foardat jo in klantpopulaasje nei de privee werjeft rjochtsje. Ynloghosts, hosts foar statyske besittings, trochstjoerdoelen en API-einpunten brekke it earst, en se binne meastentiids oer de records fan ferskate teams ferspraat.

Folgje it paad fan de resolver, dan de rûte

In laptop sjocht de privee werjeft allinnich as syn fragen de resolver berikke dy't de keppeling hat. It bewurkjen fan in hosts-bestân op 'e VPN-tsjinner publisearret neat oan ferbûne klanten, en in klant dy't mei in publike resolver konfigurearre is, sil publike antwurden bliuwe krijen salang't de tunnel omheech is. Befêstigje it resolveradres dat de klant krige, en werhelje dan de fraach fan 'e klant ôf ynstee fan fan 'e tsjinner ôf.

As de namme ienris oplost, test dan it paad nei it weromjûn adres as in aparte stap, bygelyks mei ip route get tsjin it adres dat de fraach weromjoech. In korrekt privee antwurd sûnder rûte nei it adres is in routingprobleem, en in antwurd oer in ûntbrekkende record is in DNS-werjeftprobleem; se as ien kwestje behannelje jout reparaasjes dy't net hâlde. Lit de kontrôles fan 'e TLS-hostnamme en it sertifikaat fan 'e tsjinst ûnferoare, want in privee adres feroaret wêr't de ferbining hinne giet en neat oer hokker sertifikaat jildich is.

Einigje troch de sône, de keppeling, de resolver en de nammen dy't jo ferifiearre hawwe yn 'e feroaringsnotysje fêst te lizzen. Dan wit de folgjende persoan dy't in record tafoeget hokker nammeromte foar dy klantpopulaasje gesachfierend is.