Skip to content

Is there a propagation gap between AssociateVPCWithHostedZone and DNS resolution for pre-existing records?

0

We need to create a private hosted zone for a parent domain (e.g. example.com) in a consumer's VPC. However, there is an existing public subdomain record (apigateway.example.com) that must continue resolving during the transition. Creating the private hosted zone directly in the consumer's VPC causes NXDOMAIN for apigateway.example.com because the private zone takes over before we can add the record.

To avoid this, we use a placeholder VPC approach:

  1. Create the private hosted zone associated with a placeholder VPC (not the consumer's real VPC)
  2. Add all required records (including apigateway.example.com)
  3. Wait for GetChange to return INSYNC
  4. Call AssociateVPCWithHostedZone to associate the consumer's real VPC

Our assumption is that since the records are already INSYNC on the authoritative servers at step 4, the VPC Resolver will return them immediately when it starts routing queries to the private zone.

However, we have been unable to find documentation that confirms there is no propagation gap between the VPC association completing and the VPC Resolver being able to resolve the pre-existing records. The GetChange documentation states that INSYNC means "changes have propagated to all Route 53 DNS servers managing the hosted zone," but does not address whether the VPC Resolver will see those records on the first query after a new VPC association.

Questions:

  1. When AssociateVPCWithHostedZone completes for a private hosted zone that already has INSYNC records, is there any window where the VPC Resolver could query the zone but not see those records?

  2. Does the VPC Resolver start routing queries to the private zone only after the association is fully complete, or could it begin routing before the auto-defined rule is fully propagated?

  3. Is the placeholder VPC approach described above a supported pattern for zero-downtime private hosted zone migrations?

2 Answers
5

The short answer is yes, there can be a small propagation window, but the "Placeholder VPC" approach is the industry-standard way to minimize it.

However, you won't find a "zero-millisecond" guarantee in the docs because it's a distributed system, but the placeholder method is the safest way to avoid the „NXDOMAIN trap“ !

1. The Propagation Window

When you call AssociateVPCWithHostedZone, Route 53 must update the VPC Resolver configuration for every DNS node within that VPC's infrastructure. While GetChange tracks the status of records within the Hosted Zone itself, it does not track the propagation of the VPC association rule.

  • The VPC Resolver starts routing queries to the Private Hosted Zone (PHZ) only after the association logic hits that specific DNS node.
  • Because this is a distributed system, there is a sub-second to multi-second window where some nodes might still use the public resolution while others use the PHZ.

2. Why the Placeholder VPC works

Your assumption is correct: By ensuring records are INSYNC before associating the consumer VPC, you eliminate the "NXDOMAIN" risk.

  • Without Placeholder: Creating the zone directly in the VPC creates an empty zone. The Resolver immediately routes queries there, sees no records, and returns NXDOMAIN.
  • With Placeholder: The zone is already "primed." When the VPC Resolver finally switches over to the PHZ, the records are already present on the authoritative side. The only "gap" is whether the Resolver picks up the new association rule yet, not whether the records exist.

3. Is this a supported pattern?

Yes. AWS effectively recommends this for cross-account or complex migrations. To achieve true zero-downtime:

1. Prime the PHZ (Placeholder approach).

2. Match TTLs: Ensure the TTL of your PHZ records matches or is lower than the public records during the transition.

3. Consistency: Since the VPC Resolver uses an eventual consistency model for configuration changes, the transition is "atomic" per DNS node, but "gradual" across the entire VPC fleet.

EXPERT
answered a month ago
2

The records should already be INSYNC in the private zone first, then the VPC association should also reach INSYNC.

EXPERT
answered a month ago
EXPERT
reviewed a month ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.