הנחיות לגבי תת-רשת של לקוח DNS (ECS)

מבוא

RFC 7871 – תת-רשת של לקוח בשאילתות DNS – הגדרה של מנגנון למקודדים רקורסיביים, כמו Google Public DNS, לשליחת מידע על כתובות IP של לקוחות חלקיים לשרתי שמות DNS מהימנים. רשתות של העברת תוכן (CDN) ושירותים רגישים לזמן האחזור משתמשים באפשרות הזו כדי לספק תשובות מדויקות למיקום גיאוגרפי כשמשיבים לבקשות חיפוש שמות שמקודדות באמצעות DNS ציבורי.

ה-RFC מתאר תכונות של ECS ששרתי שמות מוסמכים חייבים להטמיע. אך ההטמעים לא תמיד עומדים בדרישות האלה. יש גם בעיות תפעוליות ופריסה של ECS שה-RFC לא מטפל בהן, שעלולות לגרום לבעיות במקודדים כמו Google Public DNS שמזהים תמיכה ב-ECS באופן אוטומטי בשרתי שמות מהימנים, וגם במקודדים שדורשים רשימת היתרים של ECS, כמו OpenDNS.

ההנחיות האלה נועדו לעזור למפעילים ולמפעילים של DNS מהימנים להימנע משגיאות נפוצות רבות שעלולות לגרום לבעיות ב-ECS.

הגדרות של מונחים

אנחנו משתמשים במונחים הבאים כדי לתאר פעולות של ECS:

  • הטמעות של שרת שמות (או תמיכה) ב-ECS אם הן מגיבות לשאילתות ב-ECS שכוללות אפשרויות ECS תואמות (גם אם לאפשרויות ה-ECS תמיד יש קידומת גלובלית לקידומת /0).

  • Ezone הוא מופעל ב-ECS אם ECS שולח שאילתות לשרתי השמות שלו שנשלחו עם קידומת מקור שאינה אפס.

