ক্যাশিং ও TTL — "propagation" আসলে কী

গল্পে বুঝি

মিরপুরের মোড়ে হাইসামের চায়ের দোকান। দোকানের পেছনে একটা কালো বোর্ড, তাতে চক দিয়ে লেখা: “দুধ চা ১৫, লাল চা ১০, ডিম সেদ্ধ ২০”। চিনি আর দুধের দাম রোজ বদলায়, তাই হাইসাম প্রতিটা দামের পাশে ছোট করে লিখে রাখে “আজ সন্ধ্যা পর্যন্ত”। সকালে পাইকারি বাজার থেকে দাম জেনে এসে বোর্ডে লেখে, আর সারাদিন কাস্টমার জিজ্ঞেস করলে বোর্ড দেখেই বলে দেয়। বাজারে আবার ফোন করে না। সন্ধ্যা পার হলে বোর্ডের লেখার ভরসা শেষ, পরদিন সকালে আবার বাজারে গিয়ে নতুন দাম আনে।

একদিন দুপুরে পাইকার বিরুনি দুধের দাম বাড়িয়ে দিল। হাইসাম কিন্তু জানে না, কারণ বিরুনি কাউকে ফোন করে জানায় না। হাইসামের বোর্ডে “আজ সন্ধ্যা পর্যন্ত” লেখা, তাই সে সন্ধ্যা পর্যন্ত পুরনো দামেই চা বেচে যায়। পাশের গলির ফাতিমার দোকানে আবার বোর্ডে লেখা “দুপুর ১২টা পর্যন্ত”, সে দুপুরেই বাজারে গিয়ে নতুন দাম জেনে এসেছে। ফলে একই এলাকায়, একই সময়ে, দুই দোকানে দুই রকম দাম। কেউ ভুল না, দুজনেই নিজের বোর্ডের মেয়াদ মেনে চলছে।

আরেকটা মজার ঘটনা: একজন কাস্টমার জিজ্ঞেস করল “কফি আছে?” হাইসাম বাজারে খোঁজ নিয়ে জানল কফি কেউ বেচে না। সে বোর্ডের কোণায় লিখে রাখল “কফি নাই — কাল পর্যন্ত”। পরদিন দুপুরে বিরুনি কফি আনা শুরু করল, কিন্তু হাইসামের বোর্ডে তো “কাল পর্যন্ত নাই” লেখা, তাই পরের কাস্টমারকেও সে বলে দিল নেই। আর যেদিন ঝড়ে বাজারে যাওয়াই গেল না, সেদিন হাইসাম গতকালের মেয়াদ-পেরোনো দামটাই বলে দিল, “বাজারে যেতে পারিনি, কালকের দামই ধরেন”, দোকান বন্ধ রাখার চেয়ে এটা ভালো।

মিলিয়ে নিই: হাইসামের বোর্ড হলো resolver-এর ক্যাশ, বিরুনির পাইকারি দোকান হলো authoritative nameserver, আর “আজ সন্ধ্যা পর্যন্ত” হলো TTL। বিরুনি দাম বদলালে কাউকে জানায় না, ঠিক যেমন DNS-এ কোনো push নেই; প্রতিটা resolver নিজের TTL শেষ হলে নতুন করে জিজ্ঞেস করে, আর এই অসমান মেয়াদ-শেষ হওয়াটাকেই লোকে ভুল করে “propagation” বলে। “কফি নাই — কাল পর্যন্ত” হলো negative caching (NXDOMAIN বা NODATA-ও ক্যাশ হয়), আর ঝড়ের দিনে পুরনো দাম বলা হলো serve-stale। বাস্তবে প্রতিটা ডোমেইন মাইগ্রেশনে এই তিনটাই আপনার ভাগ্য ঠিক করে দেয়।

ক্যাশ ছাড়া DNS টিকত না

আগের চ্যাপ্টারে দেখেছেন, একটা ঠান্ডা লুকআপে resolver-কে root, TLD আর authoritative তিন জায়গায় যেতে হয়। পৃথিবীর প্রতিটা ফোন যদি প্রতিটা রিকোয়েস্টে এই পুরো পথ ঘুরত, root সার্ভারগুলো প্রথম দিনেই গলে যেত। DNS টিকে আছে কারণ প্রায় সব উত্তর কোথাও না কোথাও আগেই ক্যাশ করা আছে।

