DNS

route53:ChangeResourceRecordSets on a public hosted zone enables DNS record mutation - traffic redirection, MX/SPF override, and subdomain NS delegation (DNS hijacking primitive).

route53:ChangeResourceRecordSets on a private hosted zone enables internal DNS hijacking within associated VPCs - traffic redirection for VPC-resident workloads only.

A dangling alias or CNAME record pointing to a deprovisioned AWS resource enables subdomain takeover - an attacker (unauthenticated, from the internet) claims the deprovisioned resource and serves content on the hijacked name without any AWS IAM permission required.

route53:ChangeResourceRecordSets enables adding NS records for a subdomain, delegating full authority for that subtree to an attacker-controlled nameserver (broader than a single A-record redirect).

route53:CreateHostedZone with --vpc or route53:AssociateVPCWithHostedZone enables creating a shadow private zone or extending an existing zone's resolution scope across VPCs - DNS MITM for all workloads in the associated VPC.

route53domains:UpdateDomainNameservers replaces the authoritative NS servers at the domain registry - full domain takeover, redirecting ALL DNS resolution for the domain to attacker-controlled infrastructure.

route53domains:TransferDomainToAnotherAwsAccount transfers domain registration ownership to another AWS account - complete loss of domain registration control, enabling the attacker to modify registrar settings and potentially lock out the legitimate owner.

A CNAME or A/AAAA alias DNS record in a public Azure DNS zone pointing to a deprovisioned Azure resource enables subdomain takeover: an external attacker can claim that resource name and inherit DNS resolution for the dangling hostname.

Write access to NS records in a public DNS zone lets an attacker replace the name-server delegation for the zone (or a sub-zone), routing all subsequent DNS queries through attacker-controlled authoritative nameservers - a higher-blast-radius attack than single-record modification.

Write access to record sets in a private Azure DNS zone (any record type) lets an attacker create or overwrite internal hostname records, redirecting resolution for internal service FQDNs (including private endpoint hostnames) to attacker-controlled private IPs within the VNet - enabling internal MitM or service impersonation.

Write access to VNet links on a private DNS zone lets an attacker add new VNet links, extending the zone's resolution scope to additional VNets - including VNets in other subscriptions within the same tenant - expanding the blast radius of any private DNS record modification.

Full administrative control over a private Azure DNS zone (Private DNS Zone Contributor or equivalent): the principal can manage all record types, zone settings, and VNet links.

Full administrative control over a public Azure DNS zone (DNS Zone Contributor or equivalent): the principal can manage all record types, zone settings, and zone-level RBAC delegation (where Owner scope is held).

Write access to record sets in a public Azure DNS zone (any record type via wildcard or specific-type write) lets an attacker create or overwrite A, CNAME, MX, or other records, redirecting hostnames under the zone to attacker-controlled infrastructure.

If the backing PaaS resource (Key Vault, Storage, etc.) has a non-empty autoApprovalSubIds list in its privateEndpointConnections properties, and a PE is created in a subscription matching that list, the connection is auto-approved (no manual approval step required). Creating a PE in that subscription immediately grants the consumer VNet private access to the resource.

An Approved private endpoint connection that crosses subscription boundaries extends private network reach across the subscription boundary: a foothold in the consumer VNet (sub A) gains private network access to the PaaS resource in the provider subscription (sub B).

A Microsoft.Network/privateDnsZones/virtualNetworkLinks ARM record directly observes that a private DNS zone is linked to a VNet. This is a structural fact: the zone's DNS records apply to name resolution within that VNet.

Write access to A or CNAME records in a private DNS zone (e.g., privatelink.vaultcore.azure.net) lets an attacker redirect in-VNet FQDN resolution for a PaaS service to an attacker-controlled IP - intercepting credentials or data sent to that service from any linked VNet.

Write access to virtual network links in a private DNS zone lets an attacker link additional VNets to the zone, expanding the blast radius of a compromised or attacker-controlled DNS zone to additional VNets whose resources now resolve PaaS FQDNs via the attacker-influenced zone.

Write access to a private DNS zone object (Microsoft.Network/privateDnsZones/write) grants full administrative control: the identity can replace, delete, or recreate the zone entirely. This is higher-impact than record-level write because it includes zone deletion (DoS) and recreation with attacker-controlled records. Zone write subsumes record write (the can-control linchpin derives Controls from this).

An Approved private endpoint with a working private DNS zone group makes the backing PaaS resource (Key Vault, Storage, SQL, etc.) reachable at a private IP from any compute in the same VNet or a peered VNet - bypassing the public firewall.

A CNAME or alias DNS record (in a public zone) pointing to a deprovisioned Azure resource enables subdomain takeover: an attacker can claim the target resource and inherit DNS resolution for the dangling name.

Write access to private DNS zone record sets lets an attacker create or modify records - enabling DNS hijack or redirect within linked VNets.

Write access to public DNS zone record sets lets an attacker create or modify A/CNAME/alias records - enabling DNS hijack, redirect, or dangling-record takeover.

A CNAME (or ALIAS) resource record set in a public Cloud DNS zone whose target resolves to a GCP-managed FQDN suffix that no longer has a backing resource in collected GCP inventory enables subdomain takeover: an external attacker can claim that resource name and inherit DNS resolution for the dangling hostname.

A principal holding dns.changes.create (or an equivalent role such as roles/dns.admin, roles/editor, or roles/owner) at the GCP project scope can submit DNS changesets to any public managed zone in that project, overwriting any resource record set - enabling hostname redirect, DNS-01 TLS certificate acquisition, MX record manipulation, and OAuth redirect URI abuse.

A principal holding dns.managedZones.update at the GCP project scope can modify the privateVisibilityConfig.networks list for a private managed zone, expanding which VPC networks can resolve the zone. This enables widening the blast radius of a private-zone DNS poisoning attack by adding attacker-controlled VPC networks to the zone's visibility scope (cross-project lateral movement via shared VPC).