Contents
Introduction
A traditional CNAME record (see also Stand-alone CNAME Records) defines a static, explicit alias in the DNS, with the oft-lamented technical limitation that a CNAME record cannot be placed at the apex of a zone (e.g. example.com).
Virtual Alias records are a non-standard but increasingly common DNS feature specifically designed to work around that limitation while still accomplishing a similar goal.
When we configure a virtual A Alias record in IPAM, our authoritative nameservers periodically query other nameservers to find the current A record(s) of the desired target name (e.g. abc123.cloudfront.net), and synthesize corresponding A record(s) for the alias name (e.g. example.com). The result is a dynamic, transparent alias:
- IPAM authoritative nameserver receives a query matching the virtual alias:
example.com. IN A? -
IPAM authoritative nameserver sends a query for the target name:
abc123.cloudfront.net. IN A? -
IPAM authoritative nameserver receives this response for the target name:
abc123.cloudfront.net. 60 IN A 198.51.100.17 abc123.cloudfront.net. 60 IN A 198.51.100.18
-
IPAM authoritative nameserver returns this synthesized response for the virtual alias name:
example.com. 60 IN A 198.51.100.17 example.com. 60 IN A 198.51.100.18
The intermediate response is cached according to its TTL (time-to-live) value, so any further identical queries received by the same IPAM authoritative nameserver within the next 60s will skip steps 2 and 3, and return the same synthesized records with a lower remaining TTL. Each individual IPAM authoritative nameserver maintains its own independent cache.
When the external nameserver’s response for the target name changes, IPAM’s response for the virtual alias name will also change (once the old response expires from cache).
If no A records are found for the target name, then IPAM will return zero A records for the virtual alias name.
This virtual A Alias record is only used to answer A record queries, but we could additionally and independently configure a virtual AAAA Alias record to answer AAAA record queries.
Key differences vs CNAME records
- A CNAME record affects query behavior for all record types, but each virtual Alias record applies to only one record type (e.g. only A records, or only AAAA records). This enables virtual Alias records to coexist with records of other types, which is why they can be placed at a zone apex while a CNAME record cannot.
-
Virtual Alias records are transparent (invisible) to clients, ultimately yielding the same query response as an equivalent set of static records:
example.com. IN A 198.51.100.17 example.com. IN A 198.51.100.18
whereas CNAME records are explicitly returned and must be interpreted by the client:
www.example.com. IN CNAME abc123.cloudfront.net. abc123.cloudfront.net. IN A 198.51.100.17 abc123.cloudfront.net. IN A 198.51.100.18
In this case only the CNAME record comes from our IPAM authoritative nameserver; the client’s recursive resolver combines that with A records from some other authoritative nameserver to form the sample response shown.
Best practice: use a CNAME record if you can. Use virtual Alias records when you need aliasing behavior but it’s not technically possible to use a CNAME record. See also Limitations below.
Limitations
Virtual Alias records cannot coexist in IPAM with other records of the same type (i.e. you cannot define both a virtual A Alias and a stand-alone A record for the same name). There is no “fallback” functionality.
Virtual Alias records can be difficult to troubleshoot, since the external behavior of their target names might change unpredictably.
CloudFront in particular tends to return a wide variety of different answers for the same target name at any given moment (not just over time), so it is entirely reasonable and expected for each individual IPAM authoritative nameserver to return a different answer for the virtual alias name (each corresponding to the response that particular nameserver most recently got from CloudFront), and for none of those answers to match a separate test query for the CloudFront target name.
Virtual Alias records cannot be used in DNSSEC signed zones.
We don’t use DNSSEC signed zones as this time, but plan to do so in the future.
At this time, we are offering virtual Alias records only for the zone apex of a second-level non-.edu domain (e.g. example.com), not for .edu subdomains.
(Note however that third-level .edu subdomains can be registered as a third-level CNAME record in the illinois.edu zone instead.)
Configuring virtual Alias records
Unfortunately we are not able to offer self-service configuration of virtual Alias records within IPAM at this time. Changes should be made by request to hostmgr; be sure to include
- fully qualified domain name (FQDN) for the virtual alias
- which record type(s) should be aliased
- the target FQDN
Virtual Alias records vs DNS Traffic Control
Virtual Alias records and DNS Traffic Control both involve synthesized responses, but they are aimed at different use cases.
Consider using DNS Traffic Control if your service has a stable set of eligible target IP addresses, but some of them might be unhealthy from time to time.
Consider using a Virtual Alias record if your service has a stable target DNS name, but the set of IP addresses that name might resolve to is unpredictable (and it’s not possible to use a CNAME record).