কম DNS লেটেন্সি দ্রুত ইন্টারনেট ব্রাউজিং এর চাবিকাঠি। এটি কমানোর জন্য, DNS সার্ভারগুলিকে সাবধানে নির্বাচন করা গুরুত্বপূর্ণ বেনামী রিলে. কিন্তু প্রথম ধাপ হল অকেজো প্রশ্ন পরিত্রাণ পেতে.

এই কারণেই ডিএনএস মূলত একটি উচ্চ ক্যাশেযোগ্য প্রোটোকল হিসাবে ডিজাইন করা হয়েছিল। জোন অ্যাডমিনিস্ট্রেটররা পৃথক এন্ট্রির জন্য একটি টাইম টু লাইভ (টিটিএল) সেট করে, এবং অপ্রয়োজনীয় ট্র্যাফিক এড়াতে মেমরিতে এন্ট্রি সংরক্ষণ করার সময় সমাধানকারীরা এই তথ্য ব্যবহার করে।

ক্যাশিং কি কার্যকর? কয়েক বছর আগে, আমার সামান্য গবেষণা দেখায় যে এটি নিখুঁত ছিল না। চলুন একনজরে দেখে নেওয়া যাক বর্তমান অবস্থা।

তথ্য সংগ্রহ করতে আমি প্যাচ করেছি এনক্রিপ্ট করা DNS সার্ভার প্রতিক্রিয়ার জন্য TTL মান সংরক্ষণ করতে। প্রতিটি আগত অনুরোধের জন্য এটির রেকর্ডের সর্বনিম্ন TTL হিসাবে সংজ্ঞায়িত করা হয়। এটি প্রকৃত ট্র্যাফিকের TTL বিতরণের একটি ভাল ওভারভিউ দেয় এবং পৃথক অনুরোধের জনপ্রিয়তাও বিবেচনা করে। সার্ভারের প্যাচ করা সংস্করণটি কয়েক ঘন্টা ধরে কাজ করেছে।

ফলস্বরূপ ডেটা সেটটিতে 1টি রেকর্ড রয়েছে (নাম, qtype, TTL, টাইমস্ট্যাম্প)। এখানে সামগ্রিক TTL বিতরণ (X-অক্ষ হল TTL সেকেন্ডে):

86 (বেশিরভাগই SOA রেকর্ডের জন্য) একটি ছোট বাম্প ছাড়াও, এটা বেশ স্পষ্ট যে TTLগুলি কম পরিসরে রয়েছে। আসুন একটি ঘনিষ্ঠভাবে তাকান:

ঠিক আছে, 1 ঘন্টার বেশি TTL পরিসংখ্যানগতভাবে তাৎপর্যপূর্ণ নয়। তাহলে চলুন 0-3600 পরিসরে ফোকাস করা যাক:

বেশিরভাগ TTL 0 থেকে 15 মিনিটের হয়:

বিশাল সংখ্যাগরিষ্ঠ হল 0 থেকে 5 মিনিটের মধ্যে:

এটা খুব ভালো না.

ক্রমবর্ধমান বিতরণ সমস্যাটিকে আরও স্পষ্ট করে তোলে:

DNS প্রতিক্রিয়াগুলির অর্ধেকের TTL 1 মিনিট বা তার কম, এবং তিন-চতুর্থাংশের TTL 5 মিনিট বা তার কম।

কিন্তু অপেক্ষা করুন, এটি আসলে আরও খারাপ। সব পরে, এটি প্রামাণিক সার্ভার থেকে TTL. যাইহোক, ক্লায়েন্ট সমাধানকারীরা (যেমন রাউটার, স্থানীয় ক্যাশে) আপস্ট্রিম রিসোলভার থেকে একটি TTL পায় এবং প্রতি সেকেন্ডে তা হ্রাস পায়।

তাই ক্লায়েন্ট প্রকৃতপক্ষে একটি নতুন অনুরোধ পাঠানোর আগে প্রতিটি এন্ট্রি, গড়ে, অর্ধেক আসল TTL ব্যবহার করতে পারে।

হতে পারে এই খুব কম টিটিএলগুলি শুধুমাত্র অস্বাভাবিক অনুরোধগুলিতে প্রযোজ্য এবং জনপ্রিয় ওয়েবসাইট এবং API গুলি নয়? চলুন দেখে নেওয়া যাক:

X অক্ষ হল TTL, Y অক্ষ হল কোয়েরি জনপ্রিয়তা।

দুর্ভাগ্যবশত, সবচেয়ে জনপ্রিয় প্রশ্নগুলিও ক্যাশে সবচেয়ে খারাপ।

আসুন জুম ইন করুন:

রায়: এটা সত্যিই খারাপ. এটা আগে খারাপ ছিল, কিন্তু এটা আরো খারাপ হয়েছে. DNS ক্যাশিং কার্যত অকেজো হয়ে গেছে। যেহেতু কম লোক তাদের ISP এর DNS সমাধানকারী ব্যবহার করে (ভাল কারণে), বিলম্বের বৃদ্ধি আরও লক্ষণীয় হয়ে ওঠে।

