Server DNS sudah menggunakan siaran apa pun. Apakah menambahkan lebih banyak IP akan meningkatkan skalabilitas?


9

RFC 1034 mengharuskan kami untuk menetapkan setidaknya dua alamat IP untuk server DNS. Namun, redundansi sudah dapat dicapai dengan satu alamat IP jika kita menggunakan pengalamatan siaran apa pun. BGP anycast tampaknya berskala baik menjadi ratusan atau bahkan ribuan server.

Jika demikian, mengapa kita masih membutuhkan beberapa alamat IP untuk server DNS? Apakah ini benar-benar meningkatkan redundansi (berkontribusi ketersediaan) jika kita sudah memiliki siaran, atau hanya mitos?

Masalah dan kesalahan apa yang bisa kita hadapi jika kita hanya menggunakan satu alamat IP?

Maksud saya, benar-benar menghilangkan alamat DNS sekunder, atau menggunakan IP palsu (mis. 1.2.3.4) Untuk alamat kedua ketika beberapa pengaturan memerlukan setidaknya dua.

Jawaban:


16

Sebuah alamat IP anycast tunggal tidak memberi Anda redundansi yang sama dengan dua alamat IP unicast dalam awalan IP yang berbeda.

Seringkali masalah yang paling sulit untuk redundansi bukanlah ketika sesuatu gagal sepenuhnya, tetapi ketika terjadi kesalahan hanya cukup untuk tetap melewati pemeriksaan kesehatan, tetapi sebenarnya tidak berfungsi.

Saya telah melihat pengaturan DNS siaran mana pun di mana server DNS turun, tetapi paket-paket masih akan dialihkan ke server DNS itu. Apa pun yang mengurus iklan awalan mungkin tidak menyadari, bahwa server DNS telah turun.

Itu menjadi lebih rumit jika server DNS yang dimaksud bukan server DNS yang otoritatif, tetapi lebih sebagai penyelesai rekursif.

Penyelesai rekursif seperti itu harus memiliki kedua alamat broadcast untuk menerima permintaan dari klien dan alamat unicast untuk menanyakan server DNS yang otoritatif. Tetapi jika alamat unicast turun, itu bisa dengan mudah terlihat cukup sehat sehingga masih akan dialihkan kueri.

Anycast adalah alat yang hebat untuk skalabilitas dan mengurangi latensi. Tetapi untuk redundansi seharusnya tidak berdiri sendiri.

Namun, beberapa kumpulan siaran yang redundan adalah solusi yang bagus untuk ketersediaan. Contoh yang terkenal adalah 8.8.8.8 dan 8.8.4.4. Keduanya adalah alamat broadcast, tetapi mereka tidak boleh dialihkan ke server DNS fisik yang sama (dengan asumsi Google melakukan pekerjaannya dengan baik).

Jika Anda memiliki 10 server DNS fisik, Anda dapat mengonfigurasinya sebagai 2 kelompok dengan 5 server di setiap kelompok atau 5 kelompok dengan 2 di setiap kelompok. Anda ingin menghindari satu server DNS fisik berada di beberapa kumpulan secara bersamaan.

Jadi, berapa banyak IP yang harus Anda alokasikan? Anda harus memiliki IP yang dapat dikonfigurasikan sebagai siaran mana pun secara terpisah. Itu biasanya berarti Anda harus mengalokasikan seluruh / 24 ruang alamat IPv4 atau / 48 ruang alamat IPv6 untuk setiap kelompok. Ini mungkin sangat membatasi jumlah kolam yang bisa Anda miliki.

Selain itu jika kita berbicara server otoritatif, balasan DNS dengan semua catatan NS Anda dan lem A dan AAAA harus sesuai dengan paket 512 byte tunggal. Untuk server root, ini berhasil ke 13 alamat. Tapi itu tidak termasuk lem dan IPv6, jadi jumlah yang Anda jangkau akan lebih rendah.

Setiap kumpulan harus didistribusikan secara geografis mungkin. Jika Anda memiliki 5 server di Eropa dan 5 di Noth America dan 2 IP broadcast, Anda tidak membuat satu kumpulan yang mencakup setiap benua. Anda menempatkan 2 dari Eropa di kolam dengan 3 dari Amerika Utara, dan 5 lainnya di kolam lain.

Jika Anda memiliki lebih dari 2 kumpulan siaran, Anda dapat membiarkan server fisik sementara berada di lebih dari satu kumpulan. Tetapi Anda tidak boleh membiarkan server fisik berada di semua kolam pada saat yang sama.

Kombinasi anycast dan unicast adalah mungkin, tetapi harus diperhatikan. Jika Anda memiliki IP untuk dua kelompok, saya tidak akan menggabungkan. Tetapi jika Anda hanya memiliki satu IP broadcast mana pun untuk bekerja, mungkin masuk akal untuk memasukkan IP unicast. Masalahnya adalah bahwa termasuk IP unicast tidak akan memberi Anda latensi dan load balancing yang baik.