הנחיות לשרתי שמות מוסמכים

  1. כל שרתי השמות המהימנים של אזור ה-ECS צריכים להפעיל את ה-ECS לאזור.

    • גם אם רק שרת שמות אחד לא מטמיע את ה-ECS או מפעיל את האזור הזה, הוא הופך במהירות למקור של רוב הנתונים שנשמרו במטמון. מאחר שהתשובות שלו בהיקף גלובלי, נעשה בהן שימוש (עד שתוקף ה-TTL שלהן יפוג) כתגובה לכל השאילתות עם אותו שם (ללא קשר לרשת המשנה של הלקוח). תגובות מהשרתים שכן מטמיעות את ה-ECS ומפעילים אותן משמשות רק לשאילתות מלקוחות בהיקף ההרשאות, כך שהסבירות שישתמשו בהן נמוכה בהרבה מאשר התשובות ברמת האתר.
  2. שרתי שמות מוסמכים שמטמיעים את ECS חייבים2 לשלוח תגובות ECS לשאילתות ECS עבור כל האזורים שמוצגים מכתובת IP או משם מארח ב-NS, גם עבור אזורים שאינם מופעלים של ECS.

    • ה-DNS הציבורי של Google מזהה באופן אוטומטי תמיכה ב-ECS לפי כתובת IP, ולא בשם המארח של שרת השמות או אזור ה-DNS, מפני שמספר הכתובות קטן יותר ממספר שמות המארחים של שרתי השמות, וקטן ממספר אזורי ה-DNS. אם שרת שמות מהימן לא שולח תמיד תגובות ECS לשאילתות EEC (גם עבור אזורים שאינם מופעלים על ידי ECS), ה-DNS הציבורי של Google עשוי להפסיק לשלוח לו שאילתות ECS.
  3. שרתי שמות מהימנים שמטמיעים את ה-ECS חייבים להגיב לכל השאילתות של ECS עם תגובות מ-ECS, כולל תגובות שליליות והפניות אוטומטיות.

    • גם בעיות שקשורות לזיהוי אוטומטי של תמיכת ECS חלות כאן.

    • תגובות שליליות (NXDOMAIN ו-NODATA) SHOULD3 עושות שימוש בהיקף גלובלי של 0/, ושמירה טובה יותר על תאימות ותאימות ל-RFC 7871.

    • מלבד NXDOMAIN ו-NODATA (ללא NOERROR עם קטע תשובות ריק), תגובות שגיאה אחרות לשאילתות ECS (במיוחד SERVFAIL ו-REFREF) צריכות לכלול אפשרות ECS תואמת עם היקף גלובלי של /0.

      • אם שרת שמות מוסמך מנסה להסיר עומס מהתקפת DoS, הוא יכול להחזיר SERVFAIL ללא נתוני ECS. הדבר עלול לגרום שוב ושוב ל-DNS ציבורי של Google להפסיק לשלוח שאילתות עם ECS (שעשויות לצמצם את מספר השאילתות החוקיות שהן שולחות, אך לא תשפיע על שאילתות אקראיות של מתקפת תת-דומיינים). הורדה של טעינת שאילתה לגיטימית במהלך מתקפת DoS עשויה לשפר את שיעור ההצלחה של שאילתות לגיטימיות, אבל לא בהכרח (את היכולת להציג תגובות מהמטמון לכל הלקוחות).

        גישה יעילה יותר לירידה בעומס היא לשלוח את כל התגובות בהיקפים גלובליים של 0/, כך ש-DNS הציבורי של Google ימשיך לשלוח שאילתות ECS. כך מתאפשר ל-Google Public DNS להחזיר תגובות הרבה זמן קצר לאחר סיום התקיפה, כי אין צורך לזהות מחדש את התמיכה של ECS, רק כדי לשלוח שאילתה מחדש אחרי שתוקף ה-TTL מסתיים בהיקף גלובלי.

    • בנוסף, לתגובה על הענקת גישה (הענקת גישה) צריכים להיות גם נתונים תואמים של ECS וSHOULD4 צריך להשתמש בהיקף גלובלי של 0/. הערה: תגובות האצלה אף פעם לא מועברות ללקוחות שהכתובות שלהם מופיעות בנתוני ECS, כך שרשומות NS, A או AAAA שממוקמות גיאוגרפית צריכות להיות נבחרות לפי כתובת ה-IP של הלקוח פותר הבעיות, ולא נתוני ECS.

  4. שרתי שמות מוסמכים שמטמיעים את ה-ECS חייבים לכלול אפשרות תואמת של ECS בתגובה לכל סוגי השאילתות שמתקבלים עם אפשרות ה-ECS. זה לא מספיק טוב כדי להגיב לשאילתות מסוג IPv4 (A) עם נתוני ECS. בתשובות מסוג A, AAAA, PTR, MX או כל סוג אחר של שאילתה חייבת להיות התאמה בין נתוני ECS למקודדים או כמקודדים, ו-Google Public DNS עשוי להפסיק לשלוח שאילתות עם נתוני ECS.

    באופן ספציפי, תגובות ECS לשאילתות SOA, NS ו-DS צריכות תמיד להשתמש בהיקף גלובלי /00 כדי לשמור במטמון בצורה טובה יותר וכדי לקבל תצוגה עקבית של הענקת גישה (תגובות עם מיקום גיאוגרפי לשאילתות A/AAAA לגבי שמות מארחים של שרתי שמות). אין להשתמש בסוגים כלשהם של שאילתות (למשל, TXT, PTR וכו') שלא משתנים על סמך נתוני ECS, בהיקף שווה לאורך קידומת המקור. יש להשתמש בהיקף גלובלי של 0 /כדי לשמור במטמון בצורה טובה יותר ובהפחתת שאילתות.

  5. שרתי שמות מוסמכים שמחזירים תגובות CNAME המותאמות ל-ECS SHOULD5 כוללים רק את ה-CNAME הראשון בשרשרת, והיעד הסופי של שרשרת ה-CNAME צריך להיות מופעל ב-ECS לאותו אורך של קידומת ההיקף. עקב חוסר בהירות במפרט ה-ECS, חלק מהמקודדים החוזרים (למשל, Unbound 6) עשויים להחזיר תגובה עם ההיקף של הדומיין הסופי שאינו CNAME (/0 אם הוא לא תומך ב-ECS).

  6. נתוני ECS עשויים להכיל כתובות IPv6 גם עבור שרתי שמות מסוג IPv4 בלבד (ולהפך, למרות ששרתי שמות מסוג IPv6 בלבד הם נדירים).

    • שרתי שמות צריכים להגיב עם נתונים חוקיים של אפשרות ECS (טווח 0// מותר, אבל כתובת המקור ואורך הקידומת חייבים להתאים).

    • ניתן להפעיל ECS עבור אזור בנפרד לכתובות IPv4 ו-IPv6.

  7. שרתי שמות מוסמכים שמחזירה תשובות עם תמיכה ב-ECS לא7 חופפים לקידומות של הטווחים בתשובות שלהם. דוגמה לתחיליות חופפות חופפות:

    • שאילתה עם קידומת המקור 198.18.0.0/15: תשובה א' עם קידומת היקף 198.0.0.0/8

    • שאילתה עם קידומת מקור 198.51.100/24: תשובה ב' עם קידומת היקף 198.51.0.0/16

    אם לקוח שולח שאילתה פתוחה חוזרת שכוללת את ECS לפי הסדר שלמעלה, שתי השאילתות עשויות לקבל תגובה A, כי ההיקף של התגובה A שנשמר במטמון כולל את ההיקף של השאילתה השנייה. גם אם שאילתות הלקוח נשלחות בסדר ההפוך, ושתי השאילתות עוברות לשרתי שמות מוסמכים, התוקף של תגובות שנשמרו במטמון עשוי לפוג בזמנים שונים. שאילתות עוקבות למקודד החוזר בקידומת החופפת יכולות 198.51.100/24 לקבל את התשובה A או B.

  8. בפעם הראשונה שמטמיעים תמיכה ב-ECS בשרתי שמות, צריך להשתמש בכתובות IP חדשות לשרתי שמות שמשרתים את האזורים המופעלים של ECS.

    • כששרתי שמות מוסמכים הטמיעו את ה-ECS אבל החזירו תוצאות מהיקף גלובלי, מתחילים להחזיר תשובות מסוג ECS מופעלות לאזור מסוים, ה-Google Public DNS מתחיל להחזיר תשובות עם מיקום גיאוגרפי לשאילתות זמן קצר ככל שהתוקף של ה-TTL של התגובות הקודמות להיקף גלובלי פג.

    • ב-Google Public DNS, הזיהוי של תמיכה ב-ECS מתבצע לעיתים רחוקות מאוד, כשהמערכת מנסה לזהות שאילתות IP עבור כתובת IP (או שם מארח של שרת שמות) כאשר היא מזהה באופן אוטומטי תמיכה ב-ECS (זמן קצוב לתפוגה, החזרת FORMERR, VERVERS או שליחת תגובות שאינן EEC). הטמעות חדשות של ECS בכתובות ה-IP האלה (או שמות מארחים ב-NS) מזוהות באופן אוטומטי לאט מאוד, או בכלל לא.

  9. יש לוודא שחיבורי הרשת מהימנים ושכל הגבלה על שיעור תגובה מוגדרת מספיק באופן שמאפשר לשרתי השמות לא לנחות שאילתות (או פחות, תגובה עם שגיאות ללא אפשרות ECS תואמת).

    • עבור שרתי שמות שמיישמים שיעור תגובה מוגבל בשאילתות ECS, התגובה הטובה ביותר היא NODATA עם קבוצת הדגל 'חיתוך' (TC), שכוללת רק קטע תואם של שאלה ואפשרות תואמת של ECS.
  10. שולחים תשובות תוך זמן קצר לכל השאילתות (מומלץ לעשות זאת תוך שנייה אחת).

    • השימוש בשירותי חיפוש גיאוגרפי של כתובות IP עבור שאילתות ECS לא יפעל בצורה אמינה, מפני שזמן האחזור המצטבר של שאילתת DNS ושל שירות Geo-IP באינטרנט אינו צפוי להיות קצר. במסגרת הזיהוי האוטומטי של DNS ב-Google, התמיכה ב-ECS נחשבת לאיחור בתמיכת ECS, או שהיא מקטינה את הסבירות ששאילתות עתידיות יישלחו עם ECS. אם מעוכבות מספיק תגובות, היא תפסיק לשלוח שאילתות ECS.

הפניות RFC 7871 והערות שוליים אחרות

1 https://tools.ietf.org/html/rfc7871#page-12

FAMILY, SOURCE PREFIX-LENGTH, and ADDRESS in the response MUST match those in the query. Echoing back these values helps to mitigate certain attack vectors, as described in Section 11.

2 https://tools.ietf.org/html/rfc7871#section-7.2.1

An Authoritative Nameserver that implements this protocol and receives an ECS option MUST include an ECS option in its response to indicate that it SHOULD be cached accordingly, regardless of whether the client information was needed to formulate an answer.

3 https://tools.ietf.org/html/rfc7871#section-7.4

It is RECOMMENDED that no specific behavior regarding negative answers be relied upon, but that Authoritative Nameservers should conservatively expect that Intermediate Nameservers will treat all negative answers as /0; therefore, they SHOULD set SCOPE PREFIX-LENGTH accordingly.

4 https://tools.ietf.org/html/rfc7871#section-7.4

The delegations case is a bit easier to tease out. In operational practice, if an authoritative server is using address information to provide customized delegations, it is the resolver that will be using the answer for its next iterative query. Addresses in the Additional section SHOULD therefore ignore ECS data, and the Authoritative Nameserver SHOULD return a zero SCOPE PREFIX-LENGTH on delegations.

5 https://tools.ietf.org/html/rfc7871#page-12

For the specific case of a Canonical Name (CNAME) chain, the Authoritative Nameserver SHOULD only place the initial CNAME record in the Answer section, to have it cached unambiguously and appropriately. Most modern Recursive Resolvers restart the query with the CNAME, so the remainder of the chain is typically ignored anyway.

6 https://unbound.net/pipermail/unbound-users/2015-May/003875.html

השימוש בהיקף הדומיין הסופי בשרשרת CNAME אינו מזיק ב-Unbound, מאחר שהוא נפרס בדרך כלל כ-stub מקומי או כמקודד העברה, שבו כל הלקוחות נמצאים באותה תת-רשת ומקבלים את אותה תגובה.

7 https://tools.ietf.org/html/rfc7871#page-13

Authoritative Nameservers might have situations where one Tailored Response is appropriate for a relatively broad address range, such as an IPv4 /20, except for some exceptions, such as a few /24 ranges within that /20. Because it can't be guaranteed that queries for all longer prefix lengths would arrive before one that would be answered by the shorter prefix length, an Authoritative Nameserver MUST NOT overlap prefixes.

When the Authoritative Nameserver has a longer prefix length Tailored Response within a shorter prefix length Tailored Response, then implementations can either:

  1. Deaggregate the shorter prefix response into multiple longer prefix responses, or

  2. Alert the operator that the order of queries will determine which answers get cached, and either warn and continue or treat this as an error and refuse to load the configuration.

...

When deaggregating to correct the overlap, prefix lengths should be optimized to use the minimum necessary to cover the address space, in order to reduce the overhead that results from having multiple copies of the same answer. As a trivial example, if the Tailored Response for 1.2.0/20 is A but there is one exception of 1.2.3/24 for B, then the Authoritative Nameserver would need to provide Tailored Responses for 1.2.0/23, 1.2.2/24, 1.2.4/22, and 1.2.8/21 all pointing to A, and 1.2.3/24 to B.