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.
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
resolver set to an actual DNS resolver, for example
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
host2 in the
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
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: 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.
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.