Jika server fisik disediakan oleh unicast dan anycast, Anda dapat mengambil risiko pengguna mencapai server yang sama seperti primer dan sekunder dan kehilangan akses jika turun. Hal ini dapat dihindari dengan hanya menggunakan alamat server unicast yang tidak ada dalam kumpulan siaran atau dengan selalu memberikan dua alamat unicast kepada pengguna.

Semakin banyak alamat unicast yang Anda masukkan ke dalam campuran, semakin sedikit kueri yang akan dikirim ke alamat anycast, dan semakin sedikit manfaat yang Anda dapatkan dari anycast dalam hal latensi dan skalabilitas.


Maksud Anda cara terbaik untuk mencapai skalabilitas adalah dengan menggunakan banyak alamat unicast sekunder (alias cara lama mengatur ns1.domain, ns2.d, ns3.d ... ns300.d) daripada menggunakan anycast?
Pacerier

@ Peracer Tidak, bukan itu yang saya maksud. Saya akan menjelaskannya dalam jawaban saya.
kasperd

+1. Kesalahan perutean bahkan dapat menyebabkan unicast Anda masuk neraka (jalan buntu). Memiliki alamat terpisah kedua berarti Anda memiliki lebih dari satu "tiket" untuk itu;)
TomTom

2
+1 Saya ingin menambahkan bahwa menambahkan ip palsu karena alamat kedua terdengar seperti ide yang menghebohkan
Reaces

1
@Pacerier Anda mendapatkan penyeimbangan beban dengan menggunakan beberapa alamat unicast. Masalahnya adalah latensi, klien tidak tahu IP mana yang dekat dan mana yang jauh. Itu juga tidak bisa skala sejauh ini. Anda hanya bisa menggunakan sekitar 5 server, jika Anda ingin catatan lem A dan AAAA sesuai dengan 512 byte. Menggabungkan satu anycast dan beberapa unicast bermasalah untuk menyeimbangkan beban, karena Anda cenderung mendapatkan lebih banyak beban pada alamat unicast daripada pada alamat anycast.
kasperd

4

Praktik terbaik adalah menggunakan setidaknya dua alamat dari awalan yang berbeda dan memberi mereka nama di bawah dua TLD yang berbeda. Kedua alamat tersebut dapat disiarkan jika Anda mau. Hanya memiliki satu alamat IP akan memberi Anda satu titik kegagalan. Jika perutean ke alamat itu tidak berfungsi (kesalahan konfigurasi, instance anycast tidak berfungsi dengan benar, awalan dibajak dll) maka seluruh domain Anda menjadi tidak terjangkau.

Setiap alamat broadcast mana pun akan memerlukan setidaknya /24IPv4 atau /48awalan IPv6 untuk dapat dirutekan di BGP. Awalan yang lebih kecil (lebih lama) biasanya tidak akan diterima di tabel perutean global di banyak tempat.

Jangan pernah memasukkan alamat IP palsu sebagai server DNS. Ini akan menyebabkan keterlambatan parah untuk resolvers.


Lebih buruk lagi, bahwa alamat IP "palsu" adalah alamat orang lain. Mereka akan menerima pertanyaan. Jika mereka jengkel dengan semua lalu lintas itu, mereka bisa mengirim balasan dengan TTL tinggi untuk membuatnya pergi untuk sementara waktu.
kasperd

@kasperd, Bagaimana khusus diperuntukkan alamat IP yang dimiliki tidak ada?
Pacerier

1
@Pacerier Menggunakan ruang alamat RFC 1918, 4193, atau 6598 akan membatasi bahaya. Tetapi itu masih akan menyebabkan resolusi diperlambat atau bahkan gagal.
kasperd

3

RFC 1034 hanya menyatakan bahwa Anda memerlukan dua server DNS. Ini bukan persyaratan wajib, tetapi rekomendasi, jadi lakukan sesuai keinginan Anda. Apa pun yang terjadi, jika Anda menginginkan HA, 2 server DNS Anda dapat diberi IP yang sama menggunakan siaran mana pun, dan satu-satunya hal yang akan diketahui pengguna akhir Anda ketika satu server DNS gagal, adalah konektivitas yang tidak ada saat koneksi jaringan kembali.

Jadi secara ringkas, ya menggunakan siaran apa pun sudah cukup untuk memenuhi persyaratan RFC 1034.


Hmm, jika hanya satu alamat IP yang dibutuhkan, mengapa Google menawarkan dua alamat ( 8.8.8.8dan 8.8.4.4) untuk server DNS mereka? Mereka sudah memiliki siaran, jadi mengapa tidak menawarkan satu alamat saja 8.8.8.8?
Pacerier

1
Saya kira saya akan mengatakan tidak mengganggu konektivitas selama konvergensi jaringan? Karena mereka adalah pemain global dan ingin memastikan mereka memiliki cakupan seluas mungkin untuk menghilangkan kemungkinan titik kegagalan? Saya tidak sepenuhnya yakin, tapi saya tahu kita semua tidak bisa menjadi google :)
Reaces
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.