An apex record is one at the root of a DNS zone. Sometimes called "naked domains".
For example, in "https://github.com/" they are the records particularly for "github.com", rather than for subdomains that might exist such as "www.github.com" or "gist.github.com".
Apex records have a particular restriction: they cannot be aliases, because the apex includes DNS metadata that is not allowed to be aliased[3]. Read on for how this becomes a problem.
I've used the term "floating" as a visual metaphor, because what I'm about to describe lacks a universal standard name, because it is an ugly hack:
HTTP resolves endpoints using host records, so an URL of "https://github.com" means looking up A and AAAA records for "github.com". Yes, the protocol is arrogant enough[1] to assume that your host address for the whole domain is that of the web server. (This is why we ended up prepending "www" to domain names, as a service selector). In response to the query you get an IP address.
Unfortunately, IP addresses sometimes change without warning. The most common example today is the loadbalancer offered by Amazon Web Services. The solution to this is to use an alias record in your human-friendly domain, pointing at an hidden technical domain that the infrastructure provider keeps up-to-date (e.g. "my-elb-name-1-1160186271.ap-southeast-1.elb.amazonaws.com")
This is fine for "www.example.com" but not the naked "example.com", because aliases are prohibited at the apex.
As a result, DNS providers such as Route 53 have ended up with a hack: a spoofed record at the apex, one that tracks an external resource and synthesizes a fake A/AAAA response. Now you have a naked domain that tracks, or rather hopes to track, the correct endpoint. But it changes with the wind. Hence my description of it as "floating".
There is no consistent name for this kludge. AWS calls it an alias, and for reliability concerns restrict it to their own infrastructure only; DME call it an "ANAME" record [2]. The model can even be readily implemented as a shell script run out of cron on your nameserver. It is fragile, it is often unreliable, it is not at all standardised, and it doesn't scale beyond one service.
One better solution would be to require use of SRV records, which allow one to declare instead, for example, an "https" service for "example.com". Alongside, let's say, the xmpp service, sip service, or any other service you care to announce. SRV records can exist at the apex. They can also bundle the A and AAAA (IPv6) addresses for the resulting endpoints in the answer, and select alternative port numbers without bothering the user about it.
Not quite a universal panacea: there is a minor hazard of zone cuts that could increase the number of client lookups, but that's an edge case, not one you can easily blunder into and also easy to fix.
[1] HTTP/1.0 and earlier are forgiven, because they hail from a time when you just had a web server in a rack and called it "www". But HTTP/2 is supposed to respond to modern architectures.
For example, in "https://github.com/" they are the records particularly for "github.com", rather than for subdomains that might exist such as "www.github.com" or "gist.github.com".
Apex records have a particular restriction: they cannot be aliases, because the apex includes DNS metadata that is not allowed to be aliased[3]. Read on for how this becomes a problem.
I've used the term "floating" as a visual metaphor, because what I'm about to describe lacks a universal standard name, because it is an ugly hack:
HTTP resolves endpoints using host records, so an URL of "https://github.com" means looking up A and AAAA records for "github.com". Yes, the protocol is arrogant enough[1] to assume that your host address for the whole domain is that of the web server. (This is why we ended up prepending "www" to domain names, as a service selector). In response to the query you get an IP address.
Unfortunately, IP addresses sometimes change without warning. The most common example today is the loadbalancer offered by Amazon Web Services. The solution to this is to use an alias record in your human-friendly domain, pointing at an hidden technical domain that the infrastructure provider keeps up-to-date (e.g. "my-elb-name-1-1160186271.ap-southeast-1.elb.amazonaws.com")
This is fine for "www.example.com" but not the naked "example.com", because aliases are prohibited at the apex.
As a result, DNS providers such as Route 53 have ended up with a hack: a spoofed record at the apex, one that tracks an external resource and synthesizes a fake A/AAAA response. Now you have a naked domain that tracks, or rather hopes to track, the correct endpoint. But it changes with the wind. Hence my description of it as "floating".
There is no consistent name for this kludge. AWS calls it an alias, and for reliability concerns restrict it to their own infrastructure only; DME call it an "ANAME" record [2]. The model can even be readily implemented as a shell script run out of cron on your nameserver. It is fragile, it is often unreliable, it is not at all standardised, and it doesn't scale beyond one service.
One better solution would be to require use of SRV records, which allow one to declare instead, for example, an "https" service for "example.com". Alongside, let's say, the xmpp service, sip service, or any other service you care to announce. SRV records can exist at the apex. They can also bundle the A and AAAA (IPv6) addresses for the resulting endpoints in the answer, and select alternative port numbers without bothering the user about it.
Not quite a universal panacea: there is a minor hazard of zone cuts that could increase the number of client lookups, but that's an edge case, not one you can easily blunder into and also easy to fix.
[1] HTTP/1.0 and earlier are forgiven, because they hail from a time when you just had a web server in a rack and called it "www". But HTTP/2 is supposed to respond to modern architectures.
[2] http://www.dnsmadeeasy.com/services/aname-records/
[3] none of you comedians are allowed to mention DNAME records as the exotic counterexample.