Selepas satu setengah tahun pembangunan cache keluaran pelayan DNS , yang bertanggungjawab untuk resolusi nama rekursif. PowerDNS Recursor dibina pada asas kod yang sama seperti PowerDNS Authoritative Server, tetapi pelayan DNS rekursif dan autoritatif PowerDNS dibangunkan melalui kitaran pembangunan yang berbeza dan dikeluarkan sebagai produk berasingan. Kod projek dilesenkan di bawah GPLv2.
Versi baharu menghapuskan semua isu yang berkaitan dengan pemprosesan paket DNS dengan bendera EDNS. Dalam versi lama PowerDNS Recursor sebelum 2016, ia telah diamalkan untuk mengabaikan paket dengan bendera EDNS yang tidak disokong, tanpa menghantar respons dalam format lama, membuang bendera EDNS, seperti yang diperlukan oleh spesifikasi. Sebelum ini, tingkah laku bukan standard sedemikian disokong dalam BIND dalam bentuk penyelesaian, tetapi dalam rangka kerja Inisiatif Februari , pembangun pelayan DNS memutuskan untuk meninggalkan penggodaman ini.
Dalam PowerDNS, masalah utama dalam memproses paket dengan EDNS telah diperbaiki pada tahun 2017 dalam keluaran 4.1, dan dalam cawangan 2016 yang dikeluarkan pada tahun 4.0, ketidakserasian individu muncul yang berlaku di bawah satu set keadaan tertentu dan secara amnya tidak mengganggu operasi biasa. Dalam PowerDNS Recursor 4.2, seperti dalam , dialih keluar penyelesaian untuk menyokong pelayan berwibawa yang tidak menjawab pertanyaan dengan bendera EDNS dengan salah. Sehingga kini, jika tiada respons diterima selepas tempoh masa tertentu selepas menghantar permintaan dengan bendera EDNS, pelayan DNS menganggap bahawa bendera lanjutan tidak disokong dan menghantar permintaan kedua tanpa bendera EDNS. Tingkah laku ini kini dilumpuhkan, kerana mempunyai kod sedemikian mengakibatkan kelewatan yang meningkat disebabkan oleh penghantaran semula paket, peningkatan beban rangkaian dan kesamaran jika tiada tindak balas disebabkan kegagalan rangkaian, dan juga mengganggu pelaksanaan ciri berasaskan EDNS seperti penggunaan DNS Cookies untuk melindungi daripada serangan DDoS.
Tahun berikutnya diputuskan untuk mengadakan acara direka untuk memberi tumpuan kepada dengan pemecahan IP apabila memproses mesej DNS yang besar. Sebagai sebahagian daripada inisiatif betulkan saiz penimbal yang disyorkan untuk EDNS kepada 1200 bait, dan memproses permintaan melalui TCP dalam kategori yang semestinya disokong pada pelayan. Kini sokongan untuk memproses permintaan melalui UDP diperlukan, dan TCP adalah wajar, tetapi tidak diperlukan untuk operasi (standard menetapkan keupayaan untuk melumpuhkan TCP). Adalah dicadangkan untuk mengalih keluar pilihan untuk melumpuhkan TCP daripada standard dan menyeragamkan peralihan daripada menghantar permintaan melalui UDP kepada menggunakan TCP dalam kes di mana saiz penimbal EDNS yang ditetapkan tidak mencukupi.
Perubahan yang dicadangkan oleh inisiatif itu akan menghapuskan kekeliruan tentang pilihan saiz penimbal EDNS dan menyelesaikan masalah pemecahan mesej UDP yang besar, pemprosesan yang sering membawa kepada kehilangan paket dan tamat masa pada pihak pelanggan. Di sisi pelanggan, saiz penimbal EDNS akan tetap, dan respons besar akan segera dihantar kepada pelanggan melalui TCP. Mengelakkan menghantar mesej besar melalui UDP juga akan menyekat pada keracunan cache DNS, berdasarkan manipulasi paket UDP yang berpecah-belah (apabila dipecah menjadi serpihan, serpihan kedua tidak termasuk pengepala dengan pengecam, jadi ia boleh dipalsukan, yang mana ia cukup hanya untuk dipadankan dengan checksum).
PowerDNS Recursor 4.2 menangani isu dengan paket UDP yang besar dan berpindah untuk menggunakan saiz penimbal EDNS (edns-outgoing-bufsize) sebanyak 1232 bait dan bukannya had yang digunakan sebelum ini iaitu 1680 bait, yang sepatutnya mengurangkan dengan ketara kemungkinan kehilangan paket UDP. Nilai 1232 dipilih kerana ia adalah maksimum pada saiz respons DNS, dengan mengambil kira IPv6, sesuai dengan nilai MTU minimum (1280). Nilai parameter ambang pemotongan, yang bertanggungjawab untuk memotong respons kepada pelanggan, juga telah dikurangkan kepada 1232.
Perubahan lain dalam PowerDNS Recursor 4.2:
- Menambah sokongan mekanisme (X-Proxied-For), iaitu DNS bersamaan dengan pengepala HTTP X-Forwarded-For, yang membolehkan anda menghantar maklumat tentang alamat IP dan nombor port peminta asal, yang dimajukan melalui proksi perantaraan dan pengimbang beban (untuk contoh, dnsdist). Untuk mendayakan XPF, pilihan ""Dan"";
- Sokongan yang lebih baik untuk sambungan EDNS (ECS), yang membenarkan maklumat tentang subnet dari mana pertanyaan asal telah diracuni dalam permintaan DNS kepada pelayan DNS yang berwibawa (data tentang subnet sumber pelanggan diperlukan untuk operasi rangkaian penghantaran kandungan yang berkesan). Keluaran baharu menambah tetapan untuk kawalan terpilih ke atas penggunaan Subnet Pelanggan EDNS: «» dengan senarai netmask yang IP akan digunakan dalam ECS dalam permintaan keluar. Untuk alamat yang tidak sepadan dengan topeng yang ditentukan, alamat generik yang dinyatakan dalam "". Melalui arahan tersebut» anda boleh menentukan subnet, permintaan masuk dengan nilai ECS yang diisi yang tidak akan diganti;
- Untuk pelayan yang memproses sejumlah besar permintaan sesaat (lebih daripada 100 ribu), arahan "", yang menentukan bilangan utas untuk menerima permintaan masuk dan mengedarkannya di kalangan utas pekerja (hanya masuk akal apabila menggunakan "").
- Tetapan ditambah untuk menentukan fail anda sendiri dengan domain di mana pengguna boleh mendaftarkan subdomain mereka dan bukannya senarai PowerDNS Recursor terbina dalam.
Projek PowerDNS juga mengumumkan kitaran pembangunan enam bulan, dengan keluaran utama seterusnya PowerDNS Recursor 4.3 dijangka pada Januari 2020. Kemas kini untuk keluaran utama akan dilancarkan dalam tempoh setahun, diikuti oleh enam bulan lagi untuk pembetulan kerentanan. Oleh itu, sokongan untuk cawangan PowerDNS Recursor 4.2 akan bertahan sehingga Januari 2021. Perubahan kitaran pembangunan yang serupa telah diterima pakai untuk produk Pelayan Berwibawa PowerDNS, yang dijangka akan mengeluarkan 4.2 tidak lama lagi.
Ciri utama PowerDNS Recursor:
- Alat untuk pengumpulan jauh statistik;
- Mula semula segera;
- Enjin terbina dalam untuk penyambung pengendali dalam bahasa Lua;
- Sokongan penuh untuk DNSSEC dan ;
- Sokongan untuk RPZ (Zon Dasar Respons) dan keupayaan untuk menentukan senarai hitam;
- Mekanisme anti-spoofing;
- Keupayaan untuk menulis keputusan penyelesaian sebagai fail zon BIND.
- Untuk memastikan prestasi tinggi, mekanisme pemultipleksan sambungan moden dalam FreeBSD, Linux dan Solaris (kqueue, epoll, /dev/poll) digunakan, serta penghurai paket DNS berprestasi tinggi yang mampu memproses puluhan ribu permintaan selari.
Sumber: opennet.ru