نشانی را از یک جستجو در قانون مسیریابی خود کپی می‌کنید، سایت کار می‌کند و یک هفته بعد کار نمی‌کند. هیچ چیز در قانون تغییر نکرده است. سرویس به نشانی لبه دیگری منتقل شده، کلاینت نام میزبان دیگری را حل کرده، یا نشست به IPv6 رفته است. تصمیمی که پیش روی شماست این است که آیا قانون مبتنی بر نام یا محدوده‌ای صریح ابزار درست برای این سرویس است، و سه شرط آن را تعیین می‌کند. آنچه در پی می‌آید نام را از نشانی جدا می‌کند، چون تنها یکی از آن دو پایدار است.

چرا یک جستجو فهرست کامل نیست

یک شبکه توزیع محتوا با نشانی‌ای پاسخ می‌دهد که برای حل‌کننده، منطقه و لحظه انتخاب شده است. دو بار از شبکه‌های مختلف بپرسید و ممکن است پاسخ‌های متفاوتی بگیرید. یک بار بپرسید و پاسخ را فهرست نشانی‌های سرویس بدانید، و قانونی که می‌نویسید یک تصویر لحظه‌ای است، نه یک قانون. این تمام مشکل برخورد با پاسخ DNS به‌عنوان پیکربندی است.

شکاف دومی وجود دارد. یک نام میزبان قابل مشاهده به‌ندرت کل برنامه را پوشش می‌دهد، چون ورود، رسانه و ترافیک API اغلب از نام‌های جداگانه استفاده می‌کنند. قانونی که از نام میزبان نوار نشانی ساخته شود می‌تواند صفحه را پوشش دهد و ویدیو را از دست بدهد، که به‌عنوان شکست جزئی خوانده می‌شود، نه خطای مسیریابی.

شکاف سوم خانواده نشانی است. قانونی که فقط برای v4 است هیچ چیزی درباره رکورد AAAA که کلاینت ممکن است ترجیح دهد نمی‌گوید.

سه شرطی که بین قانون دامنه و محدوده‌ها تصمیم می‌گیرد

نخست، آیا سرویس مجموعه‌ای پایدار از پیشوندها را منتشر می‌کند که بتوانید مالک آن باشید و مستند کنید؟ اگر بله، محدوده‌های صریح صادقانه و ارزان‌اند. اگر نه، قانون دامنه تنها سازوکاری است که می‌تواند سرویس را دنبال کند.

دوم، آیا سازوکار دامنه کلاینت شما تازه‌سازی می‌شود؟ قانونی که یک بار هنگام اتصال حل می‌شود و دیگر هرگز، تصویری لحظه‌ای با برندینگ بهتر است. سوم، آیا سازوکار زیردامنه‌ها و هر دو خانواده نشانی را پوشش می‌دهد، یا فقط نام‌هایی که تایپ کرده‌اید؟

به آن سه پاسخ دهید و انتخاب معمولاً آشکار است. حدس زدن قانونی می‌سازد که در آزمایش کار می‌کند و در محیط عملیاتی شکست می‌خورد.

یک نشست را آزمایش کنید، نه یک صفحه

صفحه را بارگذاری کنید، سپس عملیاتی را انجام دهید که اهمیت دارد: وارد شوید، پخش را شروع کنید، فایلی را بارگذاری کنید. هر یک از این‌ها می‌تواند به میزبان متفاوتی برسد، و آنکه شکست می‌خورد همان است که قانون شما از دست داده.

فهرست کنید که نشست واقعاً با چه چیزی تماس می‌گیرد، نه آنچه صفحه نشان می‌دهد:

dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5

حل‌کننده را در طول مقایسه قابل مشاهده نگه دارید، چون قانونی که از یک حل‌کننده کار می‌کند و از دیگری شکست می‌خورد درباره پاسخ CDN به شما می‌گوید، نه درباره تونل. TTL کوتاه همچنین یعنی پاسخی که ثبت کرده‌اید تاریخ انقضا دارد.

هر سازوکار واقعاً چه چیزی را پوشش می‌دهد

دو سازوکار در صفحه تنظیمات قابل تبادل به نظر می‌رسند و در زیر سطح متفاوت رفتار می‌کنند.

MechanismWhat it matchesHow it fails
Domain ruleNames the client resolves, then their addressesMisses subdomains, or goes stale when refresh is off
Address routeA prefix you wrote downKeeps matching an address the service has left

مسیر نشانی در هسته پیشوندها را تطبیق می‌دهد. هیچ ایده‌ای ندارد که نام میزبان چیست، پس نمی‌تواند سرویسی را که نشانی عوض می‌کند دنبال کند. قانون دامنه نام‌ها را حل و نتیجه را مسیریابی می‌کند؛ سرویس را دنبال می‌کند اما به حل‌کننده، رفتار تازه‌سازی و برخورد کلاینت با زیردامنه‌ها وابسته است، پس قانونی که نام‌ها را دنبال می‌کند باید با همان حل‌کننده‌ای آزمایش شود که کلاینت واقعاً به کار می‌برد.

هیچ‌کدام ابرمجموعه دیگری نیست، از این رو آمیختن آن‌ها بدون یادداشت بعداً سردرگمی می‌آفریند.

پس از تغییر سرویس دوباره بررسی کنید

پس از به‌روزرسانی کلاینت یا تغییر سرویس، همان آزمایش نشست را دوباره اجرا کنید. فهرست نشانی‌ای که پیش‌تر کار می‌کرد شواهدی درباره آن دوره است، نه فهرست دائمی زیرساخت سرویس.

بنویسید کدام سازوکار کدام نام میزبان را پوشش می‌دهد، و تاریخ آخرین بررسی.

آن یادداشت تفاوت میان قانونی است که می‌توانید از آن دفاع کنید و قانونی که هیچ‌کس جرئت نمی‌کند به آن دست بزند. اگر سرویس فهرست پیشوندهای خودش را منتشر می‌کند، از آن استفاده کنید و تاریخ را ذکر کنید. اگر نه، این را بگویید، و قانون دامنه را با رفتار تازه‌سازی‌اش در کنارش نگه دارید.

مقالات مرتبط