Migrasi DNS yang mulus: Panduan Praktis Anda

Salah satu hal pertama yang harus Anda lakukan saat pindah ke rumah baru adalah memperbarui alamat surat pada layanan pos. Pembaruan ini tidak terlalu rumit, tetapi penting. Jika tidak, surat penting mungkin dikirim ke alamat lama Anda dan Anda maupun pengirim tidak akan tahu bahwa surat tersebut tidak terkirim.

Demikian pula dengan migrasi DNS. Jika tidak dilakukan dengan benar, situs web Anda bisa menjadi tidak dapat diakses oleh pengguna, pengiriman email gagal, dan menyebabkan masalah komunikasi dengan klien, kerusakan integrasi, dan banyak lagi. Pada dasarnya, pelanggan mungkin tidak dapat menjangkau bisnis Anda di alamat yang benar, yang dapat menyebabkan sejumlah hasil negatif.

Sistem nama domain (DNS) seperti buku telepon atau direktori untuk internet. Sistem ini memungkinkan pengguna untuk menavigasi ke situs web menggunakan nama domain yang mudah diingat, seperti IBM.com, bukan rangkaian angka (dalam hal ini, 184.85.75.7).

Tetapi DNS melibatkan lebih dari sekadar terjemahan sederhana dan kualitas layanan dari penyedia DNS terkelola dapat memengaruhi kinerja, keandalan, latensi, keamanan, privasi, dan banyak lagi. Ketika DNS Services penyedia tidak memenuhi harapan atau kebutuhan, bisnis mungkin mencari penyedia baru. Ketika mereka melakukannya, mereka perlu merencanakan migrasi DNS.

Migrasi DNS, di mana organisasi mentransfer catatan dan pengaturan DNS domain dari satu penyedia ke penyedia lainnya, tidak harus menjadi upaya sulit seperti yang sering dialami. Namun, migrasi ini memang memiliki risiko dan berpotensi menimbulkan sakit kepala jika tidak dijalankan dengan benar. Kesalahan dalam migrasi DNS dapat mengakibatkan waktu henti server, kerentanan jaringan, dan banyak lagi. Berikut adalah cara untuk membantu memastikan hal itu tidak terjadi.

Anda dapat membaca lebih lanjut tentang proses pencarian DNS di sini.

Jawaban sederhananya adalah bahwa tidak semua penyedia DNS menawarkan layanan atau kualitas layanan yang sama. Kinerja adalah fitur utama, tetapi itu bukan satu-satunya perhatian.

Sebagai contoh, penyedia DNS mungkin juga menyediakan fitur keamanan untuk mencegah penyamaran DNS dan memblokir akses ke domain yang diketahui atau dicurigai berbahaya. Kemampuan pemantauan dan pencatatan juga bervariasi di antara penyedia. Beberapa penyedia DNS menawarkan penyeimbangan beban untuk failover, di mana beberapa server web yang berlebihan menangani kueri DNS untuk menghindari kelebihan beban pada satu server, atau jaringan pengiriman konten (CDN) global yang membantu menyimpan konten untuk sementara waktu lebih dekat dengan pengguna. Tentu saja, biaya mungkin juga menjadi faktor dalam keputusan untuk mengubah penyedia DNS.

Pemimpin bisnis harus memilih layanan yang paling sesuai dengan kebutuhan bisnis mereka. Kebutuhan tersebut sering berkembang, seperti halnya persyaratan DNS. Ketika layanan penyedia DNS saat ini tidak lagi memenuhi kebutuhan bisnis, pemimpin bisnis dapat mempertimbangkan untuk memigrasikan catatan dan manajemen DNS mereka ke penyedia baru.

Secara umum, ada alasan utama mengapa banyak bisnis menunda migrasi: perasaan bahwa migrasi terlalu menakutkan dan perubahan apa pun akan menyebabkan waktu henti. Ini adalah kekhawatiran yang masuk akal, tetapi dapat dikurangi melalui perencanaan dan pelaksanaan yang cermat.

Langkah pertama dalam migrasi DNS adalah menentukan alasan migrasi. Manfaat apa yang dicari bisnis yang saat ini tidak dimilikinya? Masalah apa yang perlu diselesaikan bisnis? Sebagai contoh, jika sebuah perusahaan menggunakan DNS penyedia layanan internet (ISP) kecil, mereka mungkin mendapati bahwa waktu resolusi mencapai tiga digit milidetik. Dalam hal ini, meningkatkan kecepatan mungkin menjadi prioritas.

