This records contains important information about the DNS zone. These records are used to determine how your zone propagates to the secondary nameservers. The SOA record includes the following details:
- The primary name server for the domain.
- The responsible party for the domain.
- A timestamp that changes if you update the domain.
- The number of seconds before the zone should be refreshed.
Hereby you can find an example of a SOA Record:
An A Record is used to point a logical domain name, like openprovider.com, to the IP address of Openprovider's hosting server, "184.108.40.206".
The value of this record must be a Valid IPv4 address, see the following example:
This record has the same function than an A record but while the A record points to a IPv4 address the AAAA record points to a IPv6 address for given host.
The value of this record must be valid IPv6 address.
This is how an AAAA record looks like:
Certification Authority Authorization, or CAA record allows you to declare specific CA's permitted to issue an SSL certificate for your domain.
The record’s syntax is fairly simple. Here's an example of a valid CAA record in Openprovider:
Lets take a look at some of the values more closely:
www.domain.tld - your domain name.
0 - Issuer critical value flag. According to RFC 6844 this value should always be set to 0 in order to be compliant with future extensions to CAA.
issue - Permits a specified CA to issue a certificate for the domain. The value has two valid states: issue, which allows non-wildcard certificates to be issued, and issuewild - permits issuance of wildcard certificates.
"certificateauthority.tld" - the domain name of the CA you're granting a permission to issue a certificate.
Moreover, you can create additional "incident reporting" record, which will send iodef format reports of any issued or requested certificates that violate your CAA policy to a specified email or URL. Please refer to the example below:
CNAME stands for Canonical Name and are an alias for a sub domain.With such a record you can point a subdomain (like www) to the DNS entry of the domain.
The value of such a record must be valid hostname.
Hereby an example of a CNAME record in our system:
One thing to keep in mind when using CNAME records, a CNAME record gets priority over other records, which means that other records using the same hostname, will not be read. This can cause issues if you have MX or other records using the same hostname as the CNAME record.
A mail exchanger record (MX record) is a type of resource record in the Domain Name System that specifies a mail server responsible for accepting email messages on behalf of a recipient's domain, and a preference value used to prioritize mail delivery if multiple mail servers are available.
Here you can see how a MX record looks like:
A TXT record (short for text record) provides text information to sources outside your domain. It is a type of resource record in the Domain Name System (DNS) used to provide the ability to associate some arbitrary and unformatted text with a host or other name, such as human readable information about a server, network, data center, and other accounting information.
Hereby an example:
TXT-records are often used in e-mail security, for storing SPF and/or DMARC DNS records:
It is required to surround TXT records with quotes, otherwise the entire zone can has issues to resolve correctly. It's even required when creating a TXT record to define SPF data; if not surrounded by quotes, the behaviour may be different from what you expect.
If you want to add a large TXT record you may use quotes to split it into smaller pieces within one record like below:
name IN TXT ( “v=DKIM1; g=*; k=rsa; “
Note that the record type "SPF" is legacy; SPF records should be defined in TXT records.
An SPF record identifies which mail servers are permitted to send email on behalf of your domain. The purpose of an SPF record is to prevent spammers from sending messages with forged From addresses at your domain.
More extensive information about SPF records is available on our special SPF page.
SRV records are used in Internet Telephony for defining where a SIP service may be found. A SRV record typically defines a symbolic name and the transport protocol used as part of the domain name, and defines the priority, weight, port and target for the service in the record content. It is possible to enter SRV-records in the DNS-panel of Openprovider. The general structure of such a record is the following:
- The name of the record is the service followed by the protocol, for example _sip._tls. No domain name is added: Openprovider does this automatically
- The value contains the fields for weight, port and target, each separated by a space. Example: 1 443 sipdir.domain.com
- The priority is entered into the priority field
- The TTL is entered into the ttl field
Some more examples:
|_service._protocol||SRV||weight port target||priority||ttl|
|_sip._tls||SRV||1 443 sipdir.online.lync.com||100||86400|
|_sipfederationtls._tcp||SRV||1 5061 sipfed.online.lync.com||100||
PTR records are used for the Reverse DNS (Domain Name System) lookup. Using the IP address you can get the associated domain/hostname. An A record should exist for every PTR record. The usage of a reverse DNS setup for a mail server is a good solution. A hosting provider can add the record on the IP block
You can't create a PTR record for the ip address in your domain name DNS zone. The PTR record needs to be created in the rDNS zone by the owner of the netblock that encompasses your ip address.(i.e. your ISP)
So, this can not be added in your dns zone at Openprovider.
Unfortunately, we do not support alias / ANAME records yet.
This section does not describe a special type of record but covers the concept of a wildcard in a DNS record, like
*.example.com A 220.127.116.11
The above example says that any sub domain under example.com (www.example.com, mail.example.com, whatever.example.com) should be treated as an A record to the IP address 18.104.22.168. This is useful to quickly catch all possible subdomains to one specific IP address.
There is one important exception when using wildcards: the wildcard will not match if another record exists with the same subdomain. For example, if there is a record default._domainkey.example.com, the wildcard *.example.com will not match _domainkey.example.com anymore.
All details about wildcards in a DNS record can be found in section 4.3.3 of RFC1034.