VPN வழியாக NXDOMAIN என்பது சுரங்கப்பாதை செயலிழப்பு அல்ல

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

பதில் உண்மையில் எதை நிறுவுகிறது

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

அந்த வேறுபாடு பழுதுநீக்கம் எங்கே இருக்க வேண்டும் என்பதைத் தீர்மானிக்கிறது. A பதிவு உள்ள புரவலனில் AAAA பதிவு இல்லாதிருப்பது புரவலன் இல்லாதிருப்பது அல்ல, அதைத் தொடர்ந்து சான்றிதழை மீண்டும் வழங்குவது அல்லது சுரங்கப்பாதையை மீண்டும் கட்டுவது கிடைத்த ஒரே துப்பை வீணாக்குகிறது. இந்த வேறுபாடு அடுத்த படியின் வடிவத்தையும் தீர்மானிக்கிறது: பெயரிடல் சிக்கல் மண்டலத்தில் சரிசெய்யப்படுகிறது, வகை சிக்கல் சரியான பதிவைக் கேட்பதன் மூலம் அல்லது முகவரி குடும்பம் வெறுமனே இல்லை என்பதை ஏற்றுக்கொள்வதன் மூலம் சரிசெய்யப்படுகிறது.

கட்டுக்கதை: தனிப்பட்ட பெயர் இல்லாதிருப்பது சுரங்கப்பாதை தோல்வியடைந்தது என்பதே

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

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

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

சரியான பெயருடன் சரியான தீர்வியைக் கேளுங்கள்

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

resolvectl query vpn.internal.example
resolvectl status | grep -A3 'DNS Servers'
dig +search app.intranet.example A
dig @10.8.0.1 app.intranet.example A

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

எதிர்மறை தேக்ககம் சரிசெய்தலுக்குப் பிந்தைய தாமதத்தை விளக்குகிறது

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

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

பெயரைப் பாதையிலிருந்து பிரிக்கவும்

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

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