HTTPS வழி DNS மற்றும் நிறுவன Split-Horizon DNS: தானாகத் தீராத மோதல்

இணையத்தின் பெரும்பாலான வரலாற்றில், DNS வினவல்கள் போர்ட் 53 வழியாக மறைகுறியாக்கப்படாத தெளிவுரையாகப் பயணித்தன. வலையமைப்புப் பாதையில் இருந்த எவராலும் அவற்றைப் படிக்கவும், பதிவுசெய்யவும், மாற்றவும் முடிந்தது. இந்தத் தனியுரிமைப் பிரச்சினைக்காக IETF பின்னர் இரண்டு மறைகுறியாக்கப்பட்ட மாற்று வழிகளை உருவாக்கியது: 2016-இல் TLS வழி DNS (DoT, RFC 7858), 2018-இல் HTTPS வழி DNS (DoH, RFC 8484).

குறிப்பாக DoH நிலைமையை மாற்றியது; ஏனெனில் அது DNS-ஐ வழக்கமான HTTPS தரவோட்டத்தின் உள்ளே மறைக்கிறது. ஒரு வலையமைப்புக் கண்காணிப்பாளருக்கு, DoH வினவல் உள்ளடக்கச் சேவையகத்துக்குச் செல்லும் வேறு எந்த TLS இணைப்பைப் போலவே தெரியும். பாதுகாப்பற்ற காபி கடை வலையமைப்பில் உலாவும் பயனர்களுக்கு இது சிறந்தது. ஆனால் எல்லையைத் தாண்டும் ஒவ்வொரு DNS வினவலையும் பார்த்து—வழிநடத்தி—செயல்படும் நிறுவன IT குழுவுக்கு இது அவ்வளவு நல்லதல்ல.

இதுவே மோதல். இரு தரப்புக்கும் முறையான, தெளிவாக வரையறுக்கப்பட்ட தேவைகள் உள்ளன. தரநிலை அமைப்புகள், உலாவி நிறுவனங்கள் மற்றும் இயக்க முறைமை நிறுவனங்கள் கடந்த பத்தாண்டின் பெரும் பகுதியை இவ்விரண்டையும் ஒரே நேரத்தில் செயல்பட வைக்க முயல்வதில் செலவிட்டுள்ளன. அதன் விளைவாக உருவான சமரசங்கள் முழுமையானவை அல்ல; 2026-இல் நிறுவன வலையமைப்பை இயக்கும் எவரும் அவற்றைப் புரிந்துகொள்ள வேண்டும்.

DoH உண்மையில் என்ன செய்கிறது

ஒரு DoH கிளையன்ட், DNS வினவல்களை HTTPS POST அல்லது GET கோரிக்கைகளாக அனுப்புகிறது; பொதுவாக https://dns.google/dns-query, https://cloudflare-dns.com/dns-query அல்லது வேறொரு பொது தீர்விக்கு அவை செல்கின்றன. பதில் வழக்கமான HTTPS பதில் உள்ளடக்கமாகத் திரும்புகிறது. இதில் மூன்று பண்புகள் முக்கியம்:

• பயணத்தின்போது மறைகுறியாக்கப்பட்டது. வலையமைப்புக் கண்காணிப்பாளர்களால் வினவப்படும் பெயரையோ பதிலையோ படிக்க முடியாது.
• அங்கீகரிக்கப்பட்ட சேவையகம். தீர்வியின் TLS சான்றிதழை கிளையன்ட் சரிபார்ப்பதால், இடைமறிப்புத் தாக்குபவரால் அதைப் போல நடிக்க முடியாது.
• போர்ட் அல்லது தெளிவுரை DNS அடையாளங்களால் கண்டறிய முடியாது. DoH, போர்ட் 443-இல் HTTPS-ஐப் பயன்படுத்துவதால், போர்ட் 53 அல்லது DNS வடிவத் தரவுப் பொட்டலங்களை மட்டும் பார்த்து மற்ற HTTPS போக்குவரத்திலிருந்து அதை வலையமைப்பால் பிரிக்க முடியாது. தெரிந்த தீர்வி முனைப்புள்ளிகளை IP முகவரி அல்லது புரவலன்பெயர் கொள்கை மூலம் நிர்வாகிகள் இன்னும் தடுக்கலாம். ஆனால் பகிரப்பட்ட உள்கட்டமைப்பு, மறைகுறியாக்கப்பட்ட துணைத்தரவு மற்றும் முன்பே தெரியாத முனைப்புள்ளிகள் காரணமாக அந்தக் கட்டுப்பாடு முழுமையற்றதாகவும் செயல்பாட்டுச் செலவு அதிகமானதாகவும் இருக்கும்.

