පෞද්ගලික Route 53 කලාපයක් පොදු නම් සඳහා NXDOMAIN ලබා දෙන්නේ ඇයි

පෞද්ගලික Route 53 කලාප පොදු වාර්තාව සමඟ ඒකාබද්ධ වීම වෙනුවට නාමය සඳහා පිළිතුර ප්‍රතිස්ථාපනය කරයි, එබැවින් මිනිසුන් ඉතා නරක මොහොතේ පුදුමයට පත් වේ. අභ්‍යන්තර වාර්තාවක් එක් කරන්න api.example.net සඳහා පෞද්ගලික කලාපයක example.net, එය VPC එකකට සම්බන්ධ කරන්න, එවිට එම මව් නාමය යටතේ ඇති අනෙක් සියලුම නම් දැන් පිළිතුරු ලබා දෙන්නේ පෞද්ගලික කලාපයෙන් පමණි. ඊයේ www.example.net වෙත ළඟා විය හැකි වූ ක්ලයන්ටයාට අද සෘණාත්මක පිළිතුරක් ලැබේ. පහත විස්තරය එම අසාර්ථක විමසුමෙන් ආරම්භ වී පිළිතුරු දුන් කලාපය දෙසට පිටතට යයි.

කොන්සෝලයෙන් නොව, විමසුමෙන් ආරම්භ කරන්න

ගැටලුව වාර්තා කළ ක්ලයන්ටයා තුළම දෝෂය නැවත ජනනය කර, නිශ්චිත නම සහ වාර්තා වර්ගය සටහන් කරන්න. A සඳහා අසාර්ථක වන නම AAAA සඳහා තවමත් විසඳිය හැක, තවද කැෂ් කළ නමක් නැවත උත්සාහ කරන බ්‍රවුසරය කුමක් කැඩුණාදැයි සඟවයි. විමසුම දෙවරක් ධාවනය කරන්න: එක් වරක් ක්ලයන්ටයා සැබවින්ම භාවිතා කරන resolver හරහා, තවත් වරක් එය මග හරින ලුහුබැඳීමක් සමඟ.

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

දෙවන විධානය වැදගත් වන්නේ එයයි. එහි තත්ත්ව පේළිය සහ authority කොටස පිළිතුර නිපදවූ කලාපය නම් කරයි, එබැවින් පෞද්ගලික කලාපයෙන් ආ සෘණාත්මක පිළිතුර කාලය ඉකුත්වීම, අවහිර කළ පෝට් හෝ විමසුම කිසිදා නොලද resolver එකකින් වෙන් කර හඳුනාගත හැක. resolvectl කුමන ඉහළ සේවාදායකයෙන් ඇසුවාදැයි පෙන්වයි, එය බොහෝ විට ඔබ උපකල්පනය කළ VPN යැවූ resolver එක නොවේ.

ලුහුබැඳි විමසුම පොදු ලිපිනය ලබා දෙන අතර සාමාන්‍ය විමසුම ලබා නොදෙන්නේ නම්, පොදු වාර්තාව සුරක්ෂිත වන අතර පිළිතුරු දෙන්නේ පෞද්ගලික දර්ශනයයි. එම එක් සංසන්දනය මෙම පිටුවේ ඉතිරි කොටසේ කුමන අර්ධය ඔබට අදාළදැයි තීරණය කරයි.

කුමන කලාපය පිළිතුරු දුන්නාදැයි කියවන්න

පහත දැක්වෙන්න දරන පිළිතුරක්: 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 තුළ ඇති resolver එය යොදයි. ක්ලයන්ටයාගේ ගමනාගමනය පැමිණෙන VPC එකට සම්බන්ධ නොවූ පෞද්ගලික කලාපයකට කිසිදු බලපෑමක් නැත, එහෙත් වැරදි VPC එකකට සම්බන්ධ කිරීම වැරදි ජනගහනයට පෞද්ගලික පිළිතුරක් නිපදවයි. වාර්තා සංස්කරණය කිරීමට පෙර සම්බන්ධතා ලැයිස්තුව පරීක්ෂා කරන්න, මන්ද කලාපයක් නිවැරදි වුවත් නොපෙනී යා හැක.

අතිච්ඡාදනය වන නාම අවකාශ ව්‍යාකූලත්වයේ දෙවන මූලාශ්‍රයයි. example.net සඳහා පෞද්ගලික කලාපයක් සහ api.example.net සඳහා පෞද්ගලික කලාපයක් දෙකම API විමසුමකට ගැළපෙන අතර, වඩාත් නිශ්චිත එක පිළිතුරු දෙයි. එය පටු අභ්‍යන්තර නාම අවකාශයක් අවශ්‍ය විට ප්‍රයෝජනවත් වන අතර, පටු කලාපයේ පුළුල් කලාපයේ ඇති වාර්තාවක් නොමැති විට අනතුරුදායකය. පෞද්ගලික සත්කාරක කලාප පිළිබඳ සලකා බැලීම් Route 53 ලේඛනයේ පහළට වැටීමේ හැසිරීම සහ නීතිවල ප්‍රමුඛතාව දෙකම විස්තර කරයි, තවද දෙවන අතිච්ඡාදනය වන කලාපයක් එක් කිරීමට පෙර ඒවා කියවීම වටී.

