اوسینت جت · خواندن شواهد DNS
آیا از روی TTL میتوان زمان تغییر رکورد DNS را فهمید؟
در خروجی بررسی دامنه، کنار یک رکورد عدد ۳۰۰ را میبینید. اگر این عدد زیر عنوان TTL آمده باشد، معنیاش این نیست که رکورد پنج دقیقه پیش ساخته شده است. همچنین بهتنهایی نمیگوید پنج دقیقه دیگر همه کاربران سایت را روی سرور تازه خواهند دید. TTL یک مدتزمان برای نگهداری پاسخ در حافظه موقت است؛ تاریخ ایجاد یا آخرین ویرایش رکورد نیست.
برای بررسی سابقه یک دامنه، خود پاسخ و زمان دریافت آن را نگه دارید. TTL به تفسیر همان پاسخ کمک میکند، اما جای مدرک تاریخیِ تغییر را نمیگیرد.

اول بدانیم چه چیزی دارد شمرده میشود
TTL کوتاهشده عبارت Time to Live است و در رکورد DNS برحسب ثانیه بیان میشود. در ساختار رکورد در RFC 1035، نام، نوع رکورد، TTL و مقدار داده بخشهای جداگانهاند. TTL برابر ۳۶۰۰ یعنی یک بازه یکساعته برای کش؛ عددی نیست که بتوان آن را به تاریخ تبدیل کرد.
«کش» همان حافظه موقت پاسخهاست. سرور مرجع، داده ناحیه DNS مربوط را ارائه میکند. در مقابل، یک resolver یا حلکننده بازگشتی برای کاربر پاسخ پیدا میکند و ممکن است نسخهای را که قبلاً گرفته نگه دارد. TTL در پاسخ کششده معمولاً زمان باقیمانده برای همان نسخه را نشان میدهد. RFC 1034 سازوکار این نگهداری را توضیح میدهد.
پس قبل از مقایسه دو عدد، معلوم کنید هر پاسخ را از کدام منبع گرفتهاید. اگر یک سایت کنار TTL عبارت «آخرین بررسی» هم نمایش میدهد، این دو را یکی نگیرید. زمان آخرین بررسی میتواند زمان مشاهده آن ابزار باشد. عبارت «اولین مشاهده» در یک سرویس تاریخچه DNS نیز به سابقه گردآوری همان سرویس مربوط است؛ از خود TTL استخراج نشده است.
تمرین: دو پاسخ متفاوت، بدون تغییر دادن رکورد
این مثال آموزشی و ساختگی است؛ هیچ دامنه واقعی در آن آزمایش نشده. فرض کنید مقدار رکورد و TTL تنظیمشده روی سرور مرجع ثابت ماندهاند. TTL برابر ۳۶۰۰ ثانیه است. دو حلکننده، هر کدام پاسخ تازه را مستقیم از مرجع میگیرند و در این تمرین خبری از تازهسازی زودهنگام، حذف کش یا استفاده از پاسخ منقضی نیست.
| ساعت به وقت UTC | چه اتفاقی میافتد؟ | TTL پاسخ |
|---|---|---|
| ۱۲:۰۰ | حلکننده الف یک نسخه تازه از مقدار رکورد میگیرد. | ۳۶۰۰ ثانیه |
| ۱۲:۱۰ | الف همان نسخه نگهداشتهشده را برمیگرداند. | ۳۰۰۰ ثانیه |
| ۱۲:۱۰ | حلکننده ب نسخه تازه خودش را از همان مقدار میگیرد. | ۳۶۰۰ ثانیه |
ده دقیقه، ۶۰۰ ثانیه است؛ بنابراین از بازه الف ۳۰۰۰ ثانیه باقی مانده. با فرضهای این تمرین، این تفریق درباره زمان ورود داده به کش الف است. نمیگوید خود رکورد در ساعت ۱۲ ساخته شده. ممکن است مقدار آن از چند هفته قبل همین بوده باشد.
حالا فرضها و ردیف اول را بپوشانید. فقط دو پاسخ ساعت ۱۲:۱۰ را دارید. دیگر نمیدانید هر حافظه چه زمانی پر شده، ابتدا چه TTL گرفته یا در میانه کار تازه شده است یا نه. از اختلاف ۶۰۰ ثانیهای نمیتوان این اطلاعات گمشده را بازسازی کرد. نوشتن «زمان تغییر رکورد: ۱۲:۰۰» در گزارش، نتیجه محاسبه نیست؛ افزودن یک فرض پنهان است.
پایان TTL، ساعت قطعی تغییر برای همه نیست
سامانه واقعی همیشه به سادگی تمرین بالا عمل نمیکند. RFC 8767 قواعد TTL را بهروزرسانی کرده و اجازه میدهد وقتی تازهکردن پاسخ از مرجع ممکن نیست، در شرایط تعریفشده داده منقضی همچنان ارائه شود. چنین پاسخی میتواند TTL مثبت داشته باشد. بنابراین عدد کوچکِ مثبت بهتنهایی تازگی داده اصلی را ثابت نمیکند.
از یک خروجی نمیتوان موعدی تعیین کرد که تمام کاربران در سراسر اینترنت مقدار جدید را ببینند. همانطور که پاسخ DNS، نسخه محتوای صفحه وب را هم مشخص نمیکند. اگر ادعا درباره تغییر متن سایت است، باید صفحه و سابقه آن را جداگانه بررسی کنید.
چه چیزی را در یادداشت تغییر ثبت کنیم؟
سؤال را مشخص بنویسید: مثلاً «آیا آدرس برگشتی این نام میزبان در دو مشاهده فرق داشته است؟» برای هر مشاهده نام دقیق، نوع پرسوجو، تمام مقادیر پاسخ، TTL هر مقدار، هویت حلکننده یا منبع، ساعت UTC و فایل اصلی خروجی را ثبت کنید. رکورد A و MX پاسخ دو سؤال متفاوتاند. برشی از تصویر که منبع را نشان نمیدهد هم برای تشخیص حلکننده کافی نیست.
اگر در مدرک قدیمی مقدار X و در مدرک تازه مقدار Y دیده میشود، فعلاً همین تفاوت دو مشاهده را گزارش کنید. برای نسبتدادن آن به تغییر در مرجع، باید قابلمقایسهبودن پاسخها، احتمال کش و احتمال ارائه عمدی پاسخهای متغیر را بررسی کنید. دو نمونه، ساعت دقیق ویرایش، شخص ویرایشکننده، علت تغییر یا تمام حالتهای میان آن دو را روشن نمیکنند.
این چند فیلد را کنار خروجیها بگذارید: «نام و نوع رکورد»، «منبع هر پاسخ»، «زمان مشاهده و مقدار»، «TTL»، «تفاوت قابل مشاهده» و «مدرک مستقل زمان ویرایش». اگر مورد آخر را ندارید، بنویسید «زمان ویرایش معلوم نیست». در تمرین ما زمان ایجاد و تغییر رکورد هر دو نامعلوماند؛ داشتن عدد دقیق TTL این خلأ را پر نمیکند.
برای ادامه بررسیِ دامنه از راهنمای تحقیق درباره دامنه استفاده کنید. اگر سؤال اصلی شما زمان تغییر ادعای یک وبسایت است، روش ساخت خط زمانی سایت کمک میکند زمان ثبت، زمان مشاهده و زمان ادعاشده را به هم نیامیزید.
انتشار: 2026-11-03 · تحریریه اوسینت جت
ادامه مسیر اوسینت
سرنخهای خام را به یک تحقیق ساختارمند در اوسینت جت تبدیل کنید
برای نتیجه بهتر، فقط به یک سرنخ اکتفا نکنید. شماره تلفن، ایمیل، یوزرنیم، دامنه، نام شرکت، تصویر، شهر، لینک شبکه اجتماعی و توضیح زمینه پرونده را کنار هم قرار دهید تا موتور اطلاعاتی اوسینت جت تحلیل دقیقتری بسازد.