மூன்றாவது பண்பே இந்த மோதலை வரையறுக்கிறது. DoT-யும் வினவல்களை மறைகுறியாக்குகிறது; ஆனால் அது ஒரு பிரத்யேக போர்ட்டில் (853) இயங்குவதால், வலையமைப்பால் அதை எளிதாகத் தடுக்க முடியும். போர்ட் மற்றும் தரவுப் பொட்டல வடிவம் மட்டுமே கொண்டு DoH-ஐ அடையாளம் காண முடியாது; குறிவைத்துத் தடுக்க, தீர்வி முனைப்புள்ளியை அறிந்திருக்கவோ கட்டுப்படுத்தவோ வேண்டும். மற்ற HTTPS சேவைகளுடன் உள்கட்டமைப்பைப் பகிரும் ஒரு முனைப்புள்ளியைத் தடுப்பது துணைச் சேதத்தையும் ஏற்படுத்தலாம்.

நிறுவன Split-Horizon DNS உண்மையில் என்ன செய்கிறது

பெரும்பாலான பெரிய நிறுவனங்கள் Split-Horizon DNS-ஐ இயக்குகின்றன. ஒரே பெயர் (vpn.example.corp, git.example.com, intranet.example.com) வினவல் வலையமைப்பின் உள்ளே இருந்து வருகிறதா அல்லது வெளியிலிருந்து வருகிறதா என்பதைப் பொறுத்து வெவ்வேறு IP முகவரிகளாகத் தீர்க்கப்படுகிறது.

வலையமைப்பின் உள்ளே:

• பொதுவாக Active Directory-யுடன் ஒருங்கிணைக்கப்பட்ட நிறுவனத்தின் உள் DNS தான் தீர்வியாக இருக்கும்.
• git.example.com, 10.0.4.7 போன்ற தனிப்பட்ட RFC 1918 முகவரியாகத் தீர்க்கப்படலாம்.
• உள் பயன்பாட்டுக்கான மண்டலங்கள் (example.corp, example.internal) பொது இணையத்தில் இல்லாமலும் இருக்கலாம்.
• DLP மற்றும் பாதுகாப்புக் கருவிகள் ஒவ்வொரு வினவலையும் பார்த்து, அறியப்பட்ட தீங்கிழைக்கும் டொமைன்களுக்கான DNS வினவல்களை எச்சரிக்கலாம்.

வலையமைப்புக்கு வெளியே (அல்லது வீட்டு Wi-Fi-இல் உள்ள தனிப்பட்ட சாதனத்தில்):

• அதே வினவல் ஒரு பொது தீர்விக்குச் செல்கிறது.
• git.example.com, பொது சுமைச் சமநிலைப்படுத்தியாகத் தீர்க்கப்படுகிறது.
• உள் பயன்பாட்டுக்கான பெயர்கள் தீர்க்கப்படுவதில்லை.

உள் சேவைகள், Active Directory, VPN-கள் அல்லது DNS அடிப்படையிலான பாதுகாப்புக் கட்டுப்பாடுகள் உள்ள சூழல்களில் இது ஒரு பொதுவான நிறுவன நடைமுறையாகும். இது ஒரு முக்கிய அனுமானத்தைச் சார்ந்துள்ளது: DHCP, சாதனக் கொள்கை அல்லது VPN உள்ளமைவு வழியாக, நிறுவனம் பயன்படுத்தச் சொல்லும் தீர்வியையே முனையச் சாதனம் பயன்படுத்த வேண்டும்.

DoH அந்த அனுமானத்தை முறிக்கிறது. உலாவியே தனது சொந்தத் தீர்வியை வழங்கினாலோ, இயக்க முறைமை முறைமைத் தீர்வியைத் தவிர்த்தாலோ, முனையச் சாதனம் உள் DNS-ஐ முற்றிலும் அணுகாமல் போகிறது. உள் புரவலன்பெயர்கள் தீர்க்கப்படுவதில்லை. கண்டறிதலுக்காக பாதுகாப்புக் கருவிகள் சார்ந்திருக்கும் வினவல்களும் அவற்றுக்குத் தெரியாமல் போகின்றன.