DNS ক্যাশিং শুধুমাত্র এমন সামগ্রীর জন্য উপযোগী হয়ে উঠেছে যা কেউ পরিদর্শন করে না।

সফ্টওয়্যার হতে পারে যে নোট করুন বিভিন্ন উপায়ে নিম্ন TTL ব্যাখ্যা.

কেন এটা তাই?

কেন ডিএনএস রেকর্ড এত কম TTL সেট করা হয়?

• লিগ্যাসি লোড ব্যালেন্সারগুলি ডিফল্ট সেটিংস সহ বাকি ছিল৷
• এমন মিথ আছে যে DNS লোড ব্যালেন্সিং TTL এর উপর নির্ভর করে (এটি সত্য নয় - নেটস্কেপ নেভিগেটরের দিন থেকে, ক্লায়েন্টরা RR-এর সেট থেকে একটি এলোমেলো আইপি ঠিকানা বেছে নিয়েছে এবং যদি তারা সংযোগ করতে না পারে তবে স্বচ্ছভাবে অন্য একটি চেষ্টা করেছে)
• অ্যাডমিনিস্ট্রেটররা অবিলম্বে পরিবর্তনগুলি প্রয়োগ করতে চান, তাই এটি পরিকল্পনা করা সহজ।
• একটি ডিএনএস সার্ভার বা লোড ব্যালেন্সারের প্রশাসক তার কাজটিকে ব্যবহারকারীদের অনুরোধ করা কনফিগারেশনটিকে দক্ষতার সাথে স্থাপন করা এবং সাইট এবং পরিষেবাগুলির গতি বাড়ানোর মতো নয়।
• কম টিটিএল আপনাকে মানসিক শান্তি দেয়।
• লোকেরা প্রাথমিকভাবে পরীক্ষার জন্য কম TTL সেট করে এবং তারপর সেগুলি পরিবর্তন করতে ভুলে যায়।

আমি তালিকায় "ফেলওভার" অন্তর্ভুক্ত করিনি কারণ এটি কম এবং কম প্রাসঙ্গিক হয়ে উঠছে। আপনি যদি ব্যবহারকারীদের অন্য নেটওয়ার্কে পুনঃনির্দেশ করতে চান শুধুমাত্র একটি ত্রুটি পৃষ্ঠা প্রদর্শন করার জন্য যখন অন্য সব কিছু ভেঙে যায়, 1 মিনিটের বেশি বিলম্ব সম্ভবত গ্রহণযোগ্য।

অতিরিক্তভাবে, এক মিনিটের TTL মানে হল যে যদি প্রামাণিক DNS সার্ভারগুলি 1 মিনিটের বেশি সময়ের জন্য অবরুদ্ধ থাকে, অন্য কেউ নির্ভরশীল পরিষেবাগুলি অ্যাক্সেস করতে সক্ষম হবে না। এবং রিডানড্যান্সি সাহায্য করবে না যদি কারণটি একটি কনফিগারেশন ত্রুটি বা একটি হ্যাক হয়। অন্যদিকে, যুক্তিসঙ্গত TTL-এর সাথে, অনেক ক্লায়েন্ট পূর্ববর্তী কনফিগারেশন ব্যবহার করতে থাকবে এবং কখনই কিছু লক্ষ্য করবে না।

কম TTL-এর জন্য CDN পরিষেবা এবং লোড ব্যালেন্সারগুলি মূলত দায়ী, বিশেষ করে যখন তারা কম TTL-এর সাথে CNAMEs এবং সমানভাবে কম (কিন্তু স্বাধীন) 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 তে 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-এর প্রাথমিক TTL 60 সেকেন্ডের, কিন্তু ডোমেনের জন্য 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

Firefox এবং TTL-এর মতো একই সমস্যা লেভেল1 রেজলভার ব্যবহার করার সময় বেশিরভাগ সময় 3 সেকেন্ডে আটকে থাকবে।

ড্রপবক্স?

$ ড্রিল 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 $ ড্রিল 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 সেকেন্ড, Facebook ডোমেনের মত। এবং, আবার, ক্লায়েন্টের দৃষ্টিকোণ থেকে, এই মানগুলি অর্ধেক করা হয়েছে।

একটি ন্যূনতম TTL সেট সম্পর্কে কিভাবে?

নাম, অনুরোধের ধরন, TTL, এবং প্রাথমিকভাবে সংরক্ষিত টাইমস্ট্যাম্প ব্যবহার করে, আমি একটি স্ক্রিপ্ট লিখেছিলাম যাতে ক্যাশিং রেজোলিভারের মধ্য দিয়ে যাওয়া 1,5 মিলিয়ন অনুরোধের অনুকরণ করা হয় যাতে মেয়াদ শেষ হয়ে যাওয়া ক্যাশে এন্ট্রির কারণে প্রেরিত অপ্রয়োজনীয় অনুরোধের পরিমাণ অনুমান করা যায়।

