The following DNS record types are available in the DNS Management of Openprovider; below the table, each DNS record is explained in more detail:
|A||Refers to an IP address||Valid IPv4 address||-|
|AAAA||Refers to an IPv6 address||Valid IPv6 address||-|
|CAA||Defines which CAs are allowed to issue SSL certificates||Issuing information|
|CNAME||Alias for a subdomain||Valid hostname||-|
|MX||Defines a mailserver||Existing A-record||Low value means high priority|
|NS||Defines the nameservers||Valid nameservers||-|
|SOA||Important information about the DNS zone||This records contains information about:
- the master nameserver
- e-mailaddress of the zone responsible
- some synchronization fields
|SPF (deprecated)||Authorizes e-mail messages; see TXT record for details.||Sender Policy Framework definition||-|
|SRV||Allows for discovery of services||Weight, port and target||-|
|TXT||Allows human-readable text (max. 255 characters)||
Free value; also used for definition of SPF, DKIM and DMARC records.
|Wildcard||General information about using wildcard DNS records.|
|Unsupported DNS record types||General information about DNS records not (yet) supported by Openprovider.|
An A record is used to point a logical domain name, like openprovider.com, to the IP address of Openprovider's hosting server, "22.214.171.124".
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:
Note: MX records with a priority of "0" are not supported in our DNS Zones.
Nameserver (NS) records define the authoritative nameservers for the domain. In the Openprovider DNS management, the NS records are created automatically.
It is not possible to assign nameservers for sub domains.
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:
In the Openprovider DNS management, the SOA record is created automatically.
Note that the record type "SPF" is deprecated; SPF records should be defined in TXT records. 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||
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:
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; “
This section does not describe a special type of record but covers the concept of a wildcard ("*", a star or asterisk) in a DNS record, like
*.example.com A 126.96.36.199
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 188.8.131.52. 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.
Unsupported record types
This section contains basic information about record types that are not supported in the Openprovider DNS management. This section is included for reference.
An ANAME record is like a CNAME record, but at the root level. An ANAME record bypasses the problems with CNAME records at root level, so it can be used to redirect a domain to another domain. However, ANAME records are still in draft specification and as a result, are not supported by Openprovider.
NAPTR records are most commonly used for applications in Internet telephony, for example, in the mapping of servers and user addresses in the Session Initiation Protocol (SIP). The combination of NAPTR records with Service Records (SRV) allows the chaining of multiple records to form complex rewrite rules which produce new domain labels or uniform resource identifiers (URIs). For this moment Openprovider does not support NAPTR records. Because of the different structure of NAPTR records it's for this moment not supported by Openprovider.
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.