உலாவிகளும் இயக்க முறைமைகளும் இதைக் கையாள முயன்ற விதம்

நிறுவனங்கள் இந்தப் பிரச்சினையைப் புறக்கணிக்கவில்லை. இன்று இருக்கும் சமரசங்கள் பல அடுக்குகளைக் கொண்டவை; அவை ஓரளவு தற்காலிகத் தீர்வுகளாகவும் உள்ளன.

Chrome-இன் "தானியங்கி மேம்படுத்தல்" முறை

Chrome-இன் DoH செயலாக்கம், முறைமைத் தீர்வி ஏற்கெனவே Chrome-இன் DoH ஆதரவுள்ள வழங்குநர்களின் அனுமதிப்பட்டியலில் (Google, Cloudflare, Quad9 போன்றவை) இருந்தால் மட்டுமே அதை DoH-க்கு மேம்படுத்துகிறது. ஒரு உள் நிறுவனத் தீர்வியைப் பயன்படுத்தும் வகையில் முறைமை அமைக்கப்பட்டு, அது அனுமதிப்பட்டியலில் இல்லாவிட்டால், Chrome அதை மாற்றாமல் விடுகிறது. Chrome-இன் DnsOverHttpsMode அமைப்பு வழியாக நிறுவனக் கொள்கைகள் DoH-ஐ முழுமையாக முடக்கவும் முடியும்.

Firefox-இன் TRR (Trusted Recursive Resolver) முறை

Firefox-இன் அணுகுமுறை கூடுதல் சர்ச்சைக்குரியதாக இருந்துள்ளது. Mozilla இயல்புநிலையாக DoH-ஐ இயக்கியுள்ள பிராந்தியங்களில், அமெரிக்காவில் Cloudflare போன்ற ஓர் இயல்புநிலைத் தீர்வியை Firefox பயன்படுத்துகிறது; இருப்பினும் DoH-ஐ இயக்குவதற்கு முன் அது நிறுவன மற்றும் வலையமைப்புச் சூழல் குறித்த தீர்மான விதிகளையும் சோதிக்கிறது. use-application-dns.net என்ற கேனரி டொமைன் ஒரு முக்கிய சமிக்ஞை: உள்ளூர் தீர்வி எதிர்மறைப் பதிலைத் திருப்பினால், இயல்புநிலையாக DoH இயக்கப்பட்ட பயனர்களுக்கு Firefox பயன்பாட்டு-நிலை DNS-ஐ முடக்குகிறது. Split-Horizon தொடர்பான ஒரு முக்கிய நுணுக்கத்தையும் Mozilla ஆவணப்படுத்துகிறது: DoH தீர்வு தோல்வியுற்றால், உள் பயன்பாட்டுக்கான பெயர்கள் மாற்றுவழியாக வழக்கமான DNS-க்குச் செல்லலாம்; ஆனால் வலையமைப்பின் உள்ளே வேறு பதிலாகத் தீர்க்கப்படும் பொது பெயர்களுக்கு, DoH-ஐ முடக்க நிறுவனக் கொள்கை தேவை.

Apple-இன் மறைகுறியாக்கப்பட்ட DNS (iOS 14+, macOS Big Sur+)

முழு முறைமைக்கும் DoH அல்லது DoT பயன்படுத்த பயன்பாடுகளும் உள்ளமைவுச் சுயவிவரங்களும் தேர்வு செய்ய Apple அனுமதிக்கிறது; நிர்வகிக்கப்படும் சாதனங்களுக்கான MDM கட்டுப்பாடுகளையும் நிர்வாகிகளுக்கு வழங்குகிறது. எனவே ஒரு நிறுவனம் நடைமுறையில் பயன்படுத்தும் சுயவிவரங்களையும் தீர்விக் கொள்கையையும் பொறுத்தே Split-Horizon செயல்படும்; சாதனம் நிர்வகிக்கப்படுவது மட்டுமே சரியான முடிவுக்கு உத்தரவாதமல்ல.

Windows-இன் சொந்த DoH

