వేగవంతమైన ఇంటర్నెట్ బ్రౌజింగ్‌కు తక్కువ DNS జాప్యం కీలకం. దీన్ని తగ్గించడానికి, DNS సర్వర్‌లను జాగ్రత్తగా ఎంచుకోవడం మరియు . కానీ మొదటి దశ పనికిరాని ప్రశ్నలను వదిలించుకోవడమే.
అందుకే DNS నిజానికి అత్యంత క్యాచీ చేయగల ప్రోటోకాల్‌గా రూపొందించబడింది. జోన్ అడ్మినిస్ట్రేటర్‌లు వ్యక్తిగత ఎంట్రీల కోసం లైవ్ (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కి ఎందుకు సెట్ చేయబడ్డాయి?
- లెగసీ లోడ్ బ్యాలెన్సర్‌లు డిఫాల్ట్ సెట్టింగ్‌లతో మిగిలి ఉన్నాయి.
- DNS లోడ్ బ్యాలెన్సింగ్ అనేది TTLపై ఆధారపడి ఉంటుందని అపోహలు ఉన్నాయి (ఇది నిజం కాదు - నెట్‌స్కేప్ నావిగేటర్ కాలం నుండి, క్లయింట్లు RRల సెట్ నుండి యాదృచ్ఛిక IP చిరునామాను ఎంచుకున్నారు మరియు వారు కనెక్ట్ చేయలేకపోతే పారదర్శకంగా మరొకదాన్ని ప్రయత్నించారు)
- నిర్వాహకులు వెంటనే మార్పులను వర్తింపజేయాలనుకుంటున్నారు, కాబట్టి ప్లాన్ చేయడం సులభం.
- DNS సర్వర్ లేదా లోడ్ బ్యాలెన్సర్ యొక్క నిర్వాహకుడు తన పనిని వినియోగదారులు అభ్యర్థించే కాన్ఫిగరేషన్‌ను సమర్ధవంతంగా అమలు చేయడం మరియు సైట్‌లు మరియు సేవలను వేగవంతం చేయకుండా చూస్తారు.
- తక్కువ TTLలు మీకు మనశ్శాంతిని ఇస్తాయి.
- ప్రజలు మొదట్లో పరీక్ష కోసం తక్కువ TTLలను సెట్ చేసి, ఆపై వాటిని మార్చడం మర్చిపోతారు.
నేను జాబితాలో "ఫెయిల్‌ఓవర్"ని చేర్చలేదు ఎందుకంటే ఇది తక్కువ మరియు తక్కువ సందర్భోచితంగా మారుతోంది. మీరు వినియోగదారులను మరొక నెట్‌వర్క్‌కు దారి మళ్లించవలసి వస్తే, మిగతావన్నీ పూర్తిగా విచ్ఛిన్నమైనప్పుడు ఎర్రర్ పేజీని ప్రదర్శించడానికి, 1 నిమిషం కంటే ఎక్కువ ఆలస్యం చేయడం ఆమోదయోగ్యమైనది.
అదనంగా, ఒక-నిమిషం TTL అంటే అధికారిక DNS సర్వర్‌లు 1 నిమిషం కంటే ఎక్కువ బ్లాక్ చేయబడితే, ఎవరూ ఆధారిత సేవలను యాక్సెస్ చేయలేరు. కారణం కాన్ఫిగరేషన్ లోపం లేదా హ్యాక్ అయితే రిడెండెన్సీ సహాయం చేయదు. మరోవైపు, సహేతుకమైన TTLలతో, చాలా మంది క్లయింట్లు మునుపటి కాన్ఫిగరేషన్‌ను ఉపయోగించడం కొనసాగిస్తారు మరియు దేనినీ గమనించరు.
CDN సేవలు మరియు లోడ్ బ్యాలెన్సర్‌లు తక్కువ 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లతో చాలా చెడుగా ప్రవర్తిస్తారు:
$ డ్రిల్ 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 సెకన్లు మరియు వాటిలో ఏవీ దశలో లేవు.
Apple పరికరాలను నిరంతరం పోల్ చేసే డొమైన్‌ల గురించి ఏమిటి?
$ 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
Level1 పరిష్కరిణిని ఉపయోగిస్తున్నప్పుడు Firefox మరియు TTL వంటి అదే సమస్య ఎక్కువ సమయం 3 సెకనులో నిలిచిపోతుంది.
డ్రాప్‌బాక్స్?
$ డ్రిల్ 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%కి పడిపోతుంది. కనీసం 1 గంట TTL వాటిని 17%కి తగ్గిస్తుంది. ముఖ్యమైన తేడా!
సర్వర్ వైపు దేన్నీ మార్చకుండా, బదులుగా క్లయింట్ DNS కాష్‌లలో (రౌటర్‌లు, లోకల్ రిసల్వర్‌లు) కనీస TTLని సెట్ చేయడం ఎలా?
అవసరమైన అభ్యర్థనల సంఖ్య కనీసం 47 నిమిషాల TTLతో 34% నుండి 5%కి, కనిష్టంగా 25 నిమిషాలతో 15%కి మరియు కనీసం 13 గంటతో 1%కి తగ్గుతుంది. బహుశా 40 నిమిషాలు సరైనది.
ఈ చిన్న మార్పు ప్రభావం అపారమైనది.
పరిణామాలు ఏమిటి?
వాస్తవానికి, సేవను కొత్త క్లౌడ్ ప్రొవైడర్, కొత్త సర్వర్, కొత్త నెట్‌వర్క్‌కి తరలించవచ్చు, క్లయింట్లు తాజా DNS రికార్డ్‌లను ఉపయోగించాల్సి ఉంటుంది. మరియు చాలా చిన్న 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