Aspek teknis pemblokiran Internet di Rusia. Tantangan dan Prospek

Mari kita mulai segera dengan penafian: pada dasarnya tidak akan ada masalah politik di bawah ini. Kami akan melewati masalah administrasi dan hukum sebanyak yang kami bisa, sehingga tidak sepenuhnya merobek bagian teknis dari pesawat yang tersisa.

Kunci internet di Rusia sudah ada - ini adalah pemberian dengan mana kita hidup dan harus terus hidup. Dan jika demikian, Anda perlu memahami cara kerjanya secara teknis, apa yang penyedia dapat dan tidak bisa lakukan. Philip Culin ( schors ) telah lama mulai mengumpulkan informasi tentang hal ini, berpartisipasi dalam pekerjaan normatif, pergi ke berbagai pertemuan. Akibatnya, sekarang hanya Roskomnadzor yang tahu lebih banyak tentangnya tentang kunci di Rusia, tetapi ini tidak pasti. Di bawah potongan, ringkasan singkat dari keadaan saat ini.


Tentang pembicara: Direktur Jenderal Philip Kulin ( schors ) dari Deep Forest LLC, seorang hoster kecil Rusia, terutama terlibat dalam hosting bersama.

Kusut masalah

Tampaknya ada kunci dan ada. Kami tidak suka mereka, tapi mungkin tidak ada yang salah dengan mereka?

Sebenarnya, pemblokiran adalah masalah yang kusut.

Kerusakan kolateral adalah masalah pemblokiran terbesar. Contoh paling mencolok yang menggambarkan hal ini terjadi pada bulan April 2018, ketika blok besar alamat IP layanan cloud diblokir, masing-masing, banyak layanan tidak bekerja dan menderita kerusakan hebat.

Volatilitas peraturan dan praktik yang berubah sepanjang waktu. Setahun yang lalu, kisah ini akan sangat berbeda, dan dua tahun yang lalu kemungkinan besar akan bertentangan hari ini. Dalam setahun, semuanya akan berbeda lagi. Hari ini, dalam sebulan - sedikit salah, dan setelah setengah tahun tidak sama sekali. Ini harus dipantau, tetapi juga perlu untuk bekerja.

Kunci sulit didiagnosis . Jika beberapa sumber daya masuk ke kunci persis di registri - ini adalah kasus paling sederhana. Dalam kasus yang akan kita bahas nanti, cukup sulit untuk membedakan kunci nyata dari masalah teknis. Contoh yang mencolok - pada bulan Oktober, Yandex menjatuhkan DNS lima jam, selama waktu itu banyak yang memutuskan bahwa ini adalah pemblokiran Roskomnadzor. Sangat sulit untuk menentukan dengan tepat, dan situasi seperti itu sudah terjadi, jadi orang segera berpikir tentang pemblokiran.

Tidak mungkin untuk memprediksi kapan Anda akan diblokir dan apakah mereka akan diblokir sama sekali. Anda bekerja dengan tenang, dan pekerjaan Anda tiba-tiba berakhir.

Sangat tidak mungkin untuk menghitung risiko , karena, mungkin, beberapa widget di situs yang sudah Anda lupakan, atau mungkin seluruh bisnis, akan diserang. Contoh yang sangat baik dari ketidakpastian risiko adalah kasus Bitrix24. Pada bulan Maret, mereka dengan cepat memindahkan layanan mereka ke Amazon. Pada bulan yang sama, sebuah dokumen bocor ke jaringan, yang, memang benar, mungkin palsu, di mana subnet Amazon besar terdaftar. Namun demikian, Bitrix24 entah bagaimana bereaksi dan menghindari masalah pada bulan April, ketika layanan Amazon benar-benar diblokir.

Saya yakinkan Anda, sebagian besar dari Anda sangat sial! Dokumen-dokumen semacam itu tidak akan mengalir ke tangan Anda secara kebetulan. Ketika bisnis Anda selesai, Anda akan mempelajarinya setelah fakta.

Dalam kasus sederhana, diketahui mengapa situs Anda diblokir. Misalnya, forum memposting informasi yang oleh beberapa pengadilan diakui sebagai dilarang, tetapi Anda tidak punya waktu untuk bereaksi. Tetapi komunikasi dengan penyelia memiliki kerangka waktu yang tidak dapat diterima - misalnya, sehari. Di Internet selama ini, Anda bisa kehilangan seperlima bisnis.