ক্যাশ থাকে কয়েকটা স্তরে:

স্তর	কোথায়	কে নিয়ন্ত্রণ করে
ব্রাউজার	Chrome, Firefox-এর নিজস্ব host cache	ব্রাউজার
OS	systemd-resolved, macOS mDNSResponder, Windows	OS
লোকাল রাউটার	বাসার Wi-Fi রাউটার প্রায়ই নিজেই ছোট resolver	রাউটার ফার্মওয়্যার
recursive resolver	ISP, 1.1.1.1, 8.8.8.8, অফিসের resolver	resolver অপারেটর
authoritative	ক্যাশ করে না, এটাই উৎস	আপনি (ডোমেইন মালিক)

প্রতিটা স্তর আলাদাভাবে TTL গোনে। আপনার কাজ শুধু authoritative-এ সঠিক TTL বসানো; বাকিরা সেটা মেনে চলবে (মোটামুটি, যেটা নিচে দেখব)।

TTL কী, আর কীভাবে গোনে

প্রতিটা রেকর্ডের সাথে একটা সংখ্যা আসে: TTL, সেকেন্ডে। authoritative বলে দেয় “এই উত্তর সর্বোচ্চ এতক্ষণ বিশ্বাস করতে পারো”। resolver উত্তরটা ক্যাশ করে, তারপর ঘড়ি ধরে TTL কমাতে থাকে। পরের ক্লায়েন্টকে যখন ক্যাশ থেকে উত্তর দেয়, তখন বাকি থাকা TTL দেয়, শুরুরটা না।

নিজে দেখুন। একই প্রশ্ন একটা পাবলিক resolver-কে কয়েক সেকেন্ড পরপর করুন:

dig +noall +answer @1.1.1.1 baytalhikma.org A
sleep 10
dig +noall +answer @1.1.1.1 baytalhikma.org A

; illustrative output
baytalhikma.org.	300	IN	A	203.0.113.10
baytalhikma.org.	290	IN	A	203.0.113.10

প্রথমবার 300, দশ সেকেন্ড পরে 290। মানে প্রথম কোয়েরিটা ক্যাশ ভরেছে, দ্বিতীয়টা ক্যাশ থেকে এসেছে। এখন সরাসরি authoritative-কে জিজ্ঞেস করুন:

dig +noall +answer @ns1.baytalhikma.org baytalhikma.org A

; illustrative output
baytalhikma.org.	300	IN	A	203.0.113.10

authoritative প্রতিবার পুরো 300-ই দেবে, কারণ সে ক্যাশ থেকে বলছে না, সে নিজেই উৎস। এই পার্থক্যটা ডিবাগিংয়ের সবচেয়ে কাজের টুল: TTL যদি কমতে থাকে, আপনি ক্যাশ দেখছেন; যদি সবসময় পূর্ণ সংখ্যা আসে, আপনি উৎস দেখছেন।

“Propagation” একটা ভুল শব্দ

হোস্টিং কোম্পানির সাপোর্ট বলে “DNS propagate হতে ২৪-৪৮ ঘণ্টা লাগবে”। শুনলে মনে হয় আপনার পরিবর্তনটা ইন্টারনেট জুড়ে ঢেউয়ের মতো ছড়িয়ে পড়ছে। আসলে কিছুই ছড়াচ্ছে না।

আপনি authoritative-এ রেকর্ড বদলানোর মুহূর্তেই পরিবর্তনটা “লাইভ”। যে resolver এখন জিজ্ঞেস করবে, সে নতুন উত্তর পাবে। কিন্তু যে resolver পাঁচ মিনিট আগে জিজ্ঞেস করে পুরনো উত্তর এক ঘণ্টার TTL-সহ ক্যাশ করেছে, সে পরের পঞ্চান্ন মিনিট আপনার authoritative-এর কাছে আসবেই না। এই ঘটনাটা পৃথিবীর লাখো resolver-এ লাখো আলাদা সময়ে ঘটছে। এটাই “propagation”।

তাহলে সর্বোচ্চ কতক্ষণ? সহজ নিয়ম: পুরনো রেকর্ডের TTL। রেকর্ড বদলানোর সময় যে TTL চালু ছিল, তার চেয়ে বেশি কোনো সৎ resolver পুরনো উত্তর ধরে রাখবে না। ২৪-৪৮ ঘণ্টার কথাটা আসে দুই জায়গা থেকে: অনেক রেকর্ডের ডিফল্ট TTL ৮৬৪০০ (এক দিন), আর nameserver বদলালে parent zone-এর delegation TTL (নিচে দেখব)।

