د DNS ټیټ ځنډ د ګړندي انټرنیټ لټون کولو کلیدي ده. د دې د کمولو لپاره، دا مهمه ده چې په دقت سره د DNS سرورونه غوره کړئ او . مګر لومړی ګام د بې ګټې پوښتنو څخه خلاصول دي.
له همدې امله DNS په اصل کې د خورا کیچ وړ پروتوکول په توګه ډیزاین شوی و. د زون مدیران د انفرادي ننوتلو لپاره د ژوند کولو وخت (TTL) ټاکي، او حل کونکي دا معلومات کاروي کله چې په حافظه کې ننوتنې ذخیره کوي ترڅو د غیر ضروري ترافیک مخه ونیسي.
ایا کیشینګ اغیزمن دی؟ څو کاله دمخه، زما کوچنۍ څیړنې وښودله چې دا بشپړ نه و. راځئ چې د هیواد اوسني وضعیت ته یوه کتنه وکړو.
د معلوماتو راټولولو لپاره ما پیچ کړی د ځواب لپاره د TTL ارزښت خوندي کولو لپاره. دا د هرې راتلونکې غوښتنې لپاره د دې ریکارډونو لږترلږه TTL په توګه تعریف شوی. دا د ریښتیني ترافیک TTL ویش یوه ښه کتنه وړاندې کوي، او د انفرادي غوښتنو شهرت هم په پام کې نیسي. د سرور پیچ شوی نسخه د څو ساعتونو لپاره کار کاوه.
د پایلې ډاټا 1 ریکارډونه لري (نوم، qtype، TTL، timestamp). دلته د TTL ټولیز ویش دی (X-axis په ثانیو کې TTL دی):
په 86 کې د کوچني ډنډ سربیره (اکثره د SOA ریکارډونو لپاره) ، دا خورا روښانه ده چې TTLs په ټیټ حد کې دي. راځئ چې نږدې وګورو:
ښه، د 1 ساعت څخه زیات TTLs د احصایې له پلوه مهم ندي. بیا راځئ چې په رینج 0-3600 تمرکز وکړو:
ډیری TTLs له 0 څخه تر 15 دقیقو پورې دي:
لوی اکثریت له 0 څخه تر 5 دقیقو پورې دي:
دا ډیره ښه نه ده.
مجموعي توزیع ستونزه نوره هم روښانه کوي:
د DNS نیمایي ځوابونه د 1 دقیقې یا لږ TTL لري، او درې پر څلورمه برخه د 5 دقیقو یا لږ TTL لري.
مګر انتظار وکړئ، دا واقعیا بدتر دی. په هرصورت، دا د مستند سرورونو څخه TTL دی. په هرصورت، د پیرودونکي حل کونکي (د بیلګې په توګه روټرونه، محلي کیچ) د اپ سټریم حل کونکو څخه TTL ترلاسه کوي، او دا په هره ثانیه کې کمیږي.
نو پیرودونکی کولی شي په حقیقت کې د هرې ننوتلو لپاره په اوسط ډول د نوي غوښتنې لیږلو دمخه د اصلي TTL نیمایي څخه کار واخلي.
شاید دا خورا ټیټ TTLs یوازې په غیر معمولي غوښتنو پلي کیږي او نه مشهور ویب پا andې او APIs؟ راځئ چې یو نظر وګورو:
د ایکس محور TTL دی، د Y محور د پوښتنې شهرت دی.
له بده مرغه، ترټولو مشهورې پوښتنې هم د کیش لپاره خورا خراب دي.
راځئ چې زوم وکړو:
پریکړه: دا واقعیا بد دی. دا لا دمخه خراب و، مګر دا نور هم خراب شو. د DNS کیچ کول په حقیقت کې بې ګټې شوي. لکه څنګه چې لږ خلک د دوی د ISP DNS حلونکي کاروي (د ښه دلیلونو لپاره)، د ځنډ زیاتوالی د پام وړ کیږي.
د DNS کیچ کول یوازې د مینځپانګې لپاره ګټور شوي چې هیڅوک یې نه ګوري.
مهرباني وکړئ دا هم په یاد ولرئ چې سافټویر ممکن وي ټیټ TTLs تشریح کړئ.
ولې داسې
ولې د DNS ریکارډونه دومره ټیټ TTL ته ټاکل شوي؟
- د میراث بار بیلانسونه د ډیفالټ ترتیباتو سره پاتې شوي.
- داسې افسانې شتون لري چې د DNS بار توازن په TTL پورې اړه لري (دا ریښتیا ندي - د Netscape Navigator له ورځو راهیسې ، پیرودونکو د RRs سیټ څخه تصادفي IP پته غوره کړې او په شفاف ډول یې هڅه کړې که دوی وصل نشي)
- مدیران غواړي سمدلاسه بدلونونه پلي کړي، نو د پلان کولو لپاره اسانه ده.
- د DNS سرور یا د بار بیلانس مدیر د هغه دنده په مؤثره توګه د هغه تشکیلاتو ځای په ځای کولو په توګه ګوري چې کاروونکي یې غوښتنه کوي ، او د سایټونو او خدماتو ګړندۍ نه کوي.
- ټیټ TTLs تاسو ته د ذهن سکون درکوي.
- خلکو په پیل کې د ازموینې لپاره ټیټ TTLs ترتیب کړل او بیا یې بدلول هیر کړل.
ما په لیست کې "ناکامۍ" شامل نه کړ ځکه چې دا لږ او لږ اړونده کیږي. که تاسو اړتیا لرئ چې کاروونکي بلې شبکې ته واستوئ یوازې د خطا پا pageې ښودلو لپاره کله چې هرڅه مات شوي وي ، نو د 1 دقیقې څخه ډیر ځنډ شاید د منلو وړ وي.
برسیره پردې، د یوې دقیقې TTL معنی دا ده چې که مستند DNS سرورونه د 1 دقیقو څخه زیات بند شي، هیڅوک به د دې توان ونلري چې انحصاري خدماتو ته لاسرسی ومومي. او بې ځایه کیدل به مرسته ونکړي که لامل یې د تشکیلاتو تېروتنه یا هیک وي. له بلې خوا، د مناسب TTLs سره، ډیری پیرودونکي به د پخوانیو ترتیباتو کارولو ته دوام ورکړي او هیڅکله به هیڅ شی ته پام ونه کړي.
د CDN خدمتونه او د بار توازن کونکي په لویه کچه د ټیټ TTLs لپاره ملامت دي ، په ځانګړي توګه کله چې دوی CNAMEs د ټیټ TTL سره او ریکارډونه په مساوي ډول ټیټ (مګر خپلواک) TTLs سره یوځای کوي:
$ 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 ثانیې وي.
مګر انتظار وکړئ! دا نور هم خراب دی. ځینې حل کونکي پدې حالت کې د دوه تړل شوي ټیټ TTLs سره خورا بد چلند کوي:
$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 په CNAME کې github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133
د لیول 3 حل کونکی شاید په 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 لري، مګر دا په بشپړه توګه بې ګټې دی. نور CNAMEs د 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 په څیر ورته ستونزه به په 1 ثانیه کې ډیری وخت ودریږي کله چې د لیول 3 حل کونکي کاروي.
ډراپ باکس؟
$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 په 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 په CNAME client.dropbox-dns.com کې. client.dropbox-dns.com. 1 IN A 162.125.64.3
په ثبتولو کې safebrowsing.googleapis.com د TTL ارزښت 60 ثانیې دی، لکه د فیسبوک ډومین. او، بیا، د مراجعینو له نظره، دا ارزښتونه نیمایي دي.
د لږترلږه TTL تنظیم کولو په اړه څنګه؟
د نوم، غوښتنې ډول، TTL، او په اصل کې ذخیره شوي مهال ویش په کارولو سره، ما یو سکریپټ لیکلی ترڅو 1,5 ملیون غوښتنې د کیچ کولو حل کونکي څخه تیریږي ترڅو د ختم شوي کیچ داخلیدو له امله لیږل شوي غیر ضروري غوښتنو حجم اټکل کړي.
47,4٪ غوښتنې د موجوده ریکارډ له پای ته رسیدو وروسته شوې وې. دا په غیر معقول ډول لوړه ده.
که لږ تر لږه TTL ټاکل شوی وي په کیچنګ باندې به څه اغیزه ولري؟
د ایکس محور لږترلږه د TTL ارزښتونه دي. د دې ارزښت څخه پورته د سرچینې TTL سره ریکارډونه اغیزمن ندي.
Y محور د پیرودونکي څخه د غوښتنو فیصدي ده چې دمخه یې زیرمه شوې ننوتلې وي ، مګر دا پای ته رسیدلې او نوې غوښتنه کوي.
د "اضافي" غوښتنو برخه په ساده ډول د لږترلږه TTL تر 47 دقیقو پورې تنظیم کولو سره له 36٪ څخه 5٪ ته راټیټه شوې. د لږترلږه TTL 15 دقیقو په ټاکلو سره، د دې غوښتنو شمیر 29٪ ته راټیټیږي. لږترلږه د 1 ساعت TTL دوی 17٪ ته راټیټوي. د پام وړ توپیر!
د سرور اړخ کې د هیڅ شی نه بدلولو په اړه څنګه ، مګر پرځای یې د پیرودونکي DNS کیچونو کې لږترلږه TTL تنظیم کړئ (روټرونه ، ځایی حل کونکي)؟
د اړتیا وړ غوښتنو شمیر له 47٪ څخه 34٪ ته د لږترلږه 5 دقیقو TTL سره، 25٪ ته د لږترلږه 15 دقیقو سره، او لږترلږه د 13 ساعت سره 1٪ ته. شاید 40 دقیقې غوره وي.
د دې کوچني بدلون اغیز خورا لوی دی.
پایلې یې څه دي؟
البته، خدمت کولی شي نوي کلاوډ چمتو کونکي، نوي سرور، نوې شبکه ته ولیږدول شي، چې پیرودونکي د وروستي DNS ریکارډونو کارولو ته اړتیا لري. او یو کافي کوچنی TTL مرسته کوي چې دا ډول لیږد په اسانۍ او بې پامۍ سره ترسره کړي. مګر نوي زیربنا ته د لیږد سره، هیڅوک تمه نلري چې پیرودونکي د 1 دقیقو، 5 دقیقو، یا 15 دقیقو دننه نوي DNS ریکارډونو ته مهاجرت وکړي. د 40 دقیقو پرځای لږترلږه TTL 5 دقیقو ته تنظیم کول به کاروونکو ته د خدماتو لاسرسي مخه ونه نیسي.
په هرصورت، دا به د پام وړ ځنډ کم کړي او د غیر ضروري غوښتنو څخه مخنیوي سره محرمیت او اعتبار ته وده ورکړي.
البته، RFCs وايي چې TTL باید په کلکه تعقیب شي. مګر حقیقت دا دی چې د DNS سیسټم خورا غیر موثر شوی دی.
که تاسو د مستند DNS سرورونو سره کار کوئ، مهرباني وکړئ خپل TTLs وګورئ. ایا تاسو واقعیا دومره خندونکی ټیټ ارزښتونو ته اړتیا لرئ؟
البته، د DNS ریکارډونو لپاره د کوچنیو TTLs ترتیب کولو لپاره ښه دلیلونه شتون لري. مګر د DNS ترافیک 75٪ لپاره نه چې په حقیقت کې بدله پاتې ده.
او که د کوم دلیل لپاره تاسو واقعیا د DNS لپاره ټیټ TTLs کارولو ته اړتیا لرئ ، په ورته وخت کې ډاډ ترلاسه کړئ چې ستاسو سایټ د کیچ کولو وړ ندی. د ورته دلیلونو لپاره.
که تاسو د محلي DNS کیچ چلول لرئ، لکه کوم چې تاسو ته اجازه درکوي لږترلږه TTLs تنظیم کړئ ، دا فنکشن وکاروئ. دا ښه ده. هیڅ بد به نه وي. لږترلږه TTL نږدې 40 دقیقې (2400 ثانیې) او 1 ساعت ته تنظیم کړئ. خورا معقول حد.
سرچینه: www.habr.com