ພວກເຮົາຕອບສະຫນອງການບໍລິການຈາກ 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, ເຊິ່ງຢ່າງຫຼວງຫຼາຍຈະປ້ອງກັນບໍ່ໃຫ້ຜູ້ໃຫ້ບໍລິການຈາກ eavesdropping ຕາມຄໍາຮ້ອງຂໍຂອງທ່ານຕາມເສັ້ນທາງຂອງການຮ້ອງຂໍ - ແລະເກັບກໍາສະຖິຕິ, ຕິດຕາມ, ຈັດການການໂຄສະນາ. Cloudflare ອ້າງວ່າວັນທີຂອງການປະກາດ (1 ເມສາ 2018, ຫຼື 04/01 ໃນຫມາຍເຫດອາເມລິກາ) ບໍ່ໄດ້ຖືກເລືອກໂດຍບັງເອີນ: ມື້ອື່ນຂອງປີ "ສີ່ຫນ່ວຍ" ຈະຖືກນໍາສະເຫນີ?

ນັບຕັ້ງແຕ່ຜູ້ຊົມຂອງ Habr ມີຄວາມຊໍານິຊໍານານທາງດ້ານເຕັກນິກ, ສ່ວນແບບດັ້ງເດີມ "ເປັນຫຍັງທ່ານຕ້ອງການ DNS?" ຂ້າ​ພະ​ເຈົ້າ​ຈະ​ໄດ້​ວາງ​ໄວ້​ໃນ​ຕອນ​ທ້າຍ​ຂອງ​ການ​ຕອບ​ສະ​ຫນອງ​, ແຕ່​ໃນ​ທີ່​ນີ້​ຂ້າ​ພະ​ເຈົ້າ​ຈະ​ກ່າວ​ເຖິງ​ສິ່ງ​ທີ່​ເປັນ​ປະ​ໂຫຍດ​ຫຼາຍ​:

ຈະໃຊ້ບໍລິການໃໝ່ແນວໃດ?

ສິ່ງທີ່ງ່າຍດາຍທີ່ສຸດແມ່ນການກໍານົດທີ່ຢູ່ເຊີຟເວີ DNS ຂ້າງເທິງຢູ່ໃນລູກຄ້າ DNS ຂອງທ່ານ (ຫຼືເປັນ upstream ໃນການຕັ້ງຄ່າຂອງເຄື່ອງແມ່ຂ່າຍ 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 ເບິ່ງຄືວ່າບໍ່ຄາດຄິດ, ແຕ່ມີເມັດພືດທີ່ສົມເຫດສົມຜົນຢູ່ໃນມັນ: ຄໍາຮ້ອງຂໍດັ່ງກ່າວຈະຜ່ານລະບົບການກັ່ນຕອງການຈະລາຈອນຫຼາຍ, parsing ຄໍາຕອບແມ່ນຂ້ອນຂ້າງງ່າຍດາຍ, ແລະການສ້າງຄໍາຮ້ອງຂໍແມ່ນງ່າຍກວ່າ. ຫ້ອງສະຫມຸດແລະໂປໂຕຄອນປົກກະຕິແມ່ນຮັບຜິດຊອບຕໍ່ຄວາມປອດໄພ.

ຂໍຕົວຢ່າງ, ກົງຈາກເອກະສານ:

ໄດ້ຮັບການຮ້ອງຂໍໃນຮູບແບບ 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"
    }
  ]
}

ແນ່ນອນ, router ເຮືອນທີ່ຫາຍາກ (ຖ້າຢ່າງຫນ້ອຍຫນຶ່ງ) ສາມາດເຮັດວຽກກັບ DNS ໃນທາງນີ້, ແຕ່ນີ້ບໍ່ໄດ້ຫມາຍຄວາມວ່າການສະຫນັບສະຫນູນຈະບໍ່ປາກົດໃນມື້ອື່ນ - ແລະ, ຫນ້າສົນໃຈ, ໃນທີ່ນີ້ພວກເຮົາສາມາດປະຕິບັດການເຮັດວຽກກັບ DNS ໃນຄໍາຮ້ອງສະຫມັກຂອງພວກເຮົາ (ເປັນແລ້ວ. ຈະເຮັດ Mozilla, ພຽງແຕ່ຢູ່ໃນເຄື່ອງແມ່ຂ່າຍ Cloudflare).

DNS ຜ່ານ TLS