পরিবর্তন দেখার সঠিক উপায় তাই কোনো “propagation checker” ওয়েবসাইট না, বরং:

# 1. Is the source correct? Ask the authoritative directly.
dig +short @ns1.baytalhikma.org baytalhikma.org A

# 2. What is a given resolver still holding, and for how long?
dig +noall +answer @8.8.8.8 baytalhikma.org A

প্রথমটা ঠিক থাকলে আপনার কাজ শেষ, বাকিটা শুধু অপেক্ষা। দ্বিতীয়টার TTL কলাম বলে দেয় ঠিক কত সেকেন্ড অপেক্ষা।

Negative caching: “নেই” উত্তরও ক্যাশ হয়

শুধু পাওয়া উত্তর না, “পাওয়া যায়নি” উত্তরও ক্যাশ হয় (RFC 2308)। দুই রকম “নেই”:

• NXDOMAIN — এই নামটাই নেই।
• NODATA — নাম আছে, কিন্তু এই টাইপের রেকর্ড নেই (যেমন AAAA চাইলেন, শুধু A আছে)। status NOERROR, কিন্তু ANSWER খালি।

“নেই” উত্তরের সাথে তো কোনো রেকর্ড আসে না, তাহলে TTL আসে কোথা থেকে? authoritative উত্তরের AUTHORITY সেকশনে zone-এর SOA রেকর্ড জুড়ে দেয়। negative cache-এর সময় হলো SOA রেকর্ডের নিজের TTL আর SOA-র শেষ ফিল্ড (minimum), এই দুটোর মধ্যে যেটা ছোট।

dig @ns1.baytalhikma.org nai.baytalhikma.org A

; illustrative output
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 41213
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
baytalhikma.org.	3600	IN	SOA	ns1.baytalhikma.org. hostmaster.baytalhikma.org. 2026102301 7200 900 1209600 3600

শেষ সংখ্যা 3600 হলো minimum, SOA-র নিজের TTL-ও 3600। মানে কেউ nai.baytalhikma.org চেয়ে NXDOMAIN পেলে পরের এক ঘণ্টা সেই resolver বলবে “নেই”, এর মধ্যে আপনি রেকর্ড বানালেও।

SOA-র minimum কত রাখবেন? খুব বড় (এক দিন) রাখলে উপরের ফাঁদ এক দিন ধরে চলে। খুব ছোট (কয়েক সেকেন্ড) রাখলে typo-ওয়ালা নাম আর বট স্ক্যানের কোয়েরি সরাসরি আপনার authoritative-এ আসে। কয়েক মিনিট থেকে এক ঘণ্টার মধ্যে রাখাটা একটা সাধারণ, নিরাপদ পছন্দ।

resolver সবসময় আপনার TTL মানে না

TTL একটা সর্বোচ্চ সীমা, অনুরোধ। resolver অপারেটররা নিজেদের নিয়ম বসাতে পারে:

• Cap (ছাদ): খুব বড় TTL কেটে ছোট করা। ভুল করে এক সপ্তাহের TTL দিলেও resolver হয়তো এক দিনের বেশি রাখবে না। Unbound-এ cache-max-ttl, BIND-এ max-cache-ttl এই কাজ করে।
• Floor (মেঝে): খুব ছোট TTL বাড়িয়ে দেওয়া। আপনি 5 সেকেন্ড দিলেন, resolver বলল “আমি অন্তত 30 সেকেন্ড রাখব”। Unbound-এ cache-min-ttl। এটা RFC-বিরোধী আচরণ, কিন্তু বাস্তবে কিছু ISP আর এন্টারপ্রাইজ resolver এটা করে, লোড কমাতে।
• ক্লায়েন্টের নিজের ক্যাশ: কিছু রানটাইম নিজেরাই DNS ক্যাশ করে, প্রায়ই নিজের নিয়মে। Java-র JVM networkaddress.cache.ttl প্রপার্টি দিয়ে ঠিক হয়; পুরনো সেটআপে এটা “চিরকাল” পর্যন্ত হতে পারে। দীর্ঘজীবী connection pool থাকলে তো DNS আর জিজ্ঞেসই করা হয় না, পুরনো IP-তে খোলা TCP কানেকশন চলতেই থাকে।

