យើងជួបសេវាកម្មពី 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 ជាសញ្ញាសម្គាល់របស់អាមេរិក) មិនត្រូវបានជ្រើសរើសដោយចៃដន្យទេ៖ តើ "បួនគ្រឿង" នឹងបង្ហាញនៅថ្ងៃណាផ្សេងទៀតនៃឆ្នាំ?

ដោយសារទស្សនិកជនរបស់ 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 ដែលមានន័យថា

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

សំណើបង្ហោះក្នុងទម្រង់ 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 នៅក្នុងកម្មវិធីរបស់យើង (ដូចដែលរួចហើយ។ នឹងបង្កើត Mozillaគ្រាន់តែនៅលើម៉ាស៊ីនមេ 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 ដែលមានច្រើនណាស់!) ទីពីរ ISPs មួយចំនួន (យើងនឹងមិនចង្អុលដៃទេ ប៉ុន្តែមិនមែនតូចបំផុតទេ) មានទំនោរបង្ហាញការផ្សាយពាណិជ្ជកម្មជំនួសឱ្យទំព័រដែលបានស្នើសុំមួយ ឬផ្សេងទៀត (ដែលត្រូវបានអនុវត្តយ៉ាងសាមញ្ញ៖ ជំនួសឱ្យអាសយដ្ឋាន IP ដែលបានបញ្ជាក់សម្រាប់សំណួរដោយ habranabr.ru ឈ្មោះម៉ាស៊ីន ជាមនុស្សចៃដន្យ ដូច្នេះអាសយដ្ឋាននៃម៉ាស៊ីនមេគេហទំព័ររបស់អ្នកផ្តល់សេវាត្រូវបានត្រឡប់មកវិញ ដែលទំព័រដែលមានការផ្សាយពាណិជ្ជកម្មត្រូវបានបម្រើ)។ ទីបី មានអ្នកផ្តល់ការចូលប្រើអ៊ីនធឺណិតដែលអនុវត្តយន្តការសម្រាប់បំពេញតម្រូវការសម្រាប់ការទប់ស្កាត់គេហទំព័រនីមួយៗដោយជំនួសការឆ្លើយតប DNS ត្រឹមត្រូវអំពីអាសយដ្ឋាន IP នៃធនធានគេហទំព័រដែលត្រូវបានរារាំងជាមួយនឹងអាសយដ្ឋាន IP នៃម៉ាស៊ីនមេរបស់ពួកគេដែលមានទំព័រ stub (ជាលទ្ធផល ការចូលប្រើទៅកាន់ គេហទំព័របែបនេះកាន់តែស្មុគស្មាញគួរឱ្យកត់សម្គាល់) ឬទៅកាន់អាសយដ្ឋាននៃម៉ាស៊ីនមេប្រូកស៊ីរបស់អ្នកដែលធ្វើការត្រង។

នេះប្រហែលជារូបភាពពីគេហទំព័រ។ http://1.1.1.1/ប្រើដើម្បីពិពណ៌នាអំពីការភ្ជាប់ទៅសេវាកម្ម។ អ្នកនិពន្ធហាក់ដូចជាមានទំនុកចិត្តលើគុណភាពនៃ DNS របស់ពួកគេ (ទោះជាយ៉ាងណាក៏ដោយវាពិបាកក្នុងការរំពឹងអ្វីផ្សេងទៀតពី Cloudflare):

មនុស្សម្នាក់អាចយល់ច្បាស់ពី Cloudflare ដែលជាអ្នកបង្កើតសេវាកម្ម៖ ពួកគេរកបាននំប៉័ងរបស់ពួកគេដោយរក្សា និងអភិវឌ្ឍបណ្តាញ CDN ដ៏ពេញនិយមបំផុតមួយនៅក្នុងពិភពលោក (មុខងារដែលរួមបញ្ចូលមិនត្រឹមតែការចែកចាយមាតិកាប៉ុណ្ណោះទេប៉ុន្តែថែមទាំងបង្ហោះតំបន់ DNS) និងដោយសារ បំណងប្រាថ្នារបស់អ្នកទាំងនោះ, ដែលមិនពូកែបង្រៀនអ្នកទាំងនោះ អ្នកណាគេមិនដឹងទៅនោះ។ ត្រូវ​ទៅណា នៅក្នុងបណ្តាញសកល ជាញឹកញាប់ទទួលរងពីការទប់ស្កាត់អាសយដ្ឋាននៃម៉ាស៊ីនមេរបស់ពួកគេពី កុំនិយាយថាអ្នកណា - ដូច្នេះការមាន DNS ដែលមិនត្រូវបានប៉ះពាល់ដោយ "ការស្រែក ហួច និងសរសេរអក្សរ" សម្រាប់ក្រុមហ៊ុននេះ មានន័យថាមិនសូវមានគ្រោះថ្នាក់ដល់អាជីវកម្មរបស់ពួកគេ។ ហើយគុណសម្បត្តិបច្ចេកទេស (តិចតួច ប៉ុន្តែល្អ៖ ជាពិសេសសម្រាប់អតិថិជនរបស់ DNS Cloudflare ឥតគិតថ្លៃ ការធ្វើបច្ចុប្បន្នភាពទិន្នន័យ DNS នៃធនធានដែលបានបង្ហោះនៅលើម៉ាស៊ីនមេ DNS របស់ក្រុមហ៊ុននឹងមានភាពរហ័សរហួន) ធ្វើឱ្យការប្រើប្រាស់សេវាកម្មដែលបានពិពណ៌នានៅក្នុងការបង្ហោះកាន់តែគួរឱ្យចាប់អារម្មណ៍។

មានតែអ្នកប្រើប្រាស់ដែលបានចុះឈ្មោះប៉ុណ្ណោះដែលអាចចូលរួមក្នុងការស្ទង់មតិនេះ។ ចូលសូម។

តើអ្នកនឹងប្រើសេវាកម្មថ្មីទេ?

• បាទ / ចាសដោយគ្រាន់តែបញ្ជាក់វានៅក្នុង OS និង / ឬនៅលើរ៉ោតទ័រ

• បាទ/ចាស ហើយខ្ញុំនឹងប្រើពិធីការថ្មី (DNS លើ HTTPs និង DNS លើ TLS)

• ទេ ខ្ញុំមានម៉ាស៊ីនមេបច្ចុប្បន្នគ្រប់គ្រាន់ (នេះគឺជាអ្នកផ្តល់សេវាសាធារណៈ៖ Google, Yandex ។ល។)

• ទេ ខ្ញុំមិនដឹងថាខ្ញុំកំពុងប្រើអ្វីនៅពេលនេះទេ។

• ខ្ញុំប្រើ DNS ឡើងវិញរបស់ខ្ញុំជាមួយនឹងផ្លូវរូងក្រោមដី SSL ដល់ពួកគេ។

អ្នកប្រើប្រាស់ 693 នាក់បានបោះឆ្នោត។ អ្នកប្រើប្រាស់ 191 នាក់ត្រូវបានហាមឃាត់។

ប្រភព: www.habr.com