DNS-over-TLS (אבטחת שכבת התעבורה)

מבוא

התגובות והשאילתות הרגילות של ה-DNS נשלחות באמצעות UDP או TCP ללא הצפנה. המצב הזה חשוף לציתות ולזיוף (כולל סינון אינטרנט על סמך DNS). התגובות של מקודדים רקורסיביים שנשלחים ללקוחות הן החשופות ביותר לשינויים לא רצויים או זדוניים, ואילו בתקשורת בין מקודדים רקורסיביים לבין שרתי שמות מהימנים, נעשה לרוב הגנה נוספת.

כדי לפתור את הבעיות האלה, Google Public DNS מציע רזולוציית DNS באמצעות חיבורי TCP בהצפנת TLS, כפי שצוין ב-RFC 7858. פרוטוקול DNS-over-TLS משפר את הפרטיות והאבטחה בין הלקוחות לבין המקודדים. הפעולה הזו משלימה את DNSSEC ומגינה על תוצאות שאומתו באמצעות DNSSEC משינויים ומזיופים בדרך ללקוח.

איך זה עובד

הערה: בקטע הזה מוצגת סקירה כללית על פעולת DNS-over-TLS כשמדברים אל מקודד ה-DNS הציבורי של Google (בשם dns.google). לפרטים נוספים, תוכלו לקרוא את המאמר בנושא מפרט RFCs עבור DNS over Transport Layer Security ואת פרופילי שימוש ב-DNS over TLS וב-DNS over DTLS.

מערכת לקוח יכולה להשתמש ב-DNS-over-TLS עם אחד משני פרופילים: פרטיות מחמירה או אופורטוניסטית. בפרופיל הפרטיות המחמיר, המשתמש מגדיר שם של שרת DNS (שם הדומיין לאימות ב-RFC 8310) לשירות DNS-over-TLS, והלקוח צריך להיות מסוגל ליצור חיבור TLS מאובטח ביציאה 853 לשרת ה-DNS. אם לא נוצר חיבור מאובטח, זו שגיאה קשה ולא שירות DNS ללקוח.

בפרופיל הפרטיות האופורטוניסטי אפשר להגדיר את כתובת ה-IP של שרת ה-DNS באופן ישיר על ידי המשתמש, או לקבל אותה מהרשת המקומית (באמצעות DHCP או באמצעים אחרים). מקודד הלקוח מנסה ליצור חיבור מאובטח ביציאה 853 לשרת ה-DNS שצוין. אם נוצר חיבור מאובטח, הוא מספק פרטיות לשאילתות המשתמש מצופים פסיביים לאורך הנתיב. מכיוון שהלקוח לא מאמת את האותנטיות של השרת, הוא לא מוגן מפני תוקף פעיל. אם הלקוח לא מצליח ליצור חיבור מאובטח ביציאה 853, הוא חוזר בתקשורת עם שרת ה-DNS ביציאת ה-DNS הרגילה 53 באמצעות UDP או TCP, ללא צורך באבטחה או בפרטיות. השימוש ב-Opportunism Privacy נועד לתמוך בפריסה מצטברת של פרטיות מוגברת, תוך התמקדות בהטמעה נרחבת של פרופיל הפרטיות המחמיר.

כשמשתמשים בפרופיל פרטיות מחמיר, מקודדי stub יוצרים חיבור DNS-over-TLS באמצעות השלבים הבאים.

1. מקודד ה-stub מוגדר באמצעות שם המקודד של DNS-over-TLS dns.google.
2. המקודד stub מקבל את כתובות ה-IP של dns.google באמצעות מקודד ה-DNS המקומי.
3. המקודד stub יוצר חיבור TCP ליציאה 853 בכתובת ה-IP הזו.
4. המקודד stub מפעיל לחיצת יד של TLS באמצעות מקודד ה-DNS הציבורי של Google.
5. שרת ה-DNS הציבורי של Google מחזיר את אישור ה-TLS שלו יחד עם שרשרת מלאה של אישורי TLS עד לאישור בסיס מהימן.
6. המקודד stub מאמת את זהות השרת על סמך האישורים שמוצגים.
   • אם לא ניתן לאמת את הזהות, רזולוציית שם ה-DNS תיכשל ומקודד ה-stub יחזיר שגיאה.
7. אחרי שיוצרים חיבור TLS, למקודד ה-stub יש נתיב תקשורת מאובטח בין שרת DNS ציבורי של Google.
8. עכשיו המקודד stub יכול לשלוח שאילתות DNS ולקבל תשובות באמצעות החיבור.

כשהוא משתמש בפרופיל פרטיות מזדמן, הלקוח מנסה קודם כל ליצור חיבור TLS מאובטח לשרת. אנחנו עושים את זה בדומה לזה, עם הבדל חשוב אחד – הלקוח לא מבצע אימות אישורים. המשמעות היא שלא ניתן לסמוך על הזהות של השרת. אם לא ניתן ליצור חיבור TLS ביציאה 853 לשרת, מקודד ה-stub חוזר לדבר עם שרת ה-DNS ביציאה 53.

הערה: כדי למנוע התקפות של מניעת שירות ומיצוי משאבים בשרת, מערכת ה-DNS הציבורי של Google עשויה לסגור חיבורי DNS-over-TLS שלא היו פעילים במשך זמן רב מדי, או אם התקבל מספר גדול של שאילתות בחיבור. בפעם הבאה שהלקוח יצטרך לבצע שאילתות DNS, מקודד ה-stub יחזור על השלבים שלמעלה כדי ליצור מחדש חיבור למקודד ה-DNS הציבורי של Google.

פרטיות

מדיניות הפרטיות שלנו חלה על שירות DNS-over-TLS.

בתאריך 27/6/2019 הפעלנו מחדש את תת-רשת של לקוח EDNS (ECS) לשירות DNS-over-TLS. ECS הושבת בהשקת השירות.

תמיכה בתקנים

ב-DNS הציבורי של Google מתבצעת הטמעה של DNS-over-TLS על סמך RFC 7858. בנוסף, אנחנו תומכים בהמלצות הבאות כדי לספק שירות DNS באיכות גבוהה עם זמן אחזור קצר.

• TLS 1.3 (RFC 8846)
• פתיחה מהירה של TCP (RFC 7413)
• דרישות ההטמעה של העברת DNS ב-TCP (RFC 7766)

התחלת השימוש

כדאי לעיין instructions כדי להגדיר אותו במכשיר עם Android 9 (Pie) ומעלה.

יש תמיכה ב-DNS-over-TLS גם בשירות DNS64 הציבורי של Google שמיועד ל-IPv6 בלבד. שימו לב: לא מומלץ להגדיר DNS64 למכשיר נייד שיחבר לכמה רשתות, מפני ש-DNS64 פועל רק כש-IPv6 זמין.