ໂດຍຄ່າເລີ່ມຕົ້ນ, ການສອບຖາມ DNS ຖືກສົ່ງໂດຍບໍ່ມີການເຂົ້າລະຫັດ. DNS ຜ່ານ TLS ເປັນວິທີທີ່ຈະສົ່ງພວກມັນຜ່ານການເຊື່ອມຕໍ່ທີ່ປອດໄພ. Cloudflare ຮອງຮັບ DNS ຜ່ານ TLS ໃນພອດມາດຕະຖານ 853 ຕາມທີ່ກຳນົດໄວ້ RFC7858. ນີ້ໃຊ້ໃບຢັ້ງຢືນທີ່ອອກໃຫ້ສໍາລັບເຈົ້າພາບ cloudflare-dns.com, TLS 1.2 ແລະ TLS 1.3 ໄດ້ຮັບການສະຫນັບສະຫນູນ.

ການ​ສ້າງ​ການ​ເຊື່ອມ​ຕໍ່​ແລະ​ການ​ເຮັດ​ວຽກ​ຕາມ​ອະ​ນຸ​ສັນ​ຍາ​ເປັນ​ບາງ​ສິ່ງ​ບາງ​ຢ່າງ​ເຊັ່ນ​ນີ້​:

• ກ່ອນທີ່ຈະສ້າງການເຊື່ອມຕໍ່ DNS, ລູກຄ້າເກັບຮັກສາ hash 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 address ຊື່ໂຮດສະເພາະໃດ. ທຸກໆຄັ້ງທີ່ຄົນຄລິກໃສ່ການເຊື່ອມຕໍ່, ຫຼືເຂົ້າໄປໃນທີ່ຢູ່ໃນແຖບທີ່ຢູ່ຂອງຕົວທ່ອງເວັບ (ເວົ້າວ່າ, ບາງສິ່ງບາງຢ່າງເຊັ່ນ: "https://habrahabr.ru/post/346430/"), ຄອມພິວເຕີຂອງມະນຸດກໍາລັງພະຍາຍາມຄິດອອກວ່າເຄື່ອງແມ່ຂ່າຍໃດທີ່ຈະສົ່ງຄໍາຮ້ອງຂໍເພື່ອໃຫ້ໄດ້ຮັບເນື້ອຫາຂອງຫນ້າ. ໃນກໍລະນີຂອງ habrahabr.ru, ຄໍາຕອບຈາກ DNS ຈະມີຕົວຊີ້ບອກທີ່ຢູ່ IP ຂອງເຄື່ອງແມ່ຂ່າຍເວັບ: 178.248.237.68, ແລະຫຼັງຈາກນັ້ນຕົວທ່ອງເວັບຈະພະຍາຍາມຕິດຕໍ່ກັບເຄື່ອງແມ່ຂ່າຍທີ່ມີທີ່ຢູ່ IP ທີ່ລະບຸໄວ້.

ໃນທາງກັບກັນ, ເຄື່ອງແມ່ຂ່າຍ DNS, ໄດ້ຮັບຄໍາຮ້ອງຂໍ "ທີ່ຢູ່ IP ຂອງເຈົ້າພາບທີ່ມີຊື່ວ່າ habrahabr.ru ແມ່ນຫຍັງ?", ກໍານົດວ່າມັນຮູ້ຫຍັງກ່ຽວກັບເຈົ້າພາບທີ່ລະບຸ. ຖ້າບໍ່, ມັນເຮັດໃຫ້ການຮ້ອງຂໍກັບເຄື່ອງແມ່ຂ່າຍ DNS ອື່ນໆໃນໂລກ, ແລະ, ຂັ້ນຕອນໂດຍຂັ້ນຕອນ, ພະຍາຍາມຊອກຫາຄໍາຕອບຂອງຄໍາຖາມທີ່ຖາມ. ດັ່ງນັ້ນ, ເມື່ອຊອກຫາຄໍາຕອບສຸດທ້າຍ, ຂໍ້ມູນທີ່ພົບເຫັນແມ່ນຖືກສົ່ງໄປຫາລູກຄ້າທີ່ຍັງລໍຖ້າພວກເຂົາ, ບວກກັບມັນຖືກເກັບໄວ້ໃນ cache ຂອງເຄື່ອງແມ່ຂ່າຍ DNS ເອງ, ເຊິ່ງຈະຊ່ວຍໃຫ້ທ່ານສາມາດຕອບຄໍາຖາມທີ່ຄ້າຍຄືກັນໄດ້ໄວຂຶ້ນໃນຄັ້ງຕໍ່ໄປ.

