The ALIAS record type was introduced in PowerDNS to have a behavior similar to a CNAME at the zone apex. To borrow the example from the PowerDNS documentation, you can add an ALIAS record at the apex of your example.net zone like this

@ IN ALIAS mywebapp.paas-provider.net.

and the authoritative server will answer with the IP address of mywebapp.paas-provider.net at the time of the query.

I discovered that the ALIAS record type can be used in a couple of very useful alternative ways, to have fewer instances of the same IP address in a zone and to get round-robin records with quasi-CNAMEs instead of IP addresses.

Caveats

These techniques work for me in my PowerDNS authoritative setup, but they might not work for you, and even if they work now they might stop working at any time you change the configuration or upgrade PowerDNS.

I didn’t make any test with DNSSEC enabled domains, I’d be interested if anyone can make these techniques work.

ALIAS for IP addresses of MX hosts

Prerequisite: A PowerDNS authoritative DNS instance with the settings expand-alias=yes and resolver set to an actual DNS resolver, for example resolver=8.8.8.8.

Here’s a zone fragment declaring 2 MX records, with the actual MX service hosted on 2 different IP addresses:

example.com          1800 IN MX 10 mx1.example.com
example.com          1800 IN MX 20 mx2.example.com
mx1.example.com      1800 IN A 192.0.2.1
mx2.example.com      1800 IN A 192.0.2.2
host1.example.com    1800 IN A 192.0.2.1 # same IP as mx1
host2.example.com    1800 IN A 192.0.2.2 # same IP as mx2

There’s nothing wrong with this zone, but it would be better if we didn’t have to repeat the IP addresses of host1 and host2 in the mx1 and mx2 records. Also, if for some reason we have to change the IP address of host1, we’ll have to remember to change the IP address of mx1 as well.

The ALIAS record offers us a way to eliminate the repetition of those IP addresses:

example.com         1800 IN MX 10 mx1.example.com
example.com         1800 IN MX 20 mx2.example.com
mx1.example.com     1800 IN ALIAS host1.example.com
mx2.example.com     1800 IN ALIAS host2.example.com
host1.example.com   1800 IN A 192.0.2.1
host2.example.com   1800 IN A 192.0.2.2

When you query for mx1.example.com, PowerDNS will call the resolver defined in its configuration and will return the IP address of host1.example.com. If we need to update host1‘s IP address, we only have one line to change instead of two.

ALIAS for round-robin CNAME

Prerequisite: A PowerDNS hidden master, configured with expand-alias=yes and outgoing-axfr-expand-alias=yes, plus one or more PowerDNS slaves, configured to transfer zones from the hidden master via AXFR.

As far as I can see, this trick relies on AXFR and won’t work if your PowerDNS instances are running in native mode (that is, record data is transmitted via database replication).

In my experiments, the master needs to be hidden, that is not declared at your registrar nor named in the NS records for your zone, because when queried for the pseudo round-robin record it will always answer with one IP address; only the slaves will return multiple IP addresses, because their databases will actually contain the A records obtained by the resolver configured on the master.

Here’s a zone fragment with 3 A records pointing to 3 different IPs (as in 3 different physical servers) and the round-robin records:

host1.example.com     1800 IN A 192.0.2.1
host2.example.com     1800 IN A 192.0.2.2
host3.example.com     1800 IN A 192.0.2.3
srv.example.com       1800 IN A 192.0.2.1
srv.example.com       1800 IN A 192.0.2.2
srv.example.com       1800 IN A 192.0.2.3

As in the previous example, if we want to change the IP address of host1 we’ll also have to change it in the corresponding record for srv. But if we take advantage of the ALIAS record type, we’ll have to change it in one place only:

host1.example.com      1800 IN A 192.0.2.1
host2.example.com      1800 IN A 192.0.2.2
host3.example.com      1800 IN A 192.0.2.3
srv.example.com        1800 IN ALIAS host1.example.com
srv.example.com        1800 IN ALIAS host2.example.com
srv.example.com        1800 IN ALIAS host3.example.com

With this configuration, we get the benefits of a CNAME record and the round-robin behavior which is otherwise possible with A records only.

Performance and Monitoring

DNS resolution on the authoritative PowerDNS server is critical for these 2 tricks to work. PowerDNS allows specifying multiple resolvers or use whatever is specified in /etc/resolv.conf, so make sure to have at least 2 resolvers and alerts in your monitoring system.

Watch out for messages like the following in PowerDNS logs:

Aug 16 16:16:38 dns.example.com pdns_server[1673]: Aug 16 16:16:38 Error resolving for ALIAS mirror.example.net., aborting AXFR

and if they appear, check the name resolution on the hidden master.

Alternatives

After writing this article, I tried to imagine if there were cleaner, alternative ways of implementing this behavior without using ALIAS records.

For example, each one of the hosts pointed to by srv.example.com could update a record on the authoritative PowerDNS server using DDNS (the protocol defined in RFC 2136 and updates), provided that multiple records can be defined and updated with the usual DDNS client tools.

Another technique would be having each host make the appropriate API calls to the PowerDNS authoritative server to maintain one A record pointing to itself, again with the slightly increased complexity of not erasing the values for the other hosts.

I haven’t tried to implement those alternative techniques, since the current setup with the ALIAS records works well enough for me. Also, it seems to me that there is a sort of chicken-and-egg issue where each host would need to be configured with an explicit hostname and the aliased name in order to update the records on the authoritative DNS, which then wouldn’t be very authoritative anymore.