This chapter lists all record types PowerDNS supports, and how they are stored in backends. The list is mostly alphabetical but some types are grouped.
Warning
Host names and the MNAME of a SOA records are NEVER
terminated with a ‘.’ in PowerDNS storage! If a trailing ‘.’ is present
it will inevitably cause problems, problems that may be hard to debug.
Use pdnsutil check-zone to validate your zone data.
Note
Whenever the storage format is mentioned, this relates only to the way the record should be stored in one of the generic SQL backends. The other backends should use their native format.
The PowerDNS Recursor can serve and store all record types, regardless of whether these are explicitly supported.
The A record contains an IP address. It is stored as a decimal dotted quad string, for example: ‘203.0.113.210’.
The AAAA record contains an IPv6 address. An example: ‘2001:DB8:2000:bf0::1’.
A specialised record type for the ‘Andrew Filesystem’. Stored as: ‘#subtype hostname’, where subtype is a number.
The ALIAS pseudo-record type is supported to provide CNAME-like mechanisms on a zone’s apex. See the howto for information on how to configure PowerDNS to serve records synthesized from ALIAS records.
The APL record, specified in RFC 3123, is used to specify a DNS RR type “APL” for address prefix lists.
The “Certification Authority Authorization” record, specified in RFC 6844, is used to specify Certificate Authorities that may issue certificates for a domain.
The CDNSKEY (Child DNSKEY) type is supported.
The CNAME record specifies the canonical name of a record. It is stored plainly. Like all other records, it is not terminated by a dot. A sample might be ‘webserver-01.yourcompany.com’.
The CSYNC record is used for ‘Child-to-Parent Synchronization in DNS’, as described in RFC 7477. Right now it is only supported as zone content; no special processing is implemented. Note that SOA-EDIT is not applied to serial numbers in CSYNC content.
The DNSKEY DNSSEC record type is fully supported, as described in RFC 4034. Enabling DNSSEC for domains can be done with pdnsutil.
The DNAME record, as specified in RFC 6672 is supported. However,
dname-processing has to be set to yes for PowerDNS to process these records.
The DS DNSSEC record type is fully supported, as described in RFC 4034. Enabling DNSSEC for domains can be done with pdnsutil.
Hardware Info record, used to specify CPU and operating system. Stored with a single space separating these two, example: ‘i386 Linux’.
The LOC record is fully supported. For its syntax, see RFC 1876.
A sample content would be: 51 56 0.123 N 5 54 0.000 E 4.00m 1.00m 10000.00m 10.00m
The MX record specifies a mail exchanger host for a domain. Each mail
exchanger also has a priority or preference. For example
10 mx.example.net. In the generic SQL backends, the 10 should go
in the ‘priority field’.
Naming Authority Pointer, RFC 2915. Stored as follows:
'100 50 "s" "z3950+I2L+I2C" "" _z3950._tcp.gatech.edu'.
The fields are: order, preference, flags, service, regex, replacement. Note that the replacement is not enclosed in quotes, and should not be. The replacement may be omitted, in which case it is empty. See also RFC 2916 for how to use NAPTR for ENUM (E.164) purposes.
Nameserver record. Specifies nameservers for a domain. Stored plainly:
ns1.powerdns.com, as always without a terminating dot.
The NSEC, NSEC3 and NSEC3PARAM DNSSEC record type are fully supported, as described in RFC 4034. Enabling DNSSEC for domains can be done with pdnsutil.
The OPENPGPKEY records, specified in RFC 7929, are used to bind OpenPGP certificates to email addresses.
Reverse pointer, used to specify the host name belonging to an IP or
IPv6 address. Name is stored plainly: www.powerdns.com. As always,
no terminating dot.
Responsible Person record, as described in RFC 1183. Stored with a single space
between the mailbox name and the more-information pointer. Example:
peter.powerdns.com peter.people.powerdns.com, to indicate that
peter@powerdns.com is responsible and that more information about
peter is available by querying the TXT record of
peter.people.powerdns.com.
The Start of Authority record is one of the most complex available. It specifies a lot about a domain: the name of the master nameserver (‘the primary’), the hostmaster and a set of numbers indicating how the data in this domain expires and how often it needs to be checked. Further more, it contains a serial number which should rise on each change of the domain.
The stored format is:
primary hostmaster serial refresh retry expire minimum
Besides the primary and the hostmaster, all fields are numerical. The fields have complicated and sometimes controversial meanings.
The SSHFP record type, used for storing Secure Shell (SSH) fingerprints, is fully supported. A sample from RFC 4255 is:
2 1 123456789abcdef67890123456789abcdef67890
SRV records can be used to encode the location and port of services on a
domain name. When encoding, the priority field is used to encode the
priority. For example,
_ldap._tcp.dc._msdcs.conaxis.ch SRV 0 100 389 mars.conaxis.ch would
be encoded with 0 in the priority field and
100 389 mars.conaxis.ch in the content field.
New in version 4.4.0.
SVCB records, defined in (draft-ietf-dnsop-svcb-https-07) are used to facilitate the lookup of information needed to make connections to network services. SVCB records allow a service to be provided from multiple alternative endpoints, each with associated parameters (such as transport protocol configuration and keys for encrypting the TLS ClientHello). They also enable aliasing of apex domains, which is not possible with CNAME. The HTTPS RR is a variation of SVCB for HTTPS and HTTP origins.
Additional processing is supported for these types. Some PowerDNS extensions for automatic IP address hints exist as well.
The TKEY (RFC 2930) and TSIG records (RFC 2845), used for key-exchange and authenticated AXFRs, are supported. See the TSIG and DNS update <../dnsupdate> documentation for more information.
Since 3.0. The TLSA records, specified in RFC 6698, are used to bind SSL/TLS certificate to named hosts and ports.
Since 4.1. The SMIMEA record type, specified in RFC 8162, is used to bind S/MIME certificates to domains.
The TXT field can be used to attach textual data to a domain. Text is
stored plainly, PowerDNS understands content not enclosed in quotes.
However, all quotes characters (") in the TXT content must be
preceded with a backslash (\).:
"This \"is\" valid"
For a literal backslash in the TXT record, escape it:
"This is also \\ valid"
Unicode characters can be added in two ways, either by adding the
character itself or the escaped variant to the content field. e.g.
"ç" is equal to "\195\167".
When a TXT record is longer than 255 characters/bytes (excluding possible enclosing quotes), PowerDNS will cut up the content into 255 character/byte chunks for transmission to the client.
The following, rarely used or obsolete record types, are also supported: