אנו פוגשים את השירות מ-Cloudflare בכתובות 1.1.1.1 ו-1.0.0.1, או "מדף ה-DNS הציבורי הגיע!"

חברת Cloudflare מוצג DNS ציבורי בכתובות:

• 1.1.1.1
• 1.0.0.1
• 2606: 4700: 4700 :: 1111
• 2606: 4700: 4700 :: 1001

אומרים שהמדיניות היא "פרטיות תחילה", כך שמשתמשים יוכלו להיות שקט נפשי לגבי תוכן הבקשות שלהם.

השירות מעניין בכך שבנוסף ל-DNS הרגיל, הוא מספק את היכולת להשתמש בטכנולוגיות DNS-over-TLS и DNS-over-HTTPS, מה שימנע מאוד מספקים לצותת לבקשות שלכם לאורך נתיב הבקשות - ולאסוף סטטיסטיקות, לנטר, לנהל פרסום. Cloudflare טוענת כי תאריך ההכרזה (1 באפריל 2018, או 04/01 בסימון אמריקאי) לא נבחר במקרה: באיזה יום אחר בשנה יוצגו "ארבע היחידות"?

מכיוון שהקהל של הבר הוא בקיא טכנית, הקטע המסורתי "למה אתה צריך DNS?" אני אשים את זה בסוף הפוסט, אבל כאן אציין דברים שימושיים יותר מבחינה מעשית:

כיצד להשתמש בשירות החדש?

הדבר הפשוט ביותר הוא לציין את כתובות שרת ה-DNS הנ"ל בלקוח ה-DNS שלך (או כמו במעלה הזרם בהגדרות של שרת ה-DNS המקומי שבו אתה משתמש). האם זה הגיוני להחליף את הערכים הרגילים Google DNS (8.8.8.8 וכו'), או מעט פחות נפוץ שרתי DNS ציבוריים של Yandex (77.88.8.8 ואחרים כמוהם) לשרתים מ-Cloudflare - הם יחליטו בשבילכם, אבל מדברים עבור מתחילים לוח זמנים מהירות תגובה, לפיה Cloudflare מהירה יותר מכל המתחרים (אני אבהיר: המדידות בוצעו על ידי שירות של צד שלישי, והמהירות ללקוח ספציפי, כמובן, עשויה להיות שונה).

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

DNS דרך HTTPs (DoH)

כפי שהשם מרמז, התקשורת מתבצעת בערוץ HTTPS, כלומר

1. נוכחות של נקודת נחיתה (נקודת קצה) - היא ממוקמת בכתובת https://cloudflare-dns.com/dns-queryו -
2. לקוח שיכול לשלוח בקשות ולקבל תגובות.

בקשות יכולות להיות בפורמט DNS Wireformat המוגדר ב RFC1035 (נשלח באמצעות שיטות POST ו-GET HTTP), או בפורמט JSON (באמצעות שיטת GET HTTP). עבורי באופן אישי, הרעיון של ביצוע בקשות DNS באמצעות בקשות HTTP נראה בלתי צפוי, אבל יש בזה גרעין רציונלי: בקשה כזו תעבור מערכות סינון תעבורה רבות, ניתוח התגובות הוא די פשוט ויצירת בקשות קלה עוד יותר. הספריות והפרוטוקולים הרגילים אחראים לאבטחה.

בקש דוגמאות, היישר מהתיעוד:

קבל בקשה בפורמט DNS Wireformat