Semua ini mengarah pada keputusasaan tertentu. Adalah mungkin untuk berdebat dengan ironi atas, misalnya, pemblokiran David Homack dan Lurk. Tapi itu masalah yang sama sekali berbeda ketika ini terjadi pada Anda, seperti yang pernah terjadi pada saya. Klien menunjukkan alamat IP server saya pada domain yang tidak saya kelola - saya duduk, dan telepon tidak berhenti. Pelanggan mengatakan mereka akan pergi, meminta pengembalian dana, tetapi saya tidak bisa melakukan apa pun! Dan tidak ada yang bisa membantu saya dengan ini. Ini benar-benar perasaan putus asa.

Kelompok risiko

Kekhawatiran kunci:

• Pemilik situs dan layanan , yang, termasuk, dapat diblokir karena kesalahan. Atau mereka mungkin mengenali beberapa informasi sebagai dilarang.
• Pengguna layanan kunci juga terpengaruh. Fakta bahwa situs Anda diblokir terutama berkaitan dengan Anda. Tetapi ada orang yang telah menggunakan situs atau layanan ini.
• Host dan penyedia yang berada di antara dua kebakaran. Karena mereka dituntut untuk bekerja dan melayani, dan penerapan persyaratan pengawas, yang mengancam dengan denda. Biarkan saya mengingatkan Anda bahwa denda dari 50 hingga 100 ribu rubel per protokol. Mungkin ada banyak protokol seperti itu, misalnya, per bulan, dan jumlah yang diperoleh sangat besar.

Cara kerja kunci

Pertama, kita membahas secara singkat bagaimana pemblokiran terjadi untuk memahami gambaran lengkap.

• Badan eksekutif federal atau pengadilan memutuskan untuk melarang informasi apa pun karena alasan tertentu.
• Informasi dikirim ke Roskomnadzor, yang harus membuat entri dalam daftar situs yang terlarang.
• Beberapa prosedur internal melangkah lebih jauh (ada banyak di antaranya juga - seluruh kuliah dapat dibaca), sebagai akibatnya Roskomnadzor dapat memutuskan untuk memblokirnya dan menambahkan situs ke apa yang disebut "unggah" - file teknis yang dikirim ke penyedia.
• Penyedia file ini melakukan pembatasan.
• Verifikasi penyedia, yang telah otomatis selama dua tahun sekarang.

Penting untuk dipahami bahwa lalu lintas difilter oleh setiap penyedia. Artinya, bukan di suatu tempat di router lintas batas atau filter negara, tetapi setiap penyedia menetapkan filter antara Internet dan pelanggan di masing-masing subnetnya. Dalam diagram di atas, perangkat verifikasi berada di dekat pelanggan, karena perangkat itu menyatakan dirinya sebagai pelanggan - ini penting.

Alat penyaringan

Penyedia dapat membeli lalu lintas yang difilter dari penyedia yang lebih tinggi. Tetapi ada masalah - ketika membeli lalu lintas dari penyedia yang lebih tinggi, penyedia-pembeli tidak dapat menentukan masalah teknis atau blok. Dia tidak memiliki alat apa pun, karena dia menerima sudah memotong lalu lintas, dan ini tidak mempengaruhi bisnisnya dengan baik.

Atau Anda dapat menggunakan:

• solusi komersial terintegrasi khusus;
• open source solusi open source (saat ini hanya ada satu proyek semacam itu);
• "pertanian kolektif" Anda.

Tidak ada roket, dan masalah utamanya adalah tidak menulis program sama sekali.

Opsi implementasi berikut tersedia.


Misalnya, Anda memiliki saluran kecil 100 Gbps, Anda menempatkan filter di celah.


Beberapa mirror traffic, tetapi dengan mirroring traffic, masalahnya adalah ia berfungsi seolah-olah di depan kurva. Yaitu, filter mencoba merespons lebih cepat daripada jawaban normal, masing-masing, jika filter mulai melambat, maka akan didenda (ingat, 50-100 ribu rubel).


Perutean selektif - saat lalu lintas ke alamat IP, yang mungkin mencakup sesuatu dari "unggahan", melewati filter terpisah.

Sayangnya, tidak ada angka pasti, tetapi dilihat dari tanda dan tes tidak langsung, ini sekarang merupakan cara paling umum untuk menyaring lalu lintas.

