כלל דומיין של VPN נשבר כשה-CDN משנה את כתובותיו
תשובת DNS אחת היא צילום מצב, לא מלאי. שלושה תנאים קובעים אם כלל מבוסס שם או קידומת מפורשת מתאים לשירות שמאחוריו CDN.
אתם מעתיקים את הכתובת משאילתה אחת לכלל הניתוב שלכם, האתר עובד, וכעבור שבוע הוא כבר לא. דבר בכלל לא השתנה. השירות עבר לכתובת קצה אחרת, הלקוח פתר שם מארח אחר, או שהפעלה עברה ל-IPv6. ההחלטה שלפניכם היא אם כלל מבוסס שם או טווח מפורש הוא הכלי הנכון לשירות הזה, ושלושה תנאים מכריעים בכך. מה שלהלן מפריד בין השם לכתובת, כי רק אחד מהם יציב.
למה שאילתה אחת אינה מלאי
רשת אספקת תוכן עונה בכתובת שנבחרה עבור הפותר, האזור והרגע. שאלו פעמיים מרשתות שונות ותוכלו לקבל תשובות שונות. שאלו פעם אחת ותתייחסו לתשובה כרשימת הכתובות של השירות, והכלל שתכתבו הוא צילום מצב ולא כלל. זו כל הבעיה בהתייחסות לתשובת DNS כקונפיגורציה.
יש פער שני. שם מארח גלוי אחד מכסה לעתים רחוקות את כל היישום, כי התחברות, מדיה ותעבורת API משתמשים לעתים קרובות בשמות נפרדים. כלל שנבנה משם המארח בשורת הכתובת יכול לכסות את הדף ולהחמיץ את הווידאו, מה שנקרא ככשל חלקי ולא כשגיאת ניתוב.
הפער השלישי הוא משפחת הכתובות. כלל ל-v4 בלבד לא אומר דבר על רשומת AAAA שהלקוח עשוי להעדיף.
שלושה תנאים שמכריעים בין כלל דומיין לטווחים
ראשית, האם השירות מפרסם סט יציב של קידומות שתוכלו להחזיק ולתעד? אם כן, טווחים מפורשים הם כנים וזולים. אם לא, כלל דומיין הוא המנגנון היחיד שיכול לעקוב אחרי השירות.
שנית, האם מנגנון הדומיין של הלקוח שלכם מתרענן? כלל שנפתר פעם אחת בעת החיבור ולעולם לא שוב הוא צילום מצב עם מיתוג טוב יותר. שלישית, האם המנגנון מכסה תת-דומיינים ושתי משפחות הכתובות, או רק את השמות שהקלדתם?
ענו על שלושת אלה והבחירה בדרך כלל ברורה. ניחוש מייצר כלל שעובד בבדיקות ונכשל בייצור.
בדקו הפעלה, לא דף
טענו את הדף ואז בצעו את הפעולה שחשובה: התחברות, התחלת ניגון, העלאת קובץ. כל אחת מהן יכולה להגיע למארח אחר, וזו שנכשלת היא זו שהכלל שלכם פספס.
פרטו את מה שההפעלה באמת יוצרת איתו קשר ולא את מה שהדף מציג:
dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5השאירו את הפותר גלוי במהלך ההשוואה, כי כלל שעובד מפותר אחד ונכשל מאחר מספר לכם על התשובה של ה-CDN, לא על המנהרה. TTL קצר גם אומר שלתשובה שתיעדתם יש תאריך תפוגה.
מה כל מנגנון באמת מכסה
שני המנגנונים נראים ניתנים להחלפה בעמוד הגדרות ומתנהגים אחרת מבפנים.
| Mechanism | What it matches | How it fails |
|---|---|---|
| Domain rule | Names the client resolves, then their addresses | Misses subdomains, or goes stale when refresh is off |
| Address route | A prefix you wrote down | Keeps matching an address the service has left |
נתיב כתובת בקרנל מתאים קידומות. אין לו מושג מהו שם מארח, ולכן הוא לא יכול לעקוב אחרי שירות שמחליף כתובות. כלל דומיין פותר שמות ומנתב את התוצאה; הוא עוקב אחרי השירות אבל תלוי בפותר, בהתנהגות הרענון ובטיפול של הלקוח בתת-דומיינים, ולכן כלל שעוקב אחרי שמות חייב להיבדק עם הפותר שהלקוח באמת משתמש בו.
אף אחד מהם אינו על-קבוצה של האחר, ולכן ערבובם בלי הערה יוצר בלבול מאוחר יותר.
בדקו שוב אחרי שהשירות משתנה
אחרי עדכון לקוח או שינוי בשירות, הריצו שוב את אותה בדיקת הפעלה. רשימת כתובות שעבדה בעבר היא ראיה לתקופה ההיא, לא מלאי קבוע של התשתית של השירות.
רשמו איזה מנגנון מכסה איזה שם מארח, ואת התאריך שבו אימתתם אותו לאחרונה.
ההערה הזו היא ההבדל בין כלל שאפשר להגן עליו לכלל שאיש לא מעז לגעת בו. אם השירות מפרסם רשימת קידומות משלו, השתמשו בה וציינו את התאריך. אם לא, אמרו זאת, והשאירו את כלל הדומיין עם התנהגות הרענון שלו כתובה לצידו.