ບັນຫາທົ່ວໄປແມ່ນວ່າ, ທໍາອິດ, ຂໍ້ມູນການສອບຖາມ DNS ແມ່ນຖືກສົ່ງຜ່ານຢ່າງຈະແຈ້ງ (ເຊິ່ງໃຫ້ທຸກຄົນທີ່ມີການເຂົ້າເຖິງການໄຫຼເຂົ້າຂອງການຈະລາຈອນສາມາດແຍກການສອບຖາມ DNS ແລະການຕອບຮັບທີ່ເຂົາເຈົ້າໄດ້ຮັບແລະຫຼັງຈາກນັ້ນວິເຄາະໃຫ້ເຂົາເຈົ້າສໍາລັບຈຸດປະສົງຂອງຕົນເອງ; ນີ້ເຮັດໃຫ້. ຄວາມສາມາດໃນການກໍານົດເປົ້າຫມາຍການໂຄສະນາທີ່ມີຄວາມຖືກຕ້ອງສໍາລັບລູກຄ້າ DNS, ເຊິ່ງແມ່ນຂ້ອນຂ້າງຫຼາຍ!). ອັນທີສອງ, ບາງ ISPs (ພວກເຮົາຈະບໍ່ຊີ້, ແຕ່ບໍ່ແມ່ນຂະຫນາດນ້ອຍທີ່ສຸດ) ມີແນວໂນ້ມທີ່ຈະສະແດງໂຄສະນາແທນທີ່ຈະເປັນຫນ້າຫນຶ່ງຫຼືຫນ້າຮ້ອງຂໍອື່ນ (ເຊິ່ງຖືກປະຕິບັດຢ່າງງ່າຍດາຍ: ແທນທີ່ຈະເປັນທີ່ຢູ່ IP ທີ່ລະບຸໄວ້ສໍາລັບການສອບຖາມໂດຍ habranabr.ru. ຊື່ເຈົ້າພາບ, ບຸກຄົນທີ່ສຸ່ມດັ່ງນັ້ນ, ທີ່ຢູ່ຂອງເຄື່ອງແມ່ຂ່າຍເວັບໄຊຕ໌ຂອງຜູ້ໃຫ້ບໍລິການຖືກສົ່ງຄືນ, ບ່ອນທີ່ຫນ້າທີ່ມີການໂຄສະນາແມ່ນໃຫ້ບໍລິການ). ອັນທີສາມ, ມີຜູ້ໃຫ້ບໍລິການເຂົ້າເຖິງອິນເຕີເນັດທີ່ປະຕິບັດກົນໄກການປະຕິບັດຕາມຂໍ້ກໍານົດສໍາລັບການສະກັດແຕ່ລະສະຖານທີ່ໂດຍການປ່ຽນແທນການຕອບ DNS ທີ່ຖືກຕ້ອງກ່ຽວກັບທີ່ຢູ່ IP ຂອງຊັບພະຍາກອນເວັບໄຊຕ໌ທີ່ຖືກບລັອກດ້ວຍທີ່ຢູ່ IP ຂອງເຄື່ອງແມ່ຂ່າຍຂອງພວກເຂົາທີ່ມີຫນ້າ stub (ດັ່ງນັ້ນ, ການເຂົ້າເຖິງ. ສະ​ຖານ​ທີ່​ດັ່ງ​ກ່າວ​ມີ​ຄວາມ​ສັບ​ສົນ​ຫຼາຍ​ຢ່າງ​ຊັດ​ເຈນ), ຫຼື​ທີ່​ຢູ່​ຂອງ​ເຊີບ​ເວີ​ຕົວ​ແທນ​ຂອງ​ທ່ານ​ທີ່​ດໍາ​ເນີນ​ການ​ກັ່ນ​ຕອງ.

ນີ້ອາດຈະເປັນຮູບຈາກເວັບໄຊທ໌. http://1.1.1.1/, ໃຊ້ເພື່ອອະທິບາຍການເຊື່ອມຕໍ່ກັບການບໍລິການ. ຜູ້ຂຽນເບິ່ງຄືວ່າຂ້ອນຂ້າງຫມັ້ນໃຈໃນຄຸນນະພາບຂອງ DNS ຂອງເຂົາເຈົ້າ (ຢ່າງໃດກໍຕາມ, ມັນເປັນການຍາກທີ່ຈະຄາດຫວັງຫຍັງອີກແດ່ຈາກ Cloudflare):