Perutean selektif dapat dilengkapi dengan fakta bahwa set alamat IP untuk penyaringan digabungkan ke atas. Artinya, bukan hanya beberapa alamat yang diblokir, tetapi seluruh / 24 jaringan segera sampai ke filter. Plus, penyedia besar, misalnya, di MTS, memiliki layanan keamanan khusus yang secara khusus mencari blok IP dengan risiko, yang juga termasuk dalam pemfilteran.

Routing selektif juga dapat dikombinasikan dengan pemfilteran DNS query . Ini adalah metode populer yang digunakan, misalnya, oleh Dom.ru.

Kami akan menganalisis secara bertahap berbagai masalah yang ditimbulkan semua ini.

Membuat Keputusan untuk Diblokir

Roskomnadzor membuat keputusan - ini segera menyebabkan masalah terkait, katakanlah, organisasi layanan dukungan. Dalam beberapa kasus, ini harus memberi tahu pemilik situs atau hoster, tetapi pada saat yang sama penerima pemberitahuan tidak akurat (diambil dari data publik, dan tidak semua orang mendukung alamat saat ini), pemberitahuan hilang, tidak ada informasi terbuka .

Karena itu, semua hal buruk terjadi. Tuan rumah atau pemilik situs tidak dapat mengontrol permintaan apa yang dibuat untuk itu, tidak ada informasi terbuka. Sebagai contoh, Google memiliki basis data situs dengan virus di mana Anda dapat mendaftarkan diri sebagai sistem otonom, entah bagaimana mengonfirmasi bahwa Anda adalah sistem otonom, dan benar-benar melihat sendiri situs mana, menurut Google, menyebarkan "malware" di sistem otonom Anda. Tidak ada yang namanya terkunci - Anda hanya mengandalkan pemberitahuan yang sampai pada Anda dan Anda dapat membacanya tepat waktu.

Ketentuan interaksi dengan Roskomnadzor tidak dihormati, dan umumnya agak aneh, terlepas dari kenyataan bahwa ada standar - mengirim pemberitahuan dalam sehari, merespons dalam sehari, membuat keputusan dalam sehari. Ketika Anda menerima pemberitahuan, dan Anda mengatakan bahwa Anda tidak memiliki informasi seperti itu dan meminta klarifikasi, Anda bisa mendapatkan jawabannya dalam beberapa minggu. Atau mungkin mereka akan memblokir Anda, dan kemudian mereka akan menjawab bahwa Anda masih memiliki informasi. Saya mengalami situasi seperti itu, tetapi hanya sedikit orang yang menuntut - Saya tidak tahu kasus seperti itu sama sekali.

Sekali lagi, jika pemberitahuan tiba, Anda tidak selalu dapat memahami tentang apa itu. Dalam kebanyakan kasus, Roskomnadzor biasanya menggambarkan apa artinya. Tetapi bahkan dalam praktik kami ada tiga kasus micro-hoster, ketika deskripsi membuatnya tidak jelas informasi apa yang kami bicarakan. Saya bahkan tidak tahu harus menulis apa kepada klien - Roskomnadzor mengeluarkan berita acara dan teks keputusan hanya di pengadilan, meskipun mereka memiliki dokumen tersebut.

Waktu penerapan "unloading"

Jadi, keputusan dibuat, penyedia mengunduh "unggahan" dan kemudian harus melakukan sesuatu dengannya. Ada dua opsi untuk seberapa cepat: sehari atau segera.

Adalah penting bahwa hari itu dialokasikan untuk memblokir sumber daya dan untuk membuka kunci, jika tiba-tiba keputusan dibuat untuk membukanya. Bagi banyak orang, ini dilakukan sebagai pembaruan per malam. Dari pengalaman saya: Saya tidak menerima pemberitahuan tepat waktu, sumber daya diblokir, masalah telah teratasi, tetapi Anda menunggu sehari saat mereka membebaskannya. Tapi bisnisnya tidak menunggu, ada kerugian.

Tetapi sekarang dalam norma-norma sangat sering kata "segera" berbunyi , dengan persetujuan lisan ini adalah satu jam . Tetapi ada kesepakatan lisan hari ini, dan besok tidak. Pada dasarnya, kata “segera” sekarang merujuk pada keputusan penuntutan ekstremisme.

