What is the name for a DNS record starting with @?

Question

I know that DNS records starting with * are called Wildcard records. What is the name for DNS record starting with @ (the at symbol). This is a record for the root domain (e.g. just example.com, not www.example.com)

I want to find out more, but searching for "@ record dns" in Google doesn't return any useful results.

What is the correct terminology for this type of record, and where might I find it described in more detail?

RFC 1035 describes the use of @ in a DNS record, but doesn't go as far as giving it a name.

This is not a question about what the @ symbol does or how it works. It is a question about the name for this kind of record.

Answer 1

In a DNS file, the "@" symbol is a placeholder used to represent "the current domain".

The @ symbol in your DNS record refers to the record for your domain name without any www or sub-domain name.

Answer 2

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.

[2] http://www.dnsmadeeasy.com/services/aname-records/

[3] none of you comedians are allowed to mention DNAME records as the exotic counterexample.

Answer 3

@ is a "placeholder", "DNS short-hand", for "the current origin" or $ORIGIN.

And no fancy name.

---

@ in zone files is defined in RFC 1035 - page 35:

@     A free standing @ is used to denote the current origin.

but no further name is assigned.

Note that "current origin" is NOT necessarily the same as "current domain".

IMHO that makes using the name "apex" also slightly incorrect.

Although you don't see it often anymore, in manually configured zone files you can set $ORIGIN explicitly and you can set it to something different than the zone/domain name:

• you can set $ORIGIN to . (dot) which effectively disables the @ shorthand but which also prevents unexpected issues when sloppy administrators inconsistently intend to use FQDN's but don't terminate them with a trailing .

• even more rare (and confusing) is that you can reset $ORIGIN in a zone file, and leverage the fact that the new domain will be used for subsequent unqualified domains and do something obscure like this:

  $ORIGIN 1.0.10.in-addr.arpa.
  $TTL 86400
  @     IN     SOA    dns1.example.com.     hostmaster.example.com. (
                    2001062501 ; serial
                    21600      ; refresh after 6 hours
                    3600       ; retry after 1 hour
                    604800     ; expire after 1 week
                    86400 )    ; minimum TTL of 1 day
  
  @    IN     NS     dns1.example.com.
              NS     dns2.example.com.
  
  ; The NS records above showcase several shorthand techniques
  ; 1. By starting the line with a blank character the line with 
  ;    the dns2 name server Resource Record is owned by the 
  ;    previous owner, i.e. the previous @ record
  ; 2. The @ is shorthand for $ORIGIN ==  1.0.10.in-addr.arpa.
  ; 3. When the TTL field is omitted the default $TTL will be used.
  ; 4. When the class field is omitted the default IN internet class is used. 
  ;  
  ; After expanding all shorthand :
  
  1.0.10.in-addr.arpa.  86400  IN   NS   dns1.example.com.
  1.0.10.in-addr.arpa.  86400  IN   NS   dns2.example.com.
  
  
  ; The example below showcases how a short hostname is commonly 
  ; used as shorthand. The DNS server will append $ORIGIN where 
  ; a FQDN is expected.
  
  1                                 PTR    gateway.example.com.
  2                                 PTR    dns1.example.com. 
  3                                 PTR    dns2.example.com
  
  ; note below also the effect of the common typo in dns2.example.com
  ; showcasing how any hostname not terminated with a . will be considered 
  ; a "short" hostname rather than a FQDN once all shorthand is expanded:
  
  1.1.0.10.in-addr.arpa.  86400 IN  PTR    gateway.example.com.
  2.1.0.10.in-addr.arpa.  86400 IN  PTR    dns1.example.com. 
  3.1.0.10.in-addr.arpa.  86400 IN  PTR    dns2.example.com.1.0.10.in-addr.arpa.
  
  ; showcase below how resetting the $ORIGIN can be used 
  ; for even more efficient shorthand 
  
  $ORIGIN floor1.example.com.
  20.1.0.10.in-addr.arpa.    IN     PTR    alice
  ; will be completed with the new $ORIGIN and $TTL to:
  20.1.0.10.in-addr.arpa.  86400 IN PTR    alice.floor1.example.com.
  21.1.0.10.in-addr.arpa.    IN     PTR    betty
  22.1.0.10.in-addr.arpa.    IN     PTR    charlie
  23.1.0.10.in-addr.arpa.    IN     PTR    doug
  24.1.0.10.in-addr.arpa.    IN     PTR    ernest
  25.1.0.10.in-addr.arpa.    IN     PTR    fanny
  
  $ORIGIN floor2.example.com.
  26.1.0.10.in-addr.arpa.    IN     PTR    geoff
  ; will be completed with $ORIGIN and $TTL to:
  26.1.0.10.in-addr.arpa.  86400 IN PTR    geoff.floor2.example.com.
  27.1.0.10.in-addr.arpa.    IN     PTR    honey
  

And then @ and $ORIGIN have several different values.

Answer 4

I have heard this referred to as the "Apex Record", I think it's the most suitable term in the absense of a clearly defined one.

It is also coincidental that in many places an a can be replaced by an @ symbol for stylistic reasons, so it makes a convenient mnemonic to think '@pex record'.