বাস্তব শিক্ষা: 60 সেকেন্ডের নিচে TTL দিয়ে কোনো ফেইলওভার পরিকল্পনা বানাবেন না। কিছু resolver সেটা মানবে না, আর ছোট TTL মানে authoritative-এ বেশি কোয়েরি আর ক্লায়েন্টের জন্য বেশি ঠান্ডা লুকআপ।

Serve-stale: মেয়াদ-পেরোনো উত্তর, ইচ্ছা করে

RFC 8767 resolver-কে একটা অনুমতি দেয়: TTL শেষ হয়ে গেছে, নতুন করে জিজ্ঞেস করতে গিয়ে authoritative সাড়া দিচ্ছে না, তাহলে পুরনো উত্তরটাই আরও কিছুক্ষণ দিয়ে দাও। গল্পের ঝড়ের দিনের মতো। Unbound-এ serve-expired, BIND-এ stale-answer-enable এটা চালু করে; বড় পাবলিক resolver-গুলোও কোনো না কোনো রূপে এটা করে।

এর মানে দুটো:

1. ভালো দিক: আপনার authoritative কিছুক্ষণ ডাউন থাকলেও যাদের ক্যাশে উত্তর আছে তারা সাইটে ঢুকতে পারে।
2. অবাক করা দিক: আপনি ইচ্ছা করে একটা পুরনো সার্ভার বন্ধ করে authoritative-ও সরিয়ে ফেললেন; কিছু resolver তবুও পুরনো IP দিতে থাকতে পারে, TTL পেরিয়ে যাওয়ার পরেও।

Delegation TTL: nameserver বদলালে কেন বেশি সময় লাগে

রেকর্ড বদলানো আর nameserver বদলানো আলাদা জিনিস। baytalhikma.org কোন nameserver-এ আছে, সেই তথ্য থাকে দুই জায়গায়:

1. parent zone-এ (.org রেজিস্ট্রির সার্ভারে) — delegation NS রেকর্ড, যেটা আপনি রেজিস্ট্রারের প্যানেলে বসান।
2. child zone-এ (আপনার নিজের zone-এ) — apex-এর NS রেকর্ড।

resolver প্রথমে parent-এর কাছ থেকে delegation শেখে, আর parent-এর দেওয়া TTL-এ সেটা ক্যাশ করে। সেই TTL আপনার হাতে নেই, রেজিস্ট্রি ঠিক করে। নিজে দেখুন, .com-এর একটা delegation কত TTL নিয়ে আসে:

dig +norecurse @a.gtld-servers.net example.com NS

; illustrative output — the referral arrives in AUTHORITY, not ANSWER
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 1

;; AUTHORITY SECTION:
example.com.		172800	IN	NS	a.iana-servers.net.
example.com.		172800	IN	NS	b.iana-servers.net.

.com আর .net-এর delegation TTL ঐতিহ্যগতভাবে 172800 সেকেন্ড, মানে দুই দিন; ২৪-৪৮ ঘণ্টার কিংবদন্তি এখান থেকেই। অন্য TLD-এর মান আলাদা হতে পারে, আর রেজিস্ট্রি এটা বদলাতেও পারে, তাই নিজের TLD-এর জন্য উপরের কমান্ডটা চালিয়ে দেখে নিন (২০২৬ সালের অক্টোবর অনুযায়ী)।

এজন্য nameserver বদলানোর নিয়ম: পুরনো আর নতুন দুই প্রোভাইডারে অন্তত দুই দিন একই রেকর্ড রাখুন। তাহলে কোন resolver কোন delegation ক্যাশ করে রেখেছে তাতে কিছু যায় আসে না, দুই জায়গা থেকেই সঠিক উত্তর আসবে। বিস্তারিত ধাপ চ্যাপ্টার ৬-এ।

মাইগ্রেশনের প্লেবুক: ডাউনটাইম ছাড়া IP বদলানো

ধরুন baytalhikma.org এখন 203.0.113.10-এ, নতুন সার্ভার 198.51.100.20-এ নেবেন। বর্তমান TTL 86400 (এক দিন)।