$ curl -v "https://cloudflare-dns.com/dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB" | hexdump
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x7f968700a400)
GET /dns-query?ct=application/dns-udpwireformat&dns=q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB HTTP/2
Host: cloudflare-dns.com
User-Agent: curl/7.54.0
Accept: */*

* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
HTTP/2 200
date: Fri, 23 Mar 2018 05:14:02 GMT
content-type: application/dns-udpwireformat
content-length: 49
cache-control: max-age=0
set-cookie: __cfduid=dd1fb65f0185fadf50bbb6cd14ecbc5b01521782042; expires=Sat, 23-Mar-19 05:14:02 GMT; path=/; domain=.cloudflare.com; HttpOnly
server: cloudflare-nginx
cf-ray: 3ffe69838a418c4c-SFO-DOG

{ [49 bytes data]
100    49  100    49    0     0    493      0 --:--:-- --:--:-- --:--:--   494
* Connection #0 to host cloudflare-dns.com left intact
0000000 ab cd 81 80 00 01 00 01 00 00 00 00 03 77 77 77
0000010 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00
0000020 01 c0 0c 00 01 00 01 00 00 0a 8b 00 04 5d b8 d8
0000030 22
0000031

בקשת POST בפורמט DNS Wireformat

$ echo -n 'q80BAAABAAAAAAAAA3d3dwdleGFtcGxlA2NvbQAAAQAB' | base64 -D | curl -H 'Content-Type: application/dns-udpwireformat' --data-binary @- https://cloudflare-dns.com/dns-query -o - | hexdump

{ [49 bytes data]
100    49  100    49    0     0    493      0 --:--:-- --:--:-- --:--:--   494
* Connection #0 to host cloudflare-dns.com left intact
0000000 ab cd 81 80 00 01 00 01 00 00 00 00 03 77 77 77
0000010 07 65 78 61 6d 70 6c 65 03 63 6f 6d 00 00 01 00
0000020 01 c0 0c 00 01 00 01 00 00 0a 8b 00 04 5d b8 d8
0000030 22
0000031

אותו דבר אבל באמצעות JSON

$ curl 'https://cloudflare-dns.com/dns-query?ct=application/dns-json&name=example.com&type=AAAA'

{
  "Status": 0,
  "TC": false,
  "RD": true,
  "RA": true,
  "AD": true,
  "CD": false,
  "Question": [
    {
      "name": "example.com.",
      "type": 1
    }
  ],
  "Answer": [
    {
      "name": "example.com.",
      "type": 1,
      "TTL": 1069,
      "data": "93.184.216.34"
    }
  ]
}

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

DNS על TLS

כברירת מחדל, שאילתות DNS מועברות ללא הצפנה. DNS על TLS הוא דרך לשלוח אותם דרך חיבור מאובטח. Cloudflare תומך ב-DNS על TLS ביציאה 853 סטנדרטית כפי שנקבע RFC7858. זה משתמש באישור שהונפק עבור המארח cloudflare-dns.com, TLS 1.2 ו-TLS 1.3 נתמכים.

יצירת חיבור ועבודה לפי הפרוטוקול מתבצעת בערך כך:

• לפני יצירת חיבור DNS, הלקוח מאחסן קוד SHA64 hash מקודד base256 של תעודת TLS של cloudflare-dns.com (נקרא SPKI)
• לקוח DNS יוצר חיבור TCP אל cloudflare-dns.com:853
• לקוח DNS יוזם לחיצת יד של TLS
• במהלך תהליך לחיצת היד של TLS, המארח cloudflare-dns.com מציג את אישור ה-TLS שלו.
• לאחר יצירת חיבור TLS, לקוח ה-DNS יכול לשלוח בקשות DNS דרך ערוץ מאובטח, המונע ציתות וזיוף של בקשות ותגובות.
• כל שאילתות ה-DNS הנשלחות דרך חיבור TLS חייבות לעמוד בדרישות שליחת DNS דרך TCP.

דוגמה לבקשה דרך DNS דרך TLS:

$ kdig -d @1.1.1.1 +tls-ca +tls-host=cloudflare-dns.com  example.com
;; DEBUG: Querying for owner(example.com.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP)
;; DEBUG: TLS, imported 170 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, C=US,ST=CA,L=San Francisco,O=Cloudflare, Inc.,CN=*.cloudflare-dns.com
;; DEBUG:      SHA-256 PIN: yioEpqeR4WtDwE9YxNVnCEkTxIjx6EEIwFSQW+lJsbc=
;; DEBUG:  #2, C=US,O=DigiCert Inc,CN=DigiCert ECC Secure Server CA
;; DEBUG:      SHA-256 PIN: PZXN3lRAy+8tBKk2Ox6F7jIlnzr2Yzmwqc3JnyfXoCw=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted.
;; TLS session (TLS1.2)-(ECDHE-ECDSA-SECP256R1)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 58548
;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1536 B; ext-rcode: NOERROR
;; PADDING: 408 B

;; QUESTION SECTION:
;; example.com.             IN  A

;; ANSWER SECTION:
example.com.            2347    IN  A   93.184.216.34

;; Received 468 B
;; Time 2018-03-31 15:20:57 PDT
;; From 1.1.1.1@853(TCP) in 12.6 ms

נראה כי אפשרות זו פועלת בצורה הטובה ביותר עבור שרתי DNS מקומיים המשרתים את הצרכים של רשת מקומית או משתמש בודד. נכון, עם תמיכה של התקן זה לא מאוד טוב, אבל - בואו נקווה!

שתי מילות הסבר על מה עוסקת השיחה

הקיצור DNS מייצג Domain Name Service (לכן לומר "שירות DNS" הוא מיותר משהו, הקיצור כבר מכיל את המילה "שירות"), ומשמש לפתרון משימה פשוטה - להבין איזו כתובת IP יש לשם מארח מסוים. בכל פעם שאדם לוחץ על קישור, או מזין כתובת בשורת הכתובת של הדפדפן (נניח, משהו כמו "https://habrahabr.ru/post/346430/"), המחשב האנושי מנסה להבין איזה שרת לשלוח בקשה לקבל את תוכן העמוד. במקרה של habrahabr.ru, התגובה מ-DNS תכיל אינדיקציה של כתובת ה-IP של שרת האינטרנט: 178.248.237.68, ואז הדפדפן כבר ינסה ליצור קשר עם השרת עם כתובת ה-IP שצוינה.

בתורו, שרת ה-DNS, לאחר שקיבל את הבקשה "מהי כתובת ה-IP של המארח בשם habrahabr.ru?", קובע אם הוא יודע משהו על המארח שצוין. אם לא, הוא מגיש בקשה לשרתי DNS אחרים בעולם, ושלב אחר שלב מנסה להבין את התשובה לשאלה שנשאלה. כתוצאה מכך, עם מציאת התשובה הסופית, הנתונים שנמצאו נשלחים ללקוח שעדיין מחכה להם, בנוסף הם מאוחסנים במטמון של שרת ה-DNS עצמו, מה שיאפשר לך לענות על שאלה דומה הרבה יותר מהר בפעם הבאה.

בעיה נפוצה היא, ראשית, נתוני שאילתת ה-DNS מועברים בצורה ברורה (מה שנותן לכל מי שיש לו גישה לזרימת התעבורה את היכולת לבודד את שאילתות ה-DNS ואת התגובות שהם מקבלים ולאחר מכן לנתח אותן למטרותיו; זה נותן היכולת למקד מודעות עם דיוק עבור לקוח DNS, וזה די הרבה!). שנית, ספקי שירותי אינטרנט מסוימים (לא נצביע אצבעות, אבל לא הקטנות ביותר) נוטים להציג מודעות במקום דף מבוקש כזה או אחר (שמיושם בצורה פשוטה למדי: במקום כתובת ה-IP שצוינה עבור שאילתה על ידי ה-habranabr.ru שם מארח, אדם אקראי לפיכך, מוחזרת הכתובת של שרת האינטרנט של הספק, שם מוגש הדף המכיל את הפרסומת). שלישית, ישנם ספקי גישה לאינטרנט המיישמים מנגנון למילוי הדרישות לחסימת אתרים בודדים על ידי החלפת תגובות ה-DNS הנכונות לגבי כתובות ה-IP של משאבי אינטרנט חסומים בכתובת ה-IP של השרת שלהם המכילה דפי סתימות (כתוצאה מכך, גישה אל אתרים כאלה מסובכים באופן ניכר), או לכתובת של שרת ה-proxy שלך שמבצע סינון.

זו כנראה צריכה להיות תמונה מהאתר. http://1.1.1.1/, משמש לתיאור החיבור לשירות. נראה שהכותבים די בטוחים באיכות ה-DNS שלהם (עם זאת, קשה לצפות למשהו אחר מ-Cloudflare):

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

רק משתמשים רשומים יכולים להשתתף בסקר. להתחברבבקשה.

האם תשתמש בשירות החדש?

• כן, פשוט על ידי ציון זה במערכת ההפעלה ו/או בנתב

• כן, ואני אשתמש בפרוטוקולים חדשים (DNS על HTTPs ו-DNS על TLS)

• לא, יש לי מספיק שרתים נוכחיים (זהו ספק ציבורי: גוגל, Yandex וכו')

• לא, אני אפילו לא יודע במה אני משתמש כרגע

• אני משתמש ב-DNS הרקורסיבי שלי עם מנהרת SSL אליהם

693 משתמשים הצביעו. 191 משתמשים נמנעו.

מקור: www.habr.com