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

ஒவ்வொரு இணைப்புத் தொகுதியும் உங்களுக்குச் சொல்வது

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

/etc/resolv.conf இல் 127.0.0.53 போன்ற stub முகவரி stub முன்னால் உள்ளது என்று மட்டுமே சொல்கிறது। அது பதிலளித்த மேல் மூலத்தைப் பெயரிடவில்லை, அதனால் resolv.conf மட்டுமே அடிப்படையாகக் கொண்ட கண்டறிதல் தடைபடுகிறது।

மூன்று வகை களப் பதிவுகளைச் சரியாகப் படியுங்கள்

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

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

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

ஒரு பெயரைக் கேட்டு எந்த இணைப்பு பதிலளித்தது என்பதைப் பாருங்கள்

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

resolvectl status
resolvectl query host.corp.example

தெரிவிக்கப்பட்ட நெறிமுறையையும் கவனியுங்கள், ஏனெனில் தற்காலிகச் சேமிப்பு அல்லது hosts கோப்பிலிருந்து பதில் எந்த மேல் மூலத்தையும் கேட்காமல் வரலாம்। தற்காலிகச் சேமிப்பிலிருந்து பதில் பெயர் எப்போதோ தீர்க்கப்பட்டது என்பதை நிரூபிக்கிறது, தற்போதைய கொள்கை அதைச் சரியாக வழிப்படுத்துகிறது என்பதை அல்ல।

பெயர் வழிப்பாதையைப் பாக்கெட் வழிப்பாதையிலிருந்து தனியே வைத்திருங்கள்

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

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

பெயர் தீர்க்கப்பட்ட முகவரியை இணைப்பிற்கு அருகில் பதிவு செய்யுங்கள்। தவறான முகவரியைச் சுட்டும் சரியான பெயர் வழிப்பாதை அல்ல, பதிவின் சிக்கல்।

இணைப்பு மாறிய பிறகு மீண்டும் சரிபார்க்கவும்

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

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

தொடர்புடைய கட்டுரைகள்