මේ කිසිවක් පොදු කලාපය වෙනස් නොකරයි. පොදු resolver පොදු වාර්තාවලට තවමත් නිවැරදිව පිළිතුරු දෙයි, එබැවින් VPC එකෙන් පිටත සියලු දෙනාට මෙම අසාර්ථකත්වය ක්ලයන්ට් ගැටලුවක් ලෙස පෙනේ.

වාර්තා එක් කිරීමට පෙර නාම අවකාශය තෝරන්න

අභ්‍යන්තර සේවාවන්ගේ නව පවුලකට පමණක් පෞද්ගලික නම් අවශ්‍ය නම්, එයට කැපවූ පෞද්ගලික උප වසමක් දී පොදු මව් නාමය අතහැර දමන්න. internal.example.net වැනි නාමයකට www.example.net සෙවනැල්ල දැමිය නොහැක, තවද නැතිවූ වාර්තාවක බලපෑම් අරය ඔබ ඒ අරමුණ සඳහා නිර්මාණය කළ නම්වලට සීමා වේ. මිල වන්නේ පවතින URL සහ සහතික නව නාමයට නොගැළපිය හැකි වීමයි.

පොදු සහ පෞද්ගලික පරිශීලකයින් එකම සත්කාරක නාමය රඳවා ගත යුතු විට, බෙදුණු දර්ශනයේ DNS යනු සහාය දක්වන නිර්මාණයයි, එය සෑම දර්ශනයකම වාර්තා පැහැදිලිව පවත්වා ගැනීම අවශ්‍ය කරයි. එක් වාර්තාවක් පමණක් ඇති පුළුල් පෞද්ගලික කලාපයක් එම කලාපය යටතේ ඇති පොදු යැපීම් රැක නොගනී; එය ඒවා එක් වාර්තාවක් ඇති කලාපයකින් ප්‍රතිස්ථාපනය කරයි.

ක්ලයන්ට් ජනගහනය පෞද්ගලික දර්ශනය දෙසට හරවීමට පෙර යෙදුමක් සැබවින්ම අමතන නම් ලැයිස්තුගත කරන්න. පිවිසුම් සත්කාරක, ස්ථිතික සම්පත් සත්කාරක, නැවත යොමු කිරීමේ ඉලක්ක සහ API අන්ත ලක්ෂ්‍ය පළමුව බිඳෙන අතර, ඒවා සාමාන්‍යයෙන් කණ්ඩායම් කිහිපයක වාර්තා හරහා විසිරී ඇත.

resolver මාර්ගය, පසුව ජාල මාර්ගය ලුහුබඳින්න

ලැප්ටොප් පරිගණකයක් පෞද්ගලික දර්ශනය දකින්නේ එහි විමසුම් සම්බන්ධතාව ඇති resolver වෙත ළඟා වූ විට පමණි. VPN සේවාදායකයේ hosts ගොනුවක් සංස්කරණය කිරීමෙන් සම්බන්ධිත ක්ලයන්ට්වලට කිසිවක් ප්‍රකාශයට පත් නොවේ, තවද පොදු resolver එකකින් වින්‍යාස කළ ක්ලයන්ටයෙක් උමඟ සක්‍රීයව ඇති තාක් පොදු පිළිතුරු ලබා ගනිමින් සිටී. ක්ලයන්ටයාට ලැබුණු resolver ලිපිනය තහවුරු කර, පසුව විමසුම සර්වරයෙන් නොව ක්ලයන්ටයාගෙන් නැවත කරන්න.

නාමය විසඳී ගිය පසු, ලැබුණු ලිපිනයට ඇති මාර්ගය වෙනම පියවරක් ලෙස පරීක්ෂා කරන්න, උදාහරණයක් ලෙස ip route get සමඟ විමසුම ලබා දුන් ලිපිනයට එරෙහිව. ලිපිනයට මාර්ගයක් නොමැති නිවැරදි පෞද්ගලික පිළිතුරක් මාර්ගගත කිරීමේ ගැටලුවකි, තවද වාර්තාවක් නැති බවට පිළිතුරක් DNS දර්ශන ගැටලුවකි; දෙකම එක් ගැටලුවක් ලෙස සැලකීම රැඳී නොපවතින නිවැරදි කිරීම් ඇති කරයි. සේවාවේ TLS සත්කාරක නාමය සහ සහතික පරීක්ෂාවන් නොවෙනස්ව තබන්න, මන්ද පෞද්ගලික ලිපිනයක් සම්බන්ධතාවය යන තැන වෙනස් කරන අතර කුමන සහතිකය වලංගුද යන්න ගැන කිසිවක් නොවෙනස් කරයි.

වෙනස්කම් සටහනේ කලාපය, සම්බන්ධතාව, resolver සහ ඔබ තහවුරු කළ නම් සටහන් කර අවසන් කරන්න. එවිට ඊළඟ වරට වාර්තාවක් එක් කරන පුද්ගලයාට එම ක්ලයන්ට් ජනගහනය සඳහා කුමන නාම අවකාශය අධිකාරීදැයි දැනගත හැක.