શા માટે ખાનગી Route 53 ઝોન જાહેર નામો માટે NXDOMAIN પરત કરે છે

ખાનગી Route 53 ઝોન જાહેર રેકોર્ડ સાથે મર્જ થવાને બદલે નામનો જવાબ બદલી નાખે છે, અને એટલે જ લોકો સૌથી ખરાબ ક્ષણે આશ્ચર્ય પામે છે. એક આંતરિક રેકોર્ડ ઉમેરો api.example.net માટે એક ખાનગી ઝોનમાં example.net, તેને VPC સાથે જોડો, અને તે પેરેન્ટ હેઠળનું દરેક બીજું નામ હવે ફક્ત ખાનગી ઝોનમાંથી જ જવાબ આપે છે. જે ક્લાયન્ટ ગઈકાલે www.example.net સુધી પહોંચી શકતો હતો તેને આજે નકારાત્મક જવાબ મળે છે. નીચેની સમીક્ષા તે જ નિષ્ફળ ક્વેરીથી શરૂ થાય છે અને જે ઝોને તેનો જવાબ આપ્યો તે તરફ બહાર જાય છે.

કન્સોલથી નહીં, ક્વેરીથી શરૂ કરો

જે ક્લાયન્ટે સમસ્યા નોંધાવી તેના પર જ ભૂલનું પુનરુત્પાદન કરો અને ચોક્કસ નામ અને રેકોર્ડ પ્રકાર નોંધો. જે નામ A માટે નિષ્ફળ જાય છે તે AAAA માટે હજી પણ ઉકેલાઈ શકે છે, અને કેશ કરેલું નામ ફરી પ્રયત્ન કરતું બ્રાઉઝર કયું તૂટ્યું છે તે છુપાવે છે. ક્વેરી બે વાર ચલાવો: એક વાર ક્લાયન્ટ ખરેખર જે રિઝોલ્વર વાપરે છે તેના દ્વારા, અને એક વાર તેને ટાળતા ટ્રેસિંગ સાથે.

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

બીજો આદેશ જ મહત્વનો છે. તેની સ્ટેટસ લાઇન અને ઓથોરિટી વિભાગ જે ઝોને જવાબ બનાવ્યો તેનું નામ આપે છે, તેથી તમે ખાનગી ઝોનમાંથી આવતા નકારાત્મક જવાબને ટાઇમઆઉટ, બ્લોક કરેલા પોર્ટ અથવા ક્વેરી કદી ન મળેલા રિઝોલ્વરથી અલગ કરી શકો છો. resolvectl દર્શાવે છે કે કયા અપસ્ટ્રીમને પૂછવામાં આવ્યું, અને ઘણી વાર એ તમે ધારેલો એ રિઝોલ્વર હોતો નથી જે VPNએ મોકલ્યો હોય.

જો ટ્રેસ કરેલી ક્વેરી જાહેર સરનામું પરત કરે અને સામાન્ય ક્વેરી ન કરે, તો જાહેર રેકોર્ડ અકબંધ છે અને ખાનગી દૃશ્ય જવાબ આપે છે. એ જ એક સરખામણી નક્કી કરે છે કે આ પૃષ્ઠના બાકીના ભાગનો કયો અડધો ભાગ તમને લાગુ પડે છે.

કયો ઝોન જવાબ આપ્યો તે વાંચો

એવો જવાબ જે NXDOMAIN ધરાવે છે અને ઓથોરિટી વિભાગમાં ખાનગી ઝોનનો SOA ધરાવે છે તે તે ઝોનનો નિર્ણાયક જવાબ છે, નિષ્ફળ લુકઅપ નહીં. Route 53 Resolverએ ખાનગી હોસ્ટેડ ઝોન પસંદ કર્યો કારણ કે નામ મેળ ખાતું હતું, પછી માંગેલા પ્રકારનો કોઈ રેકોર્ડ મળ્યો નહીં, અને દસ્તાવેજી વર્તન એ છે કે પ્રશ્નને જાહેર DNS પર મોકલવાને બદલે નકારાત્મક જવાબ પરત કરવો.