Windows 11 முதல், மேலும் Windows Server 2022 மற்றும் அதற்குப் பிந்தைய பதிப்புகளின் DNS கிளையன்ட்டில், முறைமைத் தீர்வி தானாகவே DoH-ஐப் பயன்படுத்த முடியும். DNS கிளையன்ட் DoH-ஐ அனுமதிக்குமா, கட்டாயப்படுத்துமா அல்லது தடைசெய்யுமா என்பதை Group Policy கட்டுப்படுத்துகிறது; உள்ளமைக்கப்பட்ட DNS சேவையகத்துக்கான DoH template-ஐயும் நிர்வாகிகள் பதிவுசெய்யலாம். இது DoH சேவையை வழங்குவதிலிருந்து வேறுபட்டது: Microsoft-இன் DNS Server service-க்கு Windows Server 2025 உடன் ஜூன் 2026 பாதுகாப்புப் புதுப்பிப்பு அல்லது அதற்குப் பிந்தையது தேவை. இரு சூழல்களிலும், பாதுகாப்புக் குழு தீர்வியையும் முனையச் சாதனக் கொள்கையையும் திட்டமிட்டே உள்ளமைக்க வேண்டும்.

இதிலிருந்து ஒரு பொதுவான முறை தெளிவாகிறது: ஒரே பயன்பாட்டுக்குள் செயல்படும் DoH, அந்தப் பயன்பாடு நிர்வகிக்கப்படாவிட்டால் முறைமைத் தீர்வியின் தேர்வுகளைத் தவிர்க்கலாம்; இயக்க முறைமை அளவிலான தீர்வியில் செயல்படும் DoH-ஐ சாதனக் கொள்கை வழியாக நிர்வகிக்கலாம். பயன்பாட்டு-நிலை DoH மறைந்துவிடவில்லை என்பதால், உலாவிக்கான நிறுவனக் கொள்கைகள் இன்னும் முக்கியமானவை.

2026-இல் ஒரு நிறுவனத்திற்கான நடைமுறைத் தேர்வுகள்

மேலே கூறிய கருவிகளைக் கருத்தில் கொண்டால், செயல்படக்கூடிய மூன்று உத்திகளும், செயல்படாத நான்காவது ஓர் உத்தியும் உள்ளன.

உத்தி A: அனைத்தும் உள் தீர்வி வழியாக; DoH தடுக்கப்படும்

ஒவ்வொரு உலாவியிலும் DoH-ஐ முடக்கும் கொள்கையை அமல்படுத்தி, அறியப்பட்ட பொது DoH முனைப்புள்ளிகளுக்கான போர்ட் 443 போக்குவரத்தைத் தடுத்து, எல்லா DNS வினவல்களையும் உள் தீர்வி வழியாகக் கட்டாயப்படுத்துங்கள். உள் தீர்வி பொது upstream தீர்விகளுடன் DoH வழியாகப் பேசலாம்; ஆனால் வலையமைப்பின் உள்ளே அனைத்தும் அதன் வழியாகவே செல்லும்.

இது மிகவும் கட்டுப்பாடுள்ள தேர்வு. Split-Horizon-ஐ முழுமையாகப் பாதுகாப்பதுடன், பாதுகாப்புக் கருவிகளுக்கு முழுக் காட்சியையும் வழங்குகிறது. புதிய DoH முனைப்புள்ளிகளுக்கான தடுப்புப்பட்டியலைப் பராமரிக்க வேண்டும் என்பது இதன் செலவு; மேலும் பயனர் நிறுவும், தன்னிச்சையாக DoH பயன்படுத்தும் எந்தப் பயன்பாடும் (சில அரட்டைச் செயலிகள், சில VPN-கள்) தவறாகச் செயல்படலாம்.

உத்தி B: உள் DoH

ஒரு உள் DoH சேவையகத்தை நிறுவி, அதைப் பயன்படுத்துமாறு முனையச் சாதனங்களை உள்ளமைத்து, அந்தத் தீர்வியிலேயே Split-Horizon-ஐ இயக்குங்கள். ஆதரவு மற்றும் செயல்பாட்டுத் தேவைகளைப் பொறுத்து, அது ஒரு பிரத்யேக DoH ஆதரவுள்ள தீர்வியாகவோ, ஜூன் 2026 பாதுகாப்புப் புதுப்பிப்பு அல்லது அதற்குப் பிந்தையதைப் பெற்ற Windows Server 2025-இன் Microsoft DNS Server service-ஆகவோ இருக்கலாம். முனையச் சாதனங்களுக்கும் தீர்விக்கும் இடையிலான போக்குவரத்து மறைகுறியாக்கப்படும்; அதே நேரத்தில் வினவல்களைப் பார்க்கும் திறனைத் தீர்வி இழக்காது.

