שיעורי מודול (2/3)
Serve-stale and data freshness
הגשה מיושן ורעננות הנתונים
בדרך כלל, פותר מרענן או משליך תשובה לאחר שה-TTL שלו פג. Serve-stale מאפשר לפותר, כאשר הוא אינו יכול לרענן נתונים, להחזיר תשובה שפג תוקפו באופן זמני במקום להיכשל באופן מיידי. זה כמו להשתמש בעותק גיבוי של ספרייה בזמן שהמשרד המרכזי אינו נגיש.
זה יכול לשפר את הזמינות אך מפחית את הרעננות: ייתכן שכתובת ישנה כבר לא תקפה או בטוחה. הפותר צריך לנסות לרענן, להגביל את משך הזמן שהוא מגיש נתונים מיושנים ולטפל בזהירות בחתימות DNSSEC שפג תוקפן וברשומות רגישות לאבטחה כגון DS או TLSA.
לדוגמה, אם לא ניתן להגיע לרשות ולפותר יש api.example.test → 192.0.2.10, הגשת התשובה המעופשת הזו עשויה להשאיר שירות זמין אם הכתובת עדיין נכונה. אם הכתובת הוקצתה מחדש, אותה התנהגות עלולה להיות מסוכנת. הגשה מעופש היא מדיניות פותר, לא ביטול אוניברסלי של TTLs. הגדירו גבולות ועקוב אחר השימוש בו.
התייחסות: RFC 8767 — הגשת נתונים מעופשים כדי לשפר את גמישות ה-DNS
בדוק את ההבנה שלך
בחר את התשובה הטובה ביותר. הדוגמאות משתמשות בשמות אימון ואינן שולחות שאילתות DNS אמיתיות.
מה הפשרה עם הגשה מעופש?