Setelah bisnis mengidentifikasi alasan untuk bermigrasi, tim TI dapat membandingkan berbagai layanan untuk menemukan perpaduan yang tepat antara fitur, layanan, dan biaya. Penyedia layanan berbeda menawarkan hal spesifik yang berbeda untuk memulai migrasi, tetapi ada beberapa panduan umum yang bisa diikuti.

Setelah tim migrasi memilih penyedia, mereka perlu mengumpulkan semua catatan dan informasi terkait dari penyedia DNS sebelumnya. Catatan ini mungkin termasuk yang berikut:

Catatan ini menyediakan terjemahan langsung dari nama domain ke alamat IP. Catatan A untuk alamat IPv4 dan catatan AAAA untuk alamat IPv6. IPv6 kini semakin umum digunakan; ia menawarkan jauh lebih banyak alamat IP unik dan mencakup beberapa fitur keamanan dasar dan peningkatan kecepatan.

Catatan nama kanonik, atau catatan CNAME, mengarahkan domain alias ke domain kanonik. Artinya, jenis catatan ini digunakan untuk menghubungkan subdomain ke catatan domain A atau AAAA.

Catatan nama delegasi, atau catatan DNAME, digunakan untuk mengarahkan beberapa subdomain dengan satu catatan dan mengarahkannya ke domain lain.

Catatan otorisasi otoritas sertifikasi, atau catatan CAA, memungkinkan pemilik domain untuk menentukan otoritas sertifikat (CA) mana yang dapat menerbitkan sertifikat untuk domain mereka. CA adalah organisasi yang memvalidasi identitas situs web dan menghubungkannya dengan kunci kriptografi dengan menerbitkan sertifikat digital.

Teks, atau catatan TXT, menyimpan informasi tekstual terkait domain dan subdomain. Catatan teks memungkinkan penyimpanan catatan kerangka kerja kebijakan pengirim (SPF) dan catatan verifikasi email. Catatan DKIM dan DMARC yang disimpan dalam data TXT membantu server email mengonfirmasi bahwa pesan berasal dari sumber yang dapat dipercaya.

Awal otoritas, atau catatan SOA, menyimpan informasi administratif penting tentang domain. Informasi ini dapat mencakup alamat email administrator domain, informasi tentang pembaruan domain, dan kapan server harus menyegarkan informasinya.

Server nama atau catatan NS menunjukkan server DNS mana yang bertindak sebagai server nama otoritatif untuk sebuah domain. Server nama otoritatif berisi informasi akhir tentang domain tertentu dan alamat IP yang sesuai. Catatan NS menunjuk ke semua catatan berbeda yang dimiliki domain Anda. Tanpa catatan NS, pengguna tidak akan dapat mengakses situs web Anda.

Zona DNS adalah pembagian dalam namespace DNS. IBM.com, misalnya, memiliki zona DNS terpisah di research.ibm.com. Subdomain ini cukup besar sehingga mendapat manfaat dari manajemen dan pemantauan terpisah. File zona DNS mencakup sebagian besar jenis file yang disebutkan di atas: catatan SOA, catatan A dan AAAA, dan banyak lagi.

Ada juga jenis catatan DNS lainnya—baca panduan ini untuk informasi selengkapnya.

Beberapa penyedia menawarkan fitur otomatisasi yang mengumpulkan, mengekspor, dan mengimpor catatan DNS untuk Anda, tetapi sering kali bijaksana untuk melakukan pencadangan manual juga: catatan yang hilang dapat mengakibatkan masalah serius. Anda juga sebaiknya menyimpan salinan file ini di tempat yang aman.

Salah satu potensi gangguan dalam proses ini adalah DNSSEC atau ekstensi keamanan sistem nama domain. DNSSEC menawarkan rangkaian perlindungan keamanan yang berharga, menggunakan verifikasi tanda tangan untuk membantu memastikan keakuratan dan mencegah penyamaran DNS dan serangan lainnya.

Tetapi proses migrasi DNS dapat menyebabkan penggunaan algoritma penandatanganan yang berbeda sehingga memutus rantai dan menyebabkan pemadaman. Ada beberapa solusi berbeda untuk masalah ini: beberapa penyedia akan menawarkan alat migrasi khusus DNSSEC, yang menjaga keamanan tersebut. Pada penyedia lain, mungkin DNSSEC perlu dinonaktifkan sebelum melakukan migrasi dan kemudian diaktifkan kembali setelah migrasi selesai.