நிறுவனம் தீர்வியை இயக்கி ஒவ்வொரு முனையச் சாதனத்தையும் நிர்வகிக்க முடியும் இடங்களில் இது தெளிவான தேர்வாக இருக்கலாம். நிர்வகிக்கப்படும் கிளையன்ட்களுக்கும் உள் தீர்விக்கும் இடையிலான வினவல்களை இது பாதுகாக்கும்; அதே நேரத்தில் தீர்வி-நிலை வடிகட்டலையும் பதிவிடலையும் தக்கவைக்கும். தளங்களின் ஆதரவும் பயன்படுத்தும் முறைகளும் வேறுபடுவதால், தேர்ந்தெடுத்த தொழில்நுட்பத் தொகுப்பின் கிளையன்ட், சேவையகம், சான்றிதழ் மற்றும் மாற்றுவழி நடத்தை அனைத்தையும் குழுக்கள் சரிபார்க்க வேண்டும்.

உத்தி C: கேனரி டொமைன் / வலையமைப்புச் சமிக்ஞை

Mozilla-வின் use-application-dns.net கேனரி வினவலுக்கு Firefox எதிர்பார்க்கும் எதிர்மறைப் பதிலை உள்ளூர் தீர்வி வழங்குமாறு உள்ளமைத்து, தொடர்புடைய உலாவிக் கொள்கைகளை அமல்படுத்துங்கள். இயல்புநிலையாக DoH இயக்கப்பட்ட Firefox பயனர்களுக்கு மட்டுமே கேனரி சமிக்ஞை பொருந்தும்; பயனர் வெளிப்படையாகத் தேர்வுசெய்த அமைப்பை அது மாற்றாது. Chromium, Mozilla-வின் கேனரி முறையைப் பயன்படுத்துவதில்லை; எனவே Chrome மற்றும் Edge-க்கு அவற்றின் சொந்த அமலாக்க முறையும் நிறுவனக் கொள்கைகளும் தேவை. ஆகவே இதை எல்லா உலாவிகளுக்கும் பொருந்தும் ஒரே வலையமைப்புச் சமிக்ஞையாகக் கருதாமல், ஒவ்வொரு உலாவிக்கும் தனித்தனியாகச் செயல்படுத்த வேண்டும்.

உத்தி D (செயல்படாது): "DoH-ஐ அப்படியே புறக்கணிப்போம்"

இந்த மோதலே இல்லை என்பதுபோல் நடந்துகொண்டு, இயல்புநிலை அமைப்புகளை மாற்றாமல் விட்டு, எல்லா DNS வினவல்களும் இன்னும் நிறுவனத் தீர்வி வழியாகத்தான் செல்கின்றன என்று அனுமானிப்பது. இதுவே மிகவும் பொதுவான நிலை; இதன் தோல்விகளை முன்கூட்டியே கணிக்க முடியும்: Edge-இல் செயல்படும் உள் பயன்பாட்டு URL-கள் Firefox-இல் செயல்படவில்லை என்று மென்பொருள் உருவாக்குநர்கள் புகாரளிப்பது, DNS பதிவுகளில் இடைவெளிகளைப் பாதுகாப்புக் குழுக்கள் காண்பது, காரணத்தைக் கண்டறிய பல மணி நேரம் பிடிக்கும் இடைக்கிடையான VPN-DNS கோளாறுகள். பிரச்சினை மறைவதில்லை. அதன் காரணத்தைக் கண்டறிவது மட்டுமே மேலும் கடினமாகிறது.

DoH-இன் தாக்கம் தனியுரிமையுடன் முடிவதில்லை

