தனியுரிமை Route 53 மண்டலம் பொது பெயர்களுக்கு NXDOMAIN திருப்புவது ஏன்

தனியுரிமை Route 53 மண்டலங்கள் பொது பதிவோடு இணைவதற்குப் பதிலாக பெயருக்கான பதிலை மாற்றுகின்றன, அதனால்தான் மிக மோசமான நேரத்தில் மக்கள் ஆச்சரியப்படுகிறார்கள். ஒரு உள் பதிவைச் சேர்க்கவும் api.example.net க்காக ஒரு தனியுரிமை மண்டலத்தில் example.net, அதை ஒரு VPC உடன் இணைக்கவும், அந்தப் பெற்றோரின் கீழ் உள்ள மற்ற ஒவ்வொரு பெயரும் இப்போது தனியுரிமை மண்டலத்திலிருந்து மட்டுமே பதிலளிக்கப்படுகிறது. நேற்று www.example.net வரை செல்ல முடிந்த வாடிக்கையாளருக்கு இன்று எதிர்மறை பதில் கிடைக்கிறது. கீழேயுள்ள விளக்கம் அந்தத் தோல்வியடைந்த வினவலில் தொடங்கி பதிலளித்த மண்டலத்தை நோக்கி வெளியே செல்கிறது.

கன்சோலில் இருந்து அல்ல, வினவலில் இருந்து தொடங்குங்கள்

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

dig +short api.example.net
dig www.example.net +noall +comments +authority
resolvectl query www.example.net

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

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

எந்த மண்டலம் பதிலளித்தது எனப் படியுங்கள்

பின்வருவதைக் கொண்ட பதில்: NXDOMAIN மற்றும் authority பகுதியில் தனியுரிமை மண்டலத்தின் SOA இருந்தால், அது அந்த மண்டலத்தின் இறுதிப் பதில், தோல்வியடைந்த தேடல் அல்ல. Route 53 Resolver பெயர் பொருந்தியதால் தனியுரிமை ஹோஸ்ட் செய்யப்பட்ட மண்டலத்தைத் தேர்ந்தெடுத்தது, பின்னர் கோரப்பட்ட வகையின் பதிவு எதுவும் கிடைக்கவில்லை, ஆவணப்படுத்தப்பட்ட நடத்தை என்பது கேள்வியை பொது DNS-க்கு அனுப்புவதற்குப் பதிலாக எதிர்மறை பதிலைத் திருப்புவதாகும்.

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

aws route53 list-hosted-zones-by-name --dns-name example.net.
aws route53 list-resource-record-sets --hosted-zone-id Z0EXAMPLEID --query "ResourceRecordSets[?Type=='A'].[Name,ResourceRecords[0].Value]"

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

தனியுரிமை மண்டலம் ஏன் வெல்லுகிறது

மண்டலத்தை VPC-க்குத் தெரியச் செய்வது இணைப்புதான், அந்த VPC-யில் உள்ள resolver அதைப் பயன்படுத்துகிறது. வாடிக்கையாளரின் போக்குவரத்து வரும் VPC-உடன் இணைக்கப்படாத தனியுரிமை மண்டலத்திற்கு எந்த விளைவும் இல்லை, தவறான VPC-உடன் இணைப்பு தவறான மக்கள்தொகைக்குத் தனியுரிமை பதிலை உருவாக்குகிறது. பதிவுகளைத் திருத்தும் முன் இணைப்புப் பட்டியலைச் சரிபார்க்கவும், ஏனெனில் மண்டலம் சரியாக இருந்தும் கண்ணுக்குத் தெரியாமல் இருக்கலாம்.

மேலிடும் பெயர் இடைவெளிகள் குழப்பத்தின் இரண்டாவது மூலம். example.net க்கான தனியுரிமை மண்டலமும் api.example.net க்கான தனியுரிமை மண்டலமும் இரண்டும் API வினவலுடன் பொருந்துகின்றன, மேலும் குறிப்பானது பதிலளிக்கிறது. குறுகிய உள் பெயர் இடைவெளி வேண்டும்போது இது பயனுள்ளது, குறுகிய மண்டலத்தில் பரந்த மண்டலத்தில் உள்ள பதிவு இல்லாதபோது ஆபத்தானது. தனியுரிமை ஹோஸ்ட் செய்யப்பட்ட மண்டலங்கள் பற்றிய பரிசீலனைகள் Route 53 ஆவணங்களில் கீழ்நோக்கி விழும் நடத்தையையும் விதிகளின் முன்னுரிமையையும் விவரிக்கின்றன, இரண்டாவது மேலிடும் மண்டலத்தைச் சேர்ப்பதற்கு முன் அவற்றைப் படிக்க வேண்டியது.

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

பதிவுகளைச் சேர்ப்பதற்கு முன் பெயர் இடைவெளியைத் தேர்ந்தெடுங்கள்

உள் சேவைகளின் புதிய குடும்பத்திற்கு மட்டும் தனியுரிமை பெயர்கள் தேவைப்பட்டால், அதற்கு அர்ப்பணிக்கப்பட்ட தனியுரிமை துணைக்களத்தைக் கொடுத்து பொது பெற்றோரை விட்டுவிடுங்கள். internal.example.net போன்ற பெயர் www.example.net ஐ மறைக்க முடியாது, மேலும் காணாமல் போன பதிவின் தாக்க வீச்சு அந்த நோக்கத்திற்காக நீங்கள் உருவாக்கிய பெயர்களுக்கு மட்டுமே. விலை என்னவென்றால், ஏற்கனவே உள்ள URL-களும் சான்றிதழ்களும் புதிய பெயருடன் பொருந்தாமல் போகலாம்.

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

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

resolver-இன் பாதையையும், பின்னர் வழித்தடத்தையும் தடமறியுங்கள்

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

பெயர் தீர்க்கப்பட்ட பிறகு, திருப்பிய முகவரிக்கான பாதையைத் தனி படியாகச் சோதியுங்கள், உதாரணமாக ip route get கொண்டு வினவல் திருப்பிய முகவரிக்கு எதிராக. முகவரிக்கு வழித்தடம் இல்லாத சரியான தனியுரிமை பதில் வழியமைப்பு சிக்கல், பதிவு இல்லை என்ற பதில் DNS காட்சி சிக்கல்; இரண்டையும் ஒரே சிக்கலாகக் கருதினால் நிலைத்திருக்காத திருத்தங்கள் வரும். சேவையின் TLS ஹோஸ்ட் பெயர் மற்றும் சான்றிதழ் சரிபார்ப்புகளை மாற்றாமல் விடுங்கள், ஏனெனில் தனியுரிமை முகவரி இணைப்பு எங்கு செல்கிறது என்பதை மாற்றுகிறது, எந்தச் சான்றிதழ் செல்லுபடியாகும் என்பதில் எதையும் அல்ல.

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