પસંદગી વિશિષ્ટતાને અનુસરે છે. ઘણા ઓવરલેપિંગ ખાનગી નામસ્થાનો હોય ત્યારે સૌથી વિશિષ્ટ મેળ ખાતો ઝોન જીતે છે, અને પસંદ કરેલા ચાઇલ્ડ ઝોનમાં ન હોય તેવા નામ માટે વિશાળ ખાનગી પેરેન્ટને બીજી તક મળતી નથી. ફોરવર્ડિંગ નિયમો બીજું સ્તર ઉમેરે છે, કારણ કે ડોમેન-વિશિષ્ટ Resolver નિયમ ખાનગી હોસ્ટેડ ઝોન જોડાણ પર જીતી શકે છે. ઝોન ખાલી છે એવું નિષ્કર્ષ કાઢતા પહેલાં જોડાણો અને નિયમોની યાદી બનાવો.

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

બંને આદેશોને ઝોન ધરાવતા ખાતાના ઓળખપત્રો જોઈએ, અને બીજાને પહેલામાંથી ઝોન આઈડી જોઈએ. તેને તમારી પોતાની આઈડીથી બદલો; ઉપરનું પ્લેસહોલ્ડર જાણી જોઈને અસલી નથી.

ખાનગી ઝોન કેમ જીતે છે

જોડાણ જ ઝોનને VPC માટે દૃશ્યમાન બનાવે છે, અને તે VPCનું રિઝોલ્વર જ તેને લાગુ કરે છે. ક્લાયન્ટનો ટ્રાફિક જે VPCમાંથી આવે તેની સાથે જોડાયેલ ન હોય તેવા ખાનગી ઝોનની કોઈ અસર થતી નથી, જ્યારે ખોટા VPC સાથેનું જોડાણ ખોટી વસ્તી માટે ખાનગી જવાબ બનાવે છે. રેકોર્ડ સંપાદિત કરતા પહેલાં જોડાણોની યાદી તપાસો, કારણ કે ઝોન સાચો હોવા છતાં અદૃશ્ય રહી શકે છે.

ઓવરલેપિંગ નામસ્થાનો મૂંઝવણનો બીજો સ્રોત છે. example.net માટેનો ખાનગી ઝોન અને api.example.net માટેનો ખાનગી ઝોન બંને API ક્વેરી સાથે મેળ ખાય છે, અને વધુ વિશિષ્ટ જવાબ આપે છે. જ્યારે તમે સાંકડું આંતરિક નામસ્થાન ઇચ્છો ત્યારે તે ઉપયોગી છે, અને જ્યારે સાંકડા ઝોનમાં વિશાળ ઝોનમાં હોય તેવો રેકોર્ડ ન હોય ત્યારે જોખમી છે. ખાનગી હોસ્ટેડ ઝોન અંગેની વિચારણાઓ Route 53 દસ્તાવેજીકરણમાં નીચે પડવાનું વર્તન અને નિયમોની અગ્રતા બંને વર્ણવે છે, અને બીજો ઓવરલેપિંગ ઝોન ઉમેરતા પહેલાં તે વાંચવા યોગ્ય છે.

આમાંથી કંઈ પણ જાહેર ઝોન બદલતું નથી. જાહેર રિઝોલ્વર હજી પણ જાહેર રેકોર્ડને યોગ્ય રીતે જવાબ આપે છે, અને એટલે જ VPCની બહારના દરેકને આ ભૂલ ક્લાયન્ટની સમસ્યા લાગે છે.

રેકોર્ડ ઉમેરતા પહેલાં નામસ્થાન પસંદ કરો

