This article covers CAA, SSHFP, and TLSA DNS records in detail. For general instructions on DNS records and how to set them up in the Customer Administration, see the article DNS – Domain Records.
In this article, you will learn:
- What CAA records are used for
- How the HTTPS record works
- How the SSHFP record works
- How the TLSA record works
- Frequently Asked Questions
CAA Records
A Certification Authority Authorization (CAA) record lets you specify which certification authorities (CAs) are allowed to issue an SSL certificate for a domain. One variant of the record also lets you define a rule for how and to whom the issuing CA reports an attempt by a certification authority that the record does not authorize to issue a certificate for the domain.
If a domain or subdomain has no CAA record set, any CA can issue a certificate for it without restriction. A certification authority may also not support CAA records, in which case it behaves as if they did not exist.
CAA records set for the main domain also apply to all subdomains that do not have their own CAA record with different rules.
Entering CAA records
For general instructions on setting up DNS records in the Customer Administration, see the article DNS – Domain Records.
If the domain uses different DNS servers, neither automatic nor manual changes to WEDOS records will affect its behavior.
CAA record data consists of the following parts:
- Flag: a positive number with a value of 0-255 ⧉ (usually 0)
- Tag: defines the property of the CAA record
- Value: the value assigned to the tag
The supported tags are:
- issue: authorizes the specified CA to issue any type of certificate
- issuewild: authorizes the specified CA to issue wildcard certificates only
- iodef: specifies the URL to which the issuing CA reports violations of the rules defined by CAA for the given domain
When filling in a CAA record, follow these rules:
- Assign exactly one tag-value rule to each record.
- If you need to enter multiple rules, split them into separate records.
- Enclose tag values (value) in quotation marks.
A general CAA record therefore 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 to be issued by letsencrypt.org. If another authority attempts to issue a certificate, it sends a notification by email to info@wds-test.cz.
HTTPS Record
An HTTPS record helps clients find a secure connection, among other things by providing information about supported protocols and ports.
HTTPS Record Format
A DNS record of type HTTPS (RFC 9460 ⧉) contains a priority, a target (if it differs from the domain), and other parameters (for example, supported HTTP versions and IP address hints).
SSHFP Record
When a connection to a server is established using the SSH protocol, authentication takes place by verifying the server’s identity using keys. The security of the connection therefore depends on comparing the fingerprint provided by the server with the expected fingerprint of the server’s public key.
A DNS record of type SSHFP (RFC 4255 ⧉) gives SSH clients a new way of authenticating by comparing the fingerprint provided by the server with the fingerprint stored in the domain’s DNS zone. All parameters of the SSHFP record must match during the comparison: the algorithms used to generate the key and its fingerprint, as well as the key fingerprint itself.
Using DNS SSHFP only makes sense if this record is signed with DNSSEC, so that it cannot be forged.
SSHFP Record Format
An SSHFP record consists of three parts: the number of the algorithm used to generate the key, the number of the algorithm used to generate the fingerprint, and the fingerprint of the server’s public key itself.
TLSA Record
A DNS record of type TLSA (RFC 6698 ⧉) specifies the service certificate for a combination of FQDN, protocol, and port. A TLSA record can therefore be used to verify that the certificate has not been altered on the way between the recipient and the sender.
TLSA Record Format
A TLSA record has a specific format for both its name and its data. The symbolic name of an SRV record usually takes the form _port._protocol, e.g. _443._tcp.
The TLSA record data itself contains three parameters followed by binary certificate association data: the number assigning the certificate to the domain name, the selector number, the matching type number for comparing the certificate from the chain against the data in the TLSA record, and finally the data to be matched 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 without any problems even without these records.