ഒരു സ്വകാര്യ 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

രണ്ടാമത്തെ കമാൻഡാണ് പ്രധാനം. അതിന്റെ സ്റ്റാറ്റസ് ലൈനും authority വിഭാഗവും ഉത്തരം സൃഷ്ടിച്ച സോൺ പേര് പറയുന്നു, അതിനാൽ സ്വകാര്യ സോണിൽ നിന്നുള്ള നിഷേധാത്മക ഉത്തരത്തെ ടൈംഔട്ടിൽ നിന്നോ ബ്ലോക്ക് ചെയ്ത പോർട്ടിൽ നിന്നോ ക്വറി ഒരിക്കലും ലഭിക്കാത്ത റിസോൾവറിൽ നിന്നോ വേർതിരിക്കാം. resolvectl ഏത് മുകളിലെ സെർവറിനോട് ചോദിച്ചു എന്ന് കാണിക്കുന്നു, പലപ്പോഴും അത് VPN അയച്ചെന്ന് നിങ്ങൾ കരുതിയ റിസോൾവർ അല്ല.

ട്രേസ് ചെയ്ത ക്വറി പൊതു വിലാസം നൽകുകയും സാധാരണ ക്വറി നൽകാതിരിക്കുകയും ചെയ്താൽ, പൊതു റെക്കോർഡ് അക്ഷതമാണ്, ഉത്തരം നൽകുന്നത് സ്വകാര്യ വ്യൂ ആണ്. ആ ഒരു താരതമ്യമാണ് ഈ പേജിന്റെ ബാക്കി ഭാഗത്തിന്റെ ഏത് പകുതി നിങ്ങൾക്കു ബാധകമെന്ന് തീരുമാനിക്കുന്നത്.

ഏത് സോണാണ് ഉത്തരം നൽകിയതെന്ന് വായിക്കുക

ഇനിപ്പറയുന്നത് ഉൾക്കൊള്ളുന്ന ഉത്തരം: NXDOMAIN കൂടാതെ authority വിഭാഗത്തിൽ സ്വകാര്യ സോണിന്റെ 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]"

രണ്ട് കമാൻഡുകൾക്കും സോൺ സ്വന്തമാക്കിയ അക്കൗണ്ടിന്റെ ക്രെഡൻഷ്യലുകൾ വേണം, രണ്ടാമത്തേതിന് ആദ്യത്തേതിൽ നിന്നുള്ള സോൺ ID വേണം. അത് നിങ്ങളുടെ സ്വന്തം ID ഉപയോഗിച്ച് മാറ്റുക; മുകളിലുള്ള പ്ലേസ്ഹോൾഡർ ഉദ്ദേശ്യപൂർവ്വം യഥാർത്ഥമല്ല.

സ്വകാര്യ സോൺ എന്തുകൊണ്ട് വിജയിക്കുന്നു

സോണിനെ ഒരു 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 ഹോസ്റ്റ് നാമവും സർട്ടിഫിക്കറ്റ് പരിശോധനകളും മാറ്റാതെ വയ്ക്കുക, കാരണം സ്വകാര്യ വിലാസം കണക്ഷൻ എവിടെ പോകുന്നു എന്നത് മാറ്റുന്നു, ഏത് സർട്ടിഫിക്കറ്റ് സാധുവാണ് എന്നതിനെക്കുറിച്ച് ഒന്നുമല്ല.

മാറ്റക്കുറിപ്പിൽ സോൺ, അസോസിയേഷൻ, റിസോൾവർ, നിങ്ങൾ പരിശോധിച്ച പേരുകൾ എന്നിവ രേഖപ്പെടുത്തി അവസാനിപ്പിക്കുക. അപ്പോൾ അടുത്ത തവണ റെക്കോർഡ് ചേർക്കുന്നയാൾക്ക് ആ ഉപഭോക്തൃ ജനക്കൂട്ടത്തിന് ഏത് നാമസ്ഥലമാണ് അധികാരമുള്ളതെന്ന് അറിയാം.