Untuk memahami bagaimana semuanya difilter, Anda perlu tahu apa yang ada di dalam "debit". Ada daftar entri dalam XML dari satu dari empat jenis berdasarkan jenis kunci dan detail solusinya:

1. URL + domain + alamat IP;
   
2. Domain + alamat IP;
   
3. Domain dengan mask (* .example.com) + alamat IP (a);
   
4. Alamat IP (a) - tentu saja, ada alamat, dan diblokir sepenuhnya.
   

Untuk memperjelas angka apa yang dipertanyakan, di bawah ini adalah statistik untuk 22 Januari 2019.


Penting: hanya 139 ribu catatan, dan jenis pemblokiran yang paling populer adalah pemblokiran “menurut domain”. Ini adalah protokol HTTP dan HTTPS.

Toksisitas "bongkar"

Sebelum memblokir sumber daya, penyedia harus mengurai "pembongkaran". Ada masalah dengan ini juga. Saya secara khusus menarik perhatian pada fakta bahwa "pembongkaran" bukan sebuah registri, tetapi sebuah dokumen teknis yang dikeluarkan untuk penyedia sehingga ia membuat keputusan atas dasar itu. Tetapi meskipun demikian, penyedia harus melakukan pemrosesan "pembongkaran" yang sangat besar.

Misalnya, dalam "unggahan" ada redundansi , catatan saling tumpang tindih. Jika Anda mengambil URL, ini tidak berarti bahwa tidak akan ada pemblokiran oleh domain yang terkandung dalam URL ini. Tidak banyak dari mereka sekarang, bagaimanapun, sedikit lebih dari tiga ribu.