DoH-இன் ஓர் நுட்பமான விளைவு, தீர்விச் சேவை மையப்படுத்தப்படுவதாகும். ஒரு பொது DoH தீர்வியைப் பயன்படுத்துமாறு உலாவி அல்லது இயக்க முறைமை உள்ளமைக்கப்பட்டால், பயனரின் DNS தரவோட்டத்தில் அதிகமான பகுதி ஒரே தீர்வி நிறுவனத்துக்குச் செல்லலாம். முடிந்தவரை பயனரின் ஏற்கெனவே உள்ள DNS வழங்குநரையே தக்கவைக்க Chrome-இன் தானியங்கி முறை வெளிப்படையாக வடிவமைக்கப்பட்டுள்ளது; Firefox-இன் இயல்புநிலை அமலாக்கம் பிராந்தியத்தையும் சூழல் சார்ந்த தீர்மான விதிகளையும் பொறுத்தது. ஆகவே ஒவ்வொரு பயன்பாட்டிலும் "ஒவ்வொரு வினவலும்" ஒரே இடத்துக்குச் செல்கிறது என்பது இதன் பொருள் அல்ல. இருந்தாலும் கட்டமைப்பு ரீதியான சமரசம் மாறாது: மறைகுறியாக்கப்பட்ட DNS, உள்ளூர் வலையமைப்பு அல்லது ISP மீது இருந்த நம்பிக்கையை, தேர்ந்தெடுக்கப்பட்ட சிறிய தீர்வி நிறுவனங்களின் குழுவுக்கு மாற்றலாம்.

இந்தச் சமரசம் ஏற்றுக்கொள்ளத்தக்கதா என்பது அச்சுறுத்தல் மாதிரியைப் பொறுத்தது. பாதுகாப்பற்ற காபி கடை வலையமைப்பைப் பயன்படுத்தும் ஒருவருக்கு, காபி கடையை நம்புவதற்குப் பதிலாக Cloudflare-ஐ நம்புவது தெளிவான முன்னேற்றம். ஏற்கெனவே தனது ISP உடன் ஒப்பந்த உறவு கொண்டுள்ள நிறுவனத்துக்கு அது பின்னடைவாக இருக்கலாம். தொடக்ககால DoH அமலாக்கங்களிலிருந்தே இந்தச் சமரசம் குறித்து EFF எழுதி வருகிறது.

மேலே கூறிய உத்தி B தான் மிகத் தெளிவான பதில்: உங்கள் சொந்த DoH தீர்வியை இயக்குங்கள்; அப்போது மறைகுறியாக்கப்பட்ட DNS-ஐப் பயன்படுத்த, முழு வினவல் தரவோட்டத்தையும் மூன்றாம் தரப்பிடம் ஒப்படைக்க வேண்டியதில்லை.

டொமைன் உரிமையாளர்களுக்கு இதன் பொருள் என்ன

நிறுவனங்கள் பயன்படுத்தும் ஒரு டொமைனை—SaaS பயன்பாடு, மென்பொருள் உருவாக்குநர் கருவி அல்லது API—நீங்கள் இயக்கினால், கவனிக்க வேண்டியவை:

• குறிப்பாக நிர்வகிக்கப்படாத சாதனங்கள் அல்லது வெளிப்படையாக உள்ளமைக்கப்பட்ட உலாவிகளில், உங்கள் பயனர்களில் ஒரு பகுதியினர் பொது DoH முனைப்புள்ளி வழியாக உங்கள் டொமைனைத் தீர்ப்பார்கள். CNAME சங்கிலிகள், துணை-டொமைன் ஒப்படைப்புகள் மற்றும் தனிப்பயனாக்கத்திற்காக நீங்கள் பயன்படுத்தும் எந்த நுட்பமான DNS முறைகளும் வாடிக்கையாளரின் உள் தீர்வியிலிருந்து தீர்க்கப்படும்போது மட்டுமல்லாமல், எந்தவொரு பொது தீர்வியிலிருந்து தீர்க்கப்படும்போதும் ஒரேபோல் செயல்பட வேண்டும்.
• DNS அடிப்படையிலான தணிக்கையைத் தவிர்ப்பது DoH-இன் உண்மையான பயன்பாடாகும். ஓர் அரசின் DNS வடிகட்டி உங்கள் டொமைனைத் தடுத்தால் (பல மறைகுறியாக்கப்பட்ட தகவல்தொடர்பு மற்றும் VPN டொமைன்களுக்கு நேர்ந்ததைப் போல), பொது தீர்வியுடனான DoH வழியாக பயனர்கள் உங்களை அணுகுவார்கள். தொழில்நுட்பச் செயல்முறை ஒன்றே; அரசியல் தாக்கங்கள் வேறுபட்டவை.
• Split-Horizon பெயரின் இரு காட்சிகளையும் திட்டமிட்டு வடிவமைக்கவும். பொது DoH தீர்வியை வினவும் தொலைநிலைப் பயனர், நிறுவனத்தின் உள் தீர்வியிலிருந்து வரும் தனிப்பட்ட பதிலை அல்லாமல் பொது DNS காட்சியையே பெறுவார். பொது காட்சியில் பயன்படக்கூடிய பதிவு இல்லாவிட்டால் பெயர் செயலிழக்கும்; பொது முனைப்புள்ளி இருந்தால் பயனர் அதனை அடைவார். app.example.internal போன்ற தெளிவாகப் பிரிக்கப்பட்ட உள் பயன்பாட்டு மண்டலம் நோக்கத்தைத் தெளிவாக்கலாம்; ஆனால் அதனால் மட்டுமே தொலைநிலையில் சேவையை அணுக முடியாது—VPN அணுகலும் நிர்வகிக்கப்படும் split-DNS கொள்கையும் இன்னும் தேவை.

