Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Cloud DNS mendukung migrasi domain DNS yang ada dari penyedia DNS lain ke Cloud DNS. Prosedur ini menjelaskan cara menyelesaikan langkah-langkah yang diperlukan: membuat zona terkelola untuk domain Anda, mengekspor konfigurasi DNS dari penyedia yang ada, mengimpor konfigurasi DNS yang ada ke Cloud DNS, memperbarui data server nama registrar, lalu memverifikasi migrasi.
Untuk menentukan nama project dan mengautentikasi dengan konsol Google Cloud , jalankan
perintah berikut:
gcloud auth login
Anda juga dapat menentukan parameter --project untuk perintah agar beroperasi
terhadap project lain untuk pemanggilan tersebut.
Membuat zona terkelola
Untuk memigrasikan domain yang ada, buat zona terkelola terlebih dahulu untuk memuat data DNS
Anda. Saat Anda membuat zona, zona baru tidak akan digunakan hingga Anda memperbarui
pendaftaran domain, mengarahkan resolver ke zona tersebut, atau mengkueri salah satu server nama
zona Anda.
Untuk AWS Route 53,
yang tidak mendukung ekspor, Anda dapat menggunakan alat
cli53
open source.
Mengimpor kumpulan data
Setelah mengekspor file dari penyedia lain, Anda dapat menggunakan perintah gcloud untuk mengimpornya ke zona terkelola.
Untuk mengimpor set data dengan benar, Anda harus menghapus data apex atau menggunakan
flag yang dijelaskan di tab gcloud.
gcloud
Untuk mengimpor kumpulan data, jalankan perintah
dns record-sets import. Flag --zone-file-format memberi tahu import untuk mengharapkan file berformat zona
BIND. Jika Anda menghapus tanda ini,import akan mengharapkan file data berformat
YAML:
gcloud dns record-sets import -z=EXAMPLE_ZONE_NAME
--zone-file-format path-to-example-zone-file
Ganti EXAMPLE_ZONE_NAME dengan nama zona DNS Anda.
Memverifikasi penyebaran DNS
Untuk memantau dan memverifikasi bahwa server nama Cloud DNS telah mengambil
perubahan Anda, Anda dapat menggunakan perintah watch dan dig Linux.
Dalam output, huruf yang mengikuti bagian nama ns-cloud-
disebut sebagai shard server nama. Ada lima shard tersebut
(huruf A-E). Untuk informasi selengkapnya tentang shard, lihat
Batas server nama.
Periksa apakah data tersedia di server nama.
watch dig example.com @ZONE_NAME_SERVER
Ganti ZONE_NAME_SERVER dengan salah satu server nama yang ditampilkan saat Anda menjalankan perintah sebelumnya.
Setelah melihat perubahan, tekan Ctrl+C untuk keluar.
Perintah watch menjalankan perintah dig setiap 2 detik secara default. Anda
dapat menggunakan perintah ini untuk menentukan kapan server nama resmi mengambil
perubahan Anda, yang akan terjadi dalam waktu 120 detik.
Memperbarui data server nama registrar
Login ke penyedia registrar Anda dan ubah server nama otoritatif
agar mengarah ke server nama yang Anda lihat di langkah 1. Pada saat yang sama,catat time to live (TTL) yang telah ditetapkan registrar Anda pada data.
Hal ini memberi tahu Anda berapa lama Anda harus menunggu sebelum server nama baru
mulai digunakan.
Tunggu perubahan, lalu verifikasi
Untuk mendapatkan server nama resmi bagi domain Anda di internet, jalankan perintah Linux berikut:
dig +short NS example.com
Jika output menunjukkan bahwa semua perubahan telah diterapkan, tugas Anda selesai.
Jika tidak, Anda dapat memeriksa secara berkala atau menjalankan perintah secara otomatis
setiap 2 detik sambil menunggu server nama berubah. Untuk melakukannya, jalankan
hal berikut:
watch dig +short NS example.com
Ctrl+C keluar dari perintah.
Jika tidak menggunakan Linux, Anda dapat menggunakan
perintah nslookup.
Langkah berikutnya
Untuk menambahkan, menghapus, atau memperbarui data, lihat
Mengelola data.
[[["Mudah dipahami","easyToUnderstand","thumb-up"],["Memecahkan masalah saya","solvedMyProblem","thumb-up"],["Lainnya","otherUp","thumb-up"]],[["Sulit dipahami","hardToUnderstand","thumb-down"],["Informasi atau kode contoh salah","incorrectInformationOrSampleCode","thumb-down"],["Informasi/contoh yang saya butuhkan tidak ada","missingTheInformationSamplesINeed","thumb-down"],["Masalah terjemahan","translationIssue","thumb-down"],["Lainnya","otherDown","thumb-down"]],["Terakhir diperbarui pada 2025-09-01 UTC."],[[["\u003cp\u003eCloud DNS enables migrating DNS domains from other providers, involving creating a managed zone, exporting the existing DNS configuration, and importing it into Cloud DNS.\u003c/p\u003e\n"],["\u003cp\u003eTo begin migration, users need to set up the gcloud CLI and create a managed zone using the \u003ccode\u003egcloud dns managed-zones create\u003c/code\u003e command, specifying the domain, zone description, and zone name.\u003c/p\u003e\n"],["\u003cp\u003eExisting DNS configurations must be exported from the current provider, with Cloud DNS supporting BIND or YAML zone file formats, and providers like AWS Route 53 may require third-party tools such as cli53 for export.\u003c/p\u003e\n"],["\u003cp\u003eImporting record sets into the managed zone is done using the \u003ccode\u003egcloud dns record-sets import\u003c/code\u003e command, and careful consideration of apex records (NS or SOA) is required to avoid conflicts with pre-existing Cloud DNS records.\u003c/p\u003e\n"],["\u003cp\u003eAfter updating the registrar's name server records to point to the new Cloud DNS servers, users can verify DNS propagation using Linux commands \u003ccode\u003ewatch\u003c/code\u003e and \u003ccode\u003edig\u003c/code\u003e or \u003ccode\u003enslookup\u003c/code\u003e to ensure the changes have been implemented.\u003c/p\u003e\n"]]],[],null,["# Migrate to Cloud DNS\n\nCloud DNS supports the migration of an existing DNS domain from\nanother DNS provider to Cloud DNS. This procedure describes how\nto complete the necessary steps: create a managed zone for your domain, export\nthe DNS configuration from your existing provider,\nimport your existing DNS configuration to Cloud DNS, update your\nregistrar's name server records, and then verify the migration.\n\nBefore you begin\n----------------\n\n1. If you have not yet used the Google Cloud CLI,\n [set up the gcloud CLI](/compute/docs/gcloud-compute).\n\n2. To specify the project name and authenticate with the Google Cloud console, run\n the following command:\n\n ```\n gcloud auth login\n ```\n\n You can also specify the `--project` parameter for a command to operate\n against a different project for that invocation.\n\nCreate a managed zone\n---------------------\n\nTo migrate an existing domain, first create a managed zone to contain your DNS\nrecords. When you create a zone, the new zone isn't used until you update your\ndomain registration, point a resolver at it, or query one of your zone's name\nservers. \n\n### gcloud\n\nTo create a zone, run the\n[`dns managed-zones create`](/sdk/gcloud/reference/dns/managed-zones/create)\ncommand: \n\n```\ngcloud dns managed-zones create --dns-name=example.com.\n--description=A_ZONE EXAMPLE_ZONE_NAME\n```\n\nReplace the following:\n\n- \u003cvar translate=\"no\"\u003eexample.com.\u003c/var\u003e: the DNS name\n- \u003cvar translate=\"no\"\u003eA_ZONE\u003c/var\u003e: a description of the zone\n- \u003cvar translate=\"no\"\u003eEXAMPLE_ZONE_NAME\u003c/var\u003e: the name to identify the DNS zone\n\nExport your DNS configuration from your existing provider\n---------------------------------------------------------\n\nTo export your\n[zone file](https://wikipedia.org/wiki/Zone_file),\nsee your provider's documentation. Cloud DNS supports the import\nof zone files in BIND or YAML records format.\n\nFor example:\n\n- For [Dyn](https://www.oracle.com/corporate/acquisitions/dyn/),\n go to\n [Download Your Zone File](https://help.dyn.com/dns-knowledge-base/download-your-zone-file/).\n\n- For [AWS Route 53](https://aws.amazon.com/route53/),\n which does not support export, you can use the open source\n [cli53](https://github.com/barnybug/cli53)\n tool.\n\nImport the record set\n---------------------\n\nAfter you have the exported the file from your other provider, you can use\n`gcloud` commands to import it into your managed zone.\n\nTo import record sets correctly, you must remove the apex records or use the\nflags described on the `gcloud` tab. \n\n### gcloud\n\nTo import record sets, run the\n[`dns record-sets import`](/sdk/gcloud/reference/dns/record-sets/import)\ncommand. The `--zone-file-format` flag tells `import` to expect a BIND zone\nformatted file. If you omit this flag,`import` expects a YAML-formatted\nrecords file: \n\n```\ngcloud dns record-sets import -z=EXAMPLE_ZONE_NAME\n--zone-file-format path-to-example-zone-file\n```\n\nReplace \u003cvar translate=\"no\"\u003eEXAMPLE_ZONE_NAME\u003c/var\u003e with the name of your DNS zone.\n| **Caution:**\n|\n| If your\n| import file contains NS or SOA records for the apex of the zone, they will\n| conflict with the pre-existing Cloud DNS records. To use the\n| pre-existing Cloud DNS records (recommended),\n| ensure that you remove the NS or SOA records from your import file.\n| However, there are use cases for overriding this behavior; see the\n| following important information.\n| **Caution:**\n|\n| If your authoritative DNS\n| is split across multiple providers and you have a non-Cloud DNS\n| primary name server, then you must replace the Cloud DNS\n| SOA record with the record from the other provider. To do this, you must use\n| the `--delete-all-existing` flag when importing record sets to\n| replace the SOA records that Cloud DNS provides. Otherwise, the\n| update fails because the imported records conflict with the pre-existing\n| Cloud DNS records.\n|\n| For similar reasons, you can specify that the NS records in the\n| import file be used instead of the pre-existing Cloud DNS\n| records by using the `--delete-all-existing`\n| and `--replace-origin-ns` flags together. Specifying an\n| NS record for the apex of a zone results in an error even if the\n| `--replace-origin-ns` flag is not specified. Either remove these\n| records from the import file or use both the `--delete-all-existing`\n| and `--replace-origin-ns` flags together if appropriate.\n| **Note:**\n|\n| Some DNS implementations\n| and providers export BIND zone files without\n| final periods on domain name data in CNAME, MX, PTR, and other records.\n| In zone files, Cloud DNS follows RFC standards and interprets all\n| domain names without a final period as relative to the DNS name of the zone.\n| Therefore, importing the following MX records into a zone with the DNS name\n| `example.com` results in identical (and probably undesired)\n| records for both: \n|\n| ```\n| in.smtp IN MX 5 gmail-smtp-in.l.google.com\n| in.smtp.example.com. IN MX 5 gmail-smtp-in.l.google.com.example.com.\n| ```\n|\n| Before importing your zone files, check them to ensure that all names that\n| need final periods have them.\n\nVerify DNS propagation\n----------------------\n\nTo monitor and verify that the Cloud DNS name servers have picked up\nyour changes, you can use the Linux `watch` and `dig` commands.\n**Note:** The `watch` and `dig` commands are not `gcloud` commands and are not used with the `gcloud` prefix. On non-Linux operating systems, you might need to install the `watch` and `dig` commands. \n\n### gcloud and Linux\n\n1. To look up your zone's Cloud DNS name servers, run the\n [`dns managed-zones describe`](/sdk/gcloud/reference/dns/managed-zones/describe)\n command:\n\n ```\n gcloud dns managed-zones describe EXAMPLE_ZONE_NAME\n ```\n\n Replace \u003cvar translate=\"no\"\u003eEXAMPLE_ZONE_NAME\u003c/var\u003e with the name of your DNS\n zone.\n\n The output looks something like this: \n\n ```\n nameServers:\n - ns-cloud-a1.googledomains.com.\n - ns-cloud-a2.googledomains.com.\n - ns-cloud-a3.googledomains.com.\n - ns-cloud-a4.googledomains.com.\n ```\n\n In the output, the letter following the `ns-cloud-` part of the name is\n referred to as the name server *shard* . There are five such shards\n (letters A-E). For more information about shards, see\n [Name server limits](/dns/quotas#name_server_limits).\n2. Check if the records are available on the name servers.\n\n ```\n watch dig example.com @ZONE_NAME_SERVER\n ```\n\n Replace \u003cvar translate=\"no\"\u003eZONE_NAME_SERVER\u003c/var\u003e with one of the name servers\n returned when you ran the previous command.\n3. After you see your change, press `Ctrl+C` to exit.\n\nThe `watch` command runs the `dig` command every 2 seconds by default. You\ncan use this command to determine when your authoritative name server picks\nup your change, which should happen within 120 seconds.\n\nUpdate your registrar's name server records\n-------------------------------------------\n\nSign in to your registrar provider and change the authoritative name servers\nto point to the name servers that you saw in step 1. At the same time,\nmake a note of the time to live (TTL) that your registrar has set on the records.\nThat tells you how long you have to wait before the new name servers\nbegin to be used.\n\nWait for changes and then verify\n--------------------------------\n\nTo get the authoritative name servers for your domain on the internet,\nrun the following Linux commands: \n\n```\ndig +short NS example.com\n```\n\nIf the output shows that all changes have propagated, your task is complete.\nIf not, you can check intermittently or you can automatically run the command\nevery 2 seconds while you wait for the name servers to change. To do that, run\nthe following: \n\n```\nwatch dig +short NS example.com\n```\n\n`Ctrl+C` exits the command.\n\nIf you're not using Linux, you can use the\n[`nslookup` command](https://wikipedia.org/wiki/Nslookup).\n\nWhat's next\n-----------\n\n- To add, delete, or update records, see [Manage records](/dns/docs/records).\n- To use JSON formats for Cloud DNS record types, see [Records format (JSON)](/dns/docs/reference/json-record).\n- To find solutions for common issues that you might encounter when using Cloud DNS, see [Troubleshooting](/dns/docs/troubleshooting).\n- To get an overview of Cloud DNS, see [Cloud DNS overview](/dns/docs/overview).\n- For the Cloud DNS command-line, see the [Google Cloud CLI](/sdk/gcloud/reference/dns) documentation."]]
