🥇เราพบกับบริการจาก Cloudflare ตามที่อยู่ 1.1.1.1 และ 1.0.0.1 หรือ “ชั้นวาง DNS สาธารณะมาถึงแล้ว!”

บริษัทคลาวด์แฟลร์ นำเสนอ DNS สาธารณะตามที่อยู่:

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

มีการอ้างว่ามีการใช้นโยบาย "ความเป็นส่วนตัวมาก่อน" เพื่อให้ผู้ใช้สามารถมั่นใจเกี่ยวกับเนื้อหาในคำขอของตนได้

บริการนี้น่าสนใจเพราะนอกเหนือจาก DNS ปกติแล้ว ยังให้โอกาสในการใช้เทคโนโลยีอีกด้วย DNS ผ่าน TLS и DNS ผ่าน HTTPSซึ่งจะป้องกันไม่ให้ผู้ให้บริการดักฟังคำขอของคุณตลอดเส้นทางคำขอ และรวบรวมสถิติ การตรวจสอบ และการจัดการโฆษณา Cloudflare อ้างว่าวันที่ประกาศ (1 เมษายน 2018 หรือ 04/01 ในรูปแบบอเมริกัน) ไม่ได้ถูกเลือกโดยบังเอิญ: ในวันอื่นใดของปี "สี่หน่วย" จะถูกนำเสนอ?

เนื่องจากผู้ชมของ Habr เข้าใจในทางเทคนิค ส่วนแบบดั้งเดิมจึง “ทำไมเราถึงต้องใช้ 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 ซึ่งหมายถึง

การมีอยู่ของจุดลงจอด (จุดสิ้นสุด) - ตั้งอยู่ที่ https://cloudflare-dns.com/dns-queryและ
ลูกค้าที่สามารถส่งคำขอและรับการตอบกลับ

คำขอสามารถอยู่ในรูปแบบ 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 ที่เข้ารหัส 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 ของเซิร์ฟเวอร์ที่มีหน้าต้นขั้ว (เป็นผลให้เข้าถึงได้ ไซต์ดังกล่าวจะซับซ้อนมากขึ้นอย่างเห็นได้ชัด) หรือไปยังที่อยู่ของพร็อกซีเซิร์ฟเวอร์ของคุณที่ทำการกรอง

คุณน่าจะใส่รูปภาพจากเว็บไซต์ที่นี่ http://1.1.1.1/ซึ่งทำหน้าที่อธิบายการเชื่อมต่อกับบริการ เห็นได้ชัดว่าผู้เขียนมั่นใจในคุณภาพของ DNS อย่างสมบูรณ์ (แต่ก็ยากที่จะคาดหวังสิ่งที่แตกต่างจาก Cloudflare):

เราสามารถเข้าใจ Cloudflare ผู้สร้างบริการได้อย่างถ่องแท้: พวกเขาสร้างรายได้ด้วยการสนับสนุนและพัฒนาหนึ่งในเครือข่าย CDN ที่ได้รับความนิยมมากที่สุดในโลก (ฟังก์ชั่นนี้ไม่เพียงแต่ครอบคลุมการกระจายเนื้อหาเท่านั้น แต่ยังโฮสต์โซน DNS ด้วย) และ เพราะความปรารถนาอันแรงกล้าเหล่านั้น ที่ไม่ค่อยรู้อะไรมาก, สอนสิ่งเหล่านั้น พวกเขาไม่รู้จักใครเพื่อสิ่งนั้น ว่าจะไปที่ไหน บนเครือข่ายทั่วโลก มักจะประสบปัญหาจากการบล็อกที่อยู่เซิร์ฟเวอร์ด้วย เราจะไม่พูดว่าใคร - ดังนั้น การมี DNS ที่ไม่ได้รับอิทธิพลจาก "เสียงตะโกน เสียงหวีดหวิว และการเขียนลวก ๆ" ย่อมส่งผลเสียต่อธุรกิจของบริษัทน้อยลง และข้อได้เปรียบทางเทคนิค (สิ่งเล็ก ๆ น้อย ๆ แต่ดี: โดยเฉพาะสำหรับลูกค้าของ DNS Cloudflare ฟรีการอัปเดตบันทึก DNS ของทรัพยากรที่โฮสต์บนเซิร์ฟเวอร์ DNS ของบริษัทจะเป็นไปในทันที) ทำให้การใช้บริการที่อธิบายไว้ในโพสต์น่าสนใจยิ่งขึ้น .

เฉพาะผู้ใช้ที่ลงทะเบียนเท่านั้นที่สามารถเข้าร่วมในการสำรวจได้ เข้าสู่ระบบ, โปรด.

คุณจะใช้บริการใหม่หรือไม่?

ได้ เพียงระบุในระบบปฏิบัติการและ/หรือบนเราเตอร์
ใช่ และฉันจะใช้โปรโตคอลใหม่ (DNS บน HTTP และ DNS บน TLS)
ไม่ ฉันมีเซิร์ฟเวอร์ปัจจุบันเพียงพอแล้ว (นี่คือผู้ให้บริการสาธารณะ: Google, Yandex ฯลฯ)
ไม่ ฉันไม่รู้ด้วยซ้ำว่าฉันกำลังใช้อะไรอยู่ตอนนี้
ฉันใช้ DNS แบบเรียกซ้ำของตัวเองกับอุโมงค์ SSL ที่อยู่ตรงหน้า

ผู้ใช้ 693 คนโหวต ผู้ใช้ 191 รายงดออกเสียง

ที่มา: will.com

เราพบกับบริการจาก Cloudflare ตามที่อยู่ 1.1.1.1 และ 1.0.0.1 หรือ “ชั้นวาง DNS สาธารณะมาถึงแล้ว!”

จะใช้บริการใหม่ได้อย่างไร?

DNS ผ่าน HTTPs (DoH)

DNS ผ่าน TLS

คำอธิบายสองคำเกี่ยวกับสิ่งที่เรากำลังพูดถึง

คุณจะใช้บริการใหม่หรือไม่?

เพิ่มความคิดเห็น ยกเลิกการตอบ