ধাপ ১ — আগে থেকে TTL কমান। রেকর্ডের TTL 300 করে দিন, IP বদলাবেন না। এখন অপেক্ষা করুন পুরনো TTL-এর সমান সময়, এখানে পুরো এক দিন। কারণ যে resolver গতকাল 86400 সহ ক্যাশ করেছে, সে নতুন 300 TTL শিখবে কেবল তার পুরনো ক্যাশের মেয়াদ শেষ হলে। এই অপেক্ষা বাদ দেওয়াটাই সবচেয়ে কমন ভুল।

ধাপ ২ — দুই সার্ভারই চালু রাখুন। নতুন সার্ভার পুরোপুরি তৈরি, পুরনোটাও চলছে, ডেটা সিঙ্কে। কোনো ক্লায়েন্ট কোন IP-তে যাচ্ছে তাতে যেন কিছু না যায় আসে।

ধাপ ৩ — রেকর্ড বদলান। A রেকর্ড 198.51.100.20 করুন।

ধাপ ৪ — উৎস যাচাই করুন, তারপর resolver।

# Every authoritative nameserver must agree. Check them all, not one.
for ns in $(dig +short baytalhikma.org NS); do
  echo "$ns: $(dig +short @"$ns" baytalhikma.org A)"
done

# Then watch a few big resolvers flip within ~300s.
for r in 1.1.1.1 8.8.8.8 9.9.9.9; do
  echo "$r: $(dig +noall +answer @"$r" baytalhikma.org A)"
done

ধাপ ৫ — পুরনো সার্ভারের লগ দেখুন। TTL পেরিয়ে যাওয়ার পরেও পুরনো সার্ভারে ট্রাফিক আসছে কিনা দেখুন। আসলে সেটা হয় TTL floor, serve-stale, অথবা কোনো ক্লায়েন্টের নিজস্ব ক্যাশ বা পুরনো connection pool। ট্রাফিক প্রায় শূন্যে না নামা পর্যন্ত পুরনো সার্ভার বন্ধ করবেন না।

ধাপ ৬ — TTL আবার বাড়ান। সব ঠিক থাকলে TTL 3600 বা যা স্বাভাবিক তাতে ফিরিয়ে নিন।

ক্যাশ ফ্লাশ: কার ক্যাশ, কীভাবে

ভুল উত্তর ক্যাশে আটকে গেলে অপেক্ষা ছাড়া উপায় হলো নিজে ক্যাশ খালি করা। কিন্তু আপনি শুধু নিজের হাতের ক্যাশগুলো খালি করতে পারবেন।

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux with systemd-resolved
resolvectl flush-caches
resolvectl statistics     # "Current Cache Size" should drop to 0

# Windows (PowerShell or cmd)
ipconfig /flushdns

ব্রাউজারের নিজস্ব ক্যাশ আলাদা। Chrome-এ chrome://net-internals/#dns খুলে “Clear host cache” চাপুন; Firefox-এ about:networking#dns-এ “Clear DNS Cache”।

বড় পাবলিক resolver-গুলোর নিজস্ব purge পেজ আছে (২০২৬ সালের অক্টোবর অনুযায়ী, লিংক বদলাতে পারে):

• Google Public DNS: developers.google.com/speed/public-dns/cache — নাম আর রেকর্ড টাইপ দিয়ে ফ্লাশ। নেমসার্ভার বদলালে আগে মূল ডোমেইন, তারপর সাবডোমেইন ফ্লাশ করতে বলে।
• Cloudflare 1.1.1.1: one.one.one.one/purge-cache/ — একইভাবে নাম আর টাইপ দিয়ে।

আপনার ইউজারের ISP-এর resolver ফ্লাশ করার কোনো উপায় আপনার নেই। এজন্যই প্লেবুকের ধাপ ১ (আগে থেকে TTL কমানো) এত জরুরি: পরে ফ্লাশ করে বাঁচার রাস্তা সীমিত।

ডিবাগিং: এই চ্যাপ্টারের সমস্যাগুলো

“রেকর্ড বদলেছি, কিন্তু সাইট পুরনো সার্ভারে যাচ্ছে।” নিশ্চিত হন: dig +short @<authoritative> name A দিয়ে উৎস দেখুন, তারপর dig +noall +answer name A দিয়ে আপনার resolver-এর উত্তর আর বাকি TTL দেখুন। উৎস ঠিক আর resolver-এ পুরনো IP মানে শুধু ক্যাশ; বাকি TTL-ই অপেক্ষার সময়। উৎসই ভুল হলে আপনি হয়তো ভুল প্রোভাইডারের প্যানেলে এডিট করেছেন (ডোমেইনের NS যেখানে পয়েন্ট করা, শুধু সেখানের এডিট গোনা হয়)। সমাধান: অপেক্ষা, নিজের মেশিন আর ব্রাউজার ফ্লাশ, দরকারে পাবলিক resolver-এর purge পেজ।

