Bagaimana 8.8.8.8 disimpan * selalu * hidup?

Saya tahu bagaimana Anda dapat mengelola redundansi pusat data jika ada server DNS yang berfungsi yang dapat menunjuk ke situs kerja perusahaan Anda - ada VRRP, multi WAN dll. Tetapi bagaimana server DNS itu sendiri tetap online? Ini hit pertama ketika seseorang terhubung ke layanan dan itu tidak dapat benar-benar disediakan. Maksud saya misalnya 8.8.8.8atau 8.8.4.4. Saya tidak ingat mereka sedang down. Pernah. Bagaimana ISP mengatur agar IP seperti itu selalu online?

Saya tahu itu mungkin pertanyaan yang sangat luas tetapi saya ingin mendengar hanya nama protokol / teknik yang dapat digunakan untuk itu. Saya dapat membaca detail tentang mereka sendiri.

Pertama-tama, VRRP tidak bergantung pada DNS dengan cara apa pun. Untuk redundansi dalam satu situs, Anda dapat menjalankan server DNS pada alamat VRRP bersama dengan baik.

Tetapi seperti yang lain telah disebutkan dalam komentar, layanan ini juga menggunakan perutean siaran , yang pada dasarnya berarti bahwa alamat IP yang sama ada di banyak tempat di seluruh dunia. Ketika seluruh situs turun, rute di seluruh dunia dihitung ulang sehingga paket Anda akhirnya pergi ke situs lain yang berfungsi.

Sebuah contoh yang baik dari DNS publik Google akan menjadi akar DNS server - yang yang melayani .zona dan terus pointer ke com, org, eu, dan sebagainya - karena mereka memiliki peta dari setiap contoh dari 13 alamat logis. "L" ICANN dilayani oleh 160 situs berbeda!

Perhatikan bahwa anycast tidak ada hubungannya dengan round-robin berbasis DNS (di mana nama yang sama memiliki beberapa alamat). Anycast dilakukan pada dasarnya dengan berbohong kepada protokol routing.

Internet menggunakan BGP untuk bertukar informasi perutean antar organisasi.

BGP secara inheren mendukung pemilihan rute terbaik dari beberapa rute menuju jaringan yang sama, berdasarkan berbagai kriteria. Sebagai contoh, pelanggan yang sama mungkin memiliki uplink yang berlebihan ke ISP yang sama (mengumumkan dua rute hanya berbeda dalam berat / preferensi). Atau pelanggan mungkin memiliki uplink melalui beberapa ISP, dan semua orang akan memilih rute pilihan mereka (terutama jalur AS terpendek) - itulah inti dari multi-WAN "benar".

Multihoming

                  ┌────────[AS 65535]────────┐
client 1 ---ISP---│--BGProuter--+            │
             ¦    │             ¦--DNSserver │
client 2 ---ISP---│--BGProuter--+            │
                  └──────────────────────────┘

Namun, BGP hanya mengarahkan lalu lintas ke pintu masuk Anda tetapi tidak peduli apa yang terjadi di luar itu. Jadi jika Anda secara internal mengatur kedua rute menuju server yang sama, Anda mendapatkan multihoming. Tetapi jika setiap "pintu masuk" mengarah ke server yang berbeda (dikonfigurasi untuk IP yang sama), Anda mendapatkan siaran apa pun.

Anycast... kind of?

                  ┌────────[AS 65535]────────┐
client 1 ---ISP---│--BGProuter-----DNSserver │
             ¦    │                          │
client 2 ---ISP---│--BGProuter-----DNSserver │
                  └──────────────────────────┘

Yang penting, ini juga berarti bahwa BGP tidak peduli jika AS tidak bersebelahan sama sekali. Untuk mendapatkan redundansi di seluruh dunia, cukup mengumumkan jaringan yang sama dari beberapa lokasi fisik - jika Anda menghubungkan lokasi-lokasi tersebut bersama-sama (sehingga mereka merutekan jaringan itu ke satu tempat), Anda mendapatkan multihoming; jika mereka pulau, Anda mendapatkan siaran.

Anycast

                  ┌────────[AS 65535]────────┐
client 1 ---ISP---│--BGProuter-----DNSserver │
             ¦    └──────────────────────────┘
             ¦
             ¦    ┌────────[AS 65535]────────┐
client 2 ---ISP---│--BGProuter-----DNSserver │
                  └──────────────────────────┘

(Dalam hal ini, bahkan tidak perlu AS yang sama - misalnya relai 6to4 dijalankan oleh beberapa organisasi independen, masing-masing mengumumkan rute mereka sendiri 192.88.99.0/24.)

Peringatan:

• Anycast memberikan redundansi, tetapi tidak menyeimbangkan beban. Setelah BGP bertemu, setiap router akan memilih satu rute yang disukai (atau kadang-kadang beberapa) dan akan terus menggunakannya sampai jaringan berubah.

• Namun, Anda tidak dapat memprediksi berapa lama rute akan tetap stabil, sehingga layanan penyiaran apa pun bisa rumit. DNS lolos begitu saja karena tidak memiliki kewarganegaraan dan terutama menggunakan UDP (EDNS mengurangi kebutuhan koneksi TCP).

• Harus ada koordinasi antara layanan aktual dan router BGP, sehingga rute ditarik jika layanan macet.

Lihat juga "Sejarah 4.2.2.2. Apa ceritanya?" pada milis NANOG: posting 1 , posting 2 .

Salah satu cara untuk mencapai itu adalah menggunakan penyeimbang sisi server . Saat Anda terhubung ke gateway di IP 8.8.8.8, ia akan mendistribusikan permintaan ke satu server gratis di dalam sistem. Akibatnya ketika satu server mati itu tidak menurunkan seluruh sistem.

Untuk layanan Internet, penyeimbang beban sisi server biasanya merupakan program perangkat lunak yang mendengarkan pada port tempat klien eksternal terhubung ke layanan akses. Load balancer meneruskan permintaan ke salah satu server "backend", yang biasanya membalas ke load balancer. Ini memungkinkan penyeimbang beban untuk membalas klien tanpa klien pernah tahu tentang pemisahan fungsi internal. Ini juga mencegah klien untuk menghubungi server back-end secara langsung, yang mungkin memiliki manfaat keamanan dengan menyembunyikan struktur jaringan internal dan mencegah serangan pada tumpukan jaringan kernel atau layanan yang tidak terkait yang berjalan pada port lain.

Beberapa penyeimbang beban menyediakan mekanisme untuk melakukan sesuatu yang istimewa jika semua server backend tidak tersedia. Ini mungkin termasuk meneruskan ke penyeimbang beban cadangan, atau menampilkan pesan tentang pemadaman.

Penting juga bahwa penyeimbang beban itu sendiri tidak menjadi titik kegagalan tunggal. Biasanya load balancers diimplementasikan pada pasangan dengan ketersediaan tinggi yang juga dapat mereplikasi data persistensi sesi jika diperlukan oleh aplikasi spesifik. [5]