Penyemak imbas Chromium, induk sumber terbuka Google Chrome yang berkembang pesat dan Microsoft Edge baharu, telah menerima perhatian negatif yang ketara untuk ciri yang bertujuan dengan niat baik: ia menyemak sama ada ISP pengguna "mencuri" hasil pertanyaan domain yang tidak wujud .
, yang mencipta pertanyaan palsu untuk "domain" rawak yang secara statistik tidak mungkin wujud, bertanggungjawab untuk kira-kira separuh daripada jumlah trafik yang diterima oleh pelayan DNS akar di seluruh dunia. Jurutera Verisign Matt Thomas menulis panjang lebar di blog APNIC yang menerangkan masalah dan menilai skalanya.
Bagaimana resolusi DNS biasanya dilakukan
Pelayan ini ialah pihak berkuasa tertinggi yang perlu anda hubungi untuk menyelesaikan .com, .net, dsb. supaya mereka akan memberitahu anda bahawa frglxrtmpuf bukan domain peringkat atas (TLD).
DNS, atau Sistem Nama Domain, ialah sistem yang komputer boleh menyelesaikan nama domain yang tidak dapat dilupakan seperti arstechnica.com menjadi alamat IP yang kurang mesra pengguna seperti 3.128.236.93. Tanpa DNS, Internet tidak akan wujud dalam cara yang boleh digunakan oleh manusia, bermakna beban yang tidak perlu pada infrastruktur peringkat atas adalah masalah sebenar.
Memuatkan satu halaman web moden boleh memerlukan bilangan carian DNS yang luar biasa. Sebagai contoh, apabila kami menganalisis halaman utama ESPN, kami mengira 93 nama domain berasingan, daripada a.espncdn.com hingga z.motads.com. Kesemuanya diperlukan untuk halaman dimuatkan sepenuhnya!
Untuk menampung jenis beban kerja ini untuk enjin carian yang perlu berkhidmat kepada seluruh dunia, DNS direka bentuk sebagai hierarki berbilang peringkat. Di bahagian atas piramid ini ialah pelayan akar - setiap domain peringkat atasan, seperti .com, mempunyai keluarga pelayan sendiri yang merupakan kuasa tertinggi untuk setiap domain di bawahnya. Satu langkah ke atas ini pelayan adalah pelayan akar itu sendiri, daripada a.root-servers.net kepada m.root-servers.net.
Berapa kerap ini berlaku?
Terima kasih kepada hierarki caching berbilang peringkat infrastruktur DNS, peratusan yang sangat kecil daripada pertanyaan DNS dunia mencapai pelayan akar. Kebanyakan orang mendapatkan maklumat penyelesai DNS mereka terus daripada ISP mereka. Apabila peranti pengguna perlu mengetahui cara untuk pergi ke tapak web tertentu, permintaan dihantar terlebih dahulu ke pelayan DNS yang diuruskan oleh pembekal tempatan tersebut. Jika pelayan DNS tempatan tidak mengetahui jawapannya, ia memajukan permintaan kepada "pengirim semula" sendiri (jika dinyatakan).
Jika pelayan DNS pembekal tempatan mahupun "pelayan pemajuan" yang dinyatakan dalam konfigurasinya tidak mempunyai respons cache, permintaan itu dibangkitkan terus ke pelayan domain yang berwibawa atas yang anda cuba tukar. Bila Π΄ΠΎΠΌΠ΅Π½.com ini bermakna permintaan itu dihantar kepada pelayan berwibawa bagi domain itu sendiri com, yang terletak di gtld-servers.net.
Sistem gtld-servers, yang permintaan itu dibuat, membalas dengan senarai pelayan nama yang berwibawa untuk domain domain.com, serta sekurang-kurangnya satu rekod pautan yang mengandungi alamat IP satu pelayan nama sedemikian. Seterusnya, respons bergerak ke bawah rantai - setiap penghantar menghantar respons ini ke pelayan yang memintanya, sehingga respons akhirnya sampai ke pelayan pembekal tempatan dan komputer pengguna. Kesemua mereka menyimpan jawapan ini supaya tidak mengganggu sistem peringkat tinggi secara tidak perlu.
Dalam kebanyakan kes, rekod pelayan nama untuk domain.com sudah akan dicache pada salah satu penghantar ini, jadi pelayan akar tidak akan diganggu. Walau bagaimanapun, buat masa ini kita bercakap tentang jenis URL yang kita kenali - yang ditukar menjadi tapak web biasa. Permintaan Chrome berada pada tahap atas ini, pada langkah kelompok itu sendiri root-servers.net.
Pemeriksaan kecurian Chromium dan NXDomain
Chromium menyemak "adakah pelayan DNS ini menipu saya?" menyumbang hampir separuh daripada semua trafik yang mencapai kluster pelayan DNS akar Verisign.
Penyemak imbas Chromium, projek induk Google Chrome, Microsoft Edge baharu dan banyak penyemak imbas yang kurang dikenali, mahu memberikan pengguna kemudahan mencari dalam satu kotak, kadangkala dipanggil "Kotak Omni." Dalam erti kata lain, pengguna memasukkan kedua-dua URL sebenar dan pertanyaan enjin carian ke dalam medan teks yang sama di bahagian atas tetingkap penyemak imbas. Mengambil satu lagi langkah ke arah pemudahan, ia juga tidak memaksa pengguna untuk memasukkan sebahagian daripada URL dengannya http:// atau https://.
Walaupun begitu mudah, pendekatan ini memerlukan penyemak imbas memahami perkara yang harus dianggap sebagai URL dan apa yang harus dianggap sebagai pertanyaan carian. Dalam kebanyakan kes ini cukup jelas - contohnya, rentetan dengan ruang tidak boleh menjadi URL. Tetapi perkara boleh menjadi lebih rumit apabila anda mempertimbangkan intranetβrangkaian peribadi yang juga boleh menggunakan domain peringkat atas peribadi untuk menyelesaikan tapak web sebenar.
Jika pengguna pada intranet syarikat mereka menaip "pemasaran" dan intranet syarikat mempunyai tapak web dalaman dengan nama yang sama, maka Chromium memaparkan kotak maklumat yang meminta pengguna sama ada mereka mahu mencari "pemasaran" atau pergi ke https://marketing. Ini mungkin tidak berlaku, tetapi banyak ISP dan penyedia Wi-Fi awam "merampas" setiap URL yang salah eja, mengubah hala pengguna ke beberapa halaman yang dipenuhi sepanduk.
Generasi rawak
Pembangun Chromium tidak mahu pengguna pada rangkaian biasa melihat kotak maklumat yang bertanyakan maksud mereka setiap kali mereka mencari satu perkataan, jadi mereka melaksanakan ujian: Apabila mereka melancarkan penyemak imbas atau menukar rangkaian, Chromium melakukan carian DNS pada tiga peringkat teratas "domain" yang dijana secara rawak, panjang tujuh hingga lima belas aksara. Jika mana-mana dua permintaan ini kembali dengan alamat IP yang sama, maka Chromium menganggap bahawa rangkaian setempat sedang "merampas" ralat NXDOMAIN, yang sepatutnya diterima, jadi penyemak imbas menganggap semua pertanyaan satu perkataan yang dimasukkan sebagai percubaan carian sehingga notis selanjutnya.
Malangnya, dalam rangkaian yang tiada mencuri hasil pertanyaan DNS, ketiga-tiga operasi ini biasanya naik ke bahagian paling atas, sehingga ke pelayan nama akar itu sendiri: pelayan tempatan tidak tahu bagaimana untuk menyelesaikannya qwajuixk, jadi memajukan permintaan ini kepada pemajunya, yang melakukan perkara yang sama, sehingga akhirnya a.root-servers.net atau salah seorang daripada "saudara lelaki"nya tidak akan dipaksa untuk berkata "Maaf, tetapi ini bukan domain."
Memandangkan terdapat kira-kira 1,67*10^21 kemungkinan nama domain palsu antara tujuh hingga lima belas aksara panjangnya, yang paling biasa setiap daripada ujian ini yang dilakukan pada rangkaian "jujur", ia sampai ke pelayan akar. Ini berjumlah sebanyak separuh daripada jumlah beban pada DNS akar, mengikut statistik daripada bahagian kluster itu root-servers.net, yang dimiliki oleh Verisign.
Sejarah berulang
Ini bukan kali pertama projek dibuat dengan niat terbaik atau hampir membanjiri sumber awam dengan trafik yang tidak diperlukan - ini serta-merta mengingatkan kami tentang sejarah panjang dan menyedihkan pelayan NTP (Protokol Masa Rangkaian) D-Link dan Poul-Henning Kamp pada pertengahan 2000-an.
Pada tahun 2005, pemaju FreeBSD Poul-Henning, yang juga memiliki satu-satunya pelayan Protokol Masa Rangkaian Stratum 1 Denmark, menerima bil yang tidak dijangka dan besar untuk trafik yang dihantar. Ringkasnya, sebabnya ialah pembangun D-Link menulis alamat pelayan Stratum 1 NTP, termasuk pelayan Kampa, ke dalam perisian tegar barisan suis, penghala dan titik akses syarikat. Ini serta-merta meningkatkan trafik pelayan Kampa sembilan kali ganda, menyebabkan Pertukaran Internet Denmark (Titik Pertukaran Internet Denmark) menukar tarifnya daripada "Percuma" kepada "$9 setahun."
Masalahnya bukan kerana terdapat terlalu banyak penghala D-Link, tetapi ia "keluar dari talian." Sama seperti DNS, NTP mesti beroperasi dalam bentuk hierarki - Pelayan Stratum 0 menghantar maklumat kepada pelayan Stratum 1, yang menghantar maklumat kepada pelayan Stratum 2, dan seterusnya ke bawah hierarki. Penghala rumah biasa, suis atau titik akses seperti yang D-Link telah diprogramkan dengan alamat pelayan NTP akan menghantar permintaan ke pelayan Stratum 2 atau Stratum 3.
Projek Chromium, mungkin dengan niat yang terbaik, mereplikasi masalah NTP dalam masalah DNS, memuatkan pelayan akar Internet dengan permintaan yang tidak pernah dimaksudkan untuk dikendalikan.
Terdapat harapan untuk penyelesaian yang cepat
Projek Chromium mempunyai sumber terbuka , yang memerlukan melumpuhkan Intranet Redirect Detector secara lalai untuk menyelesaikan isu ini. Kami mesti memberi kredit kepada projek Chromium: pepijat telah ditemui sebelum itubagaimana Matt Thomas dari Verisign membawa banyak perhatian kepadanya di blog APNIC. Pepijat itu ditemui pada bulan Jun, tetapi kekal dilupakan sehingga jawatan Thomas; Selepas berpuasa, dia mula berada di bawah pengawasan rapi.
Diharapkan masalah itu akan diselesaikan tidak lama lagi, dan pelayan DNS akar tidak lagi perlu menjawab anggaran 60 bilion pertanyaan palsu setiap hari.
Sebagai iklan
Pelayan epik - Adakah atau Linux dengan pemproses keluarga AMD EPYC yang berkuasa dan pemacu Intel NVMe yang sangat pantas. Cepat-cepat order!
Sumber: www.habr.com