வேகமான இணைய உலாவலுக்கு குறைந்த டிஎன்எஸ் தாமதம் முக்கியமானது. அதைக் குறைக்க, டிஎன்எஸ் சேவையகங்களை கவனமாகத் தேர்ந்தெடுப்பது முக்கியம் . ஆனால் பயனற்ற கேள்விகளை அகற்றுவதே முதல் படி.
அதனால்தான் டிஎன்எஸ் முதலில் அதிக கேச் செய்யக்கூடிய நெறிமுறையாக வடிவமைக்கப்பட்டது. மண்டல நிர்வாகிகள் தனிப்பட்ட உள்ளீடுகளுக்கு நேரலை (TTL) அமைத்துள்ளனர், மேலும் தேவையற்ற போக்குவரத்தைத் தவிர்க்க நினைவகத்தில் உள்ளீடுகளைச் சேமிக்கும்போது இந்தத் தகவலைத் தீர்ப்பவர்கள் பயன்படுத்துகின்றனர்.
கேச்சிங் பயனுள்ளதா? சில ஆண்டுகளுக்கு முன்பு, எனது சிறிய ஆராய்ச்சி அது சரியானது அல்ல என்பதைக் காட்டுகிறது. இப்போதைய நிலையைப் பார்ப்போம்.
தகவலை சேகரிக்க நான் ஒட்டினேன் பதிலுக்கான TTL மதிப்பைச் சேமிக்க. ஒவ்வொரு உள்வரும் கோரிக்கைக்கான பதிவுகளின் குறைந்தபட்ச TTL ஆக இது வரையறுக்கப்படுகிறது. இது உண்மையான போக்குவரத்தின் TTL விநியோகத்தின் நல்ல கண்ணோட்டத்தை அளிக்கிறது, மேலும் தனிப்பட்ட கோரிக்கைகளின் பிரபலத்தையும் கணக்கில் எடுத்துக்கொள்கிறது. சேவையகத்தின் பேட்ச் செய்யப்பட்ட பதிப்பு பல மணிநேரம் வேலை செய்தது.
இதன் விளைவாக வரும் தரவுத் தொகுப்பு 1 பதிவுகளைக் கொண்டுள்ளது (பெயர், qtype, TTL, நேர முத்திரை). இதோ ஒட்டுமொத்த TTL விநியோகம் (X-axis என்பது TTL வினாடிகளில்):
86 இல் ஒரு சிறிய பம்ப் தவிர (பெரும்பாலும் SOA பதிவுகளுக்கு), TTLகள் குறைந்த வரம்பில் உள்ளன என்பது தெளிவாகத் தெரிகிறது. ஒரு நெருக்கமான தோற்றத்தை எடுப்போம்:
சரி, 1 மணிநேரத்திற்கும் அதிகமான TTLகள் புள்ளியியல் ரீதியாக முக்கியத்துவம் வாய்ந்தவை அல்ல. பின்னர் 0−3600 வரம்பில் கவனம் செலுத்துவோம்:
பெரும்பாலான TTLகள் 0 முதல் 15 நிமிடங்கள் வரை:
பெரும்பாலானவை 0 முதல் 5 நிமிடங்கள் வரை:
இது மிகவும் நன்றாக இல்லை.
ஒட்டுமொத்த விநியோகம் சிக்கலை இன்னும் தெளிவாக்குகிறது:
பாதி DNS பதில்கள் 1 நிமிடம் அல்லது அதற்கும் குறைவான TTL ஐக் கொண்டுள்ளன, மேலும் முக்கால்வாசி 5 நிமிடங்கள் அல்லது அதற்கும் குறைவான TTL ஐக் கொண்டிருக்கும்.
ஆனால் காத்திருங்கள், அது உண்மையில் மோசமானது. எல்லாவற்றிற்கும் மேலாக, இது அதிகாரப்பூர்வ சேவையகங்களிலிருந்து TTL ஆகும். இருப்பினும், கிளையன்ட் ரிசல்வர்ஸ் (எ.கா. ரூட்டர்கள், லோக்கல் கேச்) அப்ஸ்ட்ரீம் ரிசல்வர்களிடமிருந்து TTLஐப் பெறுகின்றன, மேலும் அது ஒவ்வொரு நொடியும் குறைகிறது.
எனவே கிளையன்ட் உண்மையில் ஒவ்வொரு பதிவையும் புதிய கோரிக்கையை அனுப்பும் முன், சராசரியாக பாதி அசல் TTLக்கு பயன்படுத்தலாம்.
இந்த மிகக் குறைந்த TTLகள் வழக்கத்திற்கு மாறான கோரிக்கைகளுக்கு மட்டுமே பொருந்தும் மற்றும் பிரபலமான இணையதளங்கள் மற்றும் APIகளுக்கு அல்லவா? பார்ப்போம்:
X அச்சு TTL மற்றும் Y அச்சு வினவல் பிரபலம்.
துரதிர்ஷ்டவசமாக, மிகவும் பிரபலமான வினவல்கள் தற்காலிக சேமிப்பில் மோசமானவை.
பெரிதாக்குவோம்:
தீர்ப்பு: இது மிகவும் மோசமானது. இது ஏற்கனவே மோசமாக இருந்தது, ஆனால் அது இன்னும் மோசமாகிவிட்டது. DNS கேச்சிங் கிட்டத்தட்ட பயனற்றதாகிவிட்டது. குறைவான நபர்கள் தங்கள் ISP இன் DNS தீர்வை (நல்ல காரணங்களுக்காக) பயன்படுத்துவதால், தாமதத்தின் அதிகரிப்பு மிகவும் கவனிக்கத்தக்கது.
யாரும் பார்வையிடாத உள்ளடக்கத்திற்கு மட்டுமே DNS கேச்சிங் பயனுள்ளதாகிவிட்டது.
மென்பொருள் இருக்கலாம் என்பதையும் கவனத்தில் கொள்ளவும் குறைந்த TTLகளை விளக்குகிறது.
அது ஏன்?
DNS பதிவுகள் ஏன் இவ்வளவு குறைந்த TTLக்கு அமைக்கப்பட்டுள்ளன?
- லெகசி லோட் பேலன்சர்கள் இயல்புநிலை அமைப்புகளுடன் விடப்பட்டன.
- டிஎன்எஸ் சுமை சமநிலை TTL ஐச் சார்ந்தது என்று கட்டுக்கதைகள் உள்ளன (இது உண்மையல்ல - நெட்ஸ்கேப் நேவிகேட்டரின் நாட்களில் இருந்து, வாடிக்கையாளர்கள் RR களின் தொகுப்பிலிருந்து ஒரு சீரற்ற IP முகவரியைத் தேர்ந்தெடுத்து, அவர்களால் இணைக்க முடியாவிட்டால் வெளிப்படையாக வேறு ஒன்றை முயற்சித்தனர்)
- நிர்வாகிகள் உடனடியாக மாற்றங்களைப் பயன்படுத்த விரும்புகிறார்கள், எனவே திட்டமிடுவது எளிது.
- DNS சர்வர் அல்லது லோட் பேலன்சரின் நிர்வாகி தனது பணியை பயனர்கள் கோரும் உள்ளமைவை திறம்பட பயன்படுத்துவதையும், தளங்கள் மற்றும் சேவைகளை விரைவுபடுத்தாமல் இருப்பதையும் பார்க்கிறார்.
- குறைந்த TTLகள் உங்களுக்கு மன அமைதியைத் தருகின்றன.
- மக்கள் ஆரம்பத்தில் குறைந்த TTLகளை சோதனைக்காக அமைத்து, பின்னர் அவற்றை மாற்ற மறந்துவிடுகிறார்கள்.
"தோல்வியை" நான் பட்டியலில் சேர்க்கவில்லை, ஏனெனில் அது குறைவான தொடர்புடையதாகி வருகிறது. மற்ற அனைத்தும் முற்றிலும் உடைந்துவிட்டால், பிழைப் பக்கத்தைக் காண்பிக்க, பயனர்களை வேறொரு நெட்வொர்க்கிற்குத் திருப்பிவிட வேண்டும் என்றால், 1 நிமிடத்திற்கு மேல் தாமதம் ஏற்கத்தக்கது.
கூடுதலாக, ஒரு நிமிட TTL என்பது அதிகாரப்பூர்வ DNS சேவையகங்கள் 1 நிமிடத்திற்கு மேல் தடுக்கப்பட்டால், வேறு யாரும் சார்ந்த சேவைகளை அணுக முடியாது. காரணம் உள்ளமைவு பிழை அல்லது ஹேக் என்றால் பணிநீக்கம் உதவாது. மறுபுறம், நியாயமான TTLகளுடன், பல வாடிக்கையாளர்கள் முந்தைய உள்ளமைவைத் தொடர்ந்து பயன்படுத்துவார்கள் மற்றும் எதையும் கவனிக்க மாட்டார்கள்.
சிடிஎன் சேவைகள் மற்றும் லோட் பேலன்சர்கள் குறைந்த TTL களுக்குப் பெரும்பாலும் காரணம் ஆகும், குறிப்பாக அவை CNAMEகளை குறைந்த TTLகள் மற்றும் பதிவுகளை சமமான குறைந்த (ஆனால் சுயாதீனமான) TTLகளுடன் இணைக்கும்போது:
$ drill raw.githubusercontent.com raw.githubusercontent.com. 9 IN CNAME github.map.fastly.net. github.map.fastly.net. 20 IN A 151.101.128.133 github.map.fastly.net. 20 IN A 151.101.192.133 github.map.fastly.net. 20 IN A 151.101.0.133 github.map.fastly.net. 20 IN A 151.101.64.133
CNAME அல்லது ஏதேனும் A பதிவுகள் காலாவதியாகும் போதெல்லாம், ஒரு புதிய கோரிக்கை அனுப்பப்பட வேண்டும். இரண்டும் 30 வினாடி TTL ஐக் கொண்டுள்ளன, ஆனால் அது ஒன்றல்ல. உண்மையான சராசரி TTL 15 வினாடிகளாக இருக்கும்.
ஆனால் காத்திருங்கள்! இது இன்னும் மோசமானது. சில தீர்வுகள் இந்த சூழ்நிலையில் இரண்டு தொடர்புடைய குறைந்த TTLகளுடன் மிகவும் மோசமாக நடந்து கொள்கின்றன:
$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 IN CNAME github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133
Level3 ரிசல்வர் ஒருவேளை BIND இல் இயங்கும். இந்தக் கோரிக்கையை நீங்கள் தொடர்ந்து அனுப்பினால், 1 இன் TTL திரும்பப் பெறப்படும். முக்கியமாக, raw.githubusercontent.com ஒருபோதும் தற்காலிகமாக சேமிக்கப்படவில்லை.
மிகவும் பிரபலமான டொமைனுடன் அத்தகைய சூழ்நிலையின் மற்றொரு எடுத்துக்காட்டு இங்கே:
$ drill detectportal.firefox.com @1.1.1.1 detectportal.firefox.com. 25 IN CNAME detectportal.prod.mozaws.net. detectportal.prod.mozaws.net. 26 IN CNAME detectportal.firefox.com-v2.edgesuite.net. detectportal.firefox.com-v2.edgesuite.net. 10668 IN CNAME a1089.dscd.akamai.net. a1089.dscd.akamai.net. 10 IN A 104.123.50.106 a1089.dscd.akamai.net. 10 IN A 104.123.50.88
குறைந்தது மூன்று CNAME பதிவுகள். ஏய். ஒருவருக்கு ஒழுக்கமான TTL உள்ளது, ஆனால் அது முற்றிலும் பயனற்றது. பிற CNAMEகள் 60 வினாடிகளின் ஆரம்ப TTL ஐக் கொண்டுள்ளன, ஆனால் களங்களுக்கு akamai.net அதிகபட்ச TTL 20 வினாடிகள் மற்றும் அவற்றில் எதுவும் கட்டத்தில் இல்லை.
ஆப்பிள் சாதனங்களை தொடர்ந்து வாக்கெடுப்பு செய்யும் டொமைன்கள் பற்றி என்ன?
$ drill 1-courier.push.apple.com @4.2.2.2 1-courier.push.apple.com. 1253 IN CNAME 1.courier-push-apple.com.akadns.net. 1.courier-push-apple.com.akadns.net. 1 IN CNAME gb-courier-4.push-apple.com.akadns.net. gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.84 gb-courier-4.push-apple.com.akadns.net. 1 IN A 17.57.146.85
பயர்பாக்ஸ் மற்றும் TTL போன்ற அதே பிரச்சனை Level1 தீர்வைப் பயன்படுத்தும் போது பெரும்பாலான நேரங்களில் 3 வினாடியில் சிக்கியிருக்கும்.
டிராப்பாக்ஸ்?
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 IN A 162.125.67.3 $ drill client.dropbox.com @4.2.2.2 client.dropbox.com. 1 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 IN A 162.125.64.3
பதிவில் safebrowsing.googleapis.com TTL மதிப்பு Facebook டொமைன்களைப் போலவே 60 வினாடிகள் ஆகும். மேலும், மீண்டும், வாடிக்கையாளரின் பார்வையில், இந்த மதிப்புகள் பாதியாகக் குறைக்கப்படுகின்றன.
குறைந்தபட்ச TTL ஐ அமைப்பது எப்படி?
பெயர், கோரிக்கை வகை, TTL மற்றும் ஆரம்பத்தில் சேமிக்கப்பட்ட நேர முத்திரை ஆகியவற்றைப் பயன்படுத்தி, காலாவதியான கேச் உள்ளீடு காரணமாக அனுப்பப்பட்ட தேவையற்ற கோரிக்கைகளின் அளவைக் கணக்கிட, கேச்சிங் ரிசல்வர் மூலம் 1,5 மில்லியன் கோரிக்கைகளை உருவகப்படுத்த ஒரு ஸ்கிரிப்டை எழுதினேன்.
ஏற்கனவே உள்ள பதிவு காலாவதியான பிறகு 47,4% கோரிக்கைகள் செய்யப்பட்டன. இது நியாயமற்ற உயர்வானது.
குறைந்தபட்ச TTL அமைக்கப்பட்டால், தற்காலிக சேமிப்பில் என்ன தாக்கம் இருக்கும்?
X அச்சு என்பது குறைந்தபட்ச TTL மதிப்புகள். இந்த மதிப்புக்கு மேல் மூல TTLகள் கொண்ட பதிவுகள் பாதிக்கப்படாது.
Y அச்சு என்பது கிளையண்டின் கோரிக்கைகளின் சதவீதமாகும், அது ஏற்கனவே தற்காலிக சேமிப்பு உள்ளீட்டைக் கொண்டுள்ளது, ஆனால் அது காலாவதியானது மற்றும் புதிய கோரிக்கையை உருவாக்குகிறது.
குறைந்தபட்ச TTL ஐ 47 நிமிடங்களாக அமைப்பதன் மூலம் "கூடுதல்" கோரிக்கைகளின் பங்கு 36% இலிருந்து 5% ஆக குறைக்கப்படுகிறது. குறைந்தபட்ச TTL ஐ 15 நிமிடங்களாக அமைப்பதன் மூலம், இந்த கோரிக்கைகளின் எண்ணிக்கை 29% ஆக குறைகிறது. குறைந்தபட்ச TTL 1 மணிநேரம் அவற்றை 17% ஆகக் குறைக்கிறது. குறிப்பிடத்தக்க வேறுபாடு!
சர்வர் பக்கத்தில் எதையும் மாற்றாமல், அதற்கு பதிலாக கிளையன்ட் டிஎன்எஸ் கேச்களில் (ரவுட்டர்கள், லோக்கல் ரிசல்வர்ஸ்) குறைந்தபட்ச TTL ஐ அமைப்பது எப்படி?
தேவைப்படும் கோரிக்கைகளின் எண்ணிக்கை குறைந்தபட்சம் 47 நிமிடங்களில் 34% இலிருந்து 5% ஆகவும், குறைந்தபட்சம் 25 நிமிடங்களில் 15% ஆகவும், குறைந்தபட்சம் 13 மணிநேரத்தில் 1% ஆகவும் குறைகிறது. ஒருவேளை 40 நிமிடங்கள் உகந்ததாக இருக்கலாம்.
இந்த சிறிய மாற்றத்தின் தாக்கம் மிகப்பெரியது.
பின்விளைவுகள் என்ன?
நிச்சயமாக, சேவையை புதிய கிளவுட் வழங்குநர், புதிய சர்வர், புதிய நெட்வொர்க்கிற்கு நகர்த்தலாம், வாடிக்கையாளர்கள் சமீபத்திய டிஎன்எஸ் பதிவுகளைப் பயன்படுத்த வேண்டும். மற்றும் மிகவும் சிறிய TTL அத்தகைய மாற்றத்தை சீராக மற்றும் கண்ணுக்கு தெரியாத வகையில் செய்ய உதவுகிறது. ஆனால் புதிய உள்கட்டமைப்புக்கு மாறுவதால், வாடிக்கையாளர்கள் 1 நிமிடம், 5 நிமிடங்கள் அல்லது 15 நிமிடங்களுக்குள் புதிய DNS பதிவுகளுக்கு இடம்பெயர்வார்கள் என்று யாரும் எதிர்பார்க்கவில்லை. குறைந்தபட்ச TTL ஐ 40 நிமிடங்களுக்குப் பதிலாக 5 நிமிடங்களாக அமைப்பது பயனர்கள் சேவையை அணுகுவதைத் தடுக்காது.
இருப்பினும், இது தாமதத்தை கணிசமாகக் குறைக்கும் மற்றும் தேவையற்ற கோரிக்கைகளைத் தவிர்ப்பதன் மூலம் தனியுரிமை மற்றும் நம்பகத்தன்மையை மேம்படுத்தும்.
நிச்சயமாக, TTL கண்டிப்பாக பின்பற்றப்பட வேண்டும் என்று RFCகள் கூறுகின்றன. ஆனால் உண்மை என்னவென்றால், DNS அமைப்பு மிகவும் திறமையற்றதாகிவிட்டது.
நீங்கள் அதிகாரப்பூர்வ DNS சேவையகங்களுடன் பணிபுரிகிறீர்கள் என்றால், தயவுசெய்து உங்கள் TTLகளை சரிபார்க்கவும். இதுபோன்ற அபத்தமான குறைந்த மதிப்புகள் உங்களுக்கு உண்மையிலேயே தேவையா?
நிச்சயமாக, DNS பதிவுகளுக்கு சிறிய TTLகளை அமைக்க நல்ல காரணங்கள் உள்ளன. ஆனால் கிட்டத்தட்ட மாறாமல் இருக்கும் 75% DNS டிராஃபிக்கிற்கு அல்ல.
மேலும் சில காரணங்களால் நீங்கள் DNS க்காக குறைந்த TTLகளைப் பயன்படுத்த வேண்டும் என்றால், அதே நேரத்தில் உங்கள் தளத்தில் கேச்சிங் இயக்கப்படவில்லை என்பதை உறுதிப்படுத்தவும். அதே காரணங்களுக்காக.
உங்களிடம் உள்ளூர் DNS கேச் இயங்கினால், எடுத்துக்காட்டாக குறைந்தபட்ச TTLகளை அமைக்க இது உங்களை அனுமதிக்கிறது, இந்த செயல்பாட்டைப் பயன்படுத்தவும். இது நன்று. மோசமான எதுவும் நடக்காது. குறைந்தபட்ச TTL ஐ தோராயமாக 40 நிமிடங்கள் (2400 வினாடிகள்) மற்றும் 1 மணிநேரமாக அமைக்கவும். மிகவும் நியாயமான வரம்பு.
ஆதாரம்: www.habr.com