MagicDNS சாதனங்களைத் தீர்க்கிறது ஆனால் அலுவலக ஹோஸ்ட் பெயர்களை ஏன் தீர்க்கவில்லை

MagicDNS ஒரு tailnet-இல் உள்ள ஒவ்வொரு சாதனத்திற்கும் அதன் இயந்திரப் பெயர் மற்றும் tailnet-இன் DNS களத்திலிருந்து பெறப்பட்ட பெயரை வழங்குகிறது. அந்தப் பெயரை Tailscale உருவாக்குகிறது, அதற்கு Tailscale-இன் தீர்வி பாதை வழியாகப் பதில் அளிக்கப்படுகிறது. files.office.example போன்ற அலுவலக ஹோஸ்ட் பெயர் Tailscale ஒருபோதும் எழுதாத மண்டலத்தைச் சேர்ந்தது, எனவே சாதனத்தின் பெயரை மாற்றுவது அதை உருவாக்க முடியாது. இரண்டு பெயர் இடைவெளிகளும் ஒன்றாக உள்ளன; அவற்றுக்கு வெவ்வேறு உரிமையாளர்கள் மட்டுமே.

அந்த இயங்குமுறை மிகவும் பொதுவான புகாருக்குப் பின்னால் உள்ளது: Tailscale ஹோஸ்ட் பதிலளிக்கிறது, கோப்பு சேவையகம் இன்னும் தீர்வுப் பிழையைத் திருப்பித் தருகிறது.

இரண்டு பெயர் இடைவெளிகள், இரண்டு உரிமையாளர்கள்

சாதனப் பெயர் இயந்திரத்தின் சொந்த ஹோஸ்ட் பெயரிலிருந்து உருவாக்கப்படுகிறது, மோதல்களை Tailscale தீர்க்கிறது, முடிவு tailnet களத்தின் கீழ் வாழ்கிறது. அலுவலக மண்டலத்தை அலுவலகத் தீர்வியை இயக்குபவர் பராமரிக்கிறார், பதிவுகள் நிர்வாகி அல்லது மாறும் பதிவு மூலம் உருவாக்கப்படுகின்றன. குறுகிய பெயர்கள் வேறுபாட்டை மறைக்கின்றன: files அலுவலக DNS பதிலளிக்கும் தேடல் பின்னொட்டு விரிவாக்கம், ஒரு tailnet சாதனம், அல்லது எதுவும் இல்லாமல் இருக்கலாம். முழுப் பெயரை வினவினால் எந்த அமைப்பு உண்மையில் பதிலளித்தது என்று தெரியும்.

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

அலுவலக மண்டலத்தை அதன் தீர்வியை நோக்கித் திருப்புங்கள்

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

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

அணுகல் தீர்வுக்கு முன் வருகிறது

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

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

பெயரின் தோல்வியைச் சேவையின் தோல்வியிலிருந்து பிரிக்கவும்

வளம் அதன் தனியார் முகவரியில் பதிலளித்தால் ஆனால் ஹோஸ்ட் பெயரில் இல்லையெனில், விசாரணை DNS-இலேயே இருக்கும். இரண்டும் வேலை செய்யவில்லை என்றால், முதலில் வழித்தடம் அல்லது சேவையைச் சரிசெய்யுங்கள், ஏனெனில் அடைய முடியாத முகவரிக்குத் தீர்க்கப்படும் பெயர் முன்னேற்றம் அல்ல. முழுப் பெயரை வினவி எந்த சேவையகம் பதிலளித்தது என்பதைக் குறிப்பிடுங்கள். macOS-இல் சில கட்டளை வரி கருவிகள் சாதாரண பயன்பாடுகளிலிருந்து வேறு பாதையை எடுக்கின்றன, எனவே ஒரு முனையம் dig மற்றும் ஒரு உலாவி ஒரே பெயரைப் பற்றி உடன்படாமல் இருக்கலாம்.

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

மண்டலம், தீர்வியின் முகவரி மற்றும் வினவலைச் சுமக்கும் வழித்தடத்தைப் பதிவு செய்யுங்கள். இந்த மூன்றும் மற்றொரு மறுபெயரிடல் சுற்று இல்லாமல் பெரும்பாலான MagicDNS ஆச்சரியங்களை விளக்குகின்றன.