Praktik lain yang direkomendasikan adalah menurunkan nilai masa hidup (TTL). Ini adalah lamanya waktu resolver rekursif—atau server rekursif, perhentian pertama dalam kueri DNS—menyimpan alamat IP situs web yang baru-baru ini dikunjungi dalam cache. Penyimpanan sementara dalam cache menghilangkan kebutuhan untuk mencari alamat IP lagi dan membantu menyediakan koneksi yang lebih cepat.

Jika TTL diatur menjadi, katakanlah, 24 jam, ketika pengguna mencoba mengunjungi situs yang telah memigrasikan server DNS-nya dalam jangka waktu tersebut, browser mereka akan mencoba menuju ke alamat IP lama, yang kemungkinan akan menyebabkan kesalahan. Mengatur TTL ke sesuatu yang sangat rendah, mungkin hanya beberapa menit, dapat membantu menghindari masalah ini.

Sebaiknya migrasi dilakukan secara bertahap, tidak sekaligus. Lingkungan praproduksi memungkinkan tim migrasi untuk memeriksa kesalahan pada setiap fitur secara terpisah, daripada berusaha keras untuk mencari tahu apa yang salah di seluruh operasi.

Setelah tim mengekspor dokumentasi DNS yang ada dan mengimpornya dengan layanan penyedia DNS yang baru, mereka harus memeriksa dan memverifikasi dokumen untuk memastikan tidak ada yang hilang di sepanjang proses. Alat seperti [dig] dapat membantu verifikasi. [Dig] atau domain information groper, adalah alat baris perintah yang memungkinkan pengguna untuk memeriksa dokumen DNS, dari alamat IP dasar hingga TXT, SOA, dan banyak lagi. Nslookup adalah alat baris perintah lain, meskipun lebih sederhana daripada [dig], yang memberikan hasil yang kurang terperinci.

Kemudian tim dapat mulai mentransfer secara bertahap: web hosting, layanan email, lalu API dan layanan pihak ketiga lainnya. Sebaiknya seseorang di tim memeriksa dan memecahkan tiap masalah saat migrasi berlangsung. Konfigurasikan pengaturan lanjutan apa pun, seperti mengaktifkan DNSSEC. Setelah ini semua diuji di server uji, tim dapat melanjutkan dengan memperbarui informasi pada pengelola registrasi domain.

Jika bisnis memiliki pengelola registrasi domain dan penyedia DNS terpisah—mungkin menggunakan IBM NS1 Connect untuk DNS dan GoDaddy untuk pengelola registrasi domain—tim harus masuk ke layanan pendaftaran domain dan memperbarui catatan server nama. Jika bisnis menggunakan penyedia yang sama untuk DNS dan registri, hal ini seringkali dapat dilakukan secara otomatis. Anda tidak perlu mengubah apa pun pada web host itu sendiri jika tidak mengganti penyedia hosting Anda. 

Faktor penting: jangan hapus DNS lama . Ini diakibatkan oleh propagasi DNS. Catatan DNS tidak langsung berubah di seluruh internet; diperlukan waktu bagi server domain yang tersebar untuk mencari dan memperbarui catatan mereka. Tim dapat memeriksa status catatan secara berkala dengan alat online seperti WhatsMyDNS.net Biasanya dibutuhkan waktu paling lama satu atau dua hari, tetapi selama waktu itu, sebaiknya DNS Services lama dan baru Anda tetap berjalan sementara server domain memperbarui catatan mereka. Hal ini memastikan bahwa pengguna tidak mengalami pemadaman.

Setelah propagasi selesai, migrasi pada dasarnya selesai. Hanya tersisa beberapa tugas penyelesaian ringan. Ini termasuk:

Mengembalikan TTL ke normal: Meningkatkan TTL kembali ke 24 jam, atau berapa pun masa hidup sebelumnya, untuk mengaktifkan penyimpanan di cache bagi pengguna.

Perbarui dokumentasi internal: Pastikan informasi DNS, nomor akun, siklus penagihan, dan hal semacamnya, diperbarui dalam catatan organisasi untuk menghindari kebingungan.

Memantau: Meninjau kinerja dan metrik lainnya setelah migrasi. Tim TI dapat meninjau log DNS untuk menemukan kesalahan atau batas waktu, melacak waktu respons baru, menyiapkan peringatan untuk setiap waktu henti, dan memeriksa propagasi secara berkala. Banyak penyedia DNS memiliki alat pemantauan internal. Alat pihak ketiga juga tersedia.

Pelajari DNS services lebih lanjut di sini.