“নতুন সাবডোমেইন অন্যদের চলছে, আমার চলছে না।” নিশ্চিত হন: dig name A চালিয়ে status: NXDOMAIN আর AUTHORITY-তে SOA দেখছেন কিনা। দেখলে আপনার resolver আগের “নেই” উত্তর ক্যাশ করে রেখেছে। সমাধান: dig @1.1.1.1 name A দিয়ে নিশ্চিত হন রেকর্ড আসলে আছে, তারপর লোকাল ক্যাশ ফ্লাশ করুন অথবা SOA minimum পর্যন্ত অপেক্ষা করুন।

“TTL পেরিয়ে গেছে, তবু পুরনো সার্ভারে কিছু ট্রাফিক আসছে।” নিশ্চিত হন: পুরনো সার্ভারের অ্যাক্সেস লগে কোন ক্লায়েন্ট আসছে দেখুন। সাধারণত দীর্ঘজীবী connection (ডেটাবেস pool, WebSocket, HTTP keep-alive), JVM-এর মতো রানটাইমের নিজস্ব DNS ক্যাশ, TTL floor বসানো কোনো resolver, বা serve-stale। সমাধান: পুরনো সার্ভারকে কিছুদিন reverse proxy বানিয়ে নতুনটায় পাঠান, অথবা অ্যাপগুলো রিস্টার্ট করুন; ট্রাফিক শূন্য হলে বন্ধ করুন।

“nameserver বদলেছি, দুই দিন ধরে অর্ধেক ইউজার পুরনো রেকর্ড পাচ্ছে।” নিশ্চিত হন: dig +trace name চালিয়ে parent কোন NS দিচ্ছে দেখুন, তারপর পুরনো আর নতুন দুই প্রোভাইডারকে সরাসরি জিজ্ঞেস করুন। দুটো আলাদা উত্তর দিলে এটাই সমস্যা। সমাধান: delegation TTL পেরোনো পর্যন্ত দুই প্রোভাইডারে হুবহু একই রেকর্ড রাখুন; পুরনো প্রোভাইডারের zone আগে মুছবেন না।

“ফেইলওভারে TTL 30 দিয়েছি, তবু কিছু ইউজার মিনিট দশেক ডাউন দেখেছে।” নিশ্চিত হন: সমস্যাগ্রস্ত ইউজারের resolver থেকে dig করে TTL দেখুন; 30-এর বেশি দেখালে সেখানে floor বসানো। সমাধান: DNS ফেইলওভারকে মিনিট-স্কেলের টুল ধরুন; সেকেন্ড-স্কেলের ফেইলওভার লাগলে একই IP-এর পেছনে load balancer বা anycast (চ্যাপ্টার ১০)।

মূল শিক্ষা

1. DNS-এ কোনো push নেই। authoritative-এ বদলানোর মুহূর্তেই পরিবর্তন লাইভ; বাকিটা প্রতিটা resolver-এর ক্যাশ নিজের সময়ে শেষ হওয়া।
2. সর্বোচ্চ অপেক্ষা = পুরনো রেকর্ডের TTL। nameserver বদলালে parent-এর delegation TTL (.com-এ সাধারণত দুই দিন)।
3. TTL কমতে থাকা মানে ক্যাশ, পূর্ণ TTL মানে উৎস। @authoritative বনাম @resolver তুলনা করে প্রায় সব ক্যাশ-সমস্যা ধরা যায়।
4. “নেই” উত্তরও ক্যাশ হয়, SOA-র TTL আর minimum-এর ছোটটা পর্যন্ত। রেকর্ড আগে বানান, টেস্ট পরে।
5. TTL একটা অনুরোধ। resolver cap, floor, serve-stale বসাতে পারে; রানটাইম আর connection pool নিজের নিয়মে চলে।
6. মাইগ্রেশন = TTL আগে কমাও, পুরনো TTL পরিমাণ অপেক্ষা করো, বদলাও, উৎস যাচাই করো, পুরনো সার্ভারের লগ শূন্য হলে বন্ধ করো, TTL বাড়াও।