Skip to content

Knowledgebase

  1. Home
  2. Knowledgebase
  3. Domains & DNS
  4. DNS Records & Nameservers
  5. Understand the limits of publishing several A or AAAA records

Understand the limits of publishing several A or AAAA records

Articles
domains-dns

Publishing several A or AAAA records can make a hostname resolve to several server addresses. It does not by itself provide health checks, shared sessions or guaranteed failover. Every advertised destination must be able to serve the intended application.

Information to have ready

List the role and owner of each address. Confirm whether a CDN or managed load-balancer product should make this decision instead. Plan how website files, databases, uploads and session data remain consistent across destinations.

01 Assess the design and test each published address

  1. Prepare every destination with the correct website configuration and certificate for the hostname. Test each server directly while preserving the hostname in the HTTP request.
  2. Publish only the intended address set at the authoritative provider. Remove stale addresses after recording them; one forgotten old server can create apparently random failures.
  3. Use the same appropriate TTL for the address records in one record set. Choose the TTL according to the change plan rather than expecting record order to determine traffic proportions.
  4. Check IPv4 and IPv6 destinations separately. A broken AAAA route can affect a different group of visitors from a broken A address.
  5. If you need automatic removal of unhealthy endpoints or controlled traffic allocation, configure a suitable health-checked load balancer and validate its failure behaviour.

02 Example: understand what two A records actually provide

These illustrative records publish two addresses for the same website name. Replace them only with real servers that are both configured for the hostname and certificate. Publishing the set does not create a health-check service or synchronize application data.

Code or configuration example
www.example.com.  300  IN  A  192.0.2.10
www.example.com.  300  IN  A  192.0.2.11

Read the result: Resolvers may return both addresses and clients choose how to try them. DNS by itself does not remove a failed server, preserve login sessions or replicate recent store orders. If one endpoint has an old certificate or missing application data, some visitors can still receive an error.

Test each address with the same HTTP hostname before publishing both. Use a supported load-balancing or failover design when you need health-aware traffic changes, and understand its monitoring and cache limits. Keep an explicit data-consistency plan for stateful applications.

Confirm the expected result

Test normal requests, login, uploads and sessions against each destination and through ordinary DNS resolution. Simulate an allowed single-endpoint failure in a test environment to observe what clients actually do.

Troubleshoot unexpected results

Different pages or logins on successive requests often indicate inconsistent application data. Reconcile the application architecture before adding more addresses. Removing a failed address does not immediately remove cached copies from every resolver.

A common question

Will browsers always use the first A record and automatically switch to the second?

No. DNS answer ordering and client address selection vary, and a client may continue using a cached address. Some clients retry alternatives, but plain multiple-address DNS is not a service-level availability guarantee.

Was this answer helpful?

Need a little more help?

Our support team can help you find the next step.

Contact support