> ## Documentation Index > Fetch the complete documentation index at: https://docs.tensor9.com/llms.txt > Use this file to discover all available pages before exploring further. # Azure DNS > Azure DNS APIs with Cloud Adapter. This page describes how Azure DNS maps to services in the environment where the application runs. Some profiles adapt origin API calls; others translate infrastructure or document target-native behavior. ## Supported environments | Environment | Mapping | | ------------ | ------- | | AWS | API | | Google Cloud | API | API means the profile adapts origin API behavior. Infrastructure means the profile changes provisioned resources or documents a target-native alternative without promising an origin API endpoint. Check the operation and capability tables for the behavior your application depends on. ## How the targets compare Each row compares a capability of Azure DNS with its adaptation on each target. A dash means this profile does not state the capability for that target. ### Cloud Adapter | Capability | Azure DNS | AWS | Google Cloud | | ------------ | --------- | ---- | ------------ | | API coverage | full | high | high | ## On AWS ### Route53 | Operation | Area | Support | Depth | Notes | | -------------------------------- | ------- | --------- | ---------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | Alias records to cloud resources | Records | Supported | Common | An alias to an Azure resource is retargeted to the cloud resource produced by the build. | | Record sets | Records | Supported | Common | record sets keep their name, type, time to live and data | | Private zones and network links | Zones | Supported | Most usage | The private hosted zone is associated with the network produced by the Virtual Network adaptation. | | Private-zone auto-registration | Zones | Partial | Most usage | The build creates records for known VMs and requires acknowledgement that VMs joining the network later will not be registered automatically. | | Public zones | Zones | Supported | Common | a public DNS zone becomes a hosted zone on the target, and the provider answers queries for it directly | Azure DNS zones become Route 53 hosted zones. Record names, types, time to live and data are preserved. An alias to an Azure resource is retargeted to the resource produced by the build. ### Zone updates and query traffic The adapter manages the source zone and record operations through the target DNS API. Once applied, the target DNS service answers queries. Management completion and DNS caching are separate: clients can continue seeing an earlier answer until its time to live expires. ### Delegation and cutover Copy records and validate the target answers before changing a public domain's delegation at its registrar or parent zone. Keep the old and new zones consistent during the transition. Test private names from the intended networks where private zones are supported; record contents alone do not establish visibility. ### Compatibility differences For private zones, the build creates records for the VMs it knows about. Route 53 does not automatically register a VM that later joins the network, so the build requires acknowledgement of that limitation. ## On Google Cloud ### Cloud DNS | Operation | Area | Support | Depth | Notes | | -------------------------------- | ------- | --------- | ------------ | --------------------------------------------------------------------------------------------------------------------------------------------- | | Alias records to cloud resources | Records | Partial | Common | An alias to an Azure resource becomes a record for its target resource's address. The build identifies the rewrite. | | Record health checks | Records | Partial | Full surface | Health checks are configured through a routing policy. The build shows the resulting policy. | | Record sets | Records | Supported | Common | record sets keep their name, type, time to live and data | | Private zones and network links | Zones | Supported | Most usage | The private managed zone is visible to the network produced by the Virtual Network adaptation. | | Private-zone auto-registration | Zones | Partial | Most usage | The build creates records for known VMs and requires acknowledgement that VMs joining the network later will not be registered automatically. | | Public zones | Zones | Supported | Common | a public DNS zone becomes a managed zone on the target, and the provider answers queries for it directly | Azure DNS zones become Cloud DNS managed zones, preserving record names, types, time to live and data. An alias to an Azure resource is replaced with a record for the address of its target resource. Records that depend on health checks use Cloud DNS routing policies. ### Zone updates and query traffic The adapter manages the source zone and record operations through the target DNS API. Once applied, the target DNS service answers queries. Management completion and DNS caching are separate: clients can continue seeing an earlier answer until its time to live expires. ### Delegation and cutover Copy records and validate the target answers before changing a public domain's delegation at its registrar or parent zone. Keep the old and new zones consistent during the transition. Test private names from the intended networks where private zones are supported; record contents alone do not establish visibility. ### Compatibility differences For private zones, the build creates records for known VMs. VMs added later are not registered automatically. ## Existing data and credentials Selecting a backend does not copy existing data, credentials or access policies. Plan and verify migration separately before changing an application's endpoint. Do not assume an identifier, credential or encrypted value from the origin service works unchanged on the target. ## Configure, tune and debug Start with [setup](/cloud-adapter/getting-started/overview) and [configuration](/cloud-adapter/configuration/overview). Use [tuning](/cloud-adapter/tuning/overview) to understand supported request tags, [debugging](/cloud-adapter/debugging/overview) to investigate a request, and [High Fidelity Cloud Emulators](/cloud-adapter/local-testing/overview) to validate a bounded reproduction.