இதில் Namefi-இன் பங்கு

உலகளாவிய பெயரிடல் உள்ளூர் கொள்கையைச் சந்திக்கும், பொது இணையத்திற்கான கட்டுப்பாட்டுத் தளமாக DNS-ஐ Namefi கருதுகிறது. எங்களால் பட்டியலிட முடியாத DoH முனைப்புள்ளிகள் உட்பட எந்தத் தீர்வியிலிருந்தும் வினவல்கள் வரலாம் என்ற அடிப்படையில் எங்கள் DNS பணிப்பாய்வுகள் அமைந்துள்ளன; நாங்கள் வெளியிடும் பெயர்கள் எந்தத் தீர்வியிலிருந்து கேட்டாலும் ஒரேபோல் செயல்படும். உள்நிலையில் Split-Horizon-ஐ இயக்கும் வாடிக்கையாளர்களைப் பொறுத்தவரை, நாங்கள் பொது பக்கத்தில் இருக்கிறோம்: example.com-க்கான அதிகாரப்பூர்வப் பதிலை நாங்கள் வழங்குகிறோம்; உள் பயனர்களுக்காக உள் தீர்வி எதை மேலெழுதுகிறது என்பது அவர்களுக்கும் அவர்களின் முனையச் சாதனக் கொள்கைக்கும் இடையிலானது.

முக்கியமான கருத்து இதுதான்: மறைகுறியாக்கப்பட்ட DNS தொடர்ந்து நிலைக்கும்; அதேபோல் தீர்விக் கொள்கையும் வினவல் காட்சியும் தேவைப்படும் நிறுவனங்களும் தொடரும். இவ்விரண்டையும் இணைக்க, பொதுவாக நிர்வகிக்கப்படும் இயக்க முறைமை தீர்வி அமைப்புகள், ஒவ்வொரு உலாவிக்கும் உரிய நிறுவனக் கட்டுப்பாடுகள் மற்றும் Split-Horizon தேவைப்படும் இடங்களில் ஓர் உள் தீர்வி ஆகியவற்றின் கலவை பயன்படுத்தப்படுகிறது. சரியான கலவை தளத்தையும் அமலாக்கத்தையும் சார்ந்தது; இது எல்லா நிறுவனங்களும் ஒரே முறையை ஏற்றுக்கொள்ளும் உலகளாவியத் தீர்வு அல்ல, ஒரு செயல்பாட்டு வடிவமைப்புத் தேர்வு.

ஆதாரங்களும் கூடுதல் வாசிப்பும்

• IETF — HTTPS வழி DNS, RFC 8484 மற்றும் TLS வழி DNS, RFC 7858.
• Chrome Enterprise — DoH கொள்கைக் கட்டுப்பாடுகள்.
• Mozilla — Trusted Recursive Resolver திட்டம், கேனரி டொமைன் நடத்தை, மற்றும் Split-Horizon மாற்றுவழி வழிகாட்டுதல்.
• Chromium — Chrome-இன் அதே வழங்குநருக்கான DoH தானியங்கி மேம்படுத்தல் முறையும் கேனரி டொமைன் நிலைப்பாடும்.
• Microsoft — DoH பயன்படுத்த Windows DNS கிளையன்ட்டை உள்ளமைத்தல் மற்றும் Windows Server DNS Server service-இல் DoH-ஐ இயக்குதல்.
• EFF — மறைகுறியாக்கப்பட்ட DNS, இணையத்தின் மிகப் பெரிய தனியுரிமை இடைவெளிகளில் ஒன்றை மூட உதவும்.