જો ફક્ત આંતરિક સેવાઓના નવા કુટુંબને ખાનગી નામોની જરૂર હોય, તો તેને સમર્પિત ખાનગી સબડોમેન આપો અને જાહેર પેરેન્ટને અકબંધ રાખો. internal.example.net જેવું નામ www.example.net ને છાયા આપી શકતું નથી, અને ખૂટતા રેકોર્ડની અસરની ત્રિજ્યા એ નામો સુધી મર્યાદિત રહે છે જે તમે એ હેતુ માટે બનાવ્યાં હતાં. કિંમત એ છે કે હાલની URL અને પ્રમાણપત્રો નવા નામ સાથે મેળ ન ખાય.

જ્યારે જાહેર અને ખાનગી વપરાશકર્તાઓએ સમાન હોસ્ટનામ રાખવું પડે, ત્યારે સ્પ્લિટ-વ્યૂ DNS એ સમર્થિત રચના છે અને તે માગે છે કે તમે દરેક દૃશ્યમાં રેકોર્ડ સ્પષ્ટ રીતે જાળવો. એક જ રેકોર્ડ ધરાવતો વિશાળ ખાનગી ઝોન તે ઝોન હેઠળની જાહેર નિર્ભરતાઓ જાળવતો નથી; તે તેમને એક રેકોર્ડ ધરાવતા ઝોનથી બદલી નાખે છે.

ક્લાયન્ટ વસ્તીને ખાનગી દૃશ્ય તરફ દોરતા પહેલાં એપ્લિકેશન ખરેખર જે નામોને કૉલ કરે છે તેની યાદી બનાવો. લોગિન હોસ્ટ, સ્ટેટિક એસેટ હોસ્ટ, રીડાયરેક્ટ લક્ષ્યો અને API એન્ડપોઇન્ટ પહેલાં તૂટે છે, અને તે સામાન્ય રીતે ઘણી ટીમોના રેકોર્ડમાં વેરાયેલા હોય છે.

રિઝોલ્વરનો માર્ગ, પછી રૂટ ટ્રેસ કરો

લેપટોપ ખાનગી દૃશ્ય ત્યારે જ જુએ છે જ્યારે તેની ક્વેરી જોડાણ ધરાવતા રિઝોલ્વર સુધી પહોંચે. VPN સર્વર પર hosts ફાઇલ સંપાદિત કરવાથી જોડાયેલા ક્લાયન્ટને કંઈ પ્રકાશિત થતું નથી, અને જાહેર રિઝોલ્વર સાથે ગોઠવાયેલ ક્લાયન્ટ ટનલ ચાલુ હોય ત્યાં સુધી જાહેર જવાબો મેળવતો રહેશે. ક્લાયન્ટને મળેલા રિઝોલ્વર સરનામાની પુષ્ટિ કરો, પછી સર્વરથી નહીં, ક્લાયન્ટથી ક્વેરીનું પુનરાવર્તન કરો.

નામ ઉકેલાઈ ગયા પછી, પરત મળેલા સરનામા સુધીનો માર્ગ અલગ પગલા તરીકે ચકાસો, ઉદાહરણ તરીકે ip route get વડે ક્વેરીએ પરત કરેલા સરનામા સામે. સરનામા સુધીનો રૂટ વગરનો સાચો ખાનગી જવાબ રૂટિંગ સમસ્યા છે, અને રેકોર્ડ ખૂટે છે એવો જવાબ DNS દૃશ્યની સમસ્યા છે; બંનેને એક સમસ્યા ગણવાથી એવા સુધારા મળે છે જે ટકતા નથી. સેવાના TLS હોસ્ટનામ અને પ્રમાણપત્રની ચકાસણીઓ અબદલ રાખો, કારણ કે ખાનગી સરનામું બદલે છે કે કનેક્શન ક્યાં જાય છે અને કયું પ્રમાણપત્ર માન્ય છે તે વિશે કંઈ નહીં.

ફેરફાર નોંધમાં ઝોન, જોડાણ, રિઝોલ્વર અને તમે ચકાસેલા નામો લખીને પૂર્ણ કરો. પછી રેકોર્ડ ઉમેરનારી આગલી વ્યક્તિ જાણશે કે તે ક્લાયન્ટ વસ્તી માટે કયું નામસ્થાન સત્તાવાર છે.