KONFIGURASI KEAMANAN DNS
Pada tingkat makro, layanan DNS sangat penting untuk pengoperasian Internet. Pada mikro
atau di tingkat lokal, layanan DNS bisa menjadi penting bagi operasi suatu perusahaan atau rendah hati
tapi keluarga yang tercinta situs web. Dalam semua kasus, investasi yang tepat dalam keamanan harus
dilakukan untuk memastikan efektivitas dan keamanan dari sistem DNS. DNS adalah dengan sifatnya publik
sistem, dan bertindak seperti pot madu lebah buruk bagi dunia Internet. Bab ini dan
Bab 11 memperkenalkan keamanan DNS, dengan tujuan memungkinkan pembaca untuk memilih yang sesuai
teknik untuk tingkat dianggap ancaman.
Sayangnya, istilah DNSSEC memiliki reputasi buruk karena kompleksitas yang dirasakan,
dan sering digunakan untuk menutupi seluruh topik keamanan DNS. Ada banyak aspek
DNS keamanan, mulai dari yang relatif sederhana untuk mengimplementasikan untuk brutal kompleks. Bab ini
membagi keamanan menjadi empat topik:
• keamanan Administrasi: ini bagian dari bab ini mencakup penggunaan hak akses file,
server konfigurasi, konfigurasi BIND, dan sandboxes (atau chroot penjara). Semua
teknik yang relatif sederhana untuk melaksanakan, dan dapat (dan harus) diterapkan
berdiri sendiri DNS server atau untuk server yang menjalankan DNS sebagai salah satu dari sejumlah layanan.
Administrasi keamanan merupakan topik dasar-line. Semua teknik kriptografi mewah di
dunia tidak ada gunanya jika sistem dasar tidak stabil atau memiliki dunia baca-tulis-dan hak istimewa
pada semua file yang menarik.
• Zona transfer: Kecuali sistem konfigurasi multimaster sedang digunakan, transfer zona
sangat penting untuk operasi normal. Membatasi dan mengendalikan baik sumber dan tujuan
operasi transfer zona dengan keamanan fisik, BIND parameter, atau eksternal
firewall selalu berhati-hati. Secure otentikasi dari sumber dan tujuan dari
zona operasi transfer mungkin atau mungkin tidak layak usaha.
• Dynamic update: update Dynamic master mengekspos zona file untuk korupsi mungkin,
kehancuran, atau keracunan. Tidak mengambil tindakan pencegahan yang masuk akal untuk membatasi akses melalui
baik desain yang baik sistem, parameter BIND, firewall, atau mungkin otentikasi
merupakan salah ketergantungan pada kebaikan esensial umat manusia.
• Zona integritas: Jika penting bahwa data yang digunakan oleh salah satu zona lain DNS atau mengakhiri
host benar (yaitu, tanggapan query belum dirusak dan kembali
data hanya bisa berasal dari pemilik zona), maka DNSSEC diperlukan. DNSSEC
telah menjadi subjek eksperimen cukup dan perubahan selanjutnya atas
melewati tiga atau empat tahun. Buku ini menggambarkan apa yang disebut DNSSEC.bis-bahasa sehari-hari
generasi kedua yang aman DNS-dan objek pekerjaan banyak dalam IETF, yang
root-server operator, dan Regional Internet Registries (RIR). DNSSEC.bis adalah
diuraikan dalam Bab 11.
Karena begitu penting, sistem DNS adalah subyek dari banyak mitos, termasuk "besar
bug mitos "mitos ini. purports bahwa BIND begitu penuh dengan bug bahwa kita harus pergi ke setiap panjang untuk
melindungi sistem kita dari cara-cara yang merusak diri sendiri. Meskipun ini mungkin telah benar dalam
hari tua buruk dari versi awal dan versi 4 rilis dari BIND 8, maka tidak ada lagi kasus ini. Yang terakhir
CERT penasehat (www.cert.org) diterbitkan untuk BIND pada tahun 2003 dan itu untuk versi BIND
8; yang terakhir untuk BIND 9-penulisan ulang hampir lengkap BIND-adalah pada tahun 2002. Bila Anda mempertimbangkan
bahwa perangkat lunak ini sedang diakses jutaan kali setiap di seluruh dunia kedua itu
kinerja yang sangat mengesankan. sistem DNS perlu dilindungi dari sumber eksternal dan
serangan, tetapi pada umumnya tidak dari BIND itu sendiri. Penekanan dalam bagian-bagian berikut ini terutama
tentang keamanan yang menghadap ke luar, tidak masuk-menghadap keamanan.
Ikhtisar Keamanan dan Audit
Gambar 10-1 diperkenalkan pada Bab 3 dan direproduksi di sini sebagai pengingat akan kemungkinan
sumber ancaman yang membentuk dasar dari setiap audit keamanan. Setiap alur data merupakan sumber potensial
Titik kritis dalam mendefinisikan kebijakan keamanan dan prosedur untuk memahami apa yang
harus dijamin-atau tepatnya apa tingkat ancaman harus dijamin terhadap dan apa ancaman
dapat diterima. Jawaban atas dua hal akan berbeda jika DNS adalah berjalan sebagai
root-server versus berjalan sebagai-rumah sederhana di DNS yang melayani beberapa volume rendah web
situs. Tidak ada aturan yang keras dan cepat; mendefinisikan kebijakan Anda adalah masalah paranoia pencampuran
dengan penilaian.
DNS Arus Normal Data
Setiap data flow-yaitu, setiap nomor baris dalam Gambar 10-1-merupakan sumber potensi ancaman.
Tabel 10-1 mendefinisikan potensi hasil kompromi pada setiap titik dan mungkin
solusi.
Tabel 10-1. Ancaman Keamanan DNS
Jumlah Solusi Ancaman Klasifikasi Daerah
1 Zona file korupsi (berbahaya atau Sistem Lokal
disengaja) administrasi
2 Dinamis tidak sah update, alamat IP server-ke-server Jaringan arsitektur,
update spoofing (meniru update Transaksi Signasource)
tures (TSIG), SIG (0),
atau menonaktifkan
3 Zona alamat IP spoofing (imperson-Server-to-server Jaringan arsitektur,
Ating update transfer sumber) TSIG, atau menonaktifkan
4 Remote Cache keracunan oleh spoofing IP, server-klien DNSSEC
permintaan data intersepsi, atau digerogoti
master atau slave
5 resolver Data intersepsi, meracuni cache, Remote client-DNSSEC
query digerogoti master atau budak, lokal IP klien
spoofing
Tahap pertama dari setiap review keamanan adalah ancaman audit yang berlaku dan bagaimana serius
mereka dinilai dalam situasi organisasi tertentu. Sebagai contoh, jika dinamis
pembaruan tidak didukung (modus default BIND's), tidak akan ada ancaman update dinamis.
Hal ini dapat lebih mudah untuk menonaktifkan proses daripada untuk mengamankan itu. Sebagai contoh, mempertimbangkan transfer zona.
Jika konfigurasi master-budak klasik sedang digunakan, maka transfer zona akan tak terelakkan, dan
implikasi keamanan konfigurasi itu harus dievaluasi. Namun, sangat mungkin untuk menggantikan
seperti konfigurasi dengan yang multi-master di mana setiap server nama zona yang memperoleh
file lokal. Dengan demikian, transfer mungkin zona global dinonaktifkan. Dalam lingkungan ini, sinkronisasi
file zona master harus dilakukan oleh beberapa keluar-proses-band, seperti aman FTP atau
e-mail aman. Namun, proses-proses out-of-band mungkin lebih sederhana untuk mengatur atau sudah
ada. Menggunakan prosedur alternatif seperti ini kadang-kadang disebut sebagai keamanan oleh ketidakjelasan. Hal ini dapat
memperbaiki taktis menjadi berguna tetapi tidak selalu merupakan solusi strategis.
Akhirnya, catatan peringatan: ada penguasa tunggal untuk mengamankan, di zona transfer mungkin ada
satu atau dua budak untuk mengamankan, di update dinamis mungkin ada puluhan sumber update untuk aman,
dan mungkin ada ratusan atau ribuan cache remote untuk dipertimbangkan dalam solusi DNSSEC.
Secara umum, semakin jauh Anda pergi dari master, sistem yang lebih Anda harus mempertimbangkan,
dan oleh karena itu solusi yang lebih rumit. Kecuali ada alasan baik untuk tidak melakukannya, itu selalu disarankan bahwa Anda mulai dari zona master dan berhasil. Itu
akan menjadi anak laki-laki frustrasi telah menyelesaikan keberhasilan pelaksanaan sebuah kompleks
solusi DNSSEC, hanya untuk menemukan bahwa siapa pun secara dinamis dapat mengupdate file zona Anda.
Klasifikasi Keamanan
Klasifikasi keamanan merupakan sarana untuk memungkinkan pemilihan solusi yang tepat dan
strategi untuk menghindari risiko tersirat. Banyak metode-metode berikut ini dijelaskan dalam
detail dalam bab ini dan Bab 11. Penomoran berikut berhubungan dengan Gambar 10-1.
• ancaman Lokal (1): ancaman Lokal biasanya yang paling sederhana untuk mencegah, dan biasanya
diimplementasikan hanya dengan menjaga kebijakan administrasi sistem suara. zona Semua
file dan file konfigurasi lainnya DNS harus memiliki tepat membaca dan menulis akses,
dan harus aman didukung atau diselenggarakan dalam repositori CVS. Stealth (atau Split)
server DNS dapat digunakan untuk meminimalkan akses publik, dan BIND dapat dijalankan di kotak pasir
atau penjara chroot (dijelaskan di bagian "BIND dalam Chroot Penjara" kemudian dalam bab ini).
• Server-server (2): Jika sebuah organisasi budak menjalankan DNS server, perlu untuk melaksanakan zona
transfer. Seperti disebutkan sebelumnya, adalah mungkin untuk menjalankan beberapa-master server DNS, bukan
dari server master-budak, dan dengan demikian menghindari masalah yang terkait. Jika zona transfer
diperlukan, BIND menawarkan beberapa parameter konfigurasi yang dapat digunakan untuk meminimalkan
risiko yang melekat dalam proses. TSIG dan Transaksi KEY (TKEY) juga menawarkan
aman metode untuk otentikasi meminta sumber-sumber dan tujuan. Kedua metode
dijelaskan secara rinci pada bagian "Mengamankan Zona Transfer" kemudian dalam bab ini.
Transfer fisik dapat diamankan dengan menggunakan Secure Socket Layer (SSL) atau Transport
Layer Security (TLS).
• Server-server (3): default BIND adalah untuk menyangkal Dynamic DNS (DDNS) dari semua sumber.
Jika sebuah organisasi memerlukan fitur ini, maka BIND menyediakan sejumlah konfigurasi
parameter untuk meminimalkan risiko yang terkait; ini dijelaskan secara rinci nanti dalam
bab. Jaringan desain arsitektur-yaitu, semua sistem yang terlibat dalam terpercaya
perimeter-lebih lanjut dapat mengurangi eksposur tersebut. TSIG dan SIG (0) dapat digunakan untuk mengamankan
transaksi dari sumber eksternal. Konfigurasi Stealth (Split) server digambarkan
pada Bab 4 dan 7, dan TSIG dan SIG (0) keamanan yang dijelaskan dalam bagian "Mengamankan
Dynamic Update "kemudian dalam bab ini.
• Server-klien (4): Kemungkinan keracunan cache jauh karena spoofing IP, data halangan,
dan hacks lainnya mungkin sangat rendah dengan situs web sederhana. Namun, jika situs tersebut
profil tinggi, volume tinggi, terbuka untuk ancaman kompetitif, atau merupakan penghasil pendapatan yang tinggi, maka
biaya dan kompleksitas penerapan solusi DNSSEC skala penuh dapat bermanfaat.
Upaya yang signifikan sedang diinvestasikan oleh pengembang perangkat lunak, Registry Operator, yang
RIR, dan operator root-server, antara lain banyak, ke DNSSEC. Kita cenderung melihat
signifikan trickle-down efek dalam waktu dekat dalam domain publik, serta
dalam kelompok dikontrol seperti intranet dan extranet. Memang, Swedia akan menjadi yang pertama
negara di dunia untuk menawarkan dukungan DNSSEC untuk se domain mulai tahun 2005 akhir..
• Klien-klien (5): standar DNSSEC.bis mendefinisikan konsep keamanan sadar
penyelesai-suatu saat entitas-mitos yang dapat memilih untuk menangani semua validasi keamanan
langsung, dengan nama lokal server bertindak sebagai gateway komunikasi pasif.
238 BAB 10? DNS AMAN Konfigurasi
Administrasi Keamanan
Administrasi keamanan dalam konteks buku ini berkaitan dengan pemilihan dan konfigurasi
perangkat lunak dan server DNS atau server yang berjalan. Item dalam berikut
bagian terdaftar dalam urutan prioritas perkiraan, dalam hal ini didefinisikan sebagai kombinasi kembali
untuk usaha dikeluarkan dan dampaknya terhadap keamanan secara keseluruhan. Jelas, perintah tidak kaku, juga bukan berarti
menyarankan bahwa jika Anda hanya perangkat lunak tetap up to date, instalasi DNS akan aman. Namun,
instalasi penuh chroot dengan root dikenal mengeksploitasi masih dapat membuat kekacauan serius. Penghakiman
dan keadaan setempat selalu menggantikan list taktis, seperti yang pada bagian berikut.
Bagian-bagian berikut disajikan dalam bentuk checklist, dengan beberapa penjelasan terbatas
mana yang sesuai.
Up-to-Date Perangkat Lunak
Meskipun tampaknya usang, menjaga software up to date merupakan komponen keamanan penting. Banyak
administrator sibuk yang menjalankan sistem operasional tidak menyukai upgrade software stabil. Penataran
dewasa, perangkat lunak yang stabil mungkin menjadi jahat, tetapi merupakan-perlu dan penting-jahat untuk kesehatan
dan keamanan instalasi. Semakin lama tugas ditunda, semakin buruk karena mendapat. Berikut
ditawarkan sebagai kebijakan upgrade generik:
1. Dikenal memanfaatkan keamanan: Berlangganan ke salah satu layanan konsultasi yang disediakan oleh SANS
(Www.sans.org) atau CERT (www.cert.org), serta banyak orang lain, dan mengambil tindakan pada
BIND dan alert teknologi yang berhubungan. Tergantung pada beratnya waspada, ini dapat
permintaan upgrade segera diikuti dengan tes cepat sebelum puasa seluruh sistem
penggantian. Lebih baik dalam hal ini risiko masalah baru daripada mengeksploitasi dikenal.
2. Diperlukan fitur baru: Jika sebuah fitur baru yang diperlukan, waktu umumnya tidak penting.
Upgrade harus dilakukan perlahan-lahan, dengan pengujian serius penyebaran awal terbatas
sebelum upgrade akhir dari semua sistem operasional.
3. Waktu: Setiap 12-18 bulan, penulis upgrade sistem operasional jika tidak item 1
atau 2 yang diperlukan upgrade, dan bahkan jika itu berarti beberapa pekerjaan yang serius. Alasannya
di sini adalah bahwa tugas lagi ini yang tersisa, semakin besar rasa sakit dari upgrade. Upgrade lambat,
dengan penyebaran terbatas awal sebelum penggantian sistem.
Hal-hal tambahan berikut ini mungkin berguna atau sekadar masuk akal:
• Membina Daftar-pembanding upgrade: Ini harus mencakup, setidaknya, urutan upgrade,
masalah sebelumnya, item tertentu untuk memverifikasi (untuk pesan log misalnya, menggali script pengujian, dan
hasil), tes blok AXFR, dan apa pun yang Anda anggap berguna. Dalam lingkungan sibuk,
memori Anda sendiri bukan merupakan alat perencanaan yang berguna, terutama jika frekuensi upgrade
rendah. Tambahkan ke daftar setelah upgrade masing-masing, dan tetap tersedia di intranet, di
file konfigurasi sebagai komentar, atau di beberapa lokasi lain yang cocok. Harus hidup
dokumen yang akan berguna.
• Blok komunikasi versi software BIND: Semua konfigurasi named.conf sampel
file (lihat Bab 7) menggunakan versi pernyataan dalam ayat pilihan untuk menyembunyikan
saat ini versi yang menjalankan BIND. Jika nomor versi tidak diblokir, itu sederhana untuk
menggali gunakan untuk menemukan apa versi yang digunakan pada setiap lokasi tertentu. Bila
yang dikenal mengeksploitasi, mengapa membual bahwa Anda rentan?
Batas Fungsi
Cara terbaik untuk membatasi kerentanan adalah untuk menghindari menggunakan operasi dimanfaatkan, jika praktis. Sebagai
Misalnya, dengan menggunakan beberapa master adalah mungkin untuk menjalankan sebuah sistem operasi tanpa melakukan
transfer zona DNS, dalam hal ini memungkinkan transfer dan memberitahukan laporan dapat diatur ke "none"
dalam klausul opsi global. Luangkan waktu untuk merenungkan strategi alternatif dan relatif
upaya dan kembali terlibat dalam operasi, bukan hanya memilih untuk menggunakan fitur BIND
karena itu ada. Hacker cinta yang cara berpikir-memberikan mereka banyak target.
Konfigurasi defensif
Sebuah konfigurasi defensif adalah satu di mana semua, besar khususnya yang berkaitan dengan keamanan, fitur
eksplisit diidentifikasi sebagai diaktifkan atau dinonaktifkan. Konfigurasi seperti mengabaikan semua pengaturan default
dan nilai-nilai. Dibutuhkan sebagai titik awal situs kebutuhan, dan setiap mendefinisikan kebutuhan, positif
atau negatif, dengan menggunakan laporan konfigurasi yang sesuai atau parameter lainnya. Default adalah
orang malas besar bagi kami, tetapi mereka juga dapat berbahaya jika mereka berubah. Sebagai contoh, saat ini
BIND versi menonaktifkan DDNS secara default. Namun, banyak DNS administrator suka
menambahkan pernyataan itu memungkinkan-update ("none";); secara eksplisit dalam klausul opsi global, baik sebagai jelas
indikasi bahwa fitur tersebut tidak digunakan, dan sebagai perlindungan terhadap masa depan yang rilis
dapat mengubah default. Sebuah file konfigurasi yang defensif mengidentifikasi semua persyaratan
juga secara eksplisit mendefinisikan diri. Yaitu, dengan memeriksa file-tanpa perlu menemukan
manual atau referensi dokumentasi-fungsi tersebut adalah jelas. Pada 03:00 ketika hiruk-pikuk
terjadi, file diri terdefinisi tersebut dapat efek samping berguna.
Deny Semua, Ijinkan Selektif
Bahkan ketika operasi diperbolehkan, misalnya di NOTIFY atau zona transfer, itu mungkin bernilai
global menyangkal operasi dan selektif memungkinkan, seperti dalam fragmen berikut:
Pilihan (
....
memungkinkan transfer (none;); / / tidak ada transfer secara default
....
);
....
zone "example.com di (
....
memungkinkan transfer (10.0.1.2;); / / ini hanya host
....
);
Meskipun sebelumnya memerlukan konfigurasi tambahan mengetik, hal itu juga memerlukan kecil
tindakan selalu berpikir-hal yang baik-sebelum menambahkan baris di zona klausa.
Remote Access
BIND rilis datang dengan alat administrasi yang disebut rndc (dijelaskan dalam Bab 9) yang mungkin
digunakan secara lokal atau jarak jauh. Di satu sisi, rndc adalah tool yang berguna, sementara di sisi lain, jika
Anda bisa masuk, sehingga dapat orang lain. BIND default adalah mengaktifkan rndc dari loopback tersebut
alamat saja (127.0.0.1). Jika rndc tidak akan digunakan, harus secara eksplisit dinonaktifkan menggunakan null
klausa kontrol, seperti yang ditunjukkan di sini:
/ / Named.conf fragmen
kontrol ();
....
Jika rndc digunakan, maka dianjurkan bahwa klausa kontrol eksplisit digunakan, bahkan jika
akses hanya diijinkan dari localhost, seperti yang ditunjukkan di sini:
/ / Named.conf fragmen
(kontrol
inet 127.0.0.1 memungkinkan (localhost;) tombol ("rndc-key");
);
Dalam fragmen sebelumnya, nama default kunci rndc-key ditampilkan (yang dihasilkan oleh
perintah rndc-confgen-a), dan harus diganti dengan nama apapun dialokasikan untuk
kunci yang digunakan untuk mengontrol akses rndc. File rndc.conf dan file yang berisi kunci seperti
sebagai rndc.key harus dilindungi dengan hak akses terbatas seperti yang dijelaskan dalam bagian berikut,
Perizinan Batas "." BIND serius menyediakan metode sederhana untuk membuat kunci konfigurasi default
(Rndc-confgen-a) untuk digunakan dengan rndc, yang hanya untuk loopback (127.0.0.1) mungkin menggunakan
cukup untuk Anda mulai. Namun, masuk akal atau tidak dianjurkan untuk digunakan remote. Mengambil
diperlukan beberapa menit dan mempelajari bagaimana untuk menghasilkan kunci Anda sendiri rndc. Ubah setiap mereka
30 sampai 90 hari tanpa gagal.
Batas Perizinan
Teori di balik membatasi akses memiliki dua bagian berbeda yang tidak boleh bingung, dan
yang mungkin memiliki masalah yang terpisah dan strategi pelaksanaan:
• Kerahasiaan: ini melibatkan membatasi akses ke file-file rahasia yang digunakan oleh BIND atau
aplikasi DNS, untuk memastikan bahwa aplikasi atau user lain tidak dapat membaca atau menulis ke
mereka.
• kendali: ini mencegah BIND dari membaca atau menulis ke lokasi lain jika
dikompromikan.
Seperti telah dibahas sebelumnya, buku ini memberikan penekanan lebih pada melindungi server nama dari
serangan eksternal seperti keracunan cache, mengakses informasi rahasia, dan lain upaya
berkompromi isi data zona file dari dari kerusakan yang ditimbulkan oleh BIND sendiri
berkompromi. Dalam konteks ini, file yang menggunakan BIND dan izin akses mereka
cukup penting. Daftar berikut menjelaskan tujuh kelompok file atau file BIND dapat menggunakan,
dan perlindungan named.conf •: Berkas ini harus diperlakukan sebagai rahasia karena mengandung informasi
tentang gaya konfigurasi yang dapat membantu seorang penyerang, dan sering berisi
informasi menarik lainnya, seperti alamat IP, yang dapat digunakan untuk memulai spoofing
dan lainnya serangan. File named.conf tidak boleh berisi klausa kunci sebagai suatu hal
kebijakan, termasuk yang digunakan untuk akses rndc. Sebaliknya, klausa kunci harus dijaga
dalam berkas terpisah dalam direktori terpisah dan disertakan dalam file named.conf
(Menggunakan termasuk pernyataan). Jika klausa melihat sedang digunakan, kemudian sebagai minimum yang
berisi informasi pribadi untuk digunakan oleh konfigurasi Stealth (lihat Bab 4) harus
juga terkandung dalam file terpisah dan dimasukkan ke dalam file named.conf. Jika organisasi
kebijakan memungkinkan klausul zona atau bagian dari named.conf file yang akan dikendalikan atau
disunting oleh pengguna akhir, atau lebih dari satu pengguna, maka bagian ini harus disimpan secara terpisah
file dalam direktori terpisah. Dengan cara ini, hak akses dapat diterapkan sesuai
dan kemudian dimasukkan ke dalam file named.conf akhir. Perlu dicatat di sini bahwa dipercaya-kunci
klausa hanya berisi kunci publik, yang tidak informasi sensitif, seperti kunci klausa,
yang berisi berbagi rahasia dan sangat sensitif. Persyaratan untuk dipercaya-kunci
klausa adalah untuk mencegah menulis korupsi (sama seperti named.conf) daripada untuk mencegah
membaca yang tidak sah, seperti halnya untuk klausa kunci.
• Termasuk file: Setiap file yang termasuk dalam file named.conf dapat memiliki hak akses yang berbeda
diterapkan untuk itu. Kebijakan tersebut harus untuk mengkategorikan jenis file dan akses yang dibutuhkan,
dan memisahkan file ke dalam direktori-direktori dimana tingkat hak akses dapat diterapkan,
bukan main-main dengan file individual. Jadi, termasuk file yang berisi kunci
dapat disimpan dalam sebuah direktori bernama / var / named / kunci, dan pandangan pribadi dalam sebuah direktori
bernama / var / named / views. Setiap klausul zona swasta dapat disimpan dalam, katakanlah, / var / named /
zona-swasta. Umumnya klausa zona diedit dapat disimpan di direktori home
dari user yang diperbolehkan untuk mengeditnya. Setiap direktori tersebut dapat diberikan sesuai
perizinan.mereka persyaratan:
• Zona file: Zona file biasanya berisi informasi publik, sehingga sepertinya ada gunanya
dalam melindungi mereka (selain dari izin menulis global). Namun, jika melihat
Stealth klausul berbasis sistem sedang digunakan, maka zona file pada sisi pribadi
konfigurasi akan berisi data yang sensitif dan memerlukan perawatan yang terpisah. Sekali lagi,
adalah bijaksana untuk memisahkan file zona pribadi ke dalam direktori terpisah seperti / var /
bernama / master / swasta. Zone file yang dapat disunting oleh pengguna dapat ditempatkan dalam
rumah masing-masing direktori dengan hak akses pengguna yang tepat, atau Anda dapat menempatkan
mereka di var / / named / master / direktori DDNS dan memungkinkan pembaruan yang dinamis. Akhirnya,
budak zona di / var / named / budak memerlukan izin menulis untuk BIND.
• PID file: Hal ini biasanya ditulis untuk / var / run / named.pid atau / var / run / named / named.pid.
Meskipun berisi informasi sensitif (yang Identifier Proses daemon bernama),
informasi yang hanya dapat digunakan oleh root. Jika Anda dihadapkan dengan root mengeksploitasi, maka
file PID adalah salah satu dari item terakhir yang mengkhawatirkan. PID file membutuhkan menulis
akses untuk BIND dan membaca akses untuk skrip (start, stop, restart, dan sebagainya) yang membuat
menggunakannya.
• Log file: Buku ini mengkonfigurasi log akan ditulis ke / var / log / direktori bernama
sebagian besar untuk kenyamanan daripada keamanan. Secara umum, log tidak mengandung sensitif
informasi dan tidak memerlukan penanganan khusus. Namun, jika klausa view
sedang digunakan dalam konfigurasi Stealth, log-tergantung pada pilihan-mungkin berisi
sensitif informasi yang berkaitan dengan IP swasta dan harus dilindungi.
• rndc file: Jika menggunakan rndc, perlu diingat bahwa file rndc.conf (lihat Bab 9), dan terutama
setiap file yang berisi kunci, termasuk file rndc.key default, berisi sangat
informasi sensitif dan perlu dilindungi.
• Jurnal file: Sebuah file zona biasanya read-only file dari perspektif BIND's. Jika Dinamis
Update (DDNS) sedang digunakan, maka pembaruan ditulis ke file biner jnl. Untuk setiap zona,
dan hanya berkala ditulis ke file zona. Untuk file zona publik, informasi tersebut
tidak sensitif, tapi untuk zona file pribadi izin yang tepat diperlukan. Setelah DDNS
dipanggil untuk zona, prosedur khusus pada umumnya diperlukan untuk mengedit file secara manual zona.
Oleh karena itu, hak akses dapat dibuat ketat. Untuk mencerminkan izin, file zona
yang akan menggunakan DDNS dapat ditempatkan dalam direktori seperti / var / named / master / DDNS.
Sebelum membangun strategi izin, kita perlu melihat bagaimana BIND dijalankan. BIND dapat menjalankan
dalam tiga cara yang mungkin:
• Jalankan BIND sebagai root: Ini adalah hal yang berbahaya untuk dilakukan, dan biasanya memerlukan tambahan
bekerja untuk mengesampingkan pilihan didefinisikan dalam instalasi BIND yang paling standar. Metode ini
menjalankan BIND tidak dianjurkan dan tidak akan dibahas lebih lanjut.
• Jalankan BIND bawah yang unik (nonroot) UID (Linux, Unix, atau BSD) atau account pengguna
(Windows): Metode ini menggunakan perintah-u garis argumen BIND (lihat Bab 12),
dan adalah metode standar yang digunakan oleh instalasi paket yang paling di Linux, BSD, dan
Windows. User ID (UID) yang biasanya diberi nama untuk Linux / UNIX, atau mengikat jika Anda menjalankan
FreeBSD dan account pengguna diberi nama untuk Windows.
• Jalankan BIND di bak pasir atau penjara chroot: FreeBSD 5.x dan Fedora Core 2 default instalasi
menggunakan modus operasi. Kebanyakan distribusi Linux, termasuk Fedora Core 2,
menyediakan RPM bind-chroot yang dapat diterapkan setelah BIND telah terinstal, untuk menambahkan
direktori yang diperlukan dan skrip untuk menerapkan perizinan yang sesuai.
Kedua yang terakhir dua metode menjalankan BIND dengan UID yang unik (biasanya bernama atau mengikat jika
FreeBSD) dan dijelaskan secara rinci pada bagian "Menjalankan BIND sebagai Nonroot" Tabel 10-1.
menunjukkan izin yang mengunci file berbagai persyaratan minimum mereka.
Sebelum mempertimbangkan hak akses file yang dibutuhkan, perlu untuk memahami berbagai
BIND tahap mengadopsi selama urutan inisialisasi nya. Ketika BIND dimuat itu berjalan sebagai pengguna
root karena membutuhkan hak istimewa tertentu-terutama kemampuan untuk mengalokasikan dan mengikat untuk normal,
tapi nomor istimewa, pelabuhan 53, dan jika rndc diijinkan, juga ke port 953. Selama ini
BIND fase membaca semua konfigurasi dan file zona dan log setiap kegagalan untuk syslogd. Pada
menyelesaikan proses ini, maka sebuah isu () panggilan SUID (perubahan nama pengguna) untuk nama pengguna
didefinisikan pada argumen perintah baris-u. Hanya kemudian apakah itu melanjutkan untuk menulis berkas PID, log,
dan setiap file yang dibutuhkan lainnya. Struktur ini meminjamkan sendiri sempurna untuk menyesuaikan perizinan file yang tepat,
karena file read-only (dari perspektif BIND's) dapat diatur untuk hak akses berdasarkan
tentang persyaratan mengedit mereka. BIND, karena itu berjalan sebagai root selama fase membaca, dapat
membacanya di semua kasus. Tabel 10-2 mengilustrasikan jenis struktur dan fleksibilitas yang mungkin
dibuat. Struktur ini mungkin terlihat rumit, tapi yang ada kemungkinan, dan memiliki besar
Kelebihan bahwa setelah ditetapkan, memerlukan sedikit pemeliharaan.
Tabel 10-2 mengasumsikan bahwa BIND berjalan dengan UID bernama, pengeditan aman (tapi tidak rahasia)
file dilakukan di bawah nonroot pengguna dengan nama pengguna dnsadmin dan sekelompok root (untuk memungkinkan
perintah su jika perlu), dan mengedit file akses multiuser (misalnya zona, publik
file dan klausa zona) dilakukan dalam sebuah grup yang disebut dnsusers. File-file yang berisi rahasia dapat
hanya bisa dibaca oleh BIND dan disunting oleh root. File ditempatkan dalam direktori bernama bawah masing-masing
jenis file yang dijelaskan sebelumnya. Direktori rumah dnsadmin diasumsikan / var / named, dan
untuk dnsusers itu adalah / home / username atau mirip. Dalam Tabel 10-2, kolom Mask menunjukkan direktori
izin terlebih dahulu, dipisahkan dari perizinan file dengan usus (":"). Sebuah tanda tanya
("?") Menunjukkan bahwa nilai ini dapat ditentukan oleh persyaratan sistem lainnya. Pengaturan
izin terbatas pada sistem Windows yang dijelaskan pada Bab 6.
abel 10-2. Direktori dan File Perizinan
File / Grup Khas Lokasi pengguna: kelompok Mask Catatan
dnsadmin named.conf / etc: root? : 0660 Read-only file BIND. dnsadmin
dapat mengedit.
Termasuk nama pengguna username rumah umum: 0770: 0660 file BIND Read-only.
dnsusers named.conf direktori Permissions memungkinkan dnsusers
kelompok untuk mengedit.
Termasuk kunci file / var / named / tombol bernama: bernama 0400: 0400 file BIND Read-only. Hanya root
dapat mengedit atau melihat.
Termasuk swasta / var / named / views dnsadmin: root 0770: 0660 file BIND Read-only. dnsadmin
dilihat dapat mengedit.
zona Swasta / var / named / master / dnsadmin: root 0770: 0660 file BIND Read-only. dnsadmin
file-tidak DDNS swasta dapat mengedit.
zona Swasta / var / named / master / named: root 0770: 0660 Baca / menulis untuk BIND. dnsadmin
file-dengan DDNS DDNS dapat mengedit.
Slave file zona / var / named / budak bernama: root 0770: 0660 Baca / menulis untuk BIND. dnsadmin
dapat mengedit jika diperlukan.
zona Publik file rumah username username: 0.770: 0.660 Memungkinkan dnsusers grup untuk mengedit.
direktori dnsusers File-file ini tidak dapat
diperbarui secara dinamis.
named.pid / var / run / named bernama: bernama? : 0.664 Memungkinkan akses oleh alat BIND /
script dan akar.
named.log / var / log / bernama bernama: root 0770: 0.640 Write akses untuk BIND, dnsadmin
bisa membaca. Jika tidak menggunakan pandangan,
hak akses yang lebih luas dapat diatur
tergantung pada kebijakan lokal.
rndc.conf / var / named / dnsadmin rndc: root 0770: 0.660 Memungkinkan akses oleh kelompok dnsadmin.
rndc.key / var / named / rndc / tombol bernama: bernama 0400: 0400 Hanya dapat mengedit root.
English to Indonesian translation
Dalam tabel sebelumnya, pengguna FreeBSD harus menggantikan akar kelompok dengan roda dan bernama
dengan mengikat. Jika kebijakan setempat adalah untuk memungkinkan administrator hanya BIND untuk menyentuh-BIND terkait
materi, maka beberapa dari konfigurasi sebelumnya akan tidak diperlukan.
File named.conf fragmen yang akan mencerminkan seperti strategi bisa terlihat seperti
berikut:
/ / Named.conf fragmen
termasuk "/ var / named / rndc / tombol / key.clause"; / file / yang berisi kunci rndc
termasuk "/ var / named / tombol / key.clauses"; / file / yang berisi kunci
(kontrol
inet 127.0.0.1 memungkinkan (localhost;) tombol ("rndc-key");
);
Pilihan (
....
);
termasuk "/ var / named / views / swasta-view.clause"; / / tampilan swasta tersembunyi
melihat "publik-view" (
termasuk "/ home / firstuser / zone.clause";
zone "example.com" di (
jenis master;
file "var / named / / master DDNS / example.net";
/ Klausa / tombol direferensikan di bawah ini akan berada di
/ / / Var / named / tombol / keys.clause di atas
memungkinkan-update (key "example.net";);
);
);
Menjalankan BIND Sebagai Nonroot
Kebanyakan sistem paket BIND, untuk RPM dan port FreeBSD misalnya, menginstal BIND untuk berjalan dengan
sebuah nonroot (unik) UID-biasanya bernama di Linux dan Windows dan mengikat pada FreeBSD. Ini
bagian menjelaskan cara mengkonfigurasi sistem anda jika BIND tidak diinstal dan dikonfigurasi untuk menjalankan
dengan UID yang unik, dan mengatur izin untuk mengunci file. Bahkan jika Anda BIND sistem
telah diinstal untuk menjalankan di bawah UID yang unik, Anda masih mungkin ingin melihat dan mengatur sesuai
file izin, khususnya pada file yang lebih sensitif. Jika BIND yang berjalan pada sistem Anda,
statusnya dapat diinterogasi dengan mengeluarkan perintah berikut:
| # Ps aux grep bernama
Ia mengembalikan sesuatu seperti berikut:
bernama 36120 0,0 0,9 5372 4376? Apakah 1:02 0:00.11 bernama bernama-u
Menunjukkan output sebelumnya bahwa daemon bernama berjalan dibawah UID bernama (yang
pertama yang disebutkan dalam baris), yang diprakarsai oleh argumen-u di akhir baris. Jika entri
terlihat seperti berikut ini, yaitu berjalan sebagaimana ditunjukkan oleh akar akar pertama pada baris dan
adanya argumen-u
root 36120 0,0 0,9 5372 4376? Apakah bernama 01:02 0:00.11
Harus diambil tindakan segera untuk mengubah keadaan ini, seperti dijelaskan dalam berikut
bagian.
Menetapkan Waktu Jalankan UID BIND
Untuk menjalankan BIND dibawah UID sendiri, kita perlu membuat user dan group untuk daemon bernama. Oleh
konvensi ini biasanya bernama (atau mengikat di bawah FreeBSD). Buku ini menggunakan nama seluruh,
tetapi Anda dapat mengubahnya dengan nilai yang sesuai (misalnya, dns) jika Anda inginkan. Pertama, pastikan bahwa
Anda belum memiliki account yang ada dengan menggunakan perintah berikut:
# Id bernama
uid = 25 (bernama) guid = 25 (bernama) kelompok = 25 (bernama)
Tanggapan UID sebelumnya menunjukkan sudah ada. Jika akun pengguna tidak
ada, respon berikut dikembalikan:
id: nama: ada user seperti
Coba lagi dengan mengikat id, dan jika masih tidak ada pengguna yang valid, kemudian buat user yang unik dan
kelompok, sebagai berikut:
# Groupadd-r bernama
Perintah sebelumnya menambahkan grup dengan nama dengan kelompok pertama sistem account bebas
(R-argumen). Kehadiran kelompok dapat dikonfirmasikan dengan vigr perintah,
yang menampilkan dan memungkinkan pengeditan daftar kelompok dalam sistem (gunakan: q! untuk keluar vigr tanpa
membuat perubahan).
Sekarang tambahkan account bernama sistem menggunakan perintah berikut:
daemon Bind # c-useradd ''-d / var / named-s / sbin / Nologin-g-r bernama bernama
Jika c-argumen (komentar) berisi spasi, maka harus ditutup dengan tanda kutip seperti yang ditunjukkan.
The-d / var / named adalah direktori default saat login, dan diperlukan namun tidak digunakan karena ini
adalah akun sistem tanpa login atau password. -S / sbin / argumen Nologin adalah Linux
default untuk account no-shell, The-g bernama argumen mendefinisikan kelompok awal yang akan digunakan oleh
account dan referensi di grup dengan nama baru saja kita buat. useradd mengharuskan bahwa kelompok
bernama ada, jadi selalu menentukan kelompok sebelum pengguna. R-argumen mendefinisikan ini menjadi sistem
rekening (biasanya dengan UID <500 untuk Linux dan <1000 untuk FreeBSD) dengan nama akun
dari bernama.
Pengaturan Izin akses untuk UID
Kami sekarang membuat dan menciptakan hak akses untuk file-file penting berbagai. Kami berasumsi bahwa
dnsadmin user account telah ditetapkan sebagai user biasa login menggunakan account Anda
alat favorit, dan merupakan anggota dari kelompok akar untuk memungkinkan perintah su yang akan diterbitkan jika diperlukan.
Catatan Beberapa hak akses berikut? Berbeda dari yang didefinisikan dalam Tabel 10-1, karena mereka
diterapkan ke direktori dan biasanya dimaksudkan untuk memungkinkan pemeriksaan properti file. Spesifik file dalam
direktori mungkin diatur ke nilai-nilai yang didefinisikan dalam Tabel 10-1.
Untuk membuat dan mengatur hak akses untuk menulis file run time (log dan PID), gunakan berikut
perintah:
# Cd / var / log
# mkdir bernama
# Touch bernama / example.log
# Chown bernama: dnsadmin bernama / *
# Chmod 0660 bernama / *
# Cd / var / run
# mkdir bernama
# Touch bernama / named.pid
# Chown bernama: bernama / *
# Chmod 0664 bernama / *
Berikut perintah semua berasumsi bahwa berbagai direktori yang telah dibuat. Jika ini
tidak terjadi, maka perintah mkdir dirname sebelumnya harus dikeluarkan, seperti yang disajikan dalam
sebelumnya urutan perintah. Set hak akses pada setiap direktori kunci, seperti ditunjukkan pada berikut
perintah:
# Cd / var / named
# Chown bernama: bernama kunci / *
# Chmod kunci 04000 / *
Set hak akses pada setiap file zona pribadi:
# Cd / var / named
# Chown-R dnsadmin: master root / swasta / *
# Chmod-R 0660 master / swasta / *
BAB 10? DNS AMAN Konfigurasi
Set hak akses pada setiap file zona DDNS:
# Cd / var / named
# Chown-R bernama: master root / DDNS / *
# Chmod-R 0660 master / DDNS
Set hak akses pada tampilan-swasta menyertakan file:
cd / var / named
chown-R dnsadmin: dilihat root / *
chmod-R 0660 dilihat / *
Secure tombol apa saja file rndc:
# Cd / var / named
# Chown-R bernama: bernama rndc / *
# Chown-R 0660 rndc / *
Mengamankan named.conf dan file rndc.conf:
# Cd / etc
# Chown dnsadmin: named.conf root
# Chmod 0660 named.conf
# Chown dnsadmin: rndc.conf root
# Chmod 0660 rndc.conf
Akhirnya, untuk menjalankan BIND, gunakan perintah berikut:
# / Usr / sbin / named-u bernama
Sekarang memverifikasi bahwa BIND dimuat dan berjalan dengan menggunakan perintah berikut:
| # Ps aux grep bernama
Jika tidak dimuat dan berjalan, periksa syslog menggunakan perintah berikut:
+ Vi / var / log / messages
Atau, Anda dapat menggunakan perintah seperti tail / var / log / messages untuk menampilkan terakhir
sepuluh baris file jika tidak banyak syslog lalu lintas. Kemudian, pastikan BIND telah memuat
berbagai zona dengan memeriksa log file BIND:
# Cat / var / log / bernama / named.log
11-Apr-2005 13:02:42.801 zona 0.0.127.in-addr.arpa/IN: serial dimuat 1997022700
11-Apr-2005 13:02:42.806 zone example.com / DI: 2005032902 dimuat serial
11-Apr-2005 13:02:42.813 zone localhost / IN: serial dimuat 2002022401
11-Apr-2005 13:02:42.817 berjalan
11-Apr-2005 13:02:42.818 zone example.com / IN: pengiriman memberitahu (serial 2005032902)
Untuk memastikan bahwa BIND dimulai pada saat boot, kita perlu menciptakan sebuah script yang kita telah memilih
untuk panggilan yang disebutkan dalam direktori startup (untuk Linux, biasanya / etc / rc.d / init.d, atau / etc / rc.d untuk
FreeBSD). Naskah tersebut akan terlihat seperti kode berikut, yang merupakan versi sederhana dari
script saat ini digunakan pada Fedora Core 2. Ini memberikan start, stop, dan restart hanya layanan:
#! / Bin / sh
#
# Bernama ini shell script mengurus menjalankan dan menghentikan
# Bernama bawah sendiri (non-root) UID.
#
Sumber # fungsi library.
. / Etc / rc.d / init.d / fungsi
Sumber # konfigurasi jaringan.
. / Etc / sysconfig / jaringan
# Periksa jaringan itu terserah.
[$ (NETWORKING) = "no"] & & exit 0
[-F / usr / sbin / named] | | exit 0
# Lihat bagaimana kami dipanggil.
kasus "$ 1" di
mulai)
# Start daemon.
echo-n "Memulai bernama:"
daemon / usr / sbin / named-u bernama
gema
;;
menghentikan)
# Stop daemon.
echo-n "Shutting down bernama:"
killproc bernama
gema
;;
BAB 10 DNS Konfigurasi AMAN
restart)
$ 0 stop
$ 0 mulai
exit $?
;;
*)
echo "Penggunaan: bernama (| memulai stop | restart)"
1 keluar
esac
exit 0
Script sebelumnya kemudian harus dikaitkan dengan tingkat berjalan normal (s) yang digunakan, seperti menjalankan
tingkat 3 (non-X11) dan 5 (X11). Tingkat menjalankan default biasanya didefinisikan di / inittab etc / oleh
baris yang terlihat seperti ini:
id: 3: initdefault:
Untuk contoh sebelumnya, kita akan menghubungkan script untuk menjalankan tingkat yang sesuai rc.d inisialisasi
urutan, yang untuk tingkat 3 akan dijalankan sebagai berikut:
Dalam # / etc / rc.d / init.d / named / etc/rc.d/rc3.d/S68named
Dalam # / etc / rc.d / init.d / named / etc/rc.d/rc3.d/K68named
Untuk menguji proses ini, seperti perintah berikut harus dijalankan:
# / Etc / rc.d / init.d / named restart
Proses startup setara untuk pengguna FreeBSD memerlukan menambahkan baris berikut ke
/ etc / rc.conf file:
named_enable = "YES" bernama # Jalankan, server DNS (atau TIDAK).
named_program = "/ usr / sbin / named" # mengasumsikan instalasi dasar.
named_flags = "-u bind" # Flags untuk bernama
Untuk menjadi benar-benar yakin bahwa semuanya sudah bekerja sementara masih segar dalam ingatan kami,
server idealnya harus reboot, dan bernama dikonfirmasi untuk bisa berjalan dengan sukses dengan
perintah seperti ini:
| # Ps aux grep bernama
bernama 36120 0,0 0,9 5372 4376? Apakah 1:02 0:00.11 bernama bernama-u
Meskipun proses sebelumnya mungkin tampak melibatkan beberapa langkah, ia menawarkan
fleksibilitas untuk dapat mengendalikan secara tepat dan fleksibel mengedit hak akses dari berbagai
file dan grup file yang digunakan dalam pengoperasian sistem DNS BIND berbasis. Menjalankan BIND dalam
chroot penjara (atau kotak pasir) menawarkan strategi alternatif dan dijelaskan pada bagian berikut.
BIND dalam Chroot Jail
Istilah atau kurungan penjara chroot chroot (sekarang sering disebut sebagai kotak pasir) adalah nama dari
panggilan sistem chroot ("/ base / direktori");, yang memerlukan argumen direktori dasar dan tidak
tidak membiarkan aplikasi membaca atau menulis di luar direktori basis. Semua direferensikan file dan path
dalam chroot aplikasi yang ditambahkan ke direktori dasar. Jadi, jika dasar chroot
direktori / var / named / chroot dan mengakses aplikasi file bernama / etc / named.conf,
maka path lengkap diterjemahkan menjadi / var / named / chroot / etc / named.conf. Saat menjalankan BIND,
-t / base / direktori argumen perintah baris menunjukkan bahwa seharusnya menjalankan chroot BIND
dan mendefinisikan direktori dasar untuk digunakan. Dalam lingkungan chroot, baik-t dan-u (BIND
UID) argumen harus hadir untuk menyediakan lingkungan yang aman.
Kebanyakan distribusi berikan metode paket menjalankan BIND dalam sebuah penjara chroot. Berikut
bagian define menggunakan paket tersebut untuk kedua Linux Fedora Core 2 dan FreeBSD 5.x.
Akhirnya, jika paket tersebut tidak tersedia, atau master atau zona budak yang hadir, manual konfigurasi
dari sebuah penjara chroot dijelaskan.
Fedora Core 2 bind-chroot Paket
DNS dapat dijalankan dalam sebuah penjara chroot pada Fedora Core 2 di salah satu dari dua cara:
• Memilih pilihan perangkat lunak DNS selama proses instalasi menyebabkan caching chroot
nama server instalasi secara default.
• Instalasi RPM bind-chroot (khusus bind-chroot-9.3.0-2.i386.rpm, yang
instalasi rilis yang sama dijelaskan dalam Bab 6).
Dalam kedua kasus-kasus sebelumnya, proses ini sama karena proses instalasi juga menjalankan
RPM bind-chroot. RPM chroot tidak sebagai berikut:
• Hal ini menciptakan direktori chroot dasar sebagai / var / named / chroot.
• Para direktori berikut ini ditambahkan dalam / var / named / chroot: etc, var / named, var / run /
bernama, dan / dev (berisi null saja dan acak).
• relevan file akan disalin dari direktori yang sesuai. Sebagai contoh, / etc / named.conf
akan disalin ke / var / named / chroot / etc / named.conf, dan kepemilikan dari direktori chroot adalah
diatur ke akar: bernama dengan hak akses dari 0640.
• Script startup (di / etc / rc.d / init.d / named) adalah dimodifikasi untuk menambahkan argumen
-T / var / named / chroot untuk memohon fitur chroot.
Konfigurasi default Fedora file log dengan menggunakan syslogd. Jika sebuah file log diperlukan, maka sebuah
direktori yang tepat harus diciptakan. Sebagai contoh, asumsikan Anda sedang menciptakan file log yang menggunakan
fragmen berikut:
logging (
saluran normal_log (
file "/ var / log / bernama / normal.log" versi 3 ukuran 2m;
keparahan kesalahan;
print-time yes;
print-beratnya ya;
print-kategori ya;
);
Dalam hal ini, direktori / var / named / chroot / var / log / named diperlukan dengan izin menulis
untuk UID bernama.
FreeBSD 5.x
Instalasi DNS pada FreeBSD 5.x menciptakan instalasi chroot secara default dengan sebuah chroot
dasar / var / named. instalasi melakukan kegiatan sebagai berikut:
• Membuat direktori / var / named / etc / namedb dan link ke / etc / namedb (secara default,
FreeBSD mengatur semua file, termasuk file zona, di bawah direktori ini basis). Dengan demikian,
pergi ke lokasi normal untuk file-file (etc / namedb) berikut link ke chroot
lokasi.
• Selain itu, direktori berikut dibuat dalam / var / named: var / dump,
var / statistik, var / run / named, dan var / log (dengan nama file default named.security.
log). Kepemilikan adalah mengikat: mengikat untuk direktori, dan dunia membaca perizinan di-set
pada semua file.
• File / etc / default / rc.conf berisi default, seperti yang ditunjukkan dalam bagian berikut:
#
# Nama. Dimungkinkan untuk menjalankan bernama di bak pasir, keamanan manusia untuk
# Rincian.
#
named_enable = "YES" bernama # Jalankan, server DNS (atau TIDAK).
named_program = "/ usr / sbin / named" path # untuk nama, jika Anda ingin yang berbeda.
named_flags = "-u bind" # Flags untuk bernama
named_pidfile = "/ var / run / named / pid" # Harus menetapkan ini juga named.conf
named_chrootdir = "/ var / named" # Chroot direktori (atau "" tidak untuk auto-chroot itu)
named_chroot_autoupdate = "YES" # Otomatis install / update chroot
# Komponen bernama. Lihat / etc / rc.d / named.
named_symlink_enable = "YES" # symlink file pid chroot
Seperti biasa, jika perubahan yang diperlukan untuk file ini, mereka harus dibuat untuk / rc.conf etc /,
yang menimpa nilai setara di / etc / default / rc.conf.
• Script (/ etc / rc.d / named) proses parameter dalam rc.conf untuk membuat atau memperbarui
konfigurasi saat startup. Hal ini menciptakan skrip startup konfigurasi default rndc
dengan menjalankan perintah rndc-confgen-(lihat Bab 9), yang memungkinkan akses rndc
dari localhost saja (asumsi default kontrol klausa).
Konfigurasi Manual Chroot Penjara
Bagian ini mengidentifikasi setup manual dari sebuah penjara chroot atau bak pasir. Anda mungkin ingin melakukannya,
mungkin karena Anda menikmati melakukan hal semacam ini, mungkin karena ada mungkin bukan
RPM yang tersedia untuk menginstal pilihan chroot, dan mungkin karena hal yang mungkin salah. Konfigurasi
telah diuji pada Linux dan FreeBSD (keduanya terpisah didokumentasikan). Ini mengasumsikan
basis direktori chroot / chroot / named. Konfigurasi ini bisa menggunakan lebih normal
lokasi / var / named / chroot atau / var / named / untuk FreeBSD, tetapi menggunakan / chroot / named berarti kita
dapat menciptakan lingkungan chroot bersih dan menghindari hasil parsial dari instalasi default
Selanjutnya diasumsikan bahwa pengguna bernama dan grup dengan nama account telah diatur (FreeBSD
pengguna biasanya akan menggunakan bind: bind). Jika account tersebut tidak hadir, proses ini digambarkan
di bagian "Menetapkan Run Time UID BIND" dalam bab ini. Nama standar caching
server file named.conf (dari bagian "Caching-only DNS Server," terletak di Bab 7) adalah
digunakan sebagai konfigurasi target dan direproduksi di sini:
/ / Nama Caching Server untuk Example.com.
/ / Kami menyarankan Anda selalu menjaga log perubahan pada file ini seperti yang ditunjukkan di bawah ini
/ / CHANGELOG:
/ / 1. 9 Juli 2005 inisial atau NAMA
/ / A. melakukan sesuatu
/ / A. 23 Juli 2005 inisial atau NAMA
/ / A. melakukan sesuatu yang lebih
/ / B. perubahan lain
/ /
Pilihan (
/ / Semua path relatif menggunakan direktori ini sebagai dasar
direktori "/ var / named";
/ / Versi laporan keamanan untuk menghindari hacking kelemahan dikenal
/ / Jika nomor versi yang sebenarnya diterbitkan
versi "tidak tersedia";
/ / Konfigurasi khusus pilihan klausa laporan
/ / Menonaktifkan semua permintaan transfer zona
memungkinkan-transfer ("none");
/ / Opsional - default BIND adalah rekursi
rekursi ya;
);
/ /
/ / Log ke / var / log / example.log semua peristiwa dari info UP tingkat keparahan (debug tidak ada)
/ / Default untuk menggunakan 3 file dalam rotasi
/ Pesan kegagalan / sampai saat ini adalah di (syslog) / var / log / messages
/ /
logging (
saluran example_log (
file "/ var / log / bernama / example.log" versi 3 ukuran 250K;
keparahan info;
);
kategori default (
example_log;
);
);
/ Zona / dibutuhkan untuk query rekursif
zone "." (
jenis petunjuk;
file "root.servers";
);
/ Domain diperlukan host lokal
zone "localhost" di (
jenis master;
file "master.localhost";
memungkinkan-update (none;);
);
/ Peta / reverse localhost
zone "0.0.127.in-addr.arpa" in (
jenis master;
file "localhost.rev";
memungkinkan-update (none;);
);
Akhirnya, diasumsikan bahwa default konfigurasi rndc didirikan dengan menggunakan perintah
rndc-confgen-sehingga default file / etc / rndc.key hadir.
Linux (Fedora Core 2) Chroot
Konfigurasi ini membangun lingkungan chroot di lokasi yang unik untuk menampilkan seluruh proses
terlibat. Seri berikut perintah menciptakan direktori yang diperlukan dan bergerak
file dasar yang diperlukan. Baris yang dimulai dengan / / adalah komentar dan tidak harus dimasukkan:
# Cd /
# Mkdir chroot
# mkdir chroot / named
# mkdir chroot / named / var
# mkdir chroot / named / var / named
# mkdir chroot / named / var / run
# mkdir chroot / named / var / run / named
/ / Buat default file kosong pid
menyentuh # chroot / named / var / run / named / named.pid
# mkdir chroot / named / var / log
# mkdir chroot / named / var / log / named
/ / Buat file log kosong
menyentuh # chroot / named / var / log / bernama / example.log
# mkdir chroot / named / dev
/ / Membuat chroot / named / dev / null dan / dev / random
# Chroot mknod / bernama / dev / null c 1 3
# Chroot mknod / bernama / dev / random c 1 8
/ / Copy file yang dibutuhkan
# cp / etc / named.conf chroot / named / etc / named.conf
# cp / etc / localtime chroot / named / etc / localtime
# Cp / var / named / localhost.rev chroot / named / var / named / localhost.rev
# Cp / var / named / chroot master.localhost / named / var / named / master.localhost
# Cp / var / named / root.servers chroot / named / var / named / root.servers
/ / Default file rndc tombol (jika tidak cacat)
# cp / etc / rndc.key chroot / named / etc / rndc.key
/ Permissions set / dan kepemilikan
# Chown-R bernama: bernama chroot / named / *
# Chmod-R 0660 chroot / named / *
# Chmod 0666 chroot / named / dev / null
# Chmod 0644 chroot / named / dev / random
# Chmod 0664 chroot / named / var / run / named / named.pid
Jika nama server memiliki file zona tambahan (misalnya, jika seorang budak zona atau master),
kemudian direktori tambahan dan salinan file yang diperlukan untuk file-file yang relevan. Jika default rndc
konfigurasi telah dibuat (menggunakan rndc-confgen-a), maka file kunci perlu disalin
sebagaimana ditunjukkan. Jika rndc telah dinonaktifkan dengan klausa kontrol kosong (kontrol {};), maka file ini
tidak diperlukan. Jika konfigurasi rndc kustom telah dibangun, maka / etc / rndc.conf perlu
disalin bersama dengan kunci spesifik file.. Meskipun jenis perangkat Linux cenderung tetap stabil,
mungkin layak memverifikasi bahwa nomor perangkat major dan minor adalah sebagai ditunjukkan dalam
mknod perintah dengan mengeluarkan perintah berikut:
# Ls-l / dev / null
CRW-rw-rw-1 root root 1,3 23 Februari 2004 / dev / null
# Ls-l / dev / random
CRW-r-r-1 root root 1,8 23 Februari 2004 / dev / random
Akhirnya, nama mungkin mulai menggunakan perintah berikut:
# Bernama bernama-u-t / chroot / named
Dengan asumsi bernama harus dimulai pada saat sistem boot, skrip startup (/ etc / rc.d / init.d /
bernama) perlu diedit untuk menambahkan-t / chroot / named argumen.
Konfigurasi sebelumnya adalah versi sederhana menggunakan perintah untuk minimum
menunjukkan proses yang terlibat. Jika konfigurasi yang lebih kompleks diperlukan, maka prosedur
dan teknik yang diuraikan dalam bagian "Permissions Batas" dapat diterapkan.
FreeBSD Chroot
pengguna FreeBSD memiliki dua pilihan. Metode pertama menganggap bahwa semua file akan menggunakan standar (default)
FreeBSD lokasi, dan hanya melibatkan penambahan tiga baris berikut ke / rc.conf etc /:
named_chrootdir = "/ chroot / named" # Chroot direktori (atau "" tidak untuk auto-chroot itu)
named_chroot_autoupdate = "YES" # Otomatis install / update chroot
named_symlink_enable = "YES" # symlink file pid chroot
Kode sebelumnya mengabaikan nilai-nilai di / etc / default / rc.conf dan mengkonfigurasi secara otomatis
nilai-nilai yang diperlukan, termasuk pembuatan direktori berdasarkan pada standar FreeBSD (semua
File tersebut tersimpan di bawah etc / namedb direktori) pada sistem boot berikutnya.
Metode kedua harus digunakan jika lokasi default non-FreeBSD yang digunakan untuk
file. Metode ini menggunakan urutan perintah yang sama seperti yang didefinisikan untuk Linux di sebelumnya
bagian, dengan pengecualian bahwa nilai-nilai pada perintah mknod harus diverifikasi menggunakan
ls-l perintah seperti yang ditunjukkan untuk Linux. Nilai saat ini untuk 4.x FreeBSD adalah sebagai b# Chroot mknod / bernama / dev / null c 2 2
# Chroot mknod / bernama / dev / random c 2 3
Nilai untuk 5.x FreeBSD adalah sebagai berikut:
# Chroot mknod / bernama / dev / null c 2 3
# Chroot mknod / bernama / dev / random c 249 0
Akhirnya, baris berikut harus ditambahkan ke / rc.conf etc / jika belum ada:
named_enable = "YES" bernama # Jalankan, server DNS (atau TIDAK).
named_program = "/ usr / sbin / named" path # untuk nama, jika Anda ingin yang berbeda.
named_flags = "-u bind-t / chroot / named" # Flags untuk bernama
named_chrootdir = "" # Chroot direktori (atau "" tidak untuk auto-chroot itu)
Metode kedua bypasses proses inisialisasi default chroot, dan memungkinkan banyak
kontrol yang lebih ketat atas konfigurasi-dengan mengorbankan pengguna melakukan semua pekerjaan.
Dedicated Server
Yang paling dalam batasan izin atau kotak pasir akhir adalah dedicated server berjalan baik
sebagai bagian dari konfigurasi server Stealth (lihat Bab 4), atau sebagai server yang berdiri sendiri. Seperti
server bergantung pada minimalisme untuk mengurangi kemungkinan subversi, dan biasanya akan terlihat
sesuatu seperti berikut:
• No GUI interface, untuk mengurangi kompleksitas perangkat lunak
• Tidak ada compiler atau alat-alat pembangunan lainnya
• Firewall (packet filter) untuk menghambat akses ke semua port selain port 53
• Tidak ada akses jarak jauh ke sistem-Secure Shell (SSH) atau BIND (rndc)
• Tidak ada Network File System (NFS) atau Samba koneksi
• Penghapusan semua utilitas yang tidak perlu, misalnya, Telnet, FTP, dan sebagainya
• BIND atau perangkat lunak NSD berjalan di bak pasir dan biasanya dikonfigurasi sebagai authoritativeonly
server
Catat Stream
Jika keamanan merupakan keprihatinan yang signifikan, maka pemantauan atas pelanggaran keamanan menggunakan intrusiondetection
perangkat lunak seperti Snort (www.snort.org) adalah penting, tetapi alat tersebut berada di luar
cakupan buku ini. Namun, fitur BIND penebangan dapat membantu dalam proses ini dengan streaming
keamanan pesan ke dalam log file terpisah untuk memperkecil kerja pemindaian konten log secara manual,
dan maka kemungkinan hilang peristiwa penting. Fragmen berikut named.conf
stream peristiwa keamanan menjadi log terpisah:erikut:
/ / Named.conf fragmen
logging (
saluran normal_log (
file "/ var / log / bernama / normal.log" versi 3 ukuran 2m;
keparahan kesalahan;
print-time yes;
print-beratnya ya;
print-kategori ya;
);
saluran security_log (/ / streaming log keamanan
file "/ var / log / bernama / security.log" versi 3 ukuran 500k;
keparahan info;
print-time yes;
print-beratnya ya;
print-kategori ya;
);
kategori default (
normal_log;
);
kategori keamanan (
security_log;
);
);
....
Pengaturan keparahan (lihat Bab 12) dapat bereksperimen dengan menemukan yang paling
nilai yang dapat diterima untuk menyeimbangkan volume dan informasi. BIND server klausa dengan palsu
ya, pernyataan atau laporan blackhole dapat digunakan untuk menghambat layanan sepenuhnya ke
gigih keamanan pelaku.
Keanekaragaman Perangkat Lunak
Upaya yang signifikan telah banyak digunakan oleh operator root-server untuk meminimalkan exploitasi
risiko dengan menjalankan BIND pada sistem operasi beberapa host (misalnya, Linux, Solaris,
FreeBSD, dan sebagainya), untuk mengurangi eksposur terhadap kelemahan tunggal. Teorinya adalah bahwa jika sebuah mengeksploitasi adalah
ditemukan di satu OS, itu tidak mungkin untuk hadir di semua OS pada saat yang sama. Oleh karena itu, hanya
sistem rentan dapat segera pensiun sementara pelayanan terus. The paket NSD
(Www.nlnetlabs.nl / nsd), yang merupakan Open Source server nama otoritatif-satunya, telah
berjalan di server dioperasikan RIPE-root (k.root-servers.net) sejak tahun 2003, dan sepenuhnya mendukung
DNSSEC.bis fitur. Jika memikirkan sebuah BIND tunggal mengeksploitasi mengambil semua sistem Anda dari udara
pada saat yang sama menjaga Anda tetap terjaga di malam hari, maka upaya tambahan mungkin signifikan
mempertahankan versi kedua software DNS dapat bermanfaat.
Tinjauan Cryptographic
Berikutnya bagian dan Bab 11 termasuk teknik yang membuat ekstensif menggunakan modern
proses kriptografi. Bagian ini dirancang untuk memberikan pembaca gambaran singkat dari
terminologi yang digunakan, serta fungsi dan keterbatasan yang terkait dengan teknik masing-masing.
Proses matematis yang digunakan dalam kriptografi yang diperlakukan sebagai barang automagical ("terjadi")
dan tidak dijelaskan sama sekali. Untuk cryptanalyst seorang, seperti pernyataan adalah bidah murni. Namun,
memahami bagaimana matematika bekerja dalam proses algoritmik yang sebenarnya tidak perlu
memahami konsep-konsep keamanan. Sumber daya tambahan disediakan di www.netwidget.net/
buku / apress / dns untuk para pembaca yang bersenang-senang di rincian matematika mengerikan. Namun,
sebelum mengabaikan matematika sama sekali, adalah penting untuk memahami beberapa poin.
teknik Cryptographic tidak provably aman. Sebaliknya, mereka yang terkena serangan
peneliti dan spesialis yang berdedikasi. Hanya setelah melewati serangan tersebut teknik
dibuat tersedia untuk penggunaan operasional. Penelitian sedang berlangsung untuk menjaga di depan orang-orang jahat,
dan kadang-kadang menyebabkan kelemahan baru yang ditemukan. Akhirnya, semua teknik kriptografi
didasarkan pada konsep yang dikenal sebagai komputasi layak. Ini berarti baik itu
terlalu mahal untuk merakit kekuatan komputasi yang diperlukan untuk menemukan kunci, atau bahwa
itu akan memakan waktu terlalu lama. Konsep ini relatif, tidak mutlak, dan perubahan dari waktu ke waktu.
Kriptologi dapat digunakan untuk tiga tujuan:
• Kerahasiaan: Hanya pihak untuk komunikasi dapat memahami pesan
dikirim antara para pihak.
• Otentikasi: Data hanya mungkin berasal dari sumber yang dikenal.
• Integritas data: Data yang diterima oleh salah satu pihak adalah data yang dikirim oleh
pihak lainnya.
Dalam konteks standar DNS, hanya otentikasi dan integritas data yang menarik.
Dimana kerahasiaan diperlukan, diasumsikan akan disediakan oleh proses komunikasi
seperti SSL atau TLS penggantinya, dan tidak didefinisikan dalam standar DNS. BIND tidak mendukung
SSL.
Sebagian besar dari kita telah kriptografer pada tahap tertentu dalam hidup kita. Kode rahasia dan
metode kami diciptakan untuk mengirim catatan ke teman-teman sekolah kami juga mencerminkan, mungkin kasar, paling awal
proses kriptografi dimana "rahasia" itu yang terkandung dalam proses. Sebagai contoh,
kita bisa menggeser dua posisi huruf dalam alfabet dan menyandikan pesan. merugikan
dengan metode ini adalah bahwa setelah proses ini ditemukan, algoritma ini berguna; itu
harus dibuang dan yang baru diciptakan. Sebaliknya, kriptografi modern mengasumsikan bahwa
algoritma yang digunakan-metode enkripsi-diketahui semua orang, termasuk orang-orang jahat,
dan memang hanya dapat terbukti aman dengan serangan berulang. Bagian rahasia dari proses
terletak dengan tombol atau kunci unik. Jika kunci terganggu, itu hanya dibuang dan yang baru
dibuat. Seorang penyerang harus memulai lagi yang tidak memiliki pengetahuan yang lebih besar daripada sebelumnya, meskipun
algoritma dasar atau proses tetap sama. Ada dua kelas berbasis kriptografi kunci
algoritma dalam penggunaan modern: simetris dan asimetris.
Kriptografi simetris
algoritma enkripsi symmetry, juga disebut single-key, bersama-rahasia, atau bahkan, membingungkan,
sistem pribadi-tombol, menggunakan kunci tunggal untuk mengenkripsi dan mendekripsi data. Ini satu kunci yang berbagi
rahasia-harus aman dipertukarkan antara pihak-pihak yang akan menggunakannya sebelum sebenarnya aman
komunikasi. Keterbatasan sistem bersama-rahasia ada dua. Pertama, kuncinya harus
aman didistribusikan menggunakan proses yang disebut manajemen kunci, yang sendiri tidak sepele. Kedua,
metode mengamankan tombol sekali didistribusikan terletak dengan semua pihak untuk komunikasi:
"Saya percaya diri tapi apakah aku percaya semua pihak lain untuk menyimpan kunci rahasia?" Contoh
umum algoritma kunci simetrik adalah DES, AES, IDEA, dan RC4, dan ukuran tombol khas adalah
64, 128, atau 192 bit. Gambar 10-2 menunjukkan penggunaan operasional rahasia bersama untuk klasik rahasia
komunikasi.
Catatan Rahasia berbagi istilah, yang menggambarkan kunci tunggal yang digunakan, atau bersama, dengan kedua ujung komunikasi?
seharusnya tidak bingung dengan berbagi rahasia, yang menggambarkan sebuah proses dimana bersama, atau
tunggal, kunci rahasia ini dipecah menjadi bagian dan dibagi antara beberapa orang untuk membuatnya lebih aman.
algoritma Bersama-rahasia yang digunakan dalam DNS di operasi TSIG. Masalah mendistribusikan
kunci (key manajemen) tidak didefinisikan dalam standar DNS, dan bisa apa saja yang
bekerja untuk pengguna, misalnya, telepon, faks, e-mail aman, atau merpati pos. sharedsecret The
kunci (s) yang digunakan oleh perangkat lunak DNS harus terus tersedia (dikenal sebagai on-line di jargon)
untuk memungkinkan penggunaan mereka ketika memvalidasi transaksi. Namun, kunci membutuhkan visibilitas minimum;
demikian, adalah mustahil untuk menyimpannya dalam file zona. Sebaliknya, tombol tersebut disimpan dalam satu atau lebih
kunci klausa dalam file named.conf BIND's. Karena isinya sangat sensitif (a bersama
rahasia), mereka biasanya disimpan sebagai file terpisah dengan izin membaca terbatas dan termasuk
(Menggunakan termasuk pernyataan) ke file named.conf.
Kriptografi asimetrik
algoritma enkripsi asimetrik menggunakan sepasang kunci dan umumnya disebut sebagai kunci publik
sistem kriptografi atau kadang-kadang sebagai enkripsi nonsecret (a oksimoron sedikit). Dalam sistem ini,
data (disebut plain-teks dalam jargon) yang dienkripsi dengan satu kunci hanya dapat didekripsi
dengan tombol pasangan. Dengan satu tombol, maka komputasi layak untuk menurunkan tombol pasangan. Itu
sistem bekerja dengan membuat satu tombol, yang disebut kunci publik, banyak tersedia, dengan tetap menjaga tombol lain, ternyata disebut kunci pribadi, rahasia. Proses ini memiliki sisi menarik
efek. Jika pesan dienkripsi dengan kunci pribadi dan dapat didekripsi dengan publik pasangan
kunci, maka hanya pemilik kunci privat bisa melakukannya. Properti ini digunakan dalam digital
tanda tangan dan dijelaskan lebih lanjut pada bagian "Tanda tangan digital." Yang paling banyak digunakan
sistem enkripsi kunci publik adalah RSA (setelah penemu Rivest, Shamir, dan Adelman) dan
kurva eliptik. ukuran kunci yang khas untuk sistem kunci publik adalah 512-bit, 1.024 bit, atau lebih tinggi. Itu
kunci publik dari sepasang / swasta kunci publik dapat disimpan dengan aman di layanan publik seperti DNS,
sedangkan private key harus dijaga aman di lokasi pribadi. Gambar 10-3 mengilustrasikan
penggunaan kriptografi kunci publik untuk komunikasi rahasia klasik.
sistem kunci publik-memiliki satu keterbatasan yang signifikan, karena mereka bergantung pada tahu, atau percaya,
bahwa kunci publik yang akan digunakan dalam komunikasi dengan seseorang atau organisasi
benar-benar kunci publik dari orang atau organisasi dan belum spoofed oleh jahat
pihak ketiga. Metode yang ini biasanya dilakukan kadang-kadang disebut Publik
Key Infrastructure (PKI), di mana pihak ketiga terpercaya aman mengelola kunci publik. Jika
pihak ketiga diminta memberikan kunci publik X, mereka dipercaya untuk memberikan yang benar
kunci. Pihak ketiga yang dipercaya untuk puas diri dengan beberapa atestasi-proses,
notarization, dan sebagainya-bahwa X adalah satu-satunya, atau global yang unik, X.
Pesan mencerna
Seperti disebutkan sebelumnya, sistem DNS memerlukan kerahasiaan otentikasi dan integritas data, tidak.
Untuk menyediakan integritas data, pesan itu bisa saja dienkripsi. Dengan demikian, hanya pemilik
tombol tunggal (dalam sistem simetrik) atau kunci publik (dalam sistem asimetris) dapat mendekripsi
itu. Namun, sistem enkripsi menggunakan fungsi matematika yang kompleks, dan karena itu besar
pengguna sumber daya CPU. Untuk mengenkripsi semua pesan akan dikenakan biaya sangat tinggi. Untungnya,
teknik lain dapat digunakan untuk mengurangi beban ini. Yang paling umum adalah ringan
prosedur yang disebut hash satu arah, atau lebih umum pesan digest. Hash atau digest menciptakan
blok berukuran tetap yang unik dan relatif kecil data (terlepas dari pesan asli
panjang) yang tidak dapat dibatalkan. Pesan-pesan yang dikirim biasanya mencakup baik teks biasa
(Tidak terenkripsi) dan mencerna pesan. Algoritma hash yang diterapkan pada dataran diterima
teks dan jika hasilnya sesuai dengan pesan mencerna, ini berarti data yang diterima tidak berubah.
Pesan dicerna adalah dalam beberapa hal serupa di konsep untuk checksum namun telah secara signifikan berbeda
sifat matematika. Bentuk yang paling umum adalah mencerna pesan MD5 dan SHA-1
(Bagian dari keluarga SHA). Gambar 10-4 menunjukkan pesan mencerna dalam tindakan.
Kode Otentikasi Pesan
Dua solusi yang mungkin ada untuk otentikasi pengirim serta memastikan integritas. Dalam
kasus simetris, bersama-rahasia sistem, Pesan Authentication Code (MAC) dibuat
yang menggabungkan pesan mencerna dengan kunci bersama. The mengotentikasi bagian penting pengirim,
dan bagian hash menjamin integritas data. Bentuk yang paling umum Mac HMAC-MD5
dan HMAC-SHA-1. MACS digunakan untuk operasi TSIG aman dalam DNS. Gambar 10-5 menunjukkan bagaimana
MAC digunakan.
BAB 10 Konfigurasi DNS AMAN 261
Gambar 10-4.Message mencerna
Tokoh
Digital Signatures
Dalam dunia asimetris atau kunci publik, proses otentikasi dan integritas data menggunakan
apa yang disebut tanda tangan digital. Pesan sedang dikirim adalah lagi hash untuk membuat pesan
mencerna menggunakan, misalnya, MD5 atau SHA-1 untuk memastikan integritas data. Pesan yang dihasilkan kemudian mencerna
dienkripsi menggunakan kunci pribadi dari pengirim. Kedua pesan teks biasa dan dienkripsi
mencerna dikirim ke pihak lain. Penerima decrypts mencerna pesan dengan menggunakan publik
kunci dari pengirim, menerapkan algoritma hash untuk data plain-text, dan jika hasil pertandingan,
maka baik pengirim keaslian dan integritas data terjamin. Khas kunci
ukuran untuk sistem tanda tangan digital adalah 512-bit, 1.024 bit, atau lebih tinggi. Yang paling umum digital
algoritma signature RSA-MD5, RSA-SHA-1, dan Digital Signature Arsitektur (DSA; US
Pemerintah standar). tanda tangan digital digunakan dalam DNS untuk SIG (0) transaksi aman
dan untuk semua transaksi DNSSEC diuraikan dalam Bab 11. Gambar 10-6 menunjukkan bagaimana digital
tanda tangan digunakan.
Catatan algoritma hash MD5?, Dan dengan implikasi apapun algoritma yang menggunakan itu, seperti RSAMD5, telah
pindah ke "tidak direkomendasikan" status dalam dokumen IETF kebanyakan, karena beberapa kelemahan teori dipublikasikan
pada awal tahun 2005. Kelemahan ini tidak membatalkan penggunaan algoritma.
DNS Cryptographic Gunakan
DNS standar yang meliputi keamanan secara umum dan membingungkan disebut sebagai DNSSEC-
menggunakan keamanan kriptografi dalam dua cara yang berbeda. Transaksi keamanan, seperti yang digunakan dalam zona
transfer dan update dinamis, menggunakan model keamanan point-to-point di mana kedua belah pihak untuk
transaksi diasumsikan saling percaya. Pihak pertukaran informasi, termasuk
keamanan informasi, bahwa mengotentikasi sumber dan integritas data dan relevan hanya untuk
transaksi tersebut. TSIG (bersama-rahasia) dan SIG (0) (kunci publik) metode yang digunakan untuk melakukan
validasi. Kedua metode tersebut dijelaskan, dengan contoh, kemudian dalam bab ini.
Klien-server keamanan, sekarang dikenal sebagai DNSSEC.bis, memungkinkan DNS menerima untuk memvalidasi
sumber dan integritas data yang diterima dalam menanggapi permintaan apapun dari dikonfigurasi sesuai
DNS. Untuk seperti sistem untuk bekerja, itu bergantung kritis pada suatu jaminan bahwa sumber data
adalah apa yang dikatakan itu. Masalah ini, yang digambarkan dalam bagian sebelumnya, biasanya mengandalkan
pada keberadaan PKI, dimana pihak ketiga yang dipercaya memverifikasi bahwa beberapa informasi, biasanya
sebuah kunci publik, milik X, dan bahwa X benar-benar satu-satunya X. DNSSEC. bis keamanan tidak
bergantung pada PKI, melainkan menciptakan rantai hierarki atau kepercayaan berdasarkan delegasi dari DNS
nama. Sebuah bentuk akar dipercaya pihak atau Keamanan Entry Point (SEP) dari rantai kepercayaan, di
yang RRS tertentu pada titik delegasi yang cryptographically ditandatangani (menggunakan tanda tangan digital)
oleh zona induk. Hal ini menciptakan sebuah link yang aman ke dalam domain berikutnya dalam rantai, yang
dalam tanda gilirannya catatan delegasi dan seterusnya, sampai titik akhir telah tercapai. Itu
keaslian setiap link dalam rantai tersebut, dengan pengecualian titik awal, diverifikasi oleh
domain sebelumnya, atau orang tua,. DNSSEC.bis keamanan dijelaskan di Bab 11.
Sifat dari sistem aman adalah bahwa mereka harus melindungi terhadap berbagai bentuk serangan. Satu
bentuk serangan ini disebut serangan ulangan, dimana transaksi diambil dan diputar di kemudian
waktu. Untuk menghindari bentuk-bentuk serangan, semua sistem yang terlibat dalam keamanan kriptografi harus waktu
disinkronisasi. Protokol biasanya memungkinkan "fudge" faktor 300 detik (5 menit), tetapi
pelaksanaan Network Time Protocol (NTP) adalah penting dalam sistem yang menggunakan kriptografi
teknik. Pelaksanaan NTP terletak di luar ruang lingkup buku ini, tetapi implementasi Open Source
tersedia untuk sebagian besar OS dan distribusi mereka. Informasi lebih lanjut dapat
diperoleh dari www.ntp.org, termasuk daftar server waktu publik.
Perhatian sinkronisasi Waktu untuk semua host yang terlibat dalam pertukaran kriptografi adalah? Penting. BIND kegagalan
pesan tidak selalu menunjukkan dengan jelas bahwa waktu adalah sumber kegagalan dalam otentikasi, ketika 90%
waktu yang memang masalah. NTP menggunakan pendekatan bertahap untuk sinkronisasi jam, dan dapat mengambil
jangka waktu yang cukup untuk mengatur jam pada sistem host. Jika Anda tidak menjalankan perangkat lunak NTP dan ingin
bereksperimen dengan teknik yang diuraikan di seluruh bab ini dan Bab 11, maka setiap host yang akan
berpartisipasi harus menyinkronkan jam untuk waktu internet dengan menerbitkan name.of.time.server ntpdate
perintah. Dalam perintah ini, name.of.time.server harus diganti dengan waktu server yang dapat diakses;
daftar server waktu yang tersedia secara umum dapat ditemukan di www.ntp.org. Catatan ntpdate yang merupakan update satu kali,
dan ketepatan jam lokal menentukan berapa lama efeknya akan berlangsung. Operasional sistem yang berpartisipasi
di DNSSEC harus menerapkan NTP.
Mengamankan Zona Transfer
Dalam konfigurasi DNS yang paling, transfer zona sangat penting. Jika Anda seorang keamanan-sadar
kerangka pikiran, transfer zona mungkin dipandang sebagai sesuatu yang keji. Opsi default di
BIND adalah untuk memungkinkan zona transfer ke semua host yang meminta. Walaupun di wajah ini mungkin terlihat seperti
tindakan sangat ramah, didasarkan pada premis sederhana bahwa sebuah DNS publik mengandung publik
data. Segala sesuatu yang dapat ditransfer ditemukan oleh permintaan yang melelahkan, bahkan jika zona
atransfers sama sekali dilarang. Jika data tidak boleh umum, tidak harus berada dalam zona file
pada server publik. Cukup mengamankan zona transfer bukanlah solusi untuk menyembunyikan data. Namun demikian,
ada kasus-kasus di mana diperlukan sebagai bagian dari konfigurasi keamanan-mendalam untuk membatasi
zona transfer-misalnya, di sisi pribadi dari konfigurasi server Stealth (lihat Bab
4). Cara paling sederhana untuk mengamankan zona transfer adalah melalui penggunaan alamat IP dalam BIND's
named.conf file. Fragmen named.conf berikut batas transfer ke host bernama berdasarkan
nama zona:
/ / Named.conf fragmen
logging (
saluran normal_log (
file "/ var / log / bernama / normal.log" versi 3 ukuran 2m;
keparahan kesalahan;
print-time yes;
print-beratnya ya;
print-kategori ya;
);
saluran security_log (/ / streaming log keamanan
file "/ var / log / bernama / security.log" versi 3 ukuran 2m;
keparahan info;
print-time yes;
print-beratnya ya;
print-kategori ya;
);
kategori default (
normal_log;
);
kategori keamanan (
security_log;
);
);
Pilihan (
....
memungkinkan transfer (none;); / / tidak ada secara default
....
);
....
zone "example.com di (
....
memungkinkan transfer (10.1.2.5;); / / ini hanya zona
....
);
Fragmen konfigurasi sebelumnya menolak semua permintaan transfer zona dan selektif
memperbolehkan host diijinkan pada basis per-zona. Misalnya, alamat IP tunggal 10.1.2.5
diperbolehkan untuk melakukan transfer zona untuk zona example.com. Log dialiri untuk keamanan
peristiwa, karena diasumsikan bahwa sebagai bagian dari strategi defensif itu menarik untuk melihat
di mana permintaan transfer berasal. Jika perlu, setelah pemeriksaan log server klausa
dengan palsu ya, atau pernyataan blackhole dapat digunakan untuk menghentikan servis sepenuhnya untuk terus-menerus
ingin tahu host.
Mengingat situasi yang tepat, alamat IP dapat palsu, yang dapat mengakibatkan orang-inthe-
serangan tengah sehingga pihak ketiga dapat berpura-pura menjadi penguasa zona. Ketika diminta
untuk mentransfer zona, pihak ketiga ini bisa mentransfer data palsu sehingga, katakanlah, sebuah situs web
yang dibajak dengan menyediakan alternatif alamat IP dalam Resource Records (RRS). Untuk mencegah
kemungkinan seperti itu, transfer zona dapat diamankan dengan menggunakan teknik kriptografi
untuk memastikan baik otentikasi (tuan dan budak adalah yang mereka katakan) dan data
integritas (data yang diterima oleh budak itu sama dengan data yang dikirim oleh master).
Otentikasi dan Integritas Zona Transfer
Kabar buruknya adalah bahwa dari tiga metode untuk mengamankan zona transfer, untuk tujuan praktis,
hanya ada satu, sebagaimana dapat dilihat dari daftar berikut:
• TSIG: TSIG didefinisikan dalam RFC 2845 dan menggunakan rahasia bersama tunggal antara master
dan budak server sebagai bagian dari MAC. Kuncinya harus didistribusikan ke lokasi budak oleh
beberapa proses aman, seperti fax, email, kurir, atau e-mail aman, dan harus dijaga
aman di semua situs. Berbagi rahasia, karena mereka bergantung pada sebuah kunci tunggal dipertahankan
di dua lokasi atau lebih, harus sering diganti (mungkin setiap 30 sampai 60 hari). Jika
ada lebih dari satu budak server, baik rahasia bersama yang terpisah dapat digunakan untuk setiap
master-budak pasangan, atau berbagi rahasia tunggal dapat digunakan untuk semua budak. Kebijakan terakhir ini
secara signifikan lebih berisiko, karena setiap penemuan subversi atau tombol di satu situs membatalkan
semua transfer budak, sedangkan jika rahasia terpisah menggunakan budak dapat ditumbangkan
sementara dinonaktifkan hingga kuncinya diganti. Tidak ada perubahan pada operasional
zona file bila menggunakan metode TSIG, hanya file named.conf yang diubah.
• SIG (0): SIG (0) didefinisikan dalam RFC 2931 dan menggunakan sistem kunci publik untuk menghasilkan digital
tanda tangan yang baik mengotentikasi dan menjamin integritas data yang terlibat di setiap
transaksi yang mencakup transfer zona. Namun, tidak ada alat yang tersedia dengan saat ini
BIND rilis untuk mendukung SIG (0) untuk transfer zona. SIG (0) dapat digunakan dengan DDNS;
lihat bagian "Mengamankan Dynamic Update" kemudian dalam bab ini.
• TKEY: The TKEY menyediakan metode kunci bersama-rahasia bertukar aman sehingga
burung-burung merpati pembawa miskin dapat memiliki istirahat (atau apa pun yang lain metode yang Anda gunakan untuk aman
mendistribusikan kunci bersama-sama). Metode yang didefinisikan untuk mendukung kedua algoritma Diffie-Hellman
dan Keamanan API Layanan Umum (GSSAPI). Namun, standar (RFC 2930)
mengamanatkan bahwa pertukaran harus disahkan dengan baik TSIG atau SIG (0) metode.
Oleh karena itu, tampaknya tidak diterapkan secara luas, dan tidak termasuk lebih lanjut dalam
buku ini.
Untuk tujuan praktis, metode hanya tersedia untuk mengamankan transfer zona TSIG. Itu
konfigurasi rinci diperlukan untuk mendukung layanan ini tercakup dalam bagian berikut.
Konfigurasi TSIG
Transaksi Signatures (TSIG) menggunakan Message Authentication Code (MAC) dengan berbagi rahasia
baik untuk mengotentikasi dan menjamin integritas data dari setiap transaksi yang terlibat dalam transfer zona
antara budak dan tuannya dicalonkan. Sangat penting untuk diingat bahwa bersama-rahasia
data tidak pernah ditempatkan di file zona DNS. Sebaliknya, rahasia digunakan bersama oleh dua server
ketika pertukaran data, seperti transfer zona. Gambar 10-7 mengilustrasikan bagaimana berbagi rahasia adalah
digunakan dalam mengamankan transaksi.
Rahasia berbagi adalah dihasilkan dengan menggunakan utilitas dnssec-keygen, yang merupakan tujuan-umum
kriptografi utilitas yang disediakan dengan BIND dan dijelaskan dalam Bab 9. The TSIG standar (RFC
2845) memungkinkan baik HMAC-MD5 dan HMAC-1-SHA algoritma untuk digunakan sebagai Mac. Namun,
rilis terbaru dari utilitas dnssec-keygen hanya mendukung algoritma HMAC-MD5. sharedsecret The
kunci diasumsikan dihasilkan dalam sebuah direktori bernama / var / named / tombol menggunakan perintah
mirip dengan berikut:
# Cd / var / named / tombol
#-Dnssec-keygen sebuah hmac-md5-b 128-n example.com host
Perintah ini menghasilkan sebuah kunci 128-bit (b-argumen) cocok untuk digunakan dengan HMACMD5
algoritma MAC (HMAC-MD5 memungkinkan kunci 1-512 bit). N-argumen menunjukkan host
bahwa host KUNCI RR dihasilkan dengan nama example.com. KUNCI RR ini tidak digunakan dalam TSIG
transaksi untuk alasan dijelaskan nanti pada bagian ini. Namun, program dnssec-keygen
memperlakukan n-argumen sebagai wajib, jadi harus hadir. Perintah menulis dua file ke
direktori saat ini, dan ketika output mengisi pesan singkat untuk mengidentifikasi file yang dibuat,
seperti yang ditunjukkan di sini:
Kexample.com. 157 31.313
English to Indonesian translation
Nama file sebelumnya terdiri dari nilai K tetap, diikuti oleh nama host tercermin
dari perintah dnssec-keygen (dalam hal ini example.com). 157 mengidentifikasi algoritma
(HMAC-MD5). Para 31.313 disebut tag-kunci; itu dihasilkan menggunakan varian dari satu "itu
melengkapi "algoritma checksum untuk mengidentifikasi set kunci unik. Mencari di dalam direktori
di mana file itu ditulis menampilkan dua file:
Kexample.com 157 31313.. Swasta
Kexample.com 157 31313.. Kunci
Melihat file Kexample.com 157 31313.. Sesuatu swasta menampilkan seperti berikut
Data:
Swasta-kunci-format: v1.2
Algoritma: 157 (HMAC_MD5)
Kunci: JuxDyYXIJhAia5WQe9oqUA ==
Informasi sebelumnya berisi tiga baris. Baris yang dimulai dengan teks kunci: adalah
dengan versi base64 (RFC 3548) dikodekan dari kunci bersama-rahasia. Langkah selanjutnya adalah mengedit ini
data ke dalam sebuah klausul kunci yang akan digunakan pada file named.conf, seperti yang ditunjukkan di sini:
kunci "example.com" (
alogorithm hmac-md5;
rahasia JuxDyYXIJhAia5WQe9oqUA ==;
);
The example.com kunci nama, yang dapat berupa string dikutip dan mengandung spasi, atau unquoted
jika tidak ada spasi, biasanya digunakan sebagai nama nama host dalam perintah dnssec-keygen,
seperti dalam kasus sebelumnya. Tergantung pada aplikasi, dapat setiap string yang berguna, sebagai
Selama klausa nama kunci yang sama digunakan oleh kedua belah pihak dalam transaksi. Dalam kasus contoh,
kedua belah pihak (tuan dan budak) berisi klausa kunci dengan example.com nama, seperti yang disajikan dalam
contoh fragmen yang mengikuti. Nama klausa kunci bisa saja "transfer-kunci" kalau
lebih bermakna; lagi, nama klausa kunci yang sama harus digunakan oleh kedua belah pihak. Untuk TSIG sebuah
transaksi, tidak ada hubungan yang diperlukan antara nama yang digunakan dalam argumen-n dari
dnssec-keygen utilitas dan nama klausa utama. Nama didefinisikan pada klausa kunci dikirim
di meta TSIG (atau pseudo) RR dengan setiap transaksi aman untuk mengidentifikasi rahasia bersama yang
digunakan. Jika nama tombol klausa tidak sama di masing-masing pihak, maka transaksi tersebut akan gagal dengan BADNAME
kesalahan. Garis algoritma kunci mengidentifikasi klausa algoritma yang digunakan (hmac-md5 sebagai
didefinisikan dalam perintah dnssec-keygen). Data berikut rahasia adalah salinan data dari
baris kunci dari Kexample.com 157 31.313.. file, swasta diakhiri dengan titik koma. Kunci ini
klausa harus disimpan sebagai file-panggilan kita akan terpisah itu example.com.key-dan ditempatkan di direktori
kami akan menelepon / var / named / kunci dan termasuk dalam file named.conf. File ini, yang berisi sharedsecret
klausa utama, sekarang harus dibuat tersedia melalui suatu proses yang aman (seperti floppy disk,
aman e-mail, atau layanan aman lainnya), ke server budak atau server. Karena file ini berisi
data yang sangat sensitif itu harus segera dijamin pada master dan budak sedemikian rupa sehingga dapat
hanya dibaca dengan UID BIND. Perintah untuk mengamankan file sesuatu yang terlihat seperti ini:
chown bernama: bernama / var / named / tombol / example.com.key
chmod 0400 / var / named / tombol / example.com.key
Perintah sebelumnya berasumsi bahwa BIND sedang dijalankan dengan argumen-u (sebagai
diuraikan sebelumnya dalam bab ini) dan memungkinkan BIND's UID akses baca ke file. Namun,
user root bisa baik membaca dan menulis seperti biasa jika diperlukan modifikasi lanjutan. Atau,
Anda dapat menggunakan pengaturan chmod dari 0.600 dan memungkinkan mengedit semua bisa dilakukan dibawah UID BIND
jika Anda memiliki keberatan mendalam untuk menggunakan root untuk sesuatu yang tidak penting.
Catatan UID? Diasumsikan bernama, seperti yang ditunjukkan pada contoh sebelumnya. dinamakan nilai normal
digunakan dengan Linux dan Windows. Namun, FreeBSD biasanya menggunakan UID mengikat.
Melihat file Kexample.com 157 31313.. Kunci menunjukkan teks berikut:
example.com. KUNCI DALAM 512 3 157 JuxDyYXIJhAia5WQe9oqUA ==
Ini adalah KUNCI DNS-siap RR berisi kunci bersama-rahasia! Hal ini dihasilkan sebagai artefak
standar pengolahan dnssec-keygen; sayangnya, tidak ada cara untuk mencegahnya. RR KUNCI adalah
pernah digunakan dengan algoritma bersama-rahasia dan harus tidak dalam kondisi apapun dapat ditambahkan ke
file zona. Sebaliknya, hanya named.conf file klausa kunci berisi kunci bersama-rahasia yang digunakan
secara mandiri oleh kedua ujung selama komunikasi, seperti digambarkan pada Gambar 10-7. Setelah tombol
klausul didirikan pada kedua tuan dan budak, baik aman Kexample.com 157 31313.. kunci
dan Kexample.com 157. 31.313. swasta, atau lebih baik lagi, menghapus file-file ini benar-mereka tidak akan
digunakan lagi dan merupakan suatu sakit kepala keamanan tambahan.
File named.conf pada master akan terlihat seperti fragmen berikut:
/ / Named.conf example.com master fragmen
logging (
saluran normal_log (
file "/ var / log / bernama / normal.log" versi 3 ukuran 2m;
keparahan kesalahan;
print-time yes;
print-beratnya ya;
print-kategori ya;
);
saluran dnssec_log (/ / log streaming dnssec
file "/ var / log / bernama / dnssec.log" versi 3 ukuran 2m;
keparahan debug 3;
print-time yes;
print-beratnya ya;
print-kategori ya;
);
kategori default (
normal_log;
);
Kategori dnssec (
dnssec_log;
);
);
Pilihan (
....
direktori "/ var / named";
dnssec-aktifkan ya;
....
);
/ / Menyertakan klausul kunci untuk nama kunci example.com
termasuk "kunci / example.com.key"; / / menyertakan klausa kunci
/ / Referensi klausa klausa server kunci termasuk di atas
server 10.1.2.3 (
tombol ("example.com";); / / nama yang digunakan dalam ayat kunci
);
....
zone "example.com" di (
jenis master;
file "master.example.com";
/ / Hanya mengijinkan transfer jika kunci (TSIG) hadir
memungkinkan transfer (key "example.com";);
);
....
Untuk membantu dalam pengujian dan eksperimen, log tersebut telah dialirkan untuk log peristiwa DNSSEC
secara terpisah, seperti yang ditunjukkan dalam bagian sebelumnya. Tingkat keparahan debug 3; garis menghasilkan berlebihan
jumlah logging dan harus digunakan selama pengujian saja. Dalam lingkungan produksi, ini
nilai dapat diatur untuk info keparahan, atau lebih tinggi. DNSSEC tidak diaktifkan secara default di BIND. Itu
dnssec mengaktifkan ya; pernyataan harus ditempatkan pada klausa opsi global untuk menjalankan fitur tersebut.
Klausa utama yang terdapat dalam file kunci / example.com.key harus muncul sebelum dirujuk dalam
klausa server, seperti yang ditunjukkan dalam bagian sebelumnya. Klausa IPv4 yang mendefinisikan server
alamat server budak untuk example.com, dan laporan kunci dalam klausa referensi
klausa kunci berisi kunci rahasia untuk digunakan. Pernyataan memungkinkan transfer di zona klausa
untuk example.com adalah alamat-konstruksi pertandingan daftar menggunakan pilihan tombol (lihat bagian dalam
Bab 12, "BIND Definisi address_match_list") dan memberikan linkage untuk memvalidasi masuk
TSIG pesan. Budak server file named.conf yang sesuai terlihat seperti yang
yang ditampilkan di sini:
/ / Named.conf example.com budak fragmen
Pilihan (
....
direktori "/ var / named";
dnssec-aktifkan ya;
....
BAB 10? Konfigurasi DNS AMAN 269
termasuk "kunci / example.com.key"; / / menyertakan klausa kunci
server 10.1.2.5 (
tombol ("example.com";); / / nama yang digunakan dalam ayat kunci
);
....
zone "example.com" di (
jenis budak;
file "slave.example.com";
master (10.1.2.5;);
);
Kembali tombol klausa termasuk dari tombol file / example.com.key (ingat baik
sisi berbagi kunci ini) dan harus muncul sebelum dirujuk dalam klausa server,
yang dalam hal ini adalah alamat IPv4 dari master zona untuk example.com. Pernyataan para empu
pada klausa zona untuk example.com berisi alamat IPv4 menghubungkannya ke server
klausa. Hal ini memicu inisiasi dari urutan otentikasi menggunakan tombol didefinisikan
pernyataan. Meskipun laporan master dapat berisi opsi kunci dalam kasus ini, karena
budak memulai permintaan untuk transfer zona itu harus tahu ke mana harus mengirimkannya, sehingga menggunakan
Alamat IP. Pernyataan memungkinkan transfer terkait dalam fragmen master zona dapat
menggunakan Format kunci karena menanggapi permintaan tersebut.
Bagi mereka dengan rasa ingin tahu yang tak pernah puas, mungkin akan bermanfaat untuk melihat zona yang dihasilkan
transfer dengan aplikasi sniffer yang cocok (lihat Bab 15). A meta (atau pseudo) RR disebut
TSIG, berisi MAC untuk setiap transaksi, dan dengan nama shared-kunci rahasia
klausa ditempatkan di BAGIAN TAMBAHAN dari permintaan dan respon (lihat Bab 13 untuk
penjelasan dari RRS meta). Dalam hal ini, respon adalah zona transfer (AXFR). TSIG ini
RRS dibuang begitu pesan telah diverifikasi, yaitu, mereka tidak disimpan sebagai bagian dari
zona transfer data.
Catatan RR KUNCI? Dihasilkan sebagai bagian dari proses dnssec-keygen (yang terkandung dalam file. Key) digunakan
dalam sistem kunci publik saja. Ketika bersama-teknik rahasia menggunakan seperti TSIG, RR KUNCI adalah menjengkelkan
dan artefak berbahaya, dan tidak harus ditempatkan di file zona DNS. Kecuali ada alasan-alasan yang baik untuk tidak,
itu harus segera dihapus.
Mengamankan Pembaharuan Dinamis
Dynamic DNS (DDNS) didefinisikan dalam RFC 3007 dan 2136, dan menggambarkan suatu proses dimana
RRS untuk zona dapat ditambahkan, dihapus, dan dimodifikasi oleh pihak ketiga. Namun, zona tidak dapat
dihapus atau ditambahkan dengan menggunakan proses ini. Untuk menjamin konsistensi data zona, pembaruan dinamis
hanya dilakukan pada server master utama, yang didefinisikan sebagai server nama yang
muncul di RR SOA untuk zone (bidang MNAME). Default BIND adalah untuk melarang dinamis
pembaruan dari semua alamat IP. Dynamic memperbarui adalah kemampuan yang kuat, dan banyak situs menggunakan
secara ekstensif untuk memungkinkan pelanggan untuk mengedit data zona mereka secara langsung, dan dalam beberapa kasus untuk menyinkronkan
Dynamic Host Control Protocol (DHCP) dengan kedua maju dan mundur file pemetaan
secara otomatis. Seperti dengan semua positif, ada akses: negatif atas tidak bermoral
oleh pihak ketiga berbahaya dapat merusak atau racun file zona. Seperti yang dinyatakan sebelumnya, tidak mengamankan
DDNS kecuali jika terjadi di balik perimeter aman dan antara orang dewasa merupakan
ketergantungan yang berlebihan pada kebaikan esensial umat manusia. Hal ini penting untuk mengamankan DDNS. Itu
cara paling sederhana untuk mengamankan DDNS adalah melalui penggunaan pembatasan berbasis IP. Fragmen berikut
menggunakan pernyataan BIND yang memungkinkan-update untuk membatasi akses:
/ / Named.conf fragmen
logging (
saluran normal_log (
file "/ var / log / bernama / normal.log" versi 3 ukuran 2m;
keparahan kesalahan;
print-time yes;
print-beratnya ya;
print-kategori ya;
);
saluran security_log (/ / streaming log keamanan
file "/ var / log / bernama / security.log" versi 3 ukuran 2m;
keparahan info;
print-time yes;
print-beratnya ya;
print-kategori ya;
);
kategori default (
normal_log;
);
kategori keamanan (
security_log;
);
);
Pilihan (
....
);
....
zone "example.com di (
....
memungkinkan-update (10.1.2.5;); / / zona ini hanya
....
);
Fragmen konfigurasi sebelumnya menolak semua pembaruan yang dinamis dan selektif izin
host yang diijinkan berdasarkan per-zona. Sebagai contoh, alamat IP 10.1.2.5 adalah tunggal
diizinkan untuk melakukan update untuk zona example.com. Log dialiri untuk kegiatan keamanan
karena diasumsikan bahwa sebagai bagian dari strategi defensif, ada hal yang menarik untuk melihat mana
memperbarui permintaan datang dari. Jika perlu inspeksi, setelah file security.log, sebuah
klausa server dengan palsu ya, atau pernyataan blackhole dapat digunakan untuk menghentikan servis sepenuhnya
ke host yang gigih.
BAB 10? DNS AMAN Konfigurasi
Mengingat situasi yang tepat, alamat IP dapat palsu, yang dapat berakibat buruk
orang melakukan hal-hal nakal ke file zona master. Untuk mencegah kemungkinan tersebut, dinamis update
dapat diamankan melalui penggunaan teknik kriptografi untuk memastikan baik otentikasi
(Tuan dan budak adalah yang mereka katakan), dan integritas data (data yang diterima oleh
master diperbarui adalah sama dengan data yang dikirim oleh klien melakukan update).
Kedua TSIG dan SIG (0) metode ini didukung oleh nsupdate utilitas yang disediakan dengan BIND
rilis dan diuraikan dalam Bab 9. Pelaksanaan kedua TSIG dan SIG (0) metode adalah
dijelaskan dalam bagian berikut.
Konfigurasi DDNS TSIG
TSIGs menggunakan Message Authentication Code (MAC) dengan berbagi rahasia baik untuk mengotentikasi
dan menjamin integritas data dari setiap transaksi yang terlibat dalam pembaruan dinamis antara
primer master dan sumber pembaruan. Metode menghasilkan rahasia bersama adalah persis
sama seperti yang didefinisikan untuk bagian sebelumnya "TSIG Konfigurasi", dan tidak diulang lagi di sini.
Berbagi rahasia tidak dibagi dengan server nama lain dalam kasus ini, tapi dengan sumber
pembaruan yang dinamis, misalnya, utilitas nsupdate. Sekali lagi, sangat penting bahwa RRS KUNCI dihasilkan
sebagai bagian dari proses dnssec-keygen tidak harus ditambahkan ke file zona. Bila menggunakan
bersama-rahasia algoritma seperti TSIG, klausa kunci atau klausa dalam named.conf file-yang
diasumsikan tidak menjadi file publik-toko kunci rahasia.
Catatan Hal ini dimungkinkan untuk menggunakan kunci rahasia bersama-sama untuk melakukan update dinamis baik dan transfer zona?
otorisasi, terutama jika host yang sama digunakan untuk kedua operasi. Namun, secara umum, yang terpisah
rahasia bersama harus digunakan untuk setiap pasangan tuan rumah karena ini untuk meminimalkan paparan kunci dikompromikan.
named.conf File fragmen untuk mendukung pembaruan yang dinamis ditampilkan dalam berikut
kode, menggunakan baik memungkinkan-update dan laporan update-kebijakan:
/ / Named.conf example.com master fragmen
logging (
saluran normal_log (
file "/ var / log / bernama / normal.log" versi 3 ukuran 2m;
keparahan kesalahan;
print-time yes;
print-beratnya ya;
print-kategori ya;
);
saluran dnssec_log (/ / log streaming dnssec
file "/ var / log / bernama / dnssec.log" versi 3 ukuran 2m;
keparahan debug 3;
print-time yes;
print-beratnya ya;
print-kategori ya;
);
kategori default (
normal_log;
);
Kategori dnssec (
dnssec_log;
);
);
Pilihan (
....
direktori "/ var / named";
dnssec-aktifkan ya;
....
);
termasuk "kunci / example.com.key"; / / menyertakan klausa kunci
server 10.1.2.3 (
tombol ("example.com";); / / nama yang digunakan dalam ayat kunci
);
....
zone "example.com" di (
jenis master;
file "master.example.com";
memungkinkan-update (key "example.com";);
);
....
zona "example.net" di (
jenis master;
file "master.example.net";
update-kebijakan (hibah example.com subdomain example.net APAPUN;);
update-kebijakan (hibah * A * diri;);
update-kebijakan (hibah fred.example.net nama example.net MX;);
);
....
Untuk membantu dalam pengujian, log telah dialirkan untuk log peristiwa dnssec secara terpisah, seperti yang ditunjukkan
dalam bagian sebelumnya. Tingkat keparahan debug 3; garis menghasilkan jumlah berlebihan penebangan
dan harus digunakan selama pengujian saja. Dalam sistem produksi, nilai ini dapat diatur untuk tingkat keparahan
info; atau lebih tinggi. DNSSEC tidak diaktifkan secara default di BIND, sehingga mengaktifkan dnssec ya; pernyataan
harus ditempatkan dalam klausul opsi global untuk menjalankan fitur tersebut. Update-memungkinkan
klausa pernyataan dalam zona untuk example.com menggunakan opsi kunci yang address_match_list
untuk mengizinkan update ke file zone example.com. Klausa zona untuk example.net menggunakan
laporan update-kebijakan untuk memberikan kontrol ketat atas apa yang dapat dilakukan dan oleh siapa. Yang pertama
Pernyataan update-kebijakan memungkinkan suatu transaksi TSIG dengan example.com nama untuk memperbarui apapun
catatan dalam file example.net zona. Subdomain kata kunci berarti bahwa parameter berikut,
dalam kasus ini example.net, diperlakukan sebagai nama dasar. Setiap nama yang mencakup atau berakhir dengan
example.net pertandingan, misalnya, joe.example.net berakhir dengan example.net dan oleh karena itu
itu cocok, karena akan RR MX untuk domain tersebut. Pernyataan update-kebijakan kedua memungkinkan setiap
TSIG transaksi dengan nama, misalnya, bill.example.net dan yang ada klausa kunci dengan
nama yang sama (bill.example.net) untuk memperbarui hanya RR A dengan nama bill.example.net.
Klausa kunci tambahan tidak ditampilkan pada contoh, tapi ini membangun memerlukan klausa kunci
dan rahasia bersama yang unik untuk setiap kemungkinan A RR yang dapat diperbarui. Update akhir-kebijakan
pernyataan mengatakan bahwa transaksi TSIG dengan nama fred.example.net diizinkan untuk meng-update
hanya RR MX (s) untuk example.net domain.
Untuk memperkuat proses pembuatan kunci untuk aplikasi berbagi-rahasia, berikut
menunjukkan urutan penciptaan rahasia bersama untuk fred.example.com. Berbagi rahasia ini digunakan
dalam laporan update-kebijakan terakhir pada klausa zona untuk example.net dalam bagian sebelumnya.
Gunakan perintah berikut untuk menghasilkan kunci:
dnssec-keygen-a hmac-md5-b 128-n fred.example.net host
Setelah selesai, perintah meresponnya dengan identifier file seperti berikut:
Kexample.com. 157 32.713
Buat klausa kunci baru dengan nama fred.example.net menggunakan data dari Kunci:
baris dari file bernama Kexample.com 157 32713.. swasta, seperti yang ditunjukkan di sini:
kunci "fred.example.net" (
alogorithm hmac-md5;
rahasia 7aBDy3XIJhA775WQ4FoqUA ==;
);
Tambahkan klausa kunci example.com.key berkas yang telah ada, yang berisi kunci asli
klausa kami menciptakan, atau membuat file baru dan menambahkan termasuk baru pernyataan dalam named.conf.
Akhirnya, jika data tersebut akan ditambahkan ke file yang ada atau file yang baru dibuat, ingatlah untuk memeriksa
bahwa file permissions hanya membolehkan membaca, atau membaca dan menulis hanya akses, untuk BIND UID.
Untuk mengilustrasikan proses update dinamis dalam tindakan, contoh menggunakan utilitas nsupdate
disertakan dengan semua BIND rilis. Dalam hal ini, kita gunakan tombol example.com, yang dapat memperbarui
baik example.net example.com dan file zona. Sebelum invoking utilitas nsupdate, yang
file Kexample.com 31.313 157.. swasta dan Kexample.com. 157 31313. perlu kunci yang akan dipindahkan
dengan proses yang aman ke dalam direktori kerja yang sesuai pada host yang akan berjalan nsupdate yang
utilitas. Dalam hal ini kita asumsikan direktori adalah / var / named / dinamis.
Catatan Ingat? Dari sebelumnya bahwa bila menggunakan berbagi rahasia, file yang berisi RR KUNCI (di sebelumnya
157 Kexample.com 32.713 kasus.. kunci), yang dihasilkan secara otomatis oleh utilitas dnssec-keygen,
tidak harus ditambahkan ke file zona. Namun, file ini diperlukan oleh utilitas nsupdate karena alasan operasional.
Setelah aman ditransfer ke host atau host, itu harus dihapus dari host master utama.
Urutan berikut menambahkan RR baru A ke zona example.com dan example.net:
# Cd / var / named / dinamis
# Nsupdate-k Kexample.com 157 31313.. Swasta
> Server ns1.example.com
> Zona example.com
> Update menambahkan baru 36.000 DALAM 192.168.5.4
> Mengirimkan
> Menunjukkan
Outgoing query update:
;; ->> Header <<- opcode: UPDATE, status: NOERR id: 0
;; Bendera:; ZONE: 0, PREREQ: 0, UPDATE: 0, TAMBAHAN: 0
> Zona example.net
> Update menambahkan another.example.net. 36000 IN A 192.168.7.15
> Mengirimkan
> Berhenti
Contoh sebelumnya menunjukkan menambahkan RR A untuk setiap domain example.com dan
example.net. File utama yang digunakan dengan utilitas nsupdate memiliki nama example.com, yang
memiliki izin untuk memperbarui kedua example.com (melalui pernyataan memungkinkan-update pada contoh
named.conf fragmen) dan example.net (melalui laporan update-kebijakan pertama). menggali A
perintah dapat digunakan untuk memverifikasi bahwa RRS baru telah tersedia, seperti terlihat di sini:
# Dig@192.168.5.12 new.example.com A
; <<>> Dig 9.3.0 <<>> @ 192.168.5.12 new.example.com A
;; Global pilihan: printcmd
;; Got jawaban:
;; ->> Header <<- opcode: QUERY, status: NOERROR, id: 1082
;; Bendera: qr aa rd ra; QUERY: 1, JAWABAN: 1, KEWENANGAN: 2, TAMBAHAN: 2
;; PERTANYAAN BAGIAN:
; New.example.com. DALAM
;; JAWABAN BAGIAN:
new.example.com. 36000 IN A 192.168.5.4
;; KEWENANGAN BAGIAN:
example.com. 86400 IN NS ns1.example.com.
example.com. 86400 IN NS ns2.example.com.
;; TAMBAHAN BAGIAN:
ns1.example.com. 86400 IN A 192.168.5.12
ns2.example.com. 86400 IN A 192.168.5.11
;; Query time: 15 msec
;; SERVER: 192.168.5.12 # 53 (192.168.5.12)
;; KAPAN April: Thu 07 21:59:48 2005
;; MSG SIZE rcvd: 124
Output sebelumnya menegaskan bahwa update ke domain example.com berhasil
dan segera tersedia pada master utama. Proses update secara otomatis menambahkan
1 untuk bidang urutan jumlah RR SOA. Kecuali dinonaktifkan oleh pernyataan named.conf,
sebuah NOTIFY dikirim ke server untuk zona budak, dan pembaruan tersebut mengalir ke semua budak
server dalam hitungan menit.
Catatan Perlu mengingatkan pembaca bahwa sekali update dinamis dipanggil, file zona tidak boleh?
update secara manual karena pada awalnya ditulis untuk file jurnal (zone.file.name.jnl), dan zona
file hanya secara periodik diperbaharui. Jika pengeditan manual diperlukan, maka baik berhenti BIND dan melakukan mengedit, atau
gunakan perintah rndc flush, diikuti oleh zone.name beku; melakukan edit manual, dan kemudian mencair
zone.name. Dalam kedua kasus, zona itu. Jnl file harus dihapus sebelum salah satu BIND restart atau menerbitkan
mencairkan perintah rndc untuk memastikan konsistensi berikutnya.
SIG (0) Konfigurasi
Utilitas nsupdate juga mendukung SIG (0) otentikasi dan memeriksa integritas data melalui
penggunaan tanda tangan digital, yang didasarkan pada teknologi kunci publik. Teknologi kunci publik
memiliki keuntungan bahwa tidak ada tindakan khusus yang diperlukan untuk mendistribusikan kunci publik. Mereka hanya
ditempatkan sebagai KUNCI RRS di file zona, dan dapat dibaca oleh siapapun, karena tanpa mencocokkan
kunci pribadi mereka tidak berguna. Dalam urutan update, master zona menggunakan kunci publik. Itu
klien melakukan update menggunakan kunci pribadi untuk menghasilkan tanda tangan, yang diverifikasi
oleh zona menerima master utama. Jika respon terenkripsi diperlukan, server menggunakan
kunci publik untuk menandatangani respon, yang pada gilirannya diverifikasi menggunakan kunci pribadi dari memperbarui
klien. Kelemahan dari teknologi kunci publik adalah bahwa ia menggunakan sumber daya CPU secara signifikan lebih
dari teknologi bersama-rahasia. Jika volume update mungkin pada server sibuk, maka penggunaan
SIG (0) mungkin memerlukan pertimbangan cermat. Selama distribusi kunci dan manajemen
masalah yang berkaitan dengan rahasia dapat ditangani bersama, TSIG mungkin pilihan yang lebih baik. Istilah
SIG (0) dapat sedikit membingungkan, karena ada SIG RR tipe yang dilakukan fungsi
mirip dengan RRS RRSIG saat ini digunakan dalam konfigurasi DNSSEC. Namun, SIG (0) RR digunakan
untuk mengamankan transaksi adalah meta (atau pseudo) RR tipe yang dinamis dibuat oleh pengirim
aplikasi atau server dan ditambahkan ke BAGIAN TAMBAHAN transaksi (lihat Bab 15).
SIG (0) RR dibuang segera setelah verifikasi. Secara khusus, tidak di-cache atau ditambahkan
ke file zona. Bentuk RR SIG secara unik diidentifikasi oleh memiliki tipe 0 di bidang label
(Lihat bagian "SIG RR" dalam Bab 13), dan karenanya memiliki nama SIG (0).
Kunci pribadi dan publik untuk SIG (0) transaksi dibuat menggunakan keygen-dnssec
utilitas (lihat Bab 9). Karena klien bahwa update zona menggunakan kunci pribadi, pembangkitan kunci
harus dilakukan pada host ini. Jika hal ini tidak memungkinkan, file-file yang dihasilkan harus pindah ke
mesin klien menggunakan proses yang aman. Perintah-perintah ini menghasilkan sepasang / publik kunci pribadi
di direktori / var / named / tombol:
# Cd / var / named / tombol
#-Dnssec-keygen-b a rsasha1 update.example.com 512-k-n host
Dalam perintah dnssec-keygen sebelumnya,-sebuah rsasha1 menghasilkan tanda tangan digital menggunakan
algoritma RSA dengan SHA-1 message digest (utilitas dnssec-keygen mendukung DSA,
RSA-SHA-1, dan RSAMD5 metode kunci publik). B-512 argumen menunjukkan kunci itu akan
menjadi 512 bit panjang. Sebuah RSA-SHA-1 kunci mungkin dari 512 ke 2.048 bit. Semakin tinggi nomor tersebut,
kekuatan yang lebih besar kriptografi kunci, namun lebih CPU digunakan dalam enkripsi / dekripsi.
K-argumen menunjukkan bahwa jenis RR KUNCI diperlukan (bukan DNSKEY RR). N-host
menunjukkan sebuah host KUNCI RR akan dibuat dengan nama update.example.com. Setelah selesai,
perintah akan menampilkan pesan seperti ini:
Kupdate.example.com. 001 00.706
K adalah nilai tetap, update.example.com. adalah nama dari perintah dnssec-keygen, 001
menunjukkan algoritma (RSA-SHA-1), dan 00.706 adalah tag-kunci yang dihasilkan algorithmically
dan unik mengidentifikasi kunci pasangan ini. Inspeksi direktori / var / named / tombol menunjukkan
dua file:
Kupdate.example.com 001 00706.. Swasta
Kupdate.example.com 001 00706.. Kunci
File Kupdate.example.com 00706 001.. kunci berisi KUNCI RR tunggal dan terlihat sesuatu
seperti berikut:
update.example.com. KUNCI DALAM 512 3 1 (AQPL1jlhf70f9l1P / h
PFNMxU55IpkMX1O7EzvDk50rh0eM7xF + YQdQKD
brvR1rf6J8oTPFM2MM26sK98aj5MAsJX)
Data sebelumnya telah diedit untuk menyertakan bahan kunci dalam tanda kurung (memungkinkan
itu untuk dibagi di beberapa baris untuk alasan presentasi saja), tetapi muncul sebagai garis tunggal
dalam file. Ini adalah kunci publik yang terkait dengan pasangan / publik kunci pribadi, dan dapat dikirimkan
melalui metode apapun yang cocok untuk dimasukkan ke dalam zona file master untuk example.com, baik dengan memotong
dan paste, atau dengan menggunakan direktif $ TERMASUK. The Kupdate.example.com 001 00706.. Kunci file
berisi RR KUNCI adalah data publik dan tidak memerlukan penanganan khusus. Contoh berikut
menunjukkan penggunaan direktif $ TERMASUK dalam file zona untuk example.com. Ini mengasumsikan file. Kunci
ditempatkan di direktori / var / named / tombol pada host dari master zona untuk example.com:
; Example.com zona file fragmen
$ TTL 2d; zona TTL default 2 hari
$ ORIGIN example.com.
....
kunci $ TERMASUK / Kupdate.example.com 001 00706.. kunci; DDNS kunci
....
File named.conf pada master server utama sekarang harus diubah untuk memungkinkan zona
harus diperbarui menggunakan pernyataan update-kebijakan (memungkinkan pernyataan-update juga bisa
digunakan) pada klausa zona, seperti ditunjukkan pada contoh berikut:
/ / Named.conf fragmen
logging (
saluran normal_log (
file "/ var / log / bernama / normal.log" versi 3 ukuran 2m;
keparahan kesalahan;
print-time yes;
print-beratnya ya;
print-kategori ya;
);
saluran dnssec_log (/ / log streaming dnssec
file "/ var / log / bernama / dnssec.log" versi 3 ukuran 2m;
keparahan debug 3;
print-time yes;
print-beratnya ya;
print-kategori ya;
);
kategori default (
normal_log;
);
Kategori dnssec (
dnssec_log;
);
);
Pilihan (
....
direktori "/ var / named";
dnssec-aktifkan ya;
....
);
....
zone "example.com" IN (
jenis master;
file master.example.com;
update-kebijakan (hibah update.example.com subdomain example.com APAPUN);
);
Catatan Untuk membantu dalam pengujian, log tersebut telah mengalir untuk memberikan informasi tambahan tentang DNSSEC
peristiwa menggunakan keparahan debug 3;. Nilai ini tidak boleh digunakan dalam lingkungan produksi kecuali jika Anda
seperti file log besar. Pengaturan dari info keparahan; atau yang lebih tinggi harus digunakan. Karena DNSSEC tidak diaktifkan
secara otomatis, dnssec mengaktifkan ya; pernyataan harus hadir dalam klausul opsi global.
Pembaruan sebelumnya-kebijakan memungkinkan RR KUNCI dengan update.example.com nama untuk
update setiap RR dalam example.com domain. Pernyataan update-kebijakan berikut hanya memungkinkan
update.example.com untuk memodifikasi catatan NS untuk domain ini:
update-kebijakan (hibah subdomain update.example.com example.com NS);
Dengan seleksi yang seksama dari nama host saat kunci menghasilkan, kontrol halus dapat
dibuat pada biaya RRS beberapa kunci. Contoh berikut menggambarkan bagaimana menggunakan proses ini
untuk memungkinkan pengguna individual untuk mengubah hanya mencatat tuan rumah mereka sendiri. Zona fragmen file target
yang ditampilkan di sini:
; Example.com zona file fragmen
$ TTL 2d; zona TTL default 2 hari
$ ORIGIN example.com.
....
DALAM RUU 192.168.2.3
IN TXT "satu baik hari"
Bill.example.com DALAM RP.
fred IN A 192.168.2.4
Fred.example.com DALAM RP.
DI aaaa 2001: db8:: 15
....
Untuk mengontrol proses, dua masyarakat / pasangan kunci pribadi dengan nama host sebelumnya adalah
dihasilkan, seperti terlihat di sini:
#-Dnssec-keygen-b a rsasha1 bill.example.com 512-k-n host
#-Dnssec-keygen-b a rsasha1 fred.example.com 512-k-n host
Hal ini diasumsikan bahwa kunci yang dihasilkan pada masing-masing host dan bill.example.com
fred.example.com. KUNCI publik RRS termasuk dalam file zona, seperti yang ditunjukkan di sini:
; Example.com zona file fragmen
$ TTL 2d; zona TTL default 2 hari
$ ORIGIN example.com.
....
DALAM RUU 192.168.2.3
IN TXT "satu baik hari"
Bill.example.com DALAM RP. .
kunci $ TERMASUK / Kbill.example.com 001 77325.. kunci; tagihan KUNCI RR
fred IN A 192.168.2.4
Fred.example.com DALAM RP. .
DI aaaa 2001: db8:: 15
kunci $ TERMASUK / Kfred.example.com 001 08634.. kunci; fred KUNCI RR
....
The named.conf berikut update-kebijakan memastikan bahwa kunci yang sesuai dapat memperbarui hanya
perusahaan memiliki A, TXT, aaaa, dan catatan RP:
update-kebijakan (hibah * diri * A aaaa TXT) RP;
Yang * pertama menyatakan bahwa referensi ke RR KUNCI dengan nama yang sama (diri) sebagai catatan host
(Yang * kedua) diperbolehkan (hibah) untuk memperbarui A, aaaa, TXT, dan RP RRS hanya dengan host yang sama
nama. Dengan demikian, pembaruan masuk dengan nama bill.example.com (referensi RR KUNCI dari
bill.example.com) hanya diperbolehkan untuk memperbarui atau menambahkan A, aaaa, RP, atau TXT RRS dengan tuan rumah
nama bill.example.com. Demikian pula, jika update menggunakan nama fred.example.com, dapat
hanya memperbarui jenis RR didefinisikan yang memiliki nama host dari fred.example.com.
Setelah diselewengkan untuk kepentingan pribadi untuk menutupi penggunaan update-kebijakan, sekarang saatnya untuk kembali ke asli
kunci publik contoh. File Kupdate.example.com 00706 001.. swasta, yang terletak di
klien bahwa update file zona, terlihat seperti ini:
Swasta-kunci-format: v1.2
Algoritma: 1 (RSA)
Modulus: y9Y5YX 9 H/ZdT/4TxTTMVOeSKZDF9TuxM7w5OdK4dHjO8RfmEH
UCg2670da3 + ifKEzxTNjDNurCvfGo + TALCVw ==
PublicExponent: Aw ==
PrivateExponent: h + QmQP / TaqQ + NVQNLiMy40UMG7XZTifLd9L
Q0TclovoCO/y4wq3QNg4jNa5kb4Y4UQfx/2HcK84HrM/T66fzew ==
Prime1: / sRMFcz/OnBnuueuvvQi4SCKlKSCi1loWgPTHsmKLZ0 =
Prime2: zNLQux9xD8HxzBmiYl67lHkl05KbeB + TSfVfYaD8p4M =
Exponent1: qdgyuTNU0aBFJ0UfKfgXQMBcYxhXB5DwPAKMvzEGyRM =
Exponent2: iIyLJ2pLX9ahMrvBlunSYvtujQxnpWpiMU4/lmtTGlc =
Koefisien: S5di + sst/DCqT5MSNaiNLPN0DJWRjxivgkiifB7DPl4 =
Sejumlah baris sebelumnya telah terpecah di lebih dari satu baris untuk presentasi
alasan saja. File ini berisi kunci pribadi dari pasangan / publik dan kunci pribadi hanya
digunakan oleh utilitas nsupdate. Ini harus segera dijamin untuk izin read-only bawah
UID dari pengguna yang akan melakukan update dinamis. Untuk keperluan ilustrasi, itu
diasumsikan bahwa nama pengguna yang akan melakukan update adalah updater, dengan nama kelompok
pengguna. Perintah-perintah berikut mengamankan file kunci pribadi dan.. Di / var / named / dinamis:
# Chown-R updater: users / var / named / dinamis / *
# Chmod-R 0400 / var / named / dinamis / *
Untuk memanggil dan menguji SIG (0) proses update dinamis, utilitas nsupdate dipanggil dan
urutan berikut ini digunakan untuk menambahkan MX record dan yang sesuai dengan A RR untuk domain
example.com:
# Cd / var / named / dinamis
# Nsupdate-k Kexample.com 001 00706.. Swasta
> Server ns1.example.com
> Zona example.com
> Update menambahkan example.com. 36000 IN MX 10 mail2.example.com.
> Mengirimkan
> Menunjukkan
Outgoing query update:
;; ->> Header <<- opcode: UPDATE, status: NOERR id: 0
;; Bendera:; ZONE: 0, PREREQ: 0, UPDATE: 0, TAMBAHAN: 0
update> menambahkan A 192.168.2.5 mail2 IN 36000
> Mengirimkan
> Menunjukkan
Seperti contoh TSIG, perintah menggali dapat dikeluarkan untuk memverifikasi bahwa MX dan A RRS
tersedia di master utama. Dengan menunjuk perintah menggali di server budak, yang
update bertingkat, dimulai dengan pesan NOTIFY, juga bisa diverifikasi.
Hal ini dimungkinkan untuk mencampur TSIG dan SIG (0) klien update dinamis jika itu membuat operasional
akal. Hal ini juga mungkin untuk mendukung TSIG untuk transfer zona dan SIG (0) untuk update dinamis
operasi, atau kombinasi tersebut.
Ringkasan
Bab ini memperkenalkan keamanan DNS dengan mengelompokkan topik menjadi administrasi keamanan,
zona transfer, update dinamis, dan integritas zona. Tiga pertama Topik yang dibahas dalam
bab; zona integritas menggunakan DNSSEC.bis dijelaskan di Bab 11.
Diskusi keamanan meliputi seleksi administrasi dan konfigurasi DNS
server dan memperbarui perangkat lunak dibahas, membatasi fungsi, membatasi izin (termasuk
sandboxes atau penjara chroot), log streaming, dan penggunaan berbagai sumber baik OS dan DNS
perangkat lunak untuk mengurangi risiko dalam menjalankan sistem DNS. Instalasi paket dari
penjara chroot di Linux Fedora Core 2 dan FreeBSD digambarkan, serta instalasi manual
dari sebuah penjara chroot dengan tidak adanya paket yang tersedia.
Bab ini menggambarkan penggunaan teknik kriptografi untuk mengamankan berbagai transaksi.
Berbagai teknik digambarkan secara garis besar untuk pembaca terbiasa dengan umum kriptografi
proses, termasuk simetris (bersama-rahasia) sistem, asimetris (public-key)
sistem, mencerna pesan, Mac, dan tanda tangan digital.
Penggunaan laporan BIND sederhana untuk mengamankan transfer zona dengan menggunakan alamat IP dan
penggunaan TSIG (bersama-rahasia) untuk mengamankan transaksi transfer zona digambarkan dan diilustrasikan
dengan file contoh.
Bab ini menggambarkan, dengan contoh-contoh, penggunaan BIND perintah untuk mengamankan dinamis
update menggunakan alamat IP. Kedua SIG (0), dengan menggunakan teknik kriptografi kunci publik atau asimetris,
dan TSIG (bersama-rahasia) metode untuk mengamankan update dinamis digambarkan dan
lagi diilustrasikan dengan contoh dan file konfigurasi.
Bab selanjutnya menjelaskan maksud desain dan implementasi DNSSEC (bahasa sehari-hari
disebut sebagai DNSSEC.bis) untuk memastikan sumber dan integritas data zona selama normal
operasi query.
BAB 10? Konfigurasi DNS AMAN 281
DNSSEC
Ketika nama server menerima respons atas permintaan untuk, misalnya, catatan A dari sebuah situs web, untuk
misalnya, www.example.com, hanya bisa berharap bahwa data yang benar. Tidak memiliki cara untuk membuktikan bahwa
hal ini terjadi, dan sebenarnya bisa saja ditipu atau palsu dalam berbagai cara. Misalnya,
respon permintaan mungkin telah disuplai dari zona file beracun, atau mungkin permintaan
telah dicegat dan data buruk diganti di respon. Kemungkinan lain adalah permintaan dapat
telah dialihkan ke server palsu untuk domain yang bersangkutan, atau respons dapat
sempurna yang valid, data yang mengandung baik dari sumber yang benar. Dalam situasi di mana pendapatan,
reputasi, atau keamanan (yaitu, komersial atau nasional) yang dipertaruhkan, ketidakpastian tersebut dapat
tidak dapat diterima. DNSSEC dirancang untuk menghilangkan keraguan yang terlibat dalam operasi query DNS
dengan memberikan kepastian untuk diverifikasi sesuai nama server dikonfigurasi dan awalnya didefinisikan
di RFC 2535. upaya yang signifikan telah dikeluarkan selama beberapa tahun terakhir oleh banyak organisasi,
terutama ISC (www.isc.org), Nlnetlabs (www.nlnetlabs.nl), beberapa server-root
operator (www.root-servers.org), dan Regional Internet Registries (www.nro.net), untuk membangun dan
pengujian sistem aman DNS seperti yang mereka dapat diskalakan dan ditempatkan di lingkungan operasional.
Sejumlah besar RFC telah diterbitkan pada topik DNSSEC, menjelaskan banyak sangat
khusus poin pelaksanaan dan penggunaan. Upaya ini sangat sukar telah menyebabkan apa yang sekarang bahasa sehari-hari
disebut DNSSEC.bis (didefinisikan oleh RFC 4033, 4034, dan 4035) dan merupakan substansial
perangkat tambahan dengan spesifikasi asli. Bab ini dimulai dengan menggambarkan desain
DNSSEC.bis diikuti dengan contoh yang menggambarkan berbagai proses yang terlibat dalam mengamankan dan
DNSSEC mempertahankan sistem.
Catatan akhiran "?. Bis" secara luas digunakan dalam standar dunia dan berarti versi kedua
standar. Sisa bab ini akan menggunakan istilah DNSSEC tidak DNSSEC.bis untuk memperjelas hal bahwa
proses dan prosedur yang dijelaskan di sini merupakan saat-standar IETF RFC sebelum semua yang berhubungan dengan
DNSSEC dibuat usang oleh RFC 4033, 4034, dan 4035. Kedua BIND (rilis 9,3 +-lihat www.isc.org)
dan NSD (rilis 2,3 +-lihat www.nlnetlabs.nl / nsd) dukungan DNSSEC.bis.
Lingkungan DNSSEC
DNSSEC mendefinisikan sebuah proses dimana nama server dikonfigurasi sesuai dapat memverifikasi keaslian
dan integritas hasil query dari sebuah zona ditandatangani. Kunci publik (atau asimetris) kriptografi
dan satu set khusus Resource Records (RRS), khusus Resource Record Signatures (RRSIGs),
283
DNSKEY, dan Next Secure (NSEC) RRS, digunakan oleh DNSSEC.bis untuk mengaktifkan keamanan-sadar
menerima server nama untuk melakukan hal berikut:
• Otentikasi bahwa data yang diterima hanya bisa berasal dari zona yang diminta.
• Verifikasi integritas data. Data yang diterima di server nama query
adalah data yang dikirim dari tanya bernama server. Isi data yang dilindungi,
bukan saluran komunikasi.
• Verifikasi bahwa jika sebuah respons negatif (NXDOMAIN) diterima untuk permintaan tuan rumah, yang menargetkan
catatan tidak ada (bukti disebut noneksistensi dan kadang-kadang penolakan keberadaan).
Item pertama untuk dicatat di sini adalah bahwa untuk mendukung DNSSEC, kedua sumber otoritatif zona
(Master dan slave) dan server nama penerima harus dikonfigurasi untuk mendukung DNSSEC. Itu
server nama otoritatif harus sign cryptographically data zona dan menjadi dalam jargon
Secure Entry Point (SEP), dan server nama penerima harus dikonfigurasi untuk mendukung
layanan keamanan dan yang dikatakan dalam jargon yang akan keamanan sadar.
Pulau di Keamanan
Tidak masuk akal untuk menduga bahwa setiap server nama di dunia semalam akan dikonfigurasi
untuk mendukung DNSSEC atau bahwa setiap zona di dunia akan dijamin. Gambar 11-1 menunjukkan
mungkin konfigurasi yang bisa ada dan bahwa standar-standar DNSSEC harus menangani.
Gambar 11-1 mengasumsikan bahwa domain berwarna aman. Server keamanan-sadar nama
(NS1) harus terus memberikan hasil query untuk semua domain termasuk domain aman
example.com dan 168.192.in-addr.arpa, dan ini termasuk melewati domain yang aman
dari example.com untuk mendapatkan hasil untuk subdomain tidak aman dari sub.example.com. Sama dengan
keamanan-sadar nama server (NS2 adalah nama server yang tidak dikonfigurasi untuk pengamanan DNSSEC)
harus terus mendapatkan hasil yang transparan untuk semua domain, aman dan tidak aman.
NS1 dikonfigurasi untuk menjadi keamanan sadar oleh-dnssec memungkinkan ya; pernyataan dalam sebuah global
Pilihan klausa, yang menyebabkan server nama untuk mengiklankan kesadaran keamanan dengan termasuk
suatu OPT meta (atau pseudo) RR di bagian tambahan dari setiap pertanyaan dengan OK DNSSEC (DO)
bit set (lihat Bab 15 untuk informasi lebih lanjut). Sebaliknya, ada pertanyaan tanpa kedua karakteristik
dikatakan keamanan tidak menyadari. Jika sumber otoritatif zona (master atau slave) untuk example.com
menerima permintaan yang menunjukkan si pengirim adalah keamanan sadar (NS1 di skenario Gambar 11-1),
akan meresponnya dengan informasi keamanan tambahan seperti RRS RRSIG yang memungkinkan yang diminta
RRS untuk disahkan. Jika nama server menerima permintaan dari nama keamanan-sadar
server (NS2 di skenario Gambar 11-1), akan meresponnya tanpa informasi keamanan. Dalam terakhir
kasus, hasil query akan persis sama pasti tidak disertakan jika server
adalah keamanan sadar (yaitu, keamanan tidak terlihat).
kriptografi kunci publik bergantung pada pasangan kunci publik dan swasta (lihat Bab 10 untuk penjelasan
dari crytography kunci publik). Zona di example.com adalah cryptographically ditandatangani menggunakan
zona kunci pribadi. Server nama penerima harus memiliki akses ke kunci publik daerah dalam rangka
untuk melakukan verifikasi keamanan yang dibutuhkan. Hal ini menimbulkan ke kriptografi asimetris klasik
masalah-cara mendapatkan kunci publik, dalam kasus sebelumnya untuk example.com, dengan cara
yang menjamin hanya bisa berasal dari example.com. Ada dua solusi yang mungkin:
1. Publikasikan kunci publik menggunakan RR DNSKEY di file zona. Metode ini rentan terhadap
dua masalah. Jika kita menggunakan query aman untuk mendapatkan kunci, maka data respons memerlukan
kunci publik, yang kita meminta tetapi belum memiliki, sehingga keamanan akan validasi
gagal-situasi ayam dan telur. Jika permintaan tidak aman digunakan, maka penilaian dapat
sudah palsu, karena memiliki semua kelemahan permintaan standar aman dibahas
sebelumnya.
2. Mendapatkan kunci menggunakan out-proses-band seperti e-mail aman, telepon, atau
proses lain yang dapat diterima. Ini adalah metode yang diadopsi oleh DNSSEC, dan BIND yang
kunci publik, disebut jangkar terpercaya karena alasan-alasan yang akan jelas nanti, didefinisikan dengan menggunakan
klausa dipercaya-tombol pada named.conf. Gambar 11-2 menunjukkan proses ini dengan hanya NS1
memiliki klausa dipercaya-kunci untuk example.com.
Dalam Gambar 11-2, NS2 akan terus beroperasi secara transparan seperti sebelumnya, tapi NS1 telah dikonfigurasi
dengan jangkar terpercaya untuk example.com domain seperti yang semua permintaan untuk domain ini
dapat dengan aman diotentikasi-ditunjukkan dengan menetapkan dikonfirmasi Data (AD) bit dalam pesan
header respon (lihat Bab 15 untuk informasi lebih lanjut). Tidak, bagaimanapun, memiliki jangkar terpercaya untuk
domain 168.192.in-addr.arpa, dan dalam hal ini tanggapan dari zona ini akan terus
bertingkah seakan-akan mereka tidak aman. Secara teoritis, NS1 dapat menentukan status berikut
dari tanggapan dari server nama:
• Aman: Sebuah jangkar dipercaya hadir untuk zona dan telah digunakan untuk memvalidasi diterima
data berhasil. Dalam Gambar 11-2, hanya example.com akan menghasilkan respon negara seperti ditunjukkan
oleh dikonfirmasi Data (AD) bit yang ditetapkan.
• Insecure: Sebuah jangkar dipercaya hadir dan informasi memungkinkan server nama untuk membuktikan bahwa
pada titik delegasi tidak ada link ke zona yang aman. Dalam Gambar 11-2, sub.example.com adalah
domain-satunya yang akan menghasilkan seperti keadaan respon.
• gadungan: Sebuah jangkar dipercaya ada, namun data gagal otentikasi pada nama penerima
server menggunakan jangkar terpercaya. Upaya untuk menipu atau korup tanggapan dari
example.com domain akan menghasilkan negara ini.
• tak tentu: Tidak ada jangkar dipercaya untuk domain tersebut. Ini akan menjadi negara respon
untuk semua domain di Gambar 11-2 (termasuk 168.192.in-addr.arpa) kecuali example.com dan
sub.example.com.
Jelas, tidak praktis untuk setiap server nama untuk memiliki jangkar terpercaya untuk setiap aman
domain internet. Jika ini adalah satu-satunya bagian dari DNSSEC, itu hanya akan tidak skala untuk
Internet-lebar penyebaran. Namun, sebelum melihat selanjutnya menetapkan fitur, perlu
mencatat bahwa masyarakat yang menarik yang memiliki keanggotaan yang terbatas seperti extranet, afinitas
kelompok, dan jaringan perusahaan dapat mengimplementasikan DNSSEC-bahkan dengan relatif terbatas
fitur yang diuraikan sejauh ini-dan mendapatkan akses langsung ke kemampuan dijamin dalam bunga
kelompok sambil terus memberikan pelayanan yang transparan ke keamanan-sadar yang lebih luas
masyarakat. Titik kritis untuk membuat di sini adalah bahwa manfaat dari DNSSEC dapat leverage
segera diberi situasi yang tepat dan lingkungan, sedangkan pengguna mengakumulasi pengetahuan
dan pengalaman operasional. Seiring dengan berjalannya waktu, manfaat hanya akan meningkat.
Chains of Trust
Gambar 11-3 menunjukkan bahwa setiap pulau tunggal keamanan dapat bergabung ke aman (ditandatangani)
domain melalui titik delegasi perusahaan-the RRS NS titik dari domain induk atau zona
ke domain anak atau zona-dan dapat dikonfirmasi menggunakan RR terakhir dalam DNSSEC set
disebut didelegasikan Signor (DS) RR.
Dalam Gambar 11-3, rantai kepercayaan ini terlihat dari example.com ke sub.example.com. Tiga
poin mengalir dari proses ini:
1. Zona anak, sub.example.com pada Gambar 11-3, harus aman sebelum delegasi aman
dapat terjadi. Mengamankan zona merupakan prasyarat penting untuk menciptakan rantai kepercayaan.
2. Jangkar yang terpercaya untuk example.com meliputi zona aman yang didelegasikan dari itu.
Dalam kasus Gambar 11-3, jangkar terpercaya untuk example.com meliputi anak zona
sub.example.com. Delegasi dapat dilacak dengan aman dari example.com (orangtua
yang dilindungi oleh dipercaya jangkar) untuk sub.example.com (anak) menggunakan rantai
kepercayaan. Sejumlah tingkat dapat ditutup menggunakan rantai dari konsep kepercayaan.
3. Delegasi rantai dapat dibangun baik ke atas maupun ke bawah. Jadi jika gTLD
domain. com dijamin, yang example.com domain yang ada aman dapat segera
bergabung rantai, sementara domain tanpa jaminan akan terus beroperasi tidak berubah (yaitu,
mereka tidak akan menikmati keuntungan dari keamanan sampai tindakan yang diambil untuk mengamankan mereka). Itu
NS1 server memerlukan jangkar baru terpercaya untuk menutup dijamin domain com,. tapi
jangkar single ini dipercaya akan menutupi keseluruhan. domain com, termasuk example.com,
seperti yang ditunjukkan pada Gambar 11-4.
Meskipun tidak ada gTLDs belum mengumumkan rencana untuk mengamankan domain mereka, sejumlah besar
tes dan uji coba sedang dilakukan, seperti alat pembangunan untuk memekanisasi berbagai proses
terlibat, yang akan dijelaskan nanti dalam bab ini. Swedia adalah negara pertama di dunia untuk
mengumumkan bahwa pada akhir tahun 2005 itu akan mulai penandatanganan. se ccTLD domain (dnssec.nic.se) dan
DNSSEC menawarkan layanan publik yang akan baik memvalidasi berbagai teknis dan bisnis
proses yang terlibat dan meningkatkan kesadaran global manfaat dari pengamanan zona. Hal ini
hanya soal waktu sebelum orang lain mengikuti.
Setelah menggambarkan proses DNSSEC, sekarang saatnya untuk mulai melihat rincian tentang bagaimana semuanya
bekerja mulai dengan mengamankan zona file-langkah pertama dalam urutan pelaksanaan.
Mengamankan atau Menandatangani Zona yang
Langkah pertama dalam pelaksanaan DNSSEC adalah untuk cryptographically menandatangani file zona. Ini
dilakukan dengan menggunakan utilitas dnssec-signzone disediakan dengan semua distro BIND. Namun, sebelum
kita mendekati rincian menjalankan utilitas ini, perlu untuk mundur dan memahami
apa yang sedang dilakukan.
Zona adalah digital ditandatangani dengan menggunakan kunci privat dari kunci publik (asimetrik) enkripsi
teknologi. DNSSEC memungkinkan untuk penggunaan RSA-SHA-1, DSA-SHA-1, dan RSA-MD5 tanda tangan digital.
Kunci publik yang sesuai dengan kunci pribadi digunakan untuk menandatangani zona telah diterbitkan
menggunakan RR DNSKEY dan akan muncul di puncak atau akar dari zona file, misalnya, jika zona
yang ditandatangani adalah
Dua jenis kunci yang diidentifikasi untuk digunakan dalam operasi penandatanganan zona. Jenis pertama disebut
dengan Zona Penandatanganan Kunci (ZSK), dan jenis kedua disebut Key Penandatanganan Kunci (KSK). ZSK ini
digunakan untuk menandatangani RRsets dalam zona tersebut, dan ini termasuk penandatanganan ZSK itu sendiri, karena Anda akan
lihat nanti. Kunci publik ZSK ini menggunakan RR DNSKEY di puncak atau akar dari zona tersebut, yaitu,
jika zona yang ditandatangani adalah example.com, kunci publik ZSK akan didefinisikan oleh RR DNSKEY,
yang memiliki nama example.com. KSK ini digunakan untuk menandatangani kunci di puncak atau akar
zona, yang meliputi ZSK dan KSK dan juga dapat digunakan di luar zona tersebut baik sebagai
yang terpercaya jangkar di server keamanan-sadar atau sebagai bagian dari rantai kepercayaan dengan nama orang tua
server. KSK ini juga didefinisikan dalam RR DNSKEY di root atau zona puncak, yaitu, jika
zona disebut example.com, maka nama RR DNSKEY KSK juga akan example.com.
Perbedaan antara ZSK dan KSK adalah karena itu salah satu penggunaan tidak definisi, dan ini
soal pilihan operasional lokal apakah DNSKEY tunggal RR digunakan sebagai baik ZSK dan
KSK atau apakah RRS DNSKEY terpisah digunakan sebagai ZSK dan KSK. RFC memungkinkan kedua
metode. Buku ini akan menggunakan kunci terpisah di seluruh sebagai ZSF dan KSK dengan jelas terpisah
fungsi tersebut. Draft saat ini praktik terbaik RFC pada DNSSEC juga merekomendasikan
penggunaan tombol terpisah (www.ietf.org / internet-konsep / draft-IETF-dnsop-dnssec-opera ➥
nasional-praktek-05.txt). Perbedaan definisi adalah bahwa ZSK DNSKEY RR memiliki bendera
bidang 256 (lihat Bab 13), sedangkan KSK adalah ditunjukkan dengan nilai bidang bendera dari 257.
Ketika zona ditandatangani, yang ZSK dan KSK itu (ingat mereka dapat menjadi satu dan sama
kunci) yang dihasilkan dengan menggunakan utilitas dnssec-keygen normal (yang dijelaskan dalam Bab 9) dengan
nama zona. Proses detail termasuk parameter yang digunakan akan digambarkan kemudian
pada contoh berbagai operasional. The DNSKEY dihasilkan RRS yang baik diedit ke
zona file secara langsung atau dengan menggunakan perintah $ TERMASUK (lihat Bab 13) seperti ditunjukkan pada berikut
example.com zona file:
$ TTL 86400; 1 hari
$ ORIGIN example.com.
@ IN SOA ns1.example.com. hostmaster.example.com. (
2005032902; serial
10.800; refresh (3 jam)
15; coba lagi (15 detik)
604.800; berakhir (1 minggu)
10.800; minimal (3 jam)
)
NS ns1.example.com.
NS ns2.example.com.
MX 10 mail.example.com.
MX 10 mail1.example.com.
_ldap._tcp SRV 5 2 235 www
ns1 A 192.168.2.6
NS2 A 192.168.23.23
www A 10.1.2.1
A 172.16.2.1
mail A 192.168.2.3
mail1 A 192.168.2.4
example.com. DI DNSKEY 257 3 5 (AQPnvgDqCShrBmFEh5vW7k
M4DG/kMwa3EBnPSLAqWRbFOffIWP9ZA2v
cZn5ngUjVZ/1IdOViZBO0FCm63bakNgpQ
4UNH6e4LH8hnTDMyrlw9smNC xLr4ROqL
lcLWDT4ANysDpCZmHUPilvJB1WnVhGKV1
I6T01x + u4uNoe1 / uocNOQ ==); KSK (September)
example.com. DI DNSKEY 256 3 5 (AQPmYqOH3zNwuX4l2 + hkh8U
G1P14Gv8dfCSi6MbEX0N424EX + EIMl400O
OBkep/ZtIRRJ4rfJONPGs8 + HWJDMQOapZn
VSYOmSH9V5V32c + j7Gx628y/MyyzwDuT6 +
zQ3cbobUKrlzL/PLEHegqIDpGkF2VBWXWH
LDTCJ5nXB sayYeQ ==); ZSK
Yang DNSKEY pertama RR adalah KSK ditunjukkan oleh nilai bendera 257; yang DNSKEY kedua
RR, ZSK, memiliki nilai bendera 256 (untuk rinciannya lihat Bab 13). zona ini sekarang sudah siap untuk
Penandatanganan, yang dilakukan dengan menggunakan utilitas dnssec-signzone-rincian menjalankan utilitas ini
sepenuhnya menggambarkan kemudian dalam contoh. Ketika zona ditandatangani, utilitas dnssec-signzone tidak
beberapa hal automagical:
1. Hal macam itu RRS ke urutan kanonik (dasarnya abjad berdasarkan nama host).
2. Ini menambah RR NSEC setelah setiap RR untuk rantai bersama nama-nama host yang valid muncul
di file zona. Yang terakhir NSEC RR akan menunjuk kembali ke puncak zona atau akar.
3. Menggunakan ZSK untuk setiap tanda RRset dengan menciptakan RR RRSIG. Ini mencakup baik
DNSKEY RRS dan baru ditambahkan NSEC RRS dari langkah 2.
4. Menggunakan KSK untuk menandatangani (menciptakan RR RRSIG) untuk RRset DNSKEY di puncak zona.
Dihasilkan file yang secara default telah. Menandatangani ditambahkan ke nama master
zona file-setelah menjalankan utilitas dnssec-signzone akan terlihat seperti yang ditampilkan di sini:
; File tertulis pada Kamis 14 April 12:39:03 2005
; Dnssec_signzone versi 9.3.0
example.com. 86.400 DI ns1.example.com SOA. hostmaster.example.com. (
2005032902; serial
10.800; refresh (3 jam)
15; coba lagi (15 detik)
604.800; berakhir (1 minggu)
10.800; minimal (3 jam)
)
86.400 RRSIG SOA 5 2 86400 20050514153903 (
20050414153903 38.420 example.com.
P8DKXJwN2dmfl16sqJqk9eVv6HfDs6tgs9B2
k/J406v1dyxtl7lUq6oa0VSh9WzqDZTe3dis
Ji/DGNVDfXvx3gUnN26sHjkAqZIpTtzYR/ql
R + dXKfK14Sqeva0kl50GqWCmOtuaxlJ9h249
w7P3qKtEs4nL1ELrtyEnOLyCX4k =)
86.400 NS ns1.example.com.
86.400 86.400 RRSIG NS 5 2 86400 20050514153903 (
20050414153903 38.420 example.com.
TK9eFTMHpYqtyLZ + L6qWJmh5PfAsJlUFVI / Y
Z4P5XBzbEerW85U7SsgrdKCil52qZ8a8OzQI
5cbsGNrQHfrkvpPdE/D3RiIJzVGrG0mRDvkC
8 kvdywljdadVg xsCp2XMGfebG2xzKfehO7G
pFb + TtN2XYfXBVlFa + ZgGbJSkM8 =)
MX 86400 10 mail.example.com.
MX 86400 10 mail1.example.com.
86.400 RRSIG MX 5 2 86400 20050514153903 (
20050414153903 38.420 example.com.
MPFBtkjE12FoNbUF06rgpXA6FCOEnqu6g6jB
zH3nT4lE9TP89L0ErrD13XqKYik27RALoEL2
y1UFvbk78rZKIeyRPRZh4/6O3qMcMqXq/BCa
ITsCtlFjcPy4OOFb/76SN9soK8pcC3w3Nkg5
BSDgbDRImKth + l + PTPiu + iQuUYY =)
10.800 NSEC ldap._tcp.example.com. (MX NS SOA
RRSIG DNSKEY NSEC)
10.800 RRSIG NSEC 5 2 10800 20050514153903 (
20050414153903 38.420 example.com.
NYpw5eq7aW6j02eybm6Lj / T 4 llyvCYuFLQW
oqtTec38kGHxWtwMdZckSm3V + ColSnjJK8 + N
2YuoCJdooEetrwkUWZv/C/68ES3VVoFHHFqk
70 cCMs IG3nMcuGB91yuGcpwBNqkYvm3hW / P
ZBzj + ikuphPQ7x507F2VP9t1rC4 =)
86.400 DNSKEY 256 3 5 (
AQPmYqOH3zNwuX4l2 + hkh8UG1P14Gv8dfCSi
6MbEX0N424EX + EIMl400OOBkep/ZtIRRJ4rf
JONPGs8 + + HWJDMQOapZnVSYOmSH9V5V32c j7
Gx628y/MyyzwDuT6 + zQ3cbobUKrlzL/PLEHe
gqIDpGkF2VBWXWHLDTCJ5nXBsayYeQ ==
); Kunci id = 38420
86.400 DNSKEY 257 3 5 (
AQPnvgDqCShrBmFEh5vW7kM4DG/kMwa3EBnP
SLAqWRbFOffIWP9ZA2vcZn5ngUjVZ/1IdOVi
ZBO0FCm63bakNgpQ4UNH6e4LH8hnTDMyrlw9
smNCxLr4ROqLlcLWDT4ANysDpCZmHUPilvJB
1WnVhGKV1I6T01x + u4uNoe1/uocNOQ ==
); Kunci id = 12513
86.400 RRSIG DNSKEY 5 2 86400 20050514153903 (
20050414153903 12.513 example.com.
lUSl/8AXfEcdocB9syYu0Nk8AeRXSJy13ixO
tbAQaH DjDa + + + + eUpSLegMdW7uXdU2Hk GZ0w
hWdPoZOTg7 + KnjlyJ6uJ + ZozaxYYCpwZrot1
mP9Jnot6VU58PurwJ8YB2MnQR5rylWYZk84L
UNoJq8FohGy3 / Fj1fp4pZ3chM f + =)
292 BAB 11? DNSSECNS ns2.example.com.
86.400 RRSIG DNSKEY 5 2 86400 20050514153903 (
20050414153903 38.420 example.com.
awjJL2h6NNhfZ/4HX0iDMJbIYPr + blIaaeK /
xEr91vP6myOd2S7dWypZc + qbrm5ew5v6n/OV
8UC69u/MZPTBEetRLhi1 + D + + YIZ7GXmdtUjL
A + js30Pgb2cR5cJRDK8yCqi5SlxhNxwO713V
kSl/1rlKy + LSl8nQ6XJt8/pkjDM =)
_ldap._tcp.example.com. 86400 IN SRV 5 2 235 www.example.com.
86.400 RRSIG SRV 5 4 86400 20050514153903 (
20050414153903 38.420 example.com.
CnmMTizzSerS4ePF0NANviTRFEdJ4OKUwaBu
JZiPmX2ZkvQQ2ZWEl6Vvxu7NTyhi60YRvQWt
yMKSOL1LqkT61XfN8v7XWscfZTx8qb6K5qu4
3 n xghHRDPBn6yHCOu0vaC4iZeEZyx0W04jf
ce + mtaVkBq5p2dhsH3 / t + Msw5qk =)
10.800 NSEC mail.example.com. SRV RRSIG NSEC
10.800 RRSIG NSEC 5 4 10800 20050514153903 (
20050414153903 38.420 example.com.
zC3hXQX82oT9yYEH/OUtPukyTglTat4MxwQ4
p4VEWP8qPoEKP3hhtjz4rt1ylTdpLWH6tLNS
NFCE/Mdol6kjspfVXRcsL2MLVdRNOKLeqjhl
U8Sdut2kjX0nBFp4hAcicALzaN7/PpFGga0f
/ KnKcD7aM5a/gr0zZBHjswszGt4 =)
mail.example.com. 86400 IN A 192.168.2.3
86.400 RRSIG A 5 3 86400 20050514153903 (
20050414153903 38.420 example.com.
W7QBEKLgh6v7AK6T30KQ4tgSgO4RCrddAN61
cD8MYUrq5l1W7I1QgAxdT8zAlADiUjafnnlk
QNM4vJnToS3BxprhZ2mFJwiTWV3DIGBqCnPJ
c62pue0M + DmsCEBKxbVUZOKf2nW5bim + GIqH
Csxfiy0XqDRgzDF6ZZUo/njMqcA =)
10.800 NSEC mail1.example.com. Sebuah RRSIG NSEC
10.800 RRSIG NSEC 5 3 10800 20050514153903 (
20050414153903 38.420 example.com.
XiHOXLyR7uC9MvJS3m8AMVtY6QtgSdhy6tId
uaylkHjt/EjolKuZdy1F71yP1rICWDdcWgy2
eKSKVZy97RfKMlRKBbWruBspmfBfKHSUvl27
s0wehJ3n7H40D5xE0/tzJrHnL1tjHkaqeVpe
V16vLTVUUbday9HeRl/388HU10k =)
mail1.example.com. 86400 IN A 192.168.2.4
86.400 RRSIG A 5 3 86400 20050514153903 (
20050414153903 38.420 example.com.
lRounAjKet/54jW1oYxoF2LX0xw0yjoVfKX8
wNuVKXKv + WW + + AVbIacRbpx VoLLjToM8IgI0
PmHgr2CVZo1wRT1guaDCgejk1qI5uYuy9bgD
EO2gjaPL2nXYyjTcU3xNOcsWsHLp5PT72Kps
bIlGQDAry/xcQSk8mF2scDVj9mc =)
BAB 11? DNSSEC 293
10.800 NSEC ns1.example.com. Sebuah RRSIG NSEC
10.800 RRSIG NSEC 5 3 10800 20050514153903 (
20050414153903 38.420 example.com.
VMkPYVtLdiRO6sQFseMss3Xn56WSPRkeYF / q
WqRLEMbPv5GrsafzQdExKmj2XF0OJKmbgz / p
uhyGKSdzmLcZosjg hFZnrlMI2kBP5pJ67dN +
AhZynF + S + A1hymxWQ9lT2 + h4zCgW2zEDhy + J
PkMi4ra9voDWau3COsRmxcO38Eg =)
ns1.example.com. 86400 IN A 192.168.2.6
86.400 RRSIG A 5 3 86400 20050514153903 (
20050414153903 38.420 example.com.
mQioT8nfRq6dOyFvmR7k09dU8wohWU0E35ki
LTKPrQON1ERi/dhI/YhXtqBP4GDAAbBBOCQU
AUJFJP7lnV3oP5FP5YuTvL4eHBoSVcWpdhFG
bSV1OejH7CN6e/QACksNmMo7jwQ9woSZ6n5y
fpOiPnGUa39awWK + WXegz1UhZfo =)
10.800 NSEC ns2.example.com. Sebuah RRSIG NSEC
10.800 RRSIG NSEC 5 3 10800 20050514153903 (
20050414153903 38.420 example.com.
DJmXHGjUZCkbMOUkVSCxFe7eouHr2GHjKGhl
7P4etVVkhNMafMBfrsy + J7/Nf4vfbYKCzDEa
ARmN1gWBTW/xt8diFk8GKdhsZoiGDkLG0g12
rpNhwSOwJK7fdblFSoEZyCrwMQYdEUpdfsGY
XQ 7 IbdUR9gMFW + ecNcKA9jtpYA =)
ns2.example.com. 86400 IN A 192.168.23.23
86.400 RRSIG A 5 3 86400 20050514153903 (
20050414153903 38.420 example.com.
tvqos7ZVNO4ZWGWDS uVqj4juNt + + N + uNHem3
bIOaKAmHKamQzE9ecDfX2HFTO2Pr6OF7v6JQ
q9yPoVtGvsYrYrZM7jLTaPdnUhko34KpSThq
5SU2OCSUqkIgtYVCMxM18QtnZ4tsy9883OgC
9OJTxOk0HdjgYfxLRDu01AEZfww =)
10.800 NSEC www.example.com. Sebuah RRSIG NSEC
10.800 RRSIG NSEC 5 3 10800 20050514153903 (
20050414153903 38.420 example.com.
OxKKdDdRi9ICISwF9Eo4vBH7IkF + Khn8K2yC
1 1TFBpW2CeTAnn67Ngxw3mnNuD8Jh k7lFWJ
dcvI3 5 COyc0LnL2 7 ncuUg + OMv7kSYOiSaW
GlMXKHqzh9rZH8NYraCeqFQu4Zmh99w5w6NH
W9JwJOxbQU6hkq8nq8274owj/9M =)
www.example.com. 86400 IN A 10.1.2.1
86400 IN A 172.16.2.1
86.400 RRSIG A 5 3 86400 20050514153903 (
20050414153903 38.420 example.com.
MQK0nxT6 + SO1du5gUcW71CRNDYlHgp4Wddqx
py/m92dJwl1XFMOqcNVcuhz9YmCV + zn59vi6
Hj5pWpvFRVE5VsrDYtPosKkxyUHS0SeVJkfg
7jd33Mz771i/jtQdvkr4Ti3DTcNEBBYZvF59
SA + ncD56AwG 8 NEgxfKJt59d7wE =)
10.800 NSEC example.com. Sebuah RRSIG NSEC
10.800 RRSIG NSEC 5 3 10800 20050514153903 (
20050414153903 38.420 example.com.
JSP + o3gqJgopHosuT1QK + F9z/uXigSv 2 Ntg
Q1GRmBrtUawxdiaX7jCnFOvUKLDJcPDFv2cU
ceBLVxhpfu9KYQZYghXAR8SvW4XKC0zwMJ1s
HXtvU8Zx / R + S0j1FnfkndP8VXwPn2Z92ai + T
AuOAWELN837tnnFMHIn67sUId7w =)
Setelah Anda mendapatkan lebih awal perasaan lega bahwa proses ini otomatis, Anda harus
perhatikan hal berikut:
• Catatan telah mengatur kembali, khususnya DNSKEY RRS telah dipindahkan ke
atas atau puncak file ditandatangani dan RRS A untuk ns1, NS2, dan www telah disortir ke
mereka diharapkan (kanonik) pesanan.
• NSEC RRS telah ditambahkan (yang pertama adalah setelah RR MX terakhir untuk zona) seperti yang
adalah mungkin untuk rantai menggunakan catatan melalui file zona dan dengan demikian membuktikan bahwa setiap
nama host tertentu tidak ada (ingat NSEC RRS digunakan sebagai bukti tiadanya
seperti yang dijelaskan sebelumnya). Yang terakhir NSEC RRS (ada dua dari mereka) untuk RRS A
untuk jalur www.example.com kembali ke root domain (example.com), menunjukkan ada
tidak ada tambahan catatan dalam file zona. Alasan ada dua NSEC RRS keduanya menunjuk
kembali ke awal dari domain tersebut adalah karena www A RRS merupakan RRset (mereka
sama); telah ada RR itu hanya satu A, maka akan terjadi hanya satu NSEC RR.
• Setiap RRset telah ditandatangani dengan RR RRSIG. Ada empat RRsets beberapa (yang
DNSKEY RRS, di RRS NS, yang RRS MX, dan www.example.com A RRS); semua yang lain
RRsets terdiri dari RRS-tunggal yang masih RRsets!
• The DNSKEY RRS telah ditandatangani dua kali (ada dua RRSIG RRS). Tanda tangan pertama
menggunakan KSK dan merupakan artefak dari penggunaan ZSK terpisah dan KSK. Tanda tangan kedua
menggunakan ZSK dan merupakan artefak dari aturan yang mengatakan bahwa semua RRsets ditandatangani oleh
ZSK. Jika DNSKEY tunggal RR digunakan baik untuk ZSK dan fungsi sebagaimana yang diperbolehkan oleh KSK
standar, hanya akan ada satu RRSIG RR.
Akhirnya setiap RR RRSIG memiliki waktu mulai (waktu itu setelah itu dianggap valid)
yang dimulai di Universal Coordinated Time (UTC) minus 1 jam (untuk memungkinkan condong jam) berkoresponden
dengan waktu lokal menjalankan utilitas dnssec-signzone dan akan berakhir 30 hari setelah nya
mulai waktu ini adalah utilitas default dnssec-signzone. Waktu menjalankan utilitas selalu disertakan
sebagai komentar pada baris pertama dari file; berakhirnya dan waktu mulai adalah masing-masing keempat
dan parameter kelima setelah nilai tipe RRSIG (lihat juga Bab 13). Jika file zona tidak mengundurkan diri
sebelum nilai didefinisikan oleh berakhirnya waktu tiba (dalam hal ini, kasus 20050514153903 atau
14 Mei 2005 pada 03:39 UTC) nama server keamanan yang sadar akan membuang data dari
zona sebagai palsu (tidak aman); paradoks, keamanan server nama tidak menyadari akan terus
menerima data berhasil. Penandatanganan zona selalu memperkenalkan elemen waktu yang tidak
hadir di zona file unsigned dan membutuhkan perawatan berkala dari file zona. Berikutnya
bagian akan melihat implikasi-mendaftar ulang serta aspek lain pemeliharaan zona aman,
termasuk topik penting untuk mengubah kunci dengan apa yang disebut dalam jargon tombol rollover.
Zona Aman Pemeliharaan
Re-sign zona melibatkan hanya rerunning utilitas dnssec-signzone asli baik menggunakan
zona file asli atau versi saat ini ditandatangani itu. file zona Secure perlu kembali ditandatangani
untuk tiga alasan:
1. Ketika perubahan dibuat untuk catatan zona: Dalam dunia tidak aman, perubahan itu hanya
masalah memperbarui nomor seri SOA RR; dalam dunia DNSSEC, setiap kali
perubahan dibuat ke file zona, nomor seri SOA perlu diperbarui dan
zona perlu kembali ditandatangani. Masalah update dinamis (DDNS) dan re-sign adalah
dibahas nanti dalam bab ini.
2. Ketika tanda tangan berakhir: Seperti ditunjukkan dalam contoh file menandatangani zona sebelumnya, masing-masing
RRSIG RR akan berakhir secara default setiap 30 hari. Meskipun hal ini dapat dikontrol oleh parameter
untuk utilitas dnsssec-signzone, namun kembali zona-penandatanganan periodik akan selalu
diperlukan untuk menghindari kadaluwarsa tanda tangan.
3. Bila satu atau lebih dari ZSK atau KSK perlu diubah: Proses ini, disebut rollover tombol,
mungkin diperlukan baik sebagai bagian dari proses pemeliharaan rutin atau darurat-the
Kuncinya adalah baik diketahui atau diduga dikompromikan.
Dua pertama proses menggunakan DNSKEY ada RRS dan tidak memiliki dampak pada nama eksternal
server. Proses terakhir melibatkan rollover tombol memiliki implikasi signifikan untuk setiap nama eksternal
server yang memiliki RR DS (orangtua) referensi KSK, sebuah jangkar yang terpercaya referensi yang
saat ini KSK (klausa dipercaya-tombol di BIND) atau cache DNSKEY baik RRS untuk KSK atau ZSK.
kunci Cryptographic harus diubah secara berkala, biasanya setiap 30 sampai 90 hari, selama tiga
alasan:
1. Selama periode waktu yang mungkin bagi penyerang untuk mengumpulkan cukup plaintext
dan dienkripsi bahan untuk melakukan analisis kunci.
2. Serangan brute-force akan mengambil beberapa waktu. Jika kuncinya adalah berubah sebelum itu
interval, penyerang akan harus mulai lagi.
3. Jika tombol ini diam-diam dikompromikan (tidak diketahui oleh user atau operator), tidak mungkin yang
penyerang akan membual tentang hal ini tetapi lebih memilih untuk terus diam-diam decrypting material
atau menghancurkan sistem. Mengubah kunci setidaknya akan membatasi kerusakan yang mungkin
Hasil dari ini dan memaksa penyerang untuk memulai lagi.
Ketika kunci mungkin berubah, tergantung pada apakah itu adalah ZSK atau KSK, dampak satu atau
lebih dari proses berikut, kemungkinan besar akan dikontrol oleh entitas lain daripada yang
zona administrator yang memulai perubahan:
• Memperbarui dari catatan DS pada orangtua (KSK saja): Jika zona induk di mana DS
RR harus diubah tidak dikendalikan oleh pemilik yang sama dengan zona anak, kemudian sinkronisasi
perubahan RR DS dengan perubahan KSK adalah mustahil tanpa tingkat
otomatisasi yang saat ini tidak tersedia. Perbedaan waktu dapat cukup
dan melibatkan beberapa hari.
• Memperbarui dari jangkar terpercaya di server nama keamanan-sadar (KSK saja): Proses ini
akan tergantung pada metode yang digunakan, tetapi kasus terburuk mungkin melibatkan pengguna secara manual
memperbarui server nama, yang dengan mudah dapat diperlukan waktu beberapa hari. Jika update tidak dilakukan,
acara kemungkinan jika update manual yang terlibat, maka data akan ditolak zona
sebagai palsu pada server nama yang belum diperbaharui jangkar terpercaya, sehingga rendering
zona tersebut tidak tersedia.
• RRSIG RR dan RR DNSKEY cache di server nama (ZSK dan KSK): Sejak RR RRSIG
digunakan untuk menandatangani RRset dan RRS DNSKEY digunakan untuk melakukan validasi dapat diperoleh di
waktu yang berbeda, karena itu mereka akan berakhir dari cache pada waktu yang berbeda, bahkan jika semua
TTLs zona yang sama. Oleh karena itu mungkin jika zona adalah kembali ditandatangani dengan ZSK baru atau
KSK baik untuk sebuah RRSIG tua RR (sebuah RR RRSIG dibuat dengan ZSK tua atau KSK) dan
baru DNSKEY RR atau situasi sebaliknya terjadi. Dalam kedua kasus, permintaan untuk yang terkait
RRS data akan menyebabkan respons palsu.
Ini dapat dilihat dari sebelumnya bahwa tidak ada satu titik dalam waktu di mana zona
bisa berubah dari satu kunci ke kunci lain, tidak peduli apakah itu adalah suatu ZSK atau KSK. Standar,
Namun, memungkinkan beberapa tombol ada (di beberapa DNSKEY RRS) di puncak zona dan mandat
bahwa semua tombol yang tersedia harus mencoba sebelum data zona ditandai sebagai palsu. Fitur ini
memungkinkan zona ditandatangani untuk mengoperasikan untuk jangka waktu dengan kunci lama dan baru sampai berbagai proses
dapat dijamin untuk memperoleh bahan kunci baru, di mana titik kunci tua (s) dapat
sudah pensiun. Ada dua metode yang zona dapat beroperasi dengan beberapa kunci-the prepublish
metode dan metode ganda-penandatanganan.
Metode Prepublish
Metode prepublish memungkinkan satu atau lebih kunci baru yang akan hanya diperkenalkan ke dalam zona
puncak sebelum digunakan. inklusi mereka di zona itu sebelum digunakan memastikan bahwa sesuai
tombol yang tersedia di cache semua server nama keamanan-sadar ketika kunci akhirnya
bergulir, yaitu zona ini kembali ditandatangani dengan ZSK baru dan / atau KSK sementara meninggalkan kunci tua (s)
di zona puncak, walaupun mereka tampaknya tidak melakukan fungsi. Untuk menggambarkan ini
proses, diasumsikan bahwa semua TTLs untuk zona ditandatangani adalah untuk 24 jam (86.400 detik).
1. Setidaknya dua hari sebelum tanda tangan zona berakhir (bisa setiap saat sebelum itu
jika diperlukan), sebuah ZSK baru atau KSK akan ditambahkan ke DNSKEY ditetapkan pada zona puncak.
zona ini kembali ditandatangani dengan menggunakan, saat ini bukan baru, tombol (s). RR DNSKEY baru
tidak digunakan untuk masuk zona dengan cara apapun-itu hanya hadir dalam RRset DNSKEY.
2. Setelah 24 jam, dapat dijamin bahwa semua cache di server nama keamanan-sadar akan
memiliki RRset DNSKEY baru berisi baik saat ini dan tombol baru. The RRSIG
catatan untuk setiap jenis RR dalam cache akan telah ditandatangani dengan kunci saat ini.
3. Pada titik ini, zona ini kembali ditandatangani dengan menggunakan kunci baru atau tombol. Kunci lama masih dipertahankan dalam
yang RRset DNSKEY.
4. Dari titik ini dan selama 24 jam berikutnya, RRS RRSIG yang terkait dengan
diminta RR, mengatakan RR A untuk www.example.com, dapat ditandatangani dengan baik tombol yang lama,
jika RR yang sudah di cache, atau tombol baru, jika itu telah kedaluwarsa dari cache atau
tidak tersedia dalam cache dan harus diperoleh dari sumber otoritatif. Mengingat kembali
bahwa standar-standar mandat bahwa semua tombol yang tersedia harus dicoba sebelumnya menolak apapun
data sebagai palsu. Dalam kedua kasus, sebuah DNSKEY RR yang berhasil akan mengotentikasi
RR data yang diminta akan hadir di cache, atau jika RRset DNSKEY telah berakhir
atau tidak hadir, maka dapat diminta dari sumber otoritatif (master atau slave).
5. Setelah 24 jam dari penandatanganan ulang file zona dengan kunci baru (s), dengan cache semua dapat
dijamin mengandung RRSIGs hanya ditandatangani dengan kunci baru. Kunci tua, kadang-kadang
disebut tombol basi, dapat dihapus sewaktu-waktu selanjutnya nyaman dari
DNSKEY RRset di puncak zona dan zona lagi kembali ditandatangani dengan kunci baru.
Metode Double-Menandatangani
Seperti namanya, metode ganda-penandatanganan melibatkan penggunaan lebih dari satu kunci untuk tanda
zona tersebut jika ZSK, atau RRset DNSKEY di puncak zona jika seorang KSK. Sejak RRsets ditandatangani dengan
semua kunci, penandatanganan ganda memastikan bahwa tombol apa saja yang terkandung dalam cache di nama keamanan-sadar
server atau direferensikan di RR DS atau terpercaya jangkar akan mengotentikasi RRset apapun yang diminta. Ketika
semua pengguna kunci telah bermigrasi ke tombol baru (RRS DS telah diperbarui pada orangtua
zona dan jangkar dipercaya telah diganti), kunci tua dapat dihapus dari zona
file dan zona kembali hanya ditandatangani dengan kunci baru.
Key Rollover Ringkasan
Metode yang digunakan adalah sebagian besar masalah keputusan operasional, tapi untuk meminimalkan volume
catatan yang terlibat, terutama dalam file zona yang lebih besar, metode prepublish lebih cocok untuk
Zona mengubah Penandatanganan Tombol dan metode ganda-penandatanganan untuk mengubah kunci Tombol Sign.
Alasan di sini adalah bahwa setiap RRset ZSKs tanda pada file zona, yang ada biasanya akan
akan banyak. Double menandai setiap RRset secara signifikan akan meningkatkan jumlah data pada zona
file serta volume data yang terkirim pada setiap respon query. Di sisi lain, hanya KSKs
tanda RRset tunggal, RRset DNSKEY di puncak zona, dan double penandatanganan ini akan RRset
Oleh karena itu dikenakan biaya overhead yang relatif sederhana.
Proses tombol rollover melibatkan beberapa langkah, beberapa yang mungkin melibatkan ketiga
pihak, dan beberapa yang meminjamkan diri untuk otomatisasi. Setiap langkah itu sendiri tidak rumit,
tapi keseluruhan proses, ditambah dengan fakta bahwa zona bisa menjadi tidak dapat diakses
(Dengan diperlakukan sebagai palsu) jika setiap langkah gagal, menyarankan beberapa pengamatan:
• Proses kunci-rollover harus benar-benar direncanakan dan subjek untuk terus
perbaikan berkembang. Sudah jelas bahwa Internet Registries dan Registry Operator harus
dan yang memimpin di daerah ini karena secara fundamental, tetapi tidak eksklusif, sebuah
masalah operasional.
• Proses harus otomatis dimanapun praktis. Sedangkan alat pengembangan otomatis
masih dalam masa pertumbuhan, beberapa yang berkualitas tinggi telah telah dirilis
di bawah lisensi Open Source (lihat www.netwidget.net / buku / apress / dns).
• Proses tombol rollover harus dilakukan secara sering dan berkala. "Praktik
membuat sempurna "untuk mengutip pepatah lama. Meskipun dimungkinkan bahkan sekarang untuk membuat kunci
yang dapat berlaku selama bertahun-tahun, seperti upaya untuk menunda penderitaan menciptakan
efisien dan efisien rollover tombol-proses dengan membuatnya acara mungkin jarang
memperburuk masalah hanya karena mereka mengabaikan titik itu, karena penting
tombol apa saja proses kompromi tombol-rollover (terutama yang berderit satu), mungkin harus dilakukan
keluar dalam waktu singkat. Prospek ribuan administrator memberikan besar
imitasi ayam tanpa kepala sambil berusaha keras untuk mencari tahu apa yang mereka lakukan
tiga tahun lalu, ditambah dengan tanda berakhirnya jam berdetak tak terelakkan ke bawah, tidak
tidak meninggalkan satu dengan perasaan hangat dan fuzzy.
• KSKs dan ZSKs harus dipisahkan dan digulung pada interval yang berbeda. Perubahan KSK adalah
jelas yang paling signifikan dan, dengan menggunakan ukuran kunci yang lebih besar, mungkin dapat diperpanjang setiap
90 hari atau lebih versus interval ZSK dari mungkin 30 hari. Semakin besar ukuran kunci, semakin
beban CPU ditempatkan pada server. Namun, karena KSK yang digunakan relatif sangat jarang
untuk ZSK tersebut, memiliki ukuran kunci lebih besar untuk KSK harus hadir hanya sederhana tambahan
beban pada server.
Delegasi Secure
Setelah zona dijamin, itu kemudian dapat untuk ditambahkan ke rantai yang sudah ada kepercayaan atau dapat digunakan untuk mengamankan
delegasi untuk subdomain. Dalam kedua kasus, ini dicapai dengan menggunakan didelegasikan Signor RR. Itu
DS RR ditempatkan di induk dari zona aman yang akan didelegasikan dan bertindak sebagai pointer ke
kunci berikutnya dalam rantai kepercayaan. RR DS berisi hash (atau ringkasan) dari KSK ini, didefinisikan dengan menggunakan
sebuah DNSKEY RR, di puncak atau akar dari domain anak. Jadi jika sub.example.com subdomain
harus aman didelegasikan (bergabung dengan rantai kepercayaan), maka DS RR berisi ringkasan dari
DNSKEY RR dengan nama sub.example.com dan memiliki nilai bendera bidang 257 akan ditambahkan
ke example.com domain pada titik delegasi (yang RRS NS menunjuk ke subdomain
sub.example.com dalam kasus ini). Secure delegasi hanya dapat terjadi jika orang tua dan anak zona
aman, yaitu, keduanya ditandatangani. Gambar 11-6 mengilustrasikan proses ini.
Utilitas dnssec-signzone dapat menghasilkan RR DS selama proses penandatanganan untuk anak
zona menggunakan opsi-g. Tergantung pada kebijakan di tempat, DS RR dan mungkin salinan
KSK (a RR DNSKEY) untuk zona dapat dikirim ke pemilik dari domain induk untuk dimasukkan
di file zona, yang kemudian harus kembali ditandatangani. Zona anak kata untuk bergabung dengan rantai
kepercayaan dan dikonfirmasi berdasarkan otentikasi dari zona induk dan aman link nya
(RR DS) ke zona anak. Sebuah nama server keamanan-sadar menerima RRS dari domain aman
dapat melacak rute delegasi untuk sub.example.com kembali melalui satu atau lebih RRS DS dalam menandatangani
zona ke salah satu server yang memiliki nama terpercaya jangkar.
Dynamic DNS dan DNSSEC
Dynamic DNS dapat digunakan dengan zona ditandatangani. server secara otomatis akan memperbarui apapun
diperlukan NSEC RRS dan akan kembali menandatangani RRset. Hal-hal berikut, Namun, berlaku bila
bekerja dengan update dinamis dan ditandatangani zona:
• Entah TSIG atau SIG (0) keamanan dapat digunakan seperti yang dijelaskan dalam Bab 10. Jika SIG (0) (publik
kunci) pengamanan digunakan, membutuhkan RR KUNCI (bukan RR DNSKEY sebagaimana digunakan dalam DNSSEC), dan
dalam hal apapun kunci yang unik harus selalu digunakan yang harus dimasukkan atau ditambahkan ke
zona file.
• itu. Swasta file ZSK harus tersedia (on-line) baik direktori didefinisikan
oleh pernyataan direktori atau unik didefinisikan dengan menggunakan tombol-pernyataan direktori (dalam
pandangan, global, atau klausa zona) dari named.conf selama update apapun. Jika file ini tidak tersedia,
maka setiap upaya update akan gagal dengan pesan log sebagai berikut:
'Example.com / IN': menambahkan RR pada 'www.example.com' A
'Example.com / IN': tidak bisa mengambil kunci dinamis untuk update zona aman
'Example.com / IN': RRSIG / NSEC update gagal: ijin ditolak
• Jika KSK terpisah dan ZSKs didefinisikan dan jika keduanya. Swasta file on-line ketika
update dijalankan, RRsets diubah akan ditandatangani dengan kunci. Selalu membuat
yakin bahwa file pribadi KSK tersebut. diambil secara off-line secepat zona tersebut ditandatangani.
• Ketika dinamis diperbaharui zona ditandatangani, kemudian diubah prosedur manual
edit dari file zona harus diikuti:
1. BIND baik berhenti atau menggunakan zona membeku rndc.
2. Bawa KSK kunci pribadi on-line (ZSK itu.. Swasta file diasumsikan on-line
seperti disebutkan sebelumnya)
3. Re-tanda zona ditandatangani karena berisi pembaruan saat ini (memerlukan opsi-f)
4. Hapus file. Jnl
5. Ambil file KSK swasta off-line., Dan kemudian mulai mencair BIND atau zona rndc.
Secara khusus, sangat penting untuk menghapus file jnl untuk zona tersebut. Sebelum restart atau reload
file zona setelah penandatanganan ulang selesai untuk memastikan bahwa tidak ada pemutaran basi
nilai dari file ini.
Jika Anda sedang menggunakan dijamin update dinamis, menambahkan DNSSEC ke zona adalah
proses transparan. Perawatan harus diambil saat menandatangani zona yang dinamis diperbarui untuk
amati langkah-langkah tambahan yang diperlukan.
Catatan Beberapa proses? Dijelaskan sebelumnya dapat diotomatisasi dan bahkan sejumlah alat seperti
sudah ada, beberapa di antaranya diidentifikasi di www.netwidget.net / buku / apress / dns.
Pelaksanaan DNSSEC
Untuk mengilustrasikan proses pelaksanaan DNSSEC, prosedur berikut ini akan
dijelaskan dengan contoh:
• Mengamankan example.com zona menggunakan ZSK terpisah dan KSK
• Membuat terpercaya jangkar untuk example.com di server nama di ns1.example.net
• Mengamankan zona sub.example.com
• Menambahkan RR DS untuk sub.example.com ke example.com untuk menciptakan zona aman delegasi
dalam rantai kepercayaan
• Rolling yang ZSK dan KSK untuk example.com
Contoh-contoh didasarkan pada Angka 11-1 melalui 11-3, disajikan dalam bab sebelumnya.
Mengamankan example.com Zona
The example.com zona, yang akan ditandatangani selama proses ini, adalah sebuah pulau keamanan dan
zona file seperti yang ditunjukkan di sini
$ TTL 86400; 1 hari
$ ORIGIN example.com.
@ IN SOA ns1.example.com. hostmaster.example.com. (
2005032902; serial
10.800; refresh (3 jam)
15; coba lagi (15 detik)
604.800; berakhir (1 minggu)
10.800; minimal (3 jam)
)
DI ns1.example.com NS.
DI ns2.example.com NS.
IN MX 10 mail.example.com.
IN MX 10 mail1.example.com.
_ldap._tcp IN SRV 5 2 235 www
ns1 IN A 192.168.2.6
NS2 IN A 192.168.23.23
www IN A 10.1.2.1
IN A 172.16.2.1
mail IN A 192.168.2.3
mail1 IN A 192.168.2.4
$ ORIGIN sub.example.com.
@ IN NS ns3.sub.example.com.
DI ns4.sub.example.com NS.
NS3 DALAM 10.2.3.4; RR lem
ns4 DALAM 10.2.3.5; RR lem
File zona berisi delegasi untuk subdomain yang disebut sub.example.com, yang diasumsikan
pada titik ini menjadi tidak aman (seperti yang ditunjukkan di awal bab ini dalam Gambar 11-1).
Untuk mengamankan zona example.com akan memerlukan ZSK dan KSK, yang mungkin lagi satu
kunci atau dua kunci terpisah. Untuk keperluan kejelasan dan karena proses secara signifikan
berbeda, contoh menggunakan metode yang disarankan untuk menggunakan kunci terpisah untuk masing-masing ZSK
dan KSK fungsi. Kedua kunci dihasilkan oleh utilitas dnssec-keygen. Contoh berasumsi
bahwa operasi ini akan dilakukan di direktori / var / named / tombol. Untuk menghasilkan ZSK itu,
utilitas dnssec-keygen (lihat Bab 9) dijalankan dengan perintah berikut:
#-Dnssec-keygen-b a rsasha1 example.com zona 1024-n
Kexample.com. 005 03.977
Ini menghasilkan sepasang kunci untuk algoritma-1 tanda tangan digital RSA-SHA, dengan panjang kunci
1024 bit dan catatan zona dengan nama puncak zona, yang dalam hal ini adalah example.com. Itu
respon perintah Kexample.com. 005 03.977 menunjukkan bahwa file Kexample.com 005 03977.. kunci
berisi RR DNSKEY dengan kunci publik dari pasangan kunci, yang akan ditambahkan ke file zona,
dan file Kexample.com 005. 03.977. swasta berisi kunci pribadi yang digunakan dalam penandatanganan berikutnya
operasi. Nilai 03.977 adalah tag-kunci yang secara unik mengidentifikasi kunci ini. Selanjutnya, KSK itu dihasilkan
menggunakan perintah berikut:
#-Dnssec-keygen sebuah rsasha1-b 1400-f-n KSK zona example.com
Kexample.com. 005 12.513
Ini menghasilkan sepasang kunci untuk algoritma-1 tanda tangan digital RSA-SHA, dengan kunci
panjang 1400 bit dan zona DNSKEY RR dengan nama puncak zona, yang dalam hal ini
kasus example.com. Argumen KSK-f menandakan bahwa hal ini akan menghasilkan KSK DNSKEY RR,
ditandai dengan bendera bidang memiliki nilai 257 (bit September diatur). Kendali rincian
DNSKEY RR didefinisikan dalam Bab 13.
Catatan Ukuran kunci dari KSK ini? Diatur ke nilai 1400, sedangkan ukuran kunci ZSK diatur ke 1024.
KSK ini secara signifikan lebih kuat dan oleh karena itu perlu diubah (berguling) dengan frekuensi yang lebih rendah
dari ZSK tersebut. Namun, perlu dicatat bahwa rekomendasi RSA saat ini untuk ukuran kunci adalah 1024, dan
RSA menganggap bahwa kunci lebih besar dari 768 masih kebal dari serangan brute-force.
Tanggapan perintah Kexample.com. 005 12.513 menunjukkan bahwa sebuah file dengan nama
Kexample.com 005 12513.. Kunci berisi RR DNSKEY dengan kunci publik dari pasangan kunci,
yang akan ditambahkan ke file zona, dan file Kexample.com 005 12513.. swasta berisi
kunci pribadi digunakan dalam operasi penandatanganan berikutnya. Nilai 12.513 adalah tag-kunci yang
unik mengidentifikasi kunci ini. The RRS DNSKEY dihasilkan oleh operasi sebelumnya yang terkandung
dalam file Kexample.com 12.513 005. utama (KSK) dan Kexample.com 005 03977.. key..
Ini mungkin diedit ke file zona (seperti yang ditunjukkan dalam "Mengamankan atau Menandatangani Zona" sebelumnya
dalam bab ini) atau termasuk seperti yang ditunjukkan di sini:
$ TTL 86400; 1 hari
$ ORIGIN example.com.
@ IN SOA ns1.example.com. hostmaster.example.com. (
2005032902; serial
10.800; refresh (3 jam)
15; coba lagi (15 detik)
604.800; berakhir (1 minggu)
10.800; minimal (3 jam)
)
DI ns1.example.com NS.
DI ns2.example.com NS.
IN MX 10 mail.example.com.
IN MX 10 mail1.example.com.
_ldap._tcp IN SRV 5 2 235 www
ns1 IN A 192.168.2.6
NS2 IN A 192.168.23.23
www IN A 10.1.2.1
IN A 172.16.2.1
mail IN A 192.168.2.3
mail1 IN A 192.168.2.4
$ ORIGIN sub.example.com.
BAB 11? DNSSEC
@ IN NS ns3.sub.example.com.
DI ns4.sub.example.com NS.
NS3 DALAM 10.2.3.4; RR lem
ns4 DALAM 10.2.3.5; RR lem
kunci $ TERMASUK / Kexample.com 005 12513.. kunci; KSK
kunci $ TERMASUK / Kexample.com 005 03977.. kunci; ZSK
Cara alternatif untuk menambahkan RR DNSKEY langsung ke file sebelumnya akan menggunakan
perintah berikut:
kunci kucing # / Kexample.com 005 12513..> Tombol> master.example.com
kunci kucing # / Kexample.com 005 03977..> Tombol> master.example.com
Karena RR DNSKEY adalah kunci publik, tidak ada persyaratan-metode keamanan baik
benar-benar diterima.
zona ini sekarang sudah siap untuk menandatangani menggunakan perintah dnssec-signzone (lihat Bab 9) sebagai
yang ditampilkan di sini:
# Dnssec-signzone-o example.com-t-k Kexample.com 005 12.513 master.example.com \.
Kexample.com. 005 03.977
master.example.com.signed
Tanda tangan yang dihasilkan: 19
Signatures saldo: 0
Signatures menjatuhkan: 0
Signatures berhasil diverifikasi: 0
Tanda tangan tidak berhasil diverifikasi: 0
Runtime dalam hitungan detik: 0,357
Tanda tangan per detik: 53,079
Tip Kapan? Penandatanganan zona dengan ZSK tunggal, daripada terpisah KSK dan ZSK seperti yang ditunjukkan dalam
contoh, seperti menghilangkan opsi-k.
The \ dalam contoh sebelumnya menunjukkan bahwa garis telah terpecah untuk presentasi
alasan saja, artinya baris pertama dan kedua benar-benar muncul sebagai garis tunggal ke
sistem operasi. argumen-o example.com yang menunjukkan nama dari domain yang
ditandatangani. The-t menampilkan beberapa argumen statistik, yang ditampilkan pada baris berikut.
-K Kexample.com. 005 12.513 menunjukkan bahwa Kexample.com 005. 12.513. Swasta berisi
swasta kunci yang harus digunakan sebagai KSK tersebut. master.example.com adalah nama zona file
akan ditandatangani, dan Kexample.com. 005 03.977 menunjukkan bahwa Kexample.com 005. 03.977. swasta
berisi kunci pribadi yang akan digunakan sebagai ZSK tersebut. Baris pertama dari output yang dihasilkan
adalah master.example.com.signed, yang merupakan nama file default (masukan nama file dengan zona
ditandatangani ditambahkan) dialokasikan jika opsi-f tidak digunakan..
File yang dihasilkan tampak seperti yang ditunjukkan di sini:
; File ditulis pada Senin 18 April 10:48:29 2005
; Dnssec_signzone versi 9.3.0
example.com. 86.400 DI ns1.example.com SOA. hostmaster.example.com. (
2005032902; serial
10.800; refresh (3 jam)
15; coba lagi (15 detik)
604.800; berakhir (1 minggu)
10.800; minimal (3 jam)
)
86.400 RRSIG SOA 5 2 86400 20050518134829 (
3977 20050418134829 example.com.
Pcj36/iCWbY 9 / sq9Dw7 + QaeRbs =)
86.400 NS ns1.example.com.
86.400 NS ns2.example.com.
86.400 RRSIG NS 5 2 86400 20050518134829 (
3977 20050418134829 example.com.
6sfpgAuKarGSbhN3elYozOaBU6c =)
MX 86400 10 mail.example.com.
MX 86400 10 mail1.example.com.
86.400 RRSIG MX 5 2 86400 20050518134829 (
3977 20050418134829 example.com.
2y4QQlM7 + Rs039wLaxA / I 69 d38 =)
10.800 NSEC ldap._tcp.example.com. (MX NS SOA
RRSIG DNSKEY NSEC)
10.800 RSIG NSEC 5 2 10800 20050518134829 (
3977 20050418134829 example.com.
k4T48nVQVZuPBW3aQ0BhlQmYP6c =)
86.400 DNSKEY 256 3 5 (
t/4w8JgeybiVZeHbYXHIljS0kHt8vw ==
); Kunci id = 3977
86.400 DNSKEY 257 3 5 (
1WnVhGKV1I6T01x + u4uNoe1/uocNOQ ==
); Kunci id = 12513
86.400 RRSIG DNSKEY 5 2 86400 20050518134829 (
3977 20050418134829 example.com.
ihcz6BqjNRBFk4vCSGjS2UWdx7M =)
86.400 RRSIG DNSKEY 5 2 86400 20050518134829 (
20050418134829 12.513 example.com.
vv2TqynHfZI8I9GA9zpyd + y/54M =)
_ldap._tcp.example.com. 86400 IN SRV 5 2 235 www.example.com.
86.400 RRSIG SRV 5 4 86400 20050518134829 (
4hzYqMuD + YfCe6CYijkvxaK2AI8 =)
10.800 NSEC mail.example.com. SRV RRSIG NSEC
10.800 RRSIG NSEC 5 4 10800 20050518134829 (
3977 20050418134829 example.com.
8q0gADAR86IvfVUT7eXtRbXhyQg =)
mail.example.com. 86400 IN A 192.168.2.3
86.400 RRSIG A 5 3 86400 20050518134829 (
3977 20050418134829 example.com.
ntx8VinqRDuVGdLv6j1aTZPk26c =)
10.800 NSEC mail1.example.com. Sebuah RRSIG NSEC
10.800 RRSIG NSEC 5 3 10800 20050518134829 (
3977 20050418134829 example.com.
bsjUM4szz6k1kJj1eASDVh + PPdc =)
mail1.example.com. 86400 IN A 192.168.2.4
86.400 RRSIG A 5 3 86400 20050518134829 (
3977 20050418134829 example.com.
s5jnGdHV0zLEN9OooydL5QOq6Bg =)
10.800 NSEC ns1.example.com. Sebuah RRSIG NSEC
10.800 RRSIG NSEC 5 3 10800 20050518134829 (
3977 20050418134829 example.com.
/ Ca0z + gPDCxpgXp9vVBwoCDZyNs =)
ns1.example.com. 86400 IN A 192.168.2.6
86.400 RRSIG A 5 3 86400 20050518134829 (
3977 20050418134829 example.com.
WLwY0eMj29hoehng6Q8MOqP/Fps =)
10.800 NSEC ns2.example.com. Sebuah RRSIG NSEC
10.800 RRSIG NSEC 5 3 10800 20050518134829 (
3977 20050418134829 example.com.
iUm0ZtFd2tlB1kCGd03TWHA6XLE =)
ns2.example.com. 86400 IN A 192.168.23.23
86.400 RRSIG A 5 3 86400 20050518134829 (
3977 20050418134829 example.com.
D5g1Bc235ra + kcgdLy0i5o0xyKs =)
10.800 NSEC sub.example.com. Sebuah RRSIG NSEC
10.800 RRSIG NSEC 5 3 10800 20050518134829 (
3977 20050418134829 example.com.
KrYgcGOtK2EZkbMBpedYBjVLVwE =)
sub.example.com. 86400 IN NS ns3.sub.example.com.
86400 IN NS ns4.sub.example.com.
10.800 NSEC www.example.com. NS RRSIG NSEC
10.800 RRSIG NSEC 5 3 10800 20050518134829 (
3977 20050418134829 example.com.
lwTngtzMsECH + ZsOqza0d8mxORE =)
ns3.sub.example.com. 86400 IN A 10.2.3.4
ns4.sub.example.com. 86400 IN A 10.2.3.5
www.example.com. 86400 IN A 10.1.2.1
86400 IN A 172.16.2.1
86.400 RRSIG A 5 3 86400 20050518134829 (
3977 20050418134829 example.com.
5djR2cKlFB5XUU4uT92hFWGfsKE =)
10.800 NSEC example.com. Sebuah RRSIG NSEC
10.800 RRSIG NSEC 5 3 10800 20050518134829 (
3977 20050418134829 example.com.
8OcJsjO6zzkINiR2nqLUh2GEbvI =)
kategori default (
normal_log;
);
Kategori dnssec (
dnssec_log;
);
);
Pilihan (
....
direktori "/ var / named";
dnssec-aktifkan ya;
memungkinkan-transfer ("none");
....
);
....
zone "example.com" di (
jenis master;
file "master.example.com.signed";
memungkinkan transfer (192.168.23.23;); / / ns2.example.com
memungkinkan-update ("none";);
);
....
Log telah mengalir untuk acara dnssec untuk membantu dalam debugging uji. Log sampel
output akan ditampilkan kemudian pada bagian "DNSSEC Logging" Kerasnya debug 3.; pernyataan harus
tidak akan digunakan untuk produksi, karena akan menghasilkan sejumlah besar data log; bukan keparahan
info; atau yang lebih tinggi harus digunakan. DNSSEC tidak diaktifkan secara default, dan mengaktifkan dnssec ya;
Pernyataan diperlukan dalam klausul opsi global. File zona dalam zona klausa example.com
referensi menandatangani file yang dibuat oleh penandatanganan zona proses sebelumnya. Tidak ada pengobatan khusus
diperlukan pada server budak (ns2.example.com) named.conf yang akan tampak sebagaimana didefinisikan di sini:
/ / Named.conf fragmen untuk ns2.example.com
logging (
saluran normal_log (
file "/ var / log / bernama / normal.log" versi 3 ukuran 2m;
keparahan kesalahan;
print-time yes;
print-beratnya ya;
print-kategori ya;
);
saluran dnssec_log (/ / log streaming dnssec
file "/ var / log / bernama / dnssec.log" versi 3 ukuran 2m;
keparahan debug 3;
print-time yes;
print-beratnya ya;
print-kategori ya;
);
kategori default (
normal_log;
);
Kategori dnssec (
dnssec_log;
);
);
Pilihan (
....
direktori "/ var / named";
dnssec-aktifkan ya;
memungkinkan-transfer ("none");
....
);
....
zone "example.com" di (
jenis budak;
file "slave.example.com.signed";
master (192.168.2.6;); / / ns1.example.com
memungkinkan-update ("none";);
);
....
Memeriksa Zona Signed
Untuk mengkonfirmasi zona tersebut bekerja berhasil, gunakan perintah menggali untuk memverifikasi hasil. Jika normal
menggali perintah dikeluarkan, akan meniru perilaku server nama keamanan-sadar,
dan karena itu tidak ada informasi keamanan akan ditampilkan. Jika opsi dnssec + yang ditambahkan, akan
merespon dengan informasi keamanan seperti yang ditunjukkan pada contoh berikut, yang telah
diterbitkan untuk ns1.example.com, server nama otoritatif untuk zona example.com:
dig@192.168.2.6 www.example.com + dnssec + multiline
; <<>> Dig 9.3.0 <<>> @ 192.168.2.6 www.example.com + dnssec
;; Global pilihan: printcmd
;; Got jawaban:
;; ->> Header <<- opcode: QUERY, status: NOERROR, id: 1307
;; Bendera: qr aa rd ra; QUERY: 1, JAWABAN: 3, KEWENANGAN: 3, TAMBAHAN: 9
;; OPT PSEUDOSECTION:
; EDNS: versi: 0, flag: lakukan; udp: 4096
;; PERTANYAAN BAGIAN:
; Www.example.com. DALAM
;; JAWABAN BAGIAN:
www.example.com. 86400 IN A 10.1.2.1
www.example.com. 86400 IN A 172.16.2.1
www.example.com. 86.400 DI RRSIG A 5 3 86.400 (
20050628180003 20050529180003 46979 example.com.
;; KEWENANGAN BAGIAN:
example.com. 86400 IN NS ns2.example.com.
example.com. 86400 IN NS ns1.example.com.
example.com. 86400 IN NS RRSIG 5 2 86.400 (
20050628180003 20050529180003 46979 example.com.
R8Vsb5sjXJwbJ0D5rcPZocaf2Rz ==)
;; TAMBAHAN BAGIAN:
ns1.example.com. 86400 IN A 192.168.2.6
ns2.example.com. 86400 IN A 192.168.23.23
ns1.example.com. 86.400 DI RRSIG A 5 3 86.400 (
20050628180003 20050529180003 46979 example.com.
jHwcZ18dDvGqmoszU5MUOBbJA ==)
ns2.example.com. 86.400 DI RRSIG A 5 3 86.400 (
20050628180003 20050529180003 46979 example.com.
jzfYhRBXEC5svDCUwJk7U2EPB8 ==)
example.com. 86.400 DI DNSKEY 256 3 5 (
AQPYSk9lcDWan3QTOrI2kTjHz)
example.com. 86.400 DI DNSKEY 257 3 5 (
AQO9gvDKN7WDVeluu3ec)
example.com. 86.400 DI RRSIG DNSKEY 5 2 86.400 (
20050628180003 20050529180003 38070 example.com.
R73FYKx4sjR88smPpEm ==)
example.com. 86.400 DI RRSIG DNSKEY 5 2 86.400 (
20050628180003 20050529180003 46979 example.com.
AoGwqxZxQyvViBmMvyf1k8f ==)
;; Query time: 15 msec
;; SERVER: 192.168.2.6 # 53 (192.168.2.6)
;; KAPAN: Sun 29 Mei 15:26:24 2005
;; MSG SIZE rcvd: 1838
Sekali lagi, demi kepentingan singkatnya, sebagian besar bahan base64 telah dieliminasi, karena
adalah tidak menarik bagi pembaca manusia. Hal-hal berikut harus diperhatikan:
• Pilihan multiline + hanya menambahkan tanda kurung pada setiap RR lama untuk membuat sedikit
format yang mudah dibaca lebih output.
• The PSEUDOSECTION OPT menunjukkan bahwa fitur EDNS0 sedang digunakan dan ukuran blok UDP
dari 4096 byte telah dinegosiasikan untuk digunakan dalam tanggapan yang jauh lebih besar dari DNSSEC
transaksi. OPT meta (atau pseudo) RR sebenarnya ditempatkan di BAGIAN TAMBAHAN,
tapi menggali memilih untuk menampilkan dan format secara terpisah (lihat Bab 15).
• The BAGIAN JAWABAN termasuk RRSIG untuk menutup A RRS kembali dengan permintaan dan
sehingga dapat digunakan untuk otentikasi pada RRset.
• The BAGIAN KEWENANGAN juga termasuk RR RRSIG untuk menutupi RRS NS kembali dan
memungkinkan verifikasi dari seksi ini juga.
Dalam kepentingan singkatnya dan karena tidak menambah nilai bagi pembaca manusia, sebagian besar
base64 materi dalam DNSKEY dan RRSIG RRS telah dihapus. Berikut poin
harus diperhatikan:
• meliputi kunci file sudah diperluas dan pindah ke zona file ditandatangani..
• Nama-nama host telah disortir di nama host (kanonik) ketertiban; khusus,
DNSKEY RRS dari file yang disertakan, maka ns1, NS2, dan RRS www semuanya telah mengatur kembali.
• NSEC RRS telah ditambahkan ke semua RRS rantai melalui file zona dengan pengecualian
dari RRS A dua lem untuk ns3.sub.example.com. dan ns4.sub.example.com. pada titik
delegasi.
• Semua RRsets telah ditandatangani dengan RRSIG RRS dengan pengecualian lem A RRS
untuk ns3.sub.example.com. dan ns4.sub.example.com serta dua RRS NS untuk
sub.example.com. Perlu menjelaskan alasan untuk kelalaian ini. Zona
example.com tidak berwibawa untuk sub.example.com. NS RRS (dan mereka yang terkait
A RRS) untuk delegasi dianggap dimiliki oleh sub.example.com
(Anak itu), tetapi ditempatkan pada example.com (orangtua). Kurangnya signature konsekuensi
fakta bahwa zona ini tidak berwibawa untuk ini, atau delegasi lainnya,
RRS dan karena itu mereka tidak dapat masuk.
• The RRset DNKEY di puncak zona (example.com) telah menandatangani dua kali: satu kali dengan
ZSK dan sekali dengan KSK tersebut.
• The RRS RRSIG berakhir 30 hari dari tanggal waktu mulai (dalam kasus sebelumnya,
20050518134829, yang pada 01:48:29 18 Mei 2005 UTC). zona ini akan memiliki
harus kembali masuk sebelum tanggal ini. Re-sign hanya melibatkan menjalankan yang sama
dnssec perintah-signzone digunakan untuk awalnya tanda zona tersebut.
File zona ditandatangani siap untuk menjadi operasional di ns1.example.com, master utama
untuk zona tersebut, menggunakan fragmen named.conf seperti didefinisikan di sini:
/ / Named.cong fragmen untuk ns1.example.com
logging (
saluran normal_log (
file "/ var / log / bernama / normal.log" versi 3 ukuran 2m;
keparahan kesalahan;
print-time yes;
print-beratnya ya;
print-kategori ya;
);
saluran dnssec_log (/ / log streaming dnssec
file "/ var / log / bernama / dnssec.log" versi 3 ukuran 2m;
keparahan debug 3;
print-time yes;
print-beratnya ya;
print-kategori ya;
);
• The BAGIAN TAMBAHAN berisi seperti yang diharapkan para RRS A untuk nama otoritatif
server dan yang meliputi RRSIG RR. Dalam tambahan, ini juga berisi DNSKEY untuk RRS
KSK dan ZSK untuk zona dan dua RRSIGs (satu ditandatangani dengan ZSK dan
lain yang menggunakan KSK tersebut).
• Flag header tidak termasuk iklan (Data dikonfirmasi) bendera (lihat Bab 15)
karena penggalian ini dikeluarkan untuk salah satu server nama otoritatif untuk zona ditandatangani.
Tugas server nama otoritatif adalah untuk memasok informasi, dan berbagai RRSIGs
DNSKEY RRS, dengan server nama yang menerima dapat melakukan otentikasi. Namun, jika
menggali telah diterbitkan ke server nama keamanan-sadar bahwa tidak berwibawa
untuk zona example.com, maka nama server akan melakukan otentikasi
dan, dengan asumsi itu berhasil, iklan akan bendera telah ditetapkan. Proses ini
digambarkan kemudian dalam bab ini.
pembaca jeli akan diketahui bahwa zona sebelumnya telah ditandatangani kembali di kemudian hari banyak
dari yang ditunjukkan di zona asli penandatanganan contoh sebelumnya, tetapi hal ini tidak berpengaruh pada apapun
hasil.
Membuat Anchor Terpercaya
Contoh ini mengasumsikan bahwa suatu server nama keamanan-sadar di ns1.example.net ingin mengotentikasi
data dari example.com. Server nama ini perlu mendirikan jangkar terpercaya untuk
domain example.com. Administrator memperoleh ns1.example.net oleh beberapa proses aman
yang DNSKEY RR untuk KSK dari example.com domain. Sedangkan RR DNSKEY itu sendiri tidak
informasi sensitif (ini mengandung kunci publik), administrator harus mampu mengotentikasi
sumber kunci, dan karena itu proses distribusi aman seperti e-mail aman atau
FTP aman harus digunakan untuk memperoleh dipercaya jangkar. RR DNSKEY ini tersedia dari
zona file example.com menandatangani ditampilkan sebelumnya dan dikenali sebagai memiliki nilai bendera bidang 257
(Yang mencakup September atau bit KSK):
86.400 DNSKEY 257 3 5 (
1WnVhGKV1I6T01x + u4uNoe1/uocNOQ ==
); Kunci id = 12513
pembaca harus dicatat bahwa banyak dari bahan base64 telah dieliminasi dalam
bunga keringkasan dan bahwa DNSKEY nyata RR akan jauh lebih besar. Yang terpercaya
anchor diciptakan dengan mengedit ini RR DNSKEY menjadi klausa dipercaya-kunci untuk named.conf yang
file di server ns1.example.net, seperti yang ditunjukkan dalam bagian berikut:
/ / Named.conf fragmen untuk ns1.example.net
logging (
saluran normal_log (
file "/ var / log / bernama / normal.log" versi 3 ukuran 2m;
keparahan kesalahan;
print-time yes;
print-beratnya ya;
print-kategori ya;
);
saluran dnssec_log (/ / log streaming dnssec
file "/ var / log / bernama / dnssec.log" versi 3 ukuran 2m;
keparahan debug 3;
print-time yes;
print-beratnya ya;
print-kategori ya;
);
kategori default (
normal_log;
);
Kategori dnssec (
dnssec_log;
);
);
Pilihan (
....
direktori "/ var / named";
dnssec-aktifkan ya;
memungkinkan-transfer ("none");
....
);
dipercaya-kunci (
"Example.com" 257 3 5 "1WnVhGKV1I6T01x + u4uNoe1/uocNOQ ==";
);
....
Klausa dipercaya-tombol berisi jangkar terpercaya untuk example.com dan merupakan versi yang telah diedit
dari RR DNSKEY dibuat dengan menghilangkan TTL dan DNSKEY, dan menambahkan domain
nama dalam tanda kutip (string dikutip yang dapat FQDN, tapi akan bekerja dengan senang hati tanpa
trailing dot); bendera, proto, dan bidang algoritma yang tersisa utuh, dan base64 kunci publik
bahan (tombol-data) ditutup dengan tanda kutip dan diakhiri dengan titik koma. Untuk format penuh
dan tata letak tata letak jangkar terpercaya dalam klausa yang dipercaya-tombol, lihat Bab 12. Sejak
server ini keamanan-sadar, yang dnssec mengaktifkan ya; pernyataan harus disertakan. Log adalah
lagi mengalir dan kerasnya debug 3; digunakan untuk menghasilkan informasi yang mungkin berguna
selama debugging, tapi tidak boleh digunakan dalam produksi kecuali pembaca suka mengelola
log yang besar! Sebaliknya, tingkat keparahan info, atau nilai yang lebih tinggi harus digunakan didasarkan pada kenyamanan dan
pengalaman.
Menggunakan Anchor Terpercaya
Berikut ini perintah menggali diterbitkan ke server ns1.example.net rekursif yang
baik master maupun budak zona zona untuk example.com, tetapi yang telah dikonfigurasi untuk
keamanan menyadari (dengan menggunakan-dnssec memungkinkan ya; pernyataan) dan memiliki terpercaya jangkar untuk zona
example.com (dalam klausa dipercaya-kunci):
dig@ns1.example.net www.example.com
; <<>> Dig 9.3.0 <<>> @ www.example.com ns1.example.net + dnssec + multiline
;; Global pilihan: printcmd
;; Got jawaban:
;; ->> Header <<- opcode: QUERY, status: NOERROR, id: 60711
;; Bendera: iklan qr rd ra; QUERY: 1, JAWABAN: 3, KEWENANGAN: 0, TAMBAHAN: 1
;; OPT PSEUDOSECTION:
; EDNS: versi: 0, flag: lakukan; udp: 4096
;; PERTANYAAN BAGIAN:
; Www.example.com. DALAM
;; JAWABAN BAGIAN:
www.example.com. 86061 IN A 172.16.2.1
www.example.com. 86061 IN A 10.1.2.1
www.example.com. 86.061 DI RRSIG A 5 3 86400 20050628191945 (
3977 20050529191945 example.com.
tbdelN28tzTudlYyjDhy40lUIjXyqQUayzyzAzY =)
;; Query time: 1 msec
;; SERVER: 192.168.254.23 # 53 (ns1.example.net)
;; KAPAN: Sun 29 Mei 23:35:15 2005
;; MSG SIZE rcvd: 247
Sekali lagi, demi kepentingan singkatnya, sebagian besar bahan base64 telah dieliminasi, sejak
itu tidak menarik bagi pembaca manusia. Dalam hal ini, respon secara signifikan lebih pendek dari
yang ditampilkan ketika server otoritatif adalah tanya langsung (ditunjukkan dalam bagian sebelumnya,
"Zona Signed Memeriksa"). Alasannya adalah bahwa nama server 192.168.254.23,
karena keamanan sadar, telah diverifikasi berbagai tanda tangan atas nama kami, dan dikonfirmasi
tindakan dengan menetapkan iklan (Data dikonfirmasi) bendera di header, dan karenanya hanya
hasil query dipasok untuk menggali perintah. Bagian selanjutnya menunjukkan log keamanan
server nama untuk mengkonfirmasi bahwa memang dilakukan validasi ini.
DNSSEC Logging
Berikut ini log output khas menggunakan keamanan streaming penebangan dikonfigurasi sebagai
ditunjukkan dalam contoh fragmen named.conf, ini adalah output yang dihasilkan dari sebelumnya
menggali perintah:
dnssec: memvalidasi www.example.com A: mulai
dnssec: memvalidasi www.example.com A: mencoba validasi respon positif
dnssec: example.com DNSKEY memvalidasi: mulai
dnssec: example.com DNSKEY memvalidasi: mencoba validasi respon positif
dnssec: example.com DNSKEY memvalidasi: memverifikasi rdataset: sukses
dnssec: example.com memvalidasi DNSKEY: ditandatangani oleh dipercaya kunci; menandai sebagai aman
dnssec: validator @ 0x8257800: dns_validator_destroy
dnssec: memvalidasi www.example.com A: di fetch_callback_validator
dnssec: memvalidasi www.example.com A keyset: dengan kepercayaan 7
dnssec: memvalidasi www.example.com A: melanjutkan memvalidasi
memvalidasi www.example.com A: memverifikasi rdataset: sukses
dnssec: memvalidasi www.example.com A: menandai sebagai aman
dnssec: validator @ 0x81ab000: dns_validator_destroy
Demi singkatnya, tanggal dan waktu telah dihapus dari log output ini, yang
menunjukkan kedua Sebuah RRS sedang divalidasi dan menjadi ditandai sebagai aman.
Penandatanganan sub.example.com Zona
Proses untuk menandatangani subdomain pada dasarnya sama dengan yang ditetapkan untuk penandatanganan zona dengan
satu pun perbedaan. The sub.example.com zona adalah anak dari example.com zona aman, atau,
jika Anda suka, example.com adalah induk sub.example.com aman. Sebuah RR Signor dapat didelegasikan
ditambahkan ke example.com zona file untuk menciptakan delegasi aman. The sub.example.com zona akan
bergabung dengan rantai kepercayaan yang aman saat ini entry point adalah example.com. Untuk kejelasan dan kemudahan
tombol rollover, KSK terpisah dan ZSK RR akan digunakan.
Menghasilkan ZSK untuk sub.example.com:
#-Dnssec-keygen-b a rsasha1 sub.example.com zona 1024-n
Ksub.example.com. 005 48.560
Menghasilkan KSK untuk sub.example.com:
#-Dnssec-keygen sebuah rsasha1-b 1400-f-n KSK zona example.com
Ksub.example.com. 005 64.536
Sertakan tombol dalam zona sub.example.com file:
$ TTL 86400; 1 hari
$ ORIGIN sub.example.com.
@ IN SOA ns1.sub.example.com. hostmaster.example.com. (
2005032902; serial
10.800; refresh (3 jam)
15; coba lagi (15 detik)
604.800; berakhir (1 minggu)
10.800; minimal (3 jam)
)
DI ns3.example.com NS.
DI ns4.example.com NS.
IN MX 10 mail.example.com.
NS3 IN A 10.2.3.4
ns4 IN A 10.2.3.5
fred IN A 10.1.2.1
$ TERMASUK Ksub.example.com 005 48560.. Kunci; ZSK
$ TERMASUK Ksub.example.com 005 64536.. Kunci; KSK
Sign sub.example.com zona:
# Dnssec-signzone-o sub.example.com-t-g-k Kexample.com. 005 64.536 \
master.sub.example.com Kexample.com. 005 48.560
master.sub.example.com.signed
Tanda tangan yang dihasilkan: 19
Signatures saldo: 0
Signatures menjatuhkan: 0
Signatures berhasil diverifikasi: 0
Tanda tangan tidak berhasil diverifikasi: 0
Runtime dalam hitungan detik: 0,357
Tanda tangan per detik: 53,079
\ Menunjukkan bahwa garis telah terpecah karena alasan presentasi saja, berarti yang pertama
dan baris kedua benar-benar muncul sebagai garis tunggal untuk sistem operasi. Baris perintah ini adalah
sama dengan bahwa untuk zona example.com menggunakan tombol revisi dan nama zona file, dengan pengecualian
bahwa argumen-g digunakan untuk menghasilkan dua file khusus yang disebut dsset-sub.example.com.
(Berisi RR DS untuk orang tua) dan keyset-sub.example.com. (Berisi salinan publik
DNSKEY kunci RR KSK tersebut). Salah satu atau kedua file mungkin, tergantung pada kebijakan, akan dikirim ke
induk DNS administrator oleh cocok, tapi aman, proses untuk mengaktifkan delegasi aman, penciptaan
dari rantai kepercayaan, yang dijelaskan pada bagian berikutnya. Sementara tidak berisi file aman
informasi (yang berisi data RR normal), sangat penting bahwa penerima dapat mengautentifikasi
maka pengirim dan menciptakan tingkat kepercayaan yang sesuai; sehingga proses aman seperti e-mail aman
atau aman FTP harus selalu digunakan ketika membuat file-file yang tersedia. File named.conf untuk
server master dan slave untuk subdomain ini sama dengan yang digunakan untuk example.com dan
tidak memerlukan perawatan khusus. Karena sub.example.com adalah otentik melalui example.com zona,
tidak ada tindakan yang dibutuhkan pada server nama ns1.example.net klausul-dipercaya-kunci dengan yang terpercaya
jangkar untuk example.com akan mencakup sub.example.com juga melalui rantai kepercayaan.
Menciptakan Rantai Trust
Ketika administrator orangtua menerima dsset-sub.example.com. dan, opsional, yang
keyset-sub.example.com. file, mereka ditempatkan dalam direktori yang sama di mana example.com yang
zona ditandatangani. The dsset-sub.example.com. file yang termasuk dalam zona example.com asli
seperti yang ditunjukkan di sini (lokasi di zona file tidak penting, tetapi perhatikan bahwa nama file
selalu mengakhiri dengan titik):
$ TTL 86400; 1 hari
$ ORIGIN example.com.
@ IN SOA ns1.example.com. hostmaster.example.com. (
2005032902; serial
10.800; refresh (3 jam)
15; coba lagi (15 detik)
604.800; berakhir (1 minggu)
10.800; minimal (3 jam)
)
DI ns1.example.com NS.
DI ns2.example.com NS.
IN MX 10 mail.example.com.
IN MX 10 mail1.example.com.
_ldap._tcp IN SRV 5 2 235 www
ns1 IN A 192.168.2.6
NS2 IN A 192.168.23.23
www IN A 10.1.2.1
IN A 172.16.2.1
mail IN A 192.168.2.3
mail1 IN A 192.168.2.4
$ ORIGIN sub.example.com.
@ IN NS ns3.sub.example.com.
DI ns4.sub.example.com NS.
NS3 DALAM 10.2.3.4; RR lem
ns4 DALAM 10.2.3.5; RR lem
kunci $ TERMASUK / Kexample.com 005 12513.. kunci; KSK
kunci $ TERMASUK / Kexample.com 005 03977.. kunci; ZSK
$ TERMASUK dsset-sub.example.com. ; DS RR
Re-sign zona dengan menjalankan perintah-signzone dnssec persis seperti sebelumnya:
# Dnssec-signzone-o example.com-t-k Kexample.com. 005 12.513 \
master.example.com Kexample.com. 005 03.977
master.example.com.signed
Tanda tangan yang dihasilkan: 20
Signatures saldo: 0
Signatures menjatuhkan: 0
Signatures berhasil diverifikasi: 0
Tanda tangan tidak berhasil diverifikasi: 0
Runtime dalam hitungan detik: 0,357
Tanda tangan per detik: 53,079
The \ dalam contoh sebelumnya menunjukkan bahwa garis telah dilakukan pemecahan dengan alasan presentasi
saja, artinya baris pertama dan kedua benar-benar muncul sebagai garis tunggal untuk operasi
sistem. Satu-satunya yang berubah adalah bahwa garis Signatures telah dihasilkan dari
19 di versi pertama sampai 20 di versi ini karena RR DS tambahan, yang kini
ditandatangani. File zona yang dihasilkan persis sama dengan zona ditandatangani pertama, tetapi dengan
diperbarui kadaluwarsa tanda tangan, dan tambahan DS RR telah ditambahkan dan ditandatangani seperti ditunjukkan pada
fragmen berikut:
sub.example.com. 86400 IN NS ns3.sub.example.com.
86400 IN NS ns4.sub.example.com.
DS 86.400 64.536 5 1 (
CE0711D34D21C069A4C91215C50B4F38E3D5
65D1)
86.400 RRSIG DS 5 3 86400 20050518171727 (
3977 20050418171727 example.com.
RRApmGQ3fKmzbAF7ev4G6eRpWOI =)
10.800 NSEC www.example.com. (NS DS RRSIG
NSEC)
10.800 RRSIG NSEC 5 3 10800 20050518171727 (
3977 20050418171727 example.com.
gNp5LyMVZ8wcH5lNgGpKNJSsfcs =)
ns3.sub.example.com. 86400 IN A 10.2.3.4
ns4.sub.example.com. 86400 IN A 10.2.3.5
www.example.com. 86400 IN A 10.1.2.1
86400 IN A 172.16.2.1
86.400 RRSIG A 5 3 86400 20050518171727 (
3977 20050418171727 example.com.
srHGYT4F2T8IRQTRctl/ZzQa494 =)
10.800 NSEC example.com. Sebuah RRSIG NSEC
10.800 RRSIG NSEC 5 3 10800 20050518171727 (
3977 20050418171727 example.com.
5dkPy1jAM2izam5W9Eri/7PdaXI =)
BIND perlu ulang atau rndc (beku) digunakan untuk mengambil file zona baru.
Karena sub.example.com mendapat otentikasi melalui titik delegasi di example.com,
yang terpercaya jangkar dikonfigurasi di ns1.example.net juga mencakup sub.example.com, dan tidak ada tambahan
konfigurasi yang diperlukan.
Key Rollover
Seperti dijelaskan sebelumnya, ZSK dan KSK yang diperlukan untuk secara periodik diubah, atau terguling
atas, baik menggunakan sebuah prepublish atau strategi ganda penandatanganan. Secara umum, paling baik digunakan prepublish
untuk ZSKs dan menandatangani ganda untuk KSKs. Proses rollover kunci kacau tapi tidak sulit,
dan cocok untuk tingkat otomatisasi script atau lainnya, misalnya, berjalan dari cron.
Catatan Saat melakukan re-sign zona?, Untuk rollover kunci atau normal zona penandatanganan prosedur pemeliharaan,
pada zona yang diperbaharui secara dinamis, maka prosedur tambahan didokumentasikan dalam "Dynamic DNS
dan DNSSEC "dalam bab ini harus diikuti.
Prepublish ZSK Rollover
Tujuan dalam strategi prepublish adalah untuk mendapatkan DNSKEY saat ini dan baru RRS ke
cache semua server nama keamanan-sadar. Hal ini dilakukan dengan terlebih dahulu menambahkan ZSK baru untuk zona
file. Contoh ini akan mengasumsikan bahwa file zona ditandatangani untuk example.com ciptakan sebelumnya dengan
sebuah ZSK saat ini kunci-tag dari 03.977 dan KSK saat ini kunci-tag hanya akan memiliki 12.513 ZSK yang
(Kunci-tag dari 03.977) digulung. Dengan melihat file zona, yang TTL terpanjang adalah 24 jam (86.400 detik).
Setidaknya dua hari sebelum tanda tangan zona berakhir atau sebelum ZSK baru yang diperlukan,
sebuah ZSK baru dibuat menggunakan perintah berikut:
#-Dnssec-keygen-b a rsasha1 example.com zona 1024-n
Kexample.com. 005 39.539
The ZSK baru termasuk dalam zona file:
$ TTL 86400; 1 hari
$ ORIGIN example.com.
@ IN SOA ns1.example.com. hostmaster.example.com. (
2005032902; serial
10.800; refresh (3 jam)
15; coba lagi (15 detik)
604.800; berakhir (1 minggu)
10.800; minimal (3 jam)
)
DI ns1.example.com NS.
DI ns2.example.com NS.
IN MX 10 mail.example.com.
IN MX 10 mail1.example.com.
_ldap._tcp IN SRV 5 2 235 www
ns1 IN A 192.168.2.6
NS2 IN A 192.168.23.23
www IN A 10.1.2.1
IN A 172.16.2.1
mail IN A 192.168.2.3
mail1 IN A 192.168.2.4
$ ORIGIN sub.example.com.
@ IN NS ns3.sub.example.com.
DI ns4.sub.example.com NS.
NS3 DALAM 10.2.3.4; RR lem
ns4 DALAM 10.2.3.5; RR lem
kunci $ TERMASUK / Kexample.com 005 12513.. kunci; KSK
kunci $ TERMASUK / Kexample.com 005 03977.. kunci; ZSK saat ini
$ TERMASUK dsset-sub.example.com. ; DS RR
kunci $ TERMASUK / Kexample.com 005 39539.. kunci; ZSK baru
Zona ditandatangani menggunakan ZSK saat ini dan KSK-tidak ada perubahan pada perintah
digunakan dalam bagian sebelumnya:
# Dnssec-signzone-o example.com-t-k Kexample.com. 005 12.513 \
master.example.com Kexample.com. 005 03.977
master.example.com.signed
Tanda tangan yang dihasilkan: 20
Signatures saldo: 0
Signatures menjatuhkan: 0
Signatures berhasil diverifikasi: 0
Tanda tangan tidak berhasil diverifikasi: 0
Runtime dalam hitungan detik: 0,357
Tanda tangan per detik: 53,079
\ Menunjukkan bahwa garis telah terpecah karena alasan presentasi saja, berarti yang pertama
dan baris kedua benar-benar muncul sebagai garis tunggal untuk sistem operasi. Ketika file tersebut ditandatangani,
BIND adalah baik reloaded atau rndc (beku) perintah yang digunakan untuk me-refresh file zona. Itu
DNSKEY RRset di puncak zona seperti yang ditampilkan di sini:
86.400 DNSKEY 256 3 5 (
AQPCf56dKVA + TAzVQVedURNd/twKcbg0z
t/4w8JgeybiVZeHbYXHIljS0kHt8vw ==
); Kunci id = 3977
86.400 DNSKEY 256 3 5 (
AQPCrtJceGC5REQ4khX5VKSvnlWgBxH / 1
dV0aRDNEebrwNVohBMEVI1j3Nh7UIQ ==
); Kunci id = 39539
86.400 DNSKEY 257 3 5 (
AQPnvgDqCShrBmFEh5vW7kM4DG/kMwa3E
1WnVhGKV1I6T01x + u4uNoe1/uocNOQ ==
); Kunci id = 12513
86.400 RRSIG DNSKEY 5 2 86400 20050518182149 (
3977 20050418182149 example.com.
0yWzCmieTtR2bES6l + KFXBOosv8 =)
86.400 RRSIG DNSKEY 5 2 86400 20050518182149 (
20050418182149 12.513 example.com.
IQ0teNohrH5oZ1 2 EM22LrPFHrk =)
_ldap._tcp.example.com. 86400 IN SRV 5 2 235 www.example.com.
The DNSKEY baru RR (yang DNSKEY kedua RR ditampilkan sebelumnya) sekarang tersedia di
DNSKEY RRset di puncak zona di tempat yang dapat digunakan oleh server nama keamanan-sadar untuk mencoba
dan memverifikasi tanda tangan. Pada titik ini, semua upaya tersebut akan gagal karena tidak ada catatan RRSIG
menggunakan kunci ini. Ingat, bagaimanapun, bahwa server nama diberi mandat untuk mencoba semua DNSKEY RRS tersedia,
sehingga ZSK saat ini juga akan digunakan dan RRSIGs akan divalidasi. Setelah 24 jam dari
zona yang mengisi, semua server nama keamanan-sadar menggunakan zona example.com akan dijamin
baik memiliki DNSKEY RRset baru dalam cache atau timeout versi lama,
yang hanya memiliki KSK saat ini dan ZSK saat ini.
Setelah jangka waktu 24 cache propagasi jam telah berlalu, zona tersebut masih masuk kembali dengan menggunakan
KSK seperti sebelumnya dan ZSK baru (kunci-tag dari 39.539) menggunakan perintah berikut:
# Dnssec-signzone-o example.com-t-k Kexample.com. 005 12.513 \
master.example.com Kexample.com. 005 39.539
master.example.com.signed
Tanda tangan yang dihasilkan: 20
Signatures saldo: 0
Signatures menjatuhkan: 0
Signatures berhasil diverifikasi: 0
Tanda tangan tidak berhasil diverifikasi: 0
Runtime dalam hitungan detik: 0,357
Tanda tangan per detik: 53,079
BAB 11? DNSSEC 319
\ Menunjukkan bahwa garis telah terpecah karena alasan presentasi saja, berarti yang pertama
dan baris kedua benar-benar muncul sebagai garis tunggal untuk sistem operasi. Semua RRSIG RRS
kini telah ditandatangani dengan ZSK baru. Sekali lagi, BIND adalah mengisi atau rndc digunakan untuk me-refresh
zona. Setelah jangka waktu 24-jam lagi, semua server nama keamanan-sadar yang menggunakan example.com yang
zona akan memiliki DNSKEY baru RRset baik atau memiliki cache timeout yang DNSKEY RRset tua.
Setiap kali setelah zona file ini dapat dimodifikasi untuk menghapus ZSK sebelumnya (kunci-tag adalah 03.977),
zona kembali menandatangani-menggunakan ZSK baru (kunci-tag adalah 39.539) seperti pada perintah sebelumnya dan
kemudian reloaded. Tidak ada urgensi tertentu untuk menghapus kunci lama dan untuk meminimalkan ulang penandatanganan
operasi; ini dapat ditunda sampai baik zona berikutnya dijadwalkan kembali menandatangani atau berikutnya
dijadwalkan tombol rollover.
Double-penandatanganan KSK Rollover
Ingat hanya tanda KSK yang RRset DNSKEY di puncak zona. Strategi ganda penandatanganan
menggunakan dua KSKs untuk menandatangani RRset. Sekali lagi, misalnya file yang dibuat sebelumnya dan sekarang ditandatangani
dengan ZSK baru akan digunakan sebagai titik awal untuk rollover KSK. Buat KSK baru menggunakan
perintah berikut:
#-Dnssec-keygen sebuah rsasha1-b 1024-f KSK example.com zona 1024-n
Kexample.com. 005 50.148
DNSKEY baru ini termasuk dalam zona master.example.com file:
$ TTL 86400; 1 hari
$ ORIGIN example.com.
@ IN SOA ns1.example.com. hostmaster.example.com. (
2005032902; serial
10.800; refresh (3 jam)
15; coba lagi (15 detik)
604.800; berakhir (1 minggu)
10.800; minimal (3 jam)
)
DI ns1.example.com NS.
DI ns2.example.com NS.
IN MX 10 mail.example.com.
IN MX 10 mail1.example.com.
_ldap._tcp IN SRV 5 2 235 www
ns1 IN A 192.168.2.6
NS2 IN A 192.168.23.23
www IN A 10.1.2.1
IN A 172.16.2.1
mail IN A 192.168.2.3
mail1 IN A 192.168.2.4
$ ORIGIN sub.example.com.
@ IN NS ns3.sub.example.com.
DI ns4.sub.example.com NS.
NS3 DALAM 10.2.3.4; RR lem
ns4 DALAM 10.2.3.5; RR lem
kunci $ TERMASUK / Kexample.com 005 12513.. kunci; KSK saat ini
kunci $ TERMASUK / Kexample.com 005 50148.. kunci; KSK baru
$ TERMASUK dsset-sub.example.com. ; DS RR
kunci $ TERMASUK / Kexample.com 005 39539.. kunci; ZSK baru
Zona ditandatangani dengan perintah berikut:
# Dnssec-signzone-o example.com-t-k Kexample.com. 005 12.513 \
K-005 50.148 Kexample.com master.example.com Kexample.com.. 005 39.539
master.example.com.signed
Tanda tangan yang dihasilkan: 21
Signatures saldo: 0
Signatures menjatuhkan: 0
Signatures berhasil diverifikasi: 0
Tanda tangan tidak berhasil diverifikasi: 0
Runtime dalam hitungan detik: 0,357
Tanda tangan per detik: 53,079
\ Menunjukkan bahwa garis telah terpecah karena alasan presentasi saja, berarti yang pertama
dan baris kedua benar-benar muncul sebagai garis tunggal untuk sistem operasi. Perintah memiliki
argumen dua-k, menunjukkan RRset DNSKEY akan ditandatangani tiga kali, setelah masing-masing dengan
saat ini dan baru KSK dan sekali dengan ZSK tersebut. Perhatikan juga bahwa Signatures garis telah dihasilkan
meningkat sampai 21 untuk mengkonfirmasi ini. BIND sekarang harus ulang atau rndc (beku) perintah
digunakan untuk menyegarkan zona tersebut. DNSKEY fragmen file zona RRset tampak seperti yang ditunjukkan di sini dengan
tiga RRSIG RRS meliputi RRset DNSKEY:
86.400 DNSKEY 256 3 5 (
AQPCrtJceGC5REQ4khX5VKSvnlWgBxH/1xpg
dV0aRDNEebrwNVohBMEVI1j3Nh7UIQ ==
); Kunci id = 39539
86.400 DNSKEY 257 3 5 (
AQPZjeWTe9q9980o2XWmaaMYNb9xxMDdwHNH
waQ5CQ6tVQwg5udwmnWTJt5ryBI + DQ ==
); Kunci id = 50148
86.400 DNSKEY 257 3 5 (
AQPnvgDqCShrBmFEh5vW7kM4DG/kMwa3EBnP
1WnVhGKV1I6T01x + u4uNoe1/uocNOQ ==
); Kunci id = 12513
86.400 RRSIG DNSKEY 5 2 86400 20050518190823 (
20050418190823 12.513 example.com.
ZI95WgwWViUm7YYe2dwznC5M17Q =)
86.400 RRSIG DNSKEY 5 2 86400 20050518190823 (
20050418190823 39.539 example.com.
wLonbgY9l3DigWoLb6zDZxlnEVQ =)
86.400 RRSIG DNSKEY 5 2 86400 20050518190823 (
20050418190823 50.148 example.com.
Ovu + uuC8LYj8561OsmDlNE9pzVY =)
BAB 11? DNSSEC
Ringkasan
Bab ini menjelaskan teori dan implementasi DNSSEC (bahasa sehari-hari dikenal sebagai
DNSSEC.bis), yang merupakan generasi kedua dari standar yang digunakan untuk memastikan keaslian
dan integritas data yang diberikan dari server nama otoritatif yang sesuai dikonfigurasi ke
server keamanan-sadar meminta nama. DNSSEC standar menggunakan kunci publik (asimetrik) kriptografi
untuk memastikan bahwa data yang disediakan sebagai tanggapan atas permintaan untuk, misalnya, www.example.com,
hanya bisa datang dari example.com domain (keaslian), bahwa data yang diterima oleh
query nama server adalah sama dengan data yang dikirim oleh server nama query (integritas data),
dan bahwa dalam acara www.example.com tidak ada, dapat membuktikan bahwa seperti halnya
BAB 11? DNSSEC 327
(Bukti tiadanya atau penolakan eksistensi). Transaksi keamanan, digunakan untuk mengamankan operasi
seperti DDNS atau zona transfer, yang dibahas pada Bab 10.
Bab ini menjelaskan pembentukan pulau keamanan dimana tunggal, tidak terhubung
mungkin zona aman, atau sekelompok pulau-pulau terpencil seperti yang merupakan bagian dari suatu afinitas
atau kelompok kepentingan umum, seperti jaringan perusahaan, dapat dijamin. Dalam hal ini, untuk mendapatkan
cakupan zona keamanan membutuhkan jangkar dipercaya-kunci publik yang digunakan untuk menandatangani dijamin
zona-yang diperoleh melalui proses yang aman yang mengotentikasi sumber dan kemudian dikonfigurasi
ke semua server nama keamanan-sadar yang ingin memvalidasi tanggapan untuk zona menggunakan
dipercaya-kunci klausa. Mengamankan zona yang melibatkan penggunaan sebuah kunci pribadi untuk digital sign semua
RRsets di zona itu menggunakan jenis RRSIG RR. Setelah didirikan, zona aman bisa dihubungkan
bersama-sama ke dalam rantai kepercayaan menggunakan poin delegasi mereka, sehingga jika example.com dijamin, mungkin
dihubungkan ke com. gTLD atau mungkin didelegasikan kepada sub.example.com aman. Proses ini
dicapai dengan menggunakan didelegasikan Signor RR, yang ditambahkan ke dalam domain induk dan mengamankan
delegasi ke domain anak. Kunci publik digunakan dalam menandatangani didefinisikan di zona file
menggunakan DNSKEY RRS dan dikategorikan baik sebagai Zona Penandatanganan kunci, yang digunakan untuk menandatangani
catatan dalam file zona dan Penandatanganan Kunci kunci, yang digunakan untuk menandatangani hanya RRS DNSKEY
digunakan dalam proses penandatanganan dan dapat digunakan secara eksternal baik sebagai jangkar terpercaya atau dirujuk
oleh RR DS. Sementara standar memungkinkan DNSKEY tunggal RR yang akan digunakan untuk kedua ZSK dan KSK
tujuan, ini bukan kegiatan yang direkomendasikan. Bukti noneksistensi disediakan oleh NSEC
RRS, yang bersama-sama semua rantai RRS dalam zona file. Cryptographic kunci perlu
berubah baik secara berkala untuk meminimalkan risiko atau segera dalam kasus di mana tombol dikenal
untuk dikompromikan. Proses ini, disebut rollover kunci, dapat menggunakan salah satu atau doublesigning prepublish
strategi, baik dari yang digambarkan. Akhirnya, contoh-contoh yang menggambarkan pelaksanaan
dari DNSSEC dan mencakup semua poin yang sebelumnya disajikan.
DNSSEC memberikan manfaat yang sangat positif tetapi memperkenalkan tingkat baru disiplin, khususnya
sehubungan dengan waktu-tanda tangan (RRSIG RRS) dalam file zona dijamin memiliki validitas terbatas
periode dan dengan demikian perlu kembali ditandatangani secara berkala. Jika tanda tangan dibiarkan
berakhir, data dari zona akan ditandai sebagai palsu dengan menerima server keamanan-sadar.
Bab selanjutnya menjelaskan, dengan contoh-contoh dimana tepat, laporan dan klausa
digunakan dalam named.conf, file konfigurasi yang mengendalikan perilaku operasional BIND's
