VPN හරහා BIND: කොන්දේසි සහිත යොමු කිරීමද stub කලාපයද?
VPN හරහා එක් පෞද්ගලික කලාපයක් විසඳන ක්‍රම තුන සහ එක් එක් කවදාද සුදුසු: forward, stub හෝ secondary, සමඟ තීරණය කරන මූලාශ්‍ර ලිපින පරීක්ෂාව.
ඔබේ කාර්යාල resolver එක් ආයතනික නාම අවකාශයක් හැර සියල්ලට පිළිතුරු දෙන අතර, එය දන්නා ආයතනික DNS සේවාදායකය VPN පිටුපස පිහිටයි. BIND එම එකම කලාපය upstream වෙත විවිධ ක්‍රම තුනකින් භාර දිය හැකි අතර, ඒවා විවිධ ලෙස අසාර්ථක වේ. කොන්දේසි සහිත යොමු කිරීම කුඩාම කැපවීමයි, stub කලාපය delegation දත්ත තබා ගනී, සහ secondary සම්පූර්ණ පිටපතක් තබා ගනී. ඔබ මුලින්ම සොයාගත් snippet එක අනුව නොව, upstream අවසර දෙන දේ සහ ඔබේ resolver රඳවා ගත යුතු දේ අනුව තෝරන්න.
එක් නාම අවකාශයක් සඳහා විධි තුනක්
| Type | What your resolver keeps | Upstream must | Fails when |
|---|---|---|---|
forward | a forwarder list | answer queries from your source address | upstream is down and forward only is set |
stub | the zone's NS records and addresses | answer NS queries for the zone | delegation data goes stale after an NS change |
secondary | a full copy of the zone | permit AXFR or IXFR from your source | transfer is blocked by ACL or firewall |
කොන්දේසි සහිත යොමු කිරීම: කුඩාම කැපවීම
කාර්යාල resolver 192.168.10.53 ලෙසත් ආයතනික සේවාදායකය 10.40.0.53 ලෙසත්, අනුමත ටනලයක් හරහා ළඟා විය හැකි යැයි සිතමු. ප්‍රකාශය පේළි තුනකි, සහ සිත්ගන්නාසුළු වන්නේ forward only ය, මන්ද එය මාර්ගය නොව අසාර්ථකත්ව හැසිරීම වෙනස් කරයි.
zone "corp.example" {
type forward;
forward only;
forwarders { 10.40.0.53; };
};forward only සමඟ, ළඟා විය නොහැකි upstream එකක් මෙම කලාපයට පුනරාවර්තන විසඳුමට ආපසු යාම වෙනුවට SERVFAIL ලබා දෙයි. පෞද්ගලික නාම අවකාශයකට සාමාන්‍යයෙන් අවශ්‍ය වන්නේ එයයි, මන්ද ආපසු යාමේදී පෞද්ගලික නාම පොදු resolver වෙත යවා අන්තර්ජාලයෙන් නිෂ්ඵල පිළිතුරක් ගෙන එනු ඇත. BIND යොමුව ප්‍රතිපත්ති දෙකම ලේඛනගත කරයි, සහ වෙනස snippet එක ඇඟවෙන ප්‍රමාණයට වඩා වැදගත් වේ. එකම නාමය සඳහා දැනටමත් පවතින කලාපයක් ප්‍රතිස්ථාපනය නොකර කලාපය පවතින වින්‍යාසයට ඒකාබද්ධ කරන්න.
stub හෝ secondary: delegation වැදගත් වන විට
stub කලාපයක් ආයතනික සේවාදායකයෙන් කලාපයේ NS වාර්තා ඉල්ලා පසුව අධිකාරී සේවාදායකවලින් සෘජුවම අසයි. upstream ප්‍රදේශය විශාල හෝ බෙදී ඇති විට සහ සියල්ල එකම ලිපිනයකට ඇමිණීම වෙනුවට ඔබේ resolver delegation අනුගමනය කළ යුතු නම් එය තෝරන්න. මිල වන්නේ NS දත්ත යාවත්කාලීනව තිබීම සහ ලැයිස්තුගත සෑම නාම සේවාදායකයක්ම ඔබේ resolver හි මූලාශ්‍ර ලිපිනයෙන් ළඟා විය හැකි වීම මත යැපීමයි.
zone "corp.example" {
type stub;
masters { 10.40.0.53; };
};
zone "corp.example" {
type secondary;
primaries { 10.40.0.53; };
file "corp.example.db";
};secondary ස්ථානීය දත්තවලින් පිළිතුරු දෙන අතර upstream බාධාවකට ඔරොත්තු දෙයි, ඒ නිසාම සම්ප්‍රේෂණ යැපීම පිළිගැනීම වටී. එයින් අදහස් වන්නේ ඔබේ resolver දැන් තමන්ට අයත් නොවන කලාපයක පිටපතක් තබා ගන්නා බවයි, එබැවින් ගොනු මාර්ගය, ප්‍රාථමිකයේ සම්ප්‍රේෂණ ACL සහ නැවුම් කිරීමේ ටයිමර සියල්ල ඔබේ මෙහෙයුම් මතුපිට කොටසක් බවට පත් වේ.
ඒවා අතර තීරණය කරන පරීක්ෂාව
BIND තමාගේ පිටතට යන විමසුම තමන්ම ජනනය කරයි, එබැවින් ප්‍රශ්නය ලැප්ටොපය 10.40.0.53 වෙත ළඟා විය හැකිද යන්න නොව, resolver සත්කාරකය ආයතනික සේවාදායකය දකින මූලාශ්‍ර ලිපිනයෙන් ළඟා විය හැකිද යන්නයි. පළමුව කර්නලයෙන් අසන්න, පසුව සේවාදායකයෙන්, එම අනුපිළිවෙලින්.
ip route get 10.40.0.53
named-checkconf
rndc reload corp.example
dig @10.40.0.53 corp.example NS +norecurse
dig @192.168.10.53 portal.corp.exampleමාර්ගයේ UDP සහ TCP අවසර දෙන්න: කපන ලද පිළිතුරක් TCP බල කරයි, සහ UDP පමණක් අවසර දෙන ප්‍රතිපත්තියක් පැකට් නැතිවීමක් මෙන් පෙනෙන කලින් කල අසාර්ථකතා ඇති කරයි. ආයතනික පැත්තට ඔබේ resolver හි මූලාශ්‍රය සඳහා පිළිගැනීමේ නීතියක් සහ එය වෙත ආපසු මාර්ගයක් යන දෙකම අවශ්‍යයි; එම මූලාශ්‍රය resolver හි මාර්ගගත ලිපිනය හෝ පැහැදිලිව පරිවර්තනය කළ ලිපිනයක් විය හැක, සහ එය කලාතුරකින් සේවාලාභී තටාක ලිපිනයක් වේ. NS විමසුම අසාර්ථක නම්, forward කලාපය කෙසේ හැසිරුණත් stub කලාපයට ක්‍රියා කළ නොහැක.
ටනලය නොව පිළිතුර සත්‍යාපනය කරන්න
ඔබ කිසිදා ඉල්ලා නොසිටි නාමයක් සඳහා කාර්යාල resolver හරහා විමසා, පිළිතුරේ authority කොටස බලා එය ආයතනික කලාපයෙන් පැමිණියේදැයි තහවුරු කරන්න. cache හි ඇති පිළිතුරක් වර්තමාන මාර්ගය ගැන කිසිවක් ඔප්පු නොකරයි, සහ upstream වෙත සෘජු සාර්ථක විමසුමක් ඔබේ resolver එම කලාපය තෝරාගත් බව ඔප්පු නොකරයි. එම විමසුමම TCP හරහා නැවත කර මාර්ගය කැපීමට ඔරොත්තු දෙන බව තහවුරු කරන්න.
සේවාලාභීන් කාර්යාල resolver වෙත යොමු කර තබන්න, සහ DNSSEC සත්‍යාපනය සක්‍රීයව තබන්න. ස්වාධීන සංකේතන resolver එකක් සමඟ වින්‍යාස කළ බ්‍රව්සරයක් මෙම විධිය සම්පූර්ණයෙන්ම මඟ හරියි, සහ අනපේක්ෂිත පිළිතුරක් නිවැරදි ලෙස පෙනෙන පරිදි සත්‍යාපනය අක්‍රීය කිරීම දෘශ්‍යමාන අසාර්ථකත්වයක් අදෘශ්‍යමාන එකක් සමඟ මාරු කරයි.
තුනෙන් කුමන වර්ගය තෝරාගත්තාද සහ ඇයිද යන්න ලියන්න. කලාපය අසාර්ථක වන අයුරු දකින ඊළඟ පුද්ගලයාට වින්‍යාස ගොනුවට වඩා එම වාක්‍යය අවශ්‍ය වනු ඇත.