Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Cloud DNS hỗ trợ việc di chuyển miền DNS hiện có từ một nhà cung cấp DNS khác sang Cloud DNS. Quy trình này mô tả cách hoàn tất các bước cần thiết: tạo một vùng được quản lý cho miền của bạn, xuất cấu hình DNS từ nhà cung cấp hiện tại, nhập cấu hình DNS hiện tại vào Cloud DNS, cập nhật bản ghi máy chủ định danh của nhà đăng ký, sau đó xác minh quá trình di chuyển.
Để chỉ định tên dự án và xác thực bằng bảng điều khiển Google Cloud , hãy chạy lệnh sau:
gcloud auth login
Bạn cũng có thể chỉ định tham số --project cho một lệnh để hoạt động với một dự án khác cho lệnh gọi đó.
Tạo vùng được quản lý
Để di chuyển một miền hiện có, trước tiên, hãy tạo một vùng được quản lý để chứa các bản ghi DNS. Khi bạn tạo một vùng, vùng mới sẽ không được sử dụng cho đến khi bạn cập nhật thông tin đăng ký miền, trỏ trình phân giải đến vùng đó hoặc truy vấn một trong các máy chủ tên của vùng.
Đối với AWS Route 53 không hỗ trợ xuất, bạn có thể sử dụng công cụ cli53 nguồn mở.
Nhập tập bản ghi
Sau khi xuất tệp từ nhà cung cấp khác, bạn có thể sử dụng các lệnh gcloud để nhập tệp đó vào vùng được quản lý.
Để nhập tập hợp bản ghi một cách chính xác, bạn phải xoá bản ghi đỉnh hoặc sử dụng cờ được mô tả trên thẻ gcloud.
gcloud
Để nhập tập hợp bản ghi, hãy chạy lệnh dns record-sets import. Cờ --zone-file-format cho import biết rằng sẽ có một tệp được định dạng vùng BIND. Nếu bạn bỏ qua cờ này,import sẽ yêu cầu một tệp bản ghi có định dạng YAML:
gcloud dns record-sets import -z=EXAMPLE_ZONE_NAME
--zone-file-format path-to-example-zone-file
Thay thế EXAMPLE_ZONE_NAME bằng tên của vùng DNS.
Xác minh quá trình truyền DNS
Để theo dõi và xác minh rằng máy chủ định danh Cloud DNS đã nhận được các thay đổi của bạn, bạn có thể sử dụng các lệnh watch và dig của Linux.
Trong kết quả, chữ cái theo sau phần ns-cloud- của tên được gọi là mảnh máy chủ định danh. Có 5 mảnh như vậy (chữ cái A-E). Để biết thêm thông tin về mảnh, hãy xem phần Giới hạn máy chủ định danh.
Kiểm tra xem các bản ghi có trên máy chủ định danh hay không.
watch dig example.com @ZONE_NAME_SERVER
Thay thế ZONE_NAME_SERVER bằng một trong các máy chủ tên được trả về khi bạn chạy lệnh trước đó.
Sau khi bạn thấy thay đổi, hãy nhấn Ctrl+C để thoát.
Theo mặc định, lệnh watch sẽ chạy lệnh dig 2 giây một lần. Bạn có thể sử dụng lệnh này để xác định thời điểm máy chủ định danh có thẩm quyền nhận thay đổi của bạn. Quá trình này sẽ diễn ra trong vòng 120 giây.
Cập nhật bản ghi máy chủ định danh của nhà đăng ký tên miền
Đăng nhập vào nhà cung cấp dịch vụ đăng ký và thay đổi máy chủ định danh có thẩm quyền để trỏ đến các máy chủ định danh mà bạn thấy ở bước 1. Đồng thời, hãy ghi lại thời gian tồn tại (TTL) mà tổ chức đăng ký tên miền đã đặt trên các bản ghi.
Thông tin này cho bạn biết bạn phải chờ bao lâu trước khi bắt đầu sử dụng máy chủ định danh mới.
Chờ các thay đổi rồi xác minh
Để lấy máy chủ định danh có thẩm quyền cho miền của bạn trên Internet, hãy chạy các lệnh Linux sau:
dig +short NS example.com
Nếu kết quả cho thấy tất cả thay đổi đã được truyền tải, thì bạn đã hoàn tất nhiệm vụ.
Nếu không, bạn có thể kiểm tra không liên tục hoặc tự động chạy lệnh này
mỗi 2 giây trong khi chờ máy chủ định danh thay đổi. Để thực hiện việc này, hãy chạy lệnh sau:
watch dig +short NS example.com
Ctrl+C thoát khỏi lệnh.
Nếu không dùng Linux, bạn có thể sử dụng lệnh nslookup.
Bước tiếp theo
Để thêm, xoá hoặc cập nhật bản ghi, hãy xem phần Quản lý bản ghi.
Để sử dụng định dạng JSON cho các loại bản ghi DNS trên đám mây, hãy xem phần Định dạng bản ghi (JSON).
Để tìm giải pháp cho các vấn đề thường gặp mà bạn có thể gặp phải khi sử dụng Cloud DNS, hãy xem phần Khắc phục sự cố.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Khó hiểu","hardToUnderstand","thumb-down"],["Thông tin hoặc mã mẫu không chính xác","incorrectInformationOrSampleCode","thumb-down"],["Thiếu thông tin/mẫu tôi cần","missingTheInformationSamplesINeed","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 2025-06-27 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."]]