একটি বিদ্যমান রেকর্ডের মেয়াদ শেষ হওয়ার পরে 47,4% অনুরোধ করা হয়েছিল। এটি অযৌক্তিকভাবে বেশি।

ন্যূনতম TTL সেট করা হলে ক্যাশিংয়ের উপর কী প্রভাব পড়বে?

X অক্ষ হল ন্যূনতম TTL মান। এই মানের উপরে উৎস TTL সহ রেকর্ড প্রভাবিত হয় না।

Y অক্ষ হল একটি ক্লায়েন্টের কাছ থেকে অনুরোধের শতাংশ যার ইতিমধ্যে একটি ক্যাশে এন্ট্রি রয়েছে, কিন্তু এটি মেয়াদ শেষ হয়ে গেছে এবং একটি নতুন অনুরোধ করছে৷

"অতিরিক্ত" অনুরোধের ভাগ 47% থেকে কমিয়ে 36%-এ ন্যূনতম TTL সেট করে 5 মিনিট করা হয়েছে৷ ন্যূনতম TTL 15 মিনিটে সেট করে, এই অনুরোধের সংখ্যা 29% এ নেমে যায়। 1 ঘন্টার একটি ন্যূনতম TTL তাদের 17% কমিয়ে দেয়। উল্লেখযোগ্য পার্থক্য!

সার্ভারের দিকে কিছু পরিবর্তন না করে, ক্লায়েন্ট ডিএনএস ক্যাশে (রাউটার, স্থানীয় সমাধানকারী) ন্যূনতম TTL সেট করার বিষয়ে কীভাবে?

ন্যূনতম 47 মিনিটের TTL সহ প্রয়োজনীয় অনুরোধের সংখ্যা 34% থেকে 5%, সর্বনিম্ন 25 মিনিটের সাথে 15% এবং সর্বনিম্ন 13 ঘন্টার সাথে 1%-এ নেমে আসে৷ সম্ভবত 40 মিনিট সর্বোত্তম।

এই ছোট পরিবর্তনের প্রভাব বিশাল।

এর পরিণতি কি?

অবশ্যই, পরিষেবাটি একটি নতুন ক্লাউড প্রদানকারী, নতুন সার্ভার, নতুন নেটওয়ার্কে স্থানান্তরিত করা যেতে পারে, যার জন্য ক্লায়েন্টদের সর্বশেষ DNS রেকর্ড ব্যবহার করতে হবে। এবং একটি মোটামুটি ছোট TTL এই ধরনের একটি রূপান্তর মসৃণ এবং অজ্ঞাতভাবে করতে সাহায্য করে। কিন্তু নতুন পরিকাঠামোতে রূপান্তরের সাথে, কেউ আশা করে না যে ক্লায়েন্টরা 1 মিনিট, 5 মিনিট বা 15 মিনিটের মধ্যে নতুন ডিএনএস রেকর্ডে স্থানান্তরিত হবে। 40 মিনিটের পরিবর্তে ন্যূনতম TTL 5 মিনিট সেট করা ব্যবহারকারীদের পরিষেবাটি অ্যাক্সেস করতে বাধা দেবে না।

যাইহোক, এটি অপ্রয়োজনীয় অনুরোধ এড়িয়ে গোপনীয়তা এবং নির্ভরযোগ্যতাকে উল্লেখযোগ্যভাবে হ্রাস করবে এবং গোপনীয়তা এবং নির্ভরযোগ্যতা উন্নত করবে।

অবশ্যই, RFCs বলে যে TTL অবশ্যই কঠোরভাবে অনুসরণ করতে হবে। কিন্তু বাস্তবতা হল ডিএনএস সিস্টেম খুবই অকার্যকর হয়ে পড়েছে।

আপনি যদি প্রামাণিক DNS সার্ভারের সাথে কাজ করে থাকেন, তাহলে অনুগ্রহ করে আপনার TTLগুলি পরীক্ষা করুন৷ আপনি সত্যিই যেমন হাস্যকরভাবে কম মান প্রয়োজন?

অবশ্যই, DNS রেকর্ডের জন্য ছোট টিটিএল সেট করার ভালো কারণ আছে। কিন্তু DNS ট্রাফিকের 75% এর জন্য নয় যা কার্যত অপরিবর্তিত থাকে।

এবং যদি কোনো কারণে DNS-এর জন্য আপনাকে সত্যিই কম TTL ব্যবহার করতে হয়, একই সময়ে নিশ্চিত করুন যে আপনার সাইটে ক্যাশিং সক্ষম করা নেই। একই কারণে।

আপনার যদি একটি স্থানীয় DNS ক্যাশে চলমান থাকে, যেমন dnscrypt-প্রক্সিযা আপনাকে ন্যূনতম TTL সেট করতে দেয়, এই ফাংশনটি ব্যবহার করুন। এই জরিমানা. খারাপ কিছু হবে না। ন্যূনতম TTL সেট করুন প্রায় 40 মিনিট (2400 সেকেন্ড) এবং 1 ঘন্টা। বেশ যুক্তিসঙ্গত পরিসর।

উত্স: www.habr.com