This article discusses in detail the CAA, SSHFP, and TLSA DNS records. For general instructions on DNS records and how to set them up in the customer administration, see DNS - Domain Records.
In this article you will learn:
- What CAA records are used for
- How an HTTPS record works
- How the SSHFP record works
- How a TLSA record works
- Frequently Asked Questions
CAA records
The Certification Authority Authorization (CAA) record allows you to specify which certificate authorities (CAs) are allowed to issue an SSL certificate to a domain. A variant of the record also allows you to define a rule for how and to whom the issuing CA notifies an event when someone attempts to issue a certificate to the domain from a CA that is not authorized by the record to do so.
If a domain or subdomain has no CAA record set, any CA can issue a certificate to it without restriction. The CA also does not have to support CAA records, in which case it behaves as if they did not exist.
CAA records set for the main domain apply to any subdomains that do not have their own CAA record set with different rules.
Entering CAA records
For general instructions on setting up DNS records in the customer administration, see DNS - Domain Records.
If the domain uses other DNS servers, automatic or manual changes to WEDOS records will not affect its behavior.
The CAA record data consists of the following parts:
- Flag: positive number with value 0-255 ⧉ (usually 0)
- Tag: defines a property of the CAA record
- Value: value assigned to the tag
Supported tags are:
- issue: authorizes the defined CA to issue any type of certificate
- issuewild: authorizes the defined CA to issue only a wildcard certificate
- iodef: specifies the URL to which the issuing CA will report violations of the rules defined by the CAA for the domain
When completing a CAA type record, follow these rules:
- Assign just one tag-value rule to each record.
- If you need to specify multiple rules for one record, split them between separate records.
- Write tag values (value) in quotes.
A generic CAA record looks like this:
Name TTL Type Data
(domain or subdomain name) 300 CAA 0 (flag) "(value)"
Examples of CAA records
Example: the domain allows certificates from letsencrypt.org to be issued. If another authority attempts to issue a certificate, it will send an email to info@wds-test.cz.
HTTPS record type
The HTTPS log helps clients find a secure connection by, among other things, providing information about supported protocols and ports.
HTTPS record format
The DNS record of type HTTPS(RFC 9460 ⧉) contains the priority, destination (if different from the domain) and other parameters (for example, supported HTTP versions, IP address hints).
SSHFP record type
When establishing a connection to a server using the SSH protocol, authentication occurs by verifying the server's identity using keys. The security of the connection thus depends on comparing the fingerprint provided by the server with the expected public key fingerprint of the server.
The SSHFP DNS record(RFC 4255 ⧉) gives SSH clients a new way to authenticate by comparing the fingerprint provided by the server against the fingerprint stored in the domain's DNS zone. When comparing, all parameters of the SSHFP record must match - the algorithms used to generate the key and its fingerprint, and the key fingerprint itself.
Using DNS SSHFP only makes sense if the record is signed by DNSSEC and therefore cannot be spoofed.
SSHFP record format
The SSHFP record consists of three parts: the algorithm number used to generate the key, the algorithm number used to generate the fingerprint, and the server's public key fingerprint itself.
TLSA type record
A DNS TLSA record(RFC 6698 ⧉) specifies a service certificate for a combination of FQDN, protocol, and port information. The TLSA record can therefore be used to verify that the certificate has not been altered on the path between the sender and the receiver.
TLSA record format
A TLSA record has a specific name and data format. The symbolic name of an SRV record usually takes the form _port._protokol, e.g. _443._tcp.
The TLSA record data itself contains three parameters and then the binary data for the certificate association: the certificate's domain name assignment number, the selector number, the certificate match type number from the string against the data in the TLSA record, and finally the data for matching against the provided certificate.
Frequently Asked Questions
Is it necessary to set up CAA, SSHFP and TLSA records for a domain?
No, most domains work fine without these records.