ຫນຶ່ງສາມາດເຂົ້າໃຈຢ່າງເຕັມສ່ວນ Cloudflare, ຜູ້ສ້າງການບໍລິການ: ພວກເຂົາມີລາຍໄດ້ເຂົ້າຈີ່ຂອງພວກເຂົາໂດຍການຮັກສາແລະພັດທະນາຫນຶ່ງໃນເຄືອຂ່າຍ CDN ທີ່ນິຍົມທີ່ສຸດໃນໂລກ (ເຊິ່ງຫນ້າທີ່ປະກອບມີບໍ່ພຽງແຕ່ການແຈກຢາຍເນື້ອຫາ, ແຕ່ຍັງເປັນເຈົ້າພາບເຂດ DNS), ແລະ, ເນື່ອງຈາກ. ຄວາມ​ປາ​ຖະ​ຫນາ​ຂອງ​ຜູ້​ທີ່​, ຜູ້ທີ່ບໍ່ໄດ້ versed ດີ, ສອນເຫຼົ່ານັ້ນ ຜູ້ທີ່ເຂົາເຈົ້າບໍ່ຮູ້, ເຖິງວ່າ ໄປໃສ ໃນເຄືອຂ່າຍທົ່ວໂລກ, ຂ້ອນຂ້າງມັກຈະທົນທຸກຈາກການຂັດຂວາງທີ່ຢູ່ຂອງເຄື່ອງແມ່ຂ່າຍຂອງພວກເຂົາຈາກ ບໍ່ໃຫ້ເວົ້າວ່າໃຜ - ດັ່ງນັ້ນການມີ DNS ທີ່ບໍ່ໄດ້ຮັບຜົນກະທົບຈາກ "ສຽງຮ້ອງ, whistles ແລະ scribbles" ສໍາລັບບໍລິສັດຫມາຍຄວາມວ່າເປັນອັນຕະລາຍຫນ້ອຍຕໍ່ທຸລະກິດຂອງພວກເຂົາ. ແລະຄວາມໄດ້ປຽບທາງດ້ານເຕັກນິກ (ເລັກນ້ອຍ, ແຕ່ງາມ: ໂດຍສະເພາະ, ສໍາລັບລູກຄ້າຂອງ DNS Cloudflare ຟຣີ, ການປັບປຸງບັນທຶກ DNS ຂອງຊັບພະຍາກອນທີ່ໂຮດຢູ່ໃນເຄື່ອງແມ່ຂ່າຍ DNS ຂອງບໍລິສັດຈະທັນທີ) ເຮັດໃຫ້ການໃຊ້ບໍລິການທີ່ອະທິບາຍໄວ້ໃນຂໍ້ຄວາມທີ່ຫນ້າສົນໃຈຫຼາຍ.

ພຽງແຕ່ຜູ້ໃຊ້ລົງທະບຽນສາມາດເຂົ້າຮ່ວມໃນການສໍາຫຼວດ. ເຂົ້າ​ສູ່​ລະ​ບົບກະລຸນາ.

ເຈົ້າຈະໃຊ້ບໍລິການໃໝ່ບໍ?

• ແມ່ນແລ້ວ, ໂດຍພຽງແຕ່ລະບຸມັນຢູ່ໃນ OS ແລະ / ຫຼືໃນ router

• ແມ່ນແລ້ວ, ແລະຂ້ອຍຈະໃຊ້ໂປຣໂຕຄໍໃໝ່ (DNS ຜ່ານ HTTPs ແລະ DNS ຜ່ານ TLS)

• ບໍ່, ຂ້ອຍມີເຄື່ອງແມ່ຂ່າຍປະຈຸບັນພຽງພໍ (ນີ້ແມ່ນຜູ້ໃຫ້ບໍລິການສາທາລະນະ: Google, Yandex, ແລະອື່ນໆ).

• ບໍ່, ຂ້ອຍບໍ່ຮູ້ວ່າຂ້ອຍກໍາລັງໃຊ້ຫຍັງໃນຕອນນີ້

• ຂ້ອຍໃຊ້ DNS recursive ຂອງຂ້ອຍກັບອຸໂມງ SSL ໃຫ້ພວກເຂົາ

693 ຜູ້ໃຊ້ລົງຄະແນນສຽງ. 191 ຜູ້ໃຊ້ງົດ.

ແຫຼ່ງຂໍ້ມູນ: www.habr.com