"Upload" berisi URL dengan fragmen (#) dan sesi . Ini umumnya mengerikan, karena Anda perlu memahami bagaimana tes berjalan.

Penyedia harus membawa "unggahan" ke bentuk normal, karena berisi URL dan domain yang salah. Pada dasarnya, hanya backslash yang sekarang ditemukan. Ada celah, tetapi mereka dengan cepat dihapus, dan untuk backslash, untuk beberapa alasan, "cinta" khusus. Nah, dengan garis miring terbalik, mereka memutuskan pertanyaan, tetapi jika ada tanda plus? Karena itu, harus selalu ada pemantauan, selalu ada sesuatu untuk dilakukan.

Sekali lagi saya menarik perhatian pada kenyataan bahwa masalah penyedia adalah masalah kita . Apa yang dilakukan penyedia? Motivasi 100 ribu rubel adalah motivasi yang baik untuk memastikan bahwa jika ada masalah, bahkan dengan sedikit pun masalah, potong segera, lalu cari tahu.

Relevansi dari "membongkar" alamat IP yang tidak "diblokir oleh alamat IP", tetapi semua yang lain (pemblokiran menurut domain, URL, mask) terlihat seperti ini.


Secara harfiah lebih dari setengah relevan, dan sisanya adalah daging cincang lengkap.

Memeriksa Kunci

Saya akan mulai dari akhir.

Seluruh sejarah penerapan kunci di Rusia adalah sejarah pemeriksaan kunci-kunci ini.

Saya tidak tahu bagaimana di luar negeri, bersama kami itu benar-benar persis sejarah inspeksi. Semua kunci tidak dibuat seperti yang tertulis, bagaimana melakukannya, tetapi ketika mereka memeriksa, karena tidak ada yang suka membayar denda, terutama 100 ribu.

Sebelum daftar situs terlarang ada daftar bahan ekstremis dari Departemen Kehakiman (itu ada sekarang, itu baru saja dalam registri, dan kemudian terpisah) dan pemeriksaan penuntutan kunci pada daftar ini. Saya seorang micro-hoster, dan saya berhasil memblokir sumber daya semacam itu dari saya.

Jenis cek yang ada:

• Inspeksi lapangan (terutama Kementerian Dalam Negeri, FSB dan kantor kejaksaan) - jarang terjadi, tetapi ada.
• SEBAGAI "Inspektur" adalah sistem otomatis favorit yang memeriksa semua penyedia.

"Inspektur" berdiri di belakang filter dan berpura-pura menjadi pelanggan. Tetapi perangkat itu sendiri tidak melakukan apa-apa, ia menerima tugas dan memberikan jawaban ke pusat kendali tertentu, mis. itu adalah shell jarak jauh di dalam jaringan provider. Kerjanya sangat mirip RIPE Atlas .

Pusat kendali sistem otomatis adalah layanan dengan beban nyata, karena kami memiliki 4 ribu operator telekomunikasi, mereka tidak memiliki satu jaringan, tetapi satu kotak harus ada di setiap jaringan. Artinya, tidak setiap penyedia, tetapi di setiap jaringan masing-masing penyedia . Karenanya, pusat kontrol memiliki masalah tertentu.

Pertanyaan: apakah ada masalah dengan cek itu sendiri? Tentu saja ada.

Masalah Verifikasi

Di SPECTRUM-2017 (forum di bawah naungan Roskomnadzor sendiri) Veklich A.A., salah satu kepala Perusahaan Negara Kesatuan Federal Pusat Radio Frekuensi Utama (RFRC) membuat laporan lengkap tentang apa sebenarnya masalah teknis dengan inspeksi "Inspektur" penyedia.

Masalah Verifikasi:

• Apakah "Inspektur" melihat ini sebagai filter dari penyedia atau sumber daya? Mungkin salah satu dari Anda yang menemukan basis data "Inspektur" dan semua situs hanya memberikan rintisan yang terlihat seperti rintisan penyedia.
• Kecepatan pemblokiran - untuk semua jenis pemblokiran (untuk HTTPS, domain, alamat IP), apa indikator bahwa sumber daya diblokir? Misalnya, Anda perlu memindai port berdasarkan alamat IP, ini adalah masalah keseluruhan.
• Kecepatan pemblokiran untuk protokol lain.
• Bagaimana cara memeriksa domain dengan mask ? Di bawah tanda bintang mungkin ada alamat IP yang berbeda, domain yang berbeda. Bisakah saya menaruh filter pada seluruh band? Dan untuk memeriksa itu - secara selektif atau menghasilkan hash? Saya harus segera mengatakan bahwa ada kunci seperti itu, tetapi tidak ada yang memeriksanya.

Metode kerja AS "Inspektur"

Sesuai dengan masalah ini, metodologi kerja "Penguji" telah dibuat.


Dan ya, slide Anda sepenuhnya menggambarkan teknik ini. Saya tidak begitu mengerti bagaimana secara logis Anda bisa hidup dengannya. Bagi kami, ini semua diterjemahkan ke dalam fakta bahwa penyedia berusaha untuk memecahkan masalah ini, dan membuatnya nyaman bagi mereka sendiri, dan tidak selalu nyaman bagi kami.

Bekerja tanpa teknik, banyak penyedia telah memperoleh pengalaman eksistensial. Secara umum, seluruh teknik pemblokiran adalah jalur empiris yang menghabiskan uang, saraf, jatuh, bahkan sekarang, ketika beberapa teknik sudah sedikit tenang.

Ada ruang obrolan tidak resmi (yang luar biasa - di Telegram, di mana lagi), di mana penyedia berkomunikasi dengan karyawan Pusat Frekuensi Radio. Yang paling menarik adalah Anda bisa mendapatkan bantuan nyata di sana, karyawan State Reserves Center membantu penyedia memecahkan masalah mereka, dan memberi tahu cara kerja "Inspektur". Tapi ini semua tidak resmi, tidak ada dokumen.

Ada norma Roskomnadzor tentang cara dan metode membatasi akses, yang terdaftar di Kementerian Kehakiman. Ini khusus berlaku di akhir, karena memiliki prioritas terendah. Penyedia tidak bertindak seperti yang tertulis dalam peraturan, tetapi lebih pada bagaimana metode verifikasi bekerja.

Teknik kerja dengan “bongkar”

Menurut standar dan pengalaman yang diperoleh, saya akan memberi tahu Anda bagaimana mereka bekerja dengan "membongkar", yaitu, bagaimana sumber daya kami diblokir.

Dengan URL :

• Jika ini adalah protokol HTTP normal, filter berdasarkan header.
• Jika protokol terenkripsi adalah HTTPS - filter sebagai "domain"

Mengapa umumnya tidak jelas URL dengan protokol terenkripsi, ini redundansi.

Menurut domain:

• Protokol HTTP yang biasa adalah filter oleh header Host.
• Protokol terenkripsi HTTPS - atau filter DNS; atau memfilter menurut tajuk SNI (saat membuat koneksi terenkripsi, tajuk tidak terenkripsi dengan nama domain di dalamnya dikirimkan); atau filter berdasarkan alamat IP.
• Protokol lain direkomendasikan untuk diblokir oleh alamat IP, tetapi karena "Inspektur" tidak memeriksa ini, seseorang melakukannya, seseorang tidak.

Standar mengatakan bahwa dalam kasus kedua, "oleh domain" kunci tidak dapat diblokir oleh alamat IP. Tetapi penyedia, ketika ia mulai membuang filter, segera termasuk tingkat lain, agar tidak mendapatkan denda. Kisah seperti itu tidak biasa dan secara alami mengarah pada kerusakan tambahan pada bisnis.

Secara teoritis, penyedia menyaring domain dengan topeng seperti oleh domain tanpa tanda bintang. Karena sekali lagi tidak ada cek, tidak ada masalah juga.

Mereka memfilter berdasarkan alamat IP dan memblokir alamat IP karena mereka tahu bagaimana - kadang-kadang di tepi router.

Peserta yang teliti

Kita tahu bahwa tidak hanya orang-orang “jahat” diblokir, tetapi juga para peserta Internet yang teliti . Misalnya, ketika seseorang tidak memiliki niat untuk menyimpan informasi terlarang di hostingnya, tetapi tidak membaca surat itu atau tidak menerima pemberitahuan.

Kelompok kedua adalah peserta asing. Mereka hidup di bidang hukum mereka dan tidak melanggar hukum. Mereka dapat tertawa, misalnya, saat menerima suap, mereka tidak melihat ada yang salah dengan itu. Misalnya, hosters bahkan tidak memiliki hak untuk menghapus informasi ini, karena undang-undang tidak berlaku untuk mereka. Mereka bukan orang jahat, tetapi kunci juga mengenai mereka.

Masalah penyaringan

Mari kita lihat masalahnya, bicara tentang pemfilteran DNS, yang direkomendasikan oleh norma.

Pertanyaan pertama: dari mana asal DNS ? Memang, informasi terlarang dapat diposting, tetapi DNS mewakili layanan yang dibutuhkan orang, seperti halnya DNS, misalnya, alamat IP. Saat memalsukan DNS, semuanya tidak terlalu baik, dan tidak jelas mengapa.

Poin kedua adalah implementasi intersepsi DNS . ( — ), . , .ru DNS, , DNS.

, . . , .

DNS (DNSCrypt, DoT, DoH) DNS.

, IP, HTTP/HTTPS. ? , , , Telegram ( ) — ? !

— , — , 443: SNI, SNI (ESNI) , , QUIC, DNSCrypt, VPN, MTProto-proxy?

, , Google, SNI, DNSCrypt 443 . -. , , HTTPS, . , .

, , 100 . , IP-, . , , , .

, « !». «» , «», , . , . - 100 , .


— , . IP, , «» IP . , IP ( ), , , .


: IP , «» IP, , , «» — . , , .

:

• ;
• ;
• , .

. , . , LiveJournal - - CDN, /23 IP. , , .

«»

«», , «», , , . , «». «» , , .

«» 200 «» , . , , . , , .

?


, , . MSK-IX, MSK-IX , . - DNS-.

DNS- , - «» , IP- , , IP- , .. - , , .

, , , . , , «», , 5 2017 .

. , . DDoS, .

, - - ?


14 2018 : , «» . - 4 , 400 , 4 000 IP-. , , - 600 , 20% TK .

:


, IP- «». 5 : « — - ?» . , IP ( ), , : DIGITAL RESISTANCE.

: « !», . , , - . , 2 , 2 , - . «» «» 4 000, , . , , — 1538.

, — - !

, . , - : - , . , . , , DNS- — , , . «» , .

, - HTTP , . Motobratan.ru , . , .

- , :

• «»;
• , «» ;
• ;
• .

, — . , , . «». «», , : «, , !» «» , - . - .

, , «», .

, , — . :

• .
• — , , .
• — ? , Kubernetes , — Continuous Integration!

— DPI , , . , DPI . -, - , . DPI , , DPI, . . DPI , , .

— DNS , .

• , DNS , — .
• , . , , .
• , DNS, «» .

: Telegram?

, : . Telegram , , , DPI . , , , Telegram.

, .

, , Telegram- @usher2 schors

HighLoad++ 2018. — , . , , Saint HighLoad++ .