DNS Management

Can't assign nameserver to a domain: "Can't resolve IP address from host"

Symptoms

Attempt to assign a nameserver to a domain via RCP or API results in an error - "Can't resolve IP address from host"

Cause

Host (i.e. ns1.example.com) doesn't return an IP address or returned IP address mismatches one supplied by user.

Resolution

Ensure that IP address supplied to a nameserver in RCP or API matches the actual nameserver's IP address.

Ensure that specified host's DNS zone contains an A record with valid IP address. Check if IP is resolved via 

dig A your.host.tld

command.

Example of a valid dig command response:

dig A ns1.openprovider.nl

; <<>> DiG 9.18.30-0ubuntu0.20.04.2-Ubuntu <<>> A ns1.openprovider.nl
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17159
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;ns1.openprovider.nl. IN A

;; ANSWER SECTION:
ns1.openprovider.nl. 5039 IN A 162.159.26.10

DNS Records


The following DNS record types are available in the DNS Management of Openprovider; below the table, each DNS record is explained in more detail:

Record type Description Value Priority
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.

 -
TLSA record Associates a domain with its TLS/SSL certificate for secure authentication

Usage, Selector, Matching type and Certificate association data
Wildcard General information about using wildcard DNS records.
Unsupported DNS record types General information about DNS records not (yet) supported by Openprovider.

A Record

An A record is used to point a logical domain name, like openprovider.com, to the IP address of Openprovider's hosting server, "76.76.21.21".

The value of this record must be a Valid IPv4 address, see the following example:

embedded-image-c2cxmodi.png

AAAA

This record has the same function as an A record but while the A record points to a IPv4 address the AAAA record points to a IPv6 address for a given host.

The value of this record must be valid IPv6 address.

This is what an AAAA record looks like:

embedded-image-pgdjmdcv.png

CAA

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:

embedded-image-ah8c5eb9.png

Let's take a look at some of the values more closely:

Moreover, you can create an 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:

embedded-image-5vfolhbl.png

CNAME

CNAME stands for Canonical Name and is an alias for a subdomain. 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 a valid hostname.

Here is an example of a CNAME record in our system:

embedded-image-5vgl77wz.png

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. Learn more here.

Aliases to the apex are not supported at the moment.

MX

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 what an MX record looks like:

embedded-image-di6n6cin.png

 
Note: MX records with a priority of "NULL" are not supported in our DNS Zones.

NS

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 subdomains.

SOA

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:

Hereby you can find an example of a SOA Record:

embedded-image-uc5kiehu.png

In the Openprovider DNS management, the SOA record is created automatically. More information about Openprovider SOA record and its expire value can be found here.

SPF

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

SRV records are used in Internet Telephony to define where a SIP service may be found. An 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:

Some more examples:

Name

 Type Content Priority TTL
_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

86400

TXT

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:

embedded-image-awdlqufd.png

TXT records are often used in e-mail security, for storing SPF, DKIM, and/or DMARC DNS records:

Below you find an example of how to create an SPF record in the root zone of a domain.

embedded-image-vfgcedgf.png

The (SPF) TXT record will look in the DNS zone as: 
embedded-image-tasootl1.png

It is required to surround TXT records with quotes, otherwise, the entire zone can have issues to resolve correctly. It's even required when creating a TXT record to define SPF data; if not surrounded by quotes, the behavior 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 the one below:

name IN TXT ( “v=DKIM1; g=*; k=rsa; “
“p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1Z4F”
“JEMHjJDuBmt25zvYFVejlARZGt1L8f0s1+rLxIPYkfCogQi+Y8”
“oLEg9vvEKnLx9aogZzuNt6j4Sty3LgXxaIwHnMqk0LldbA/mh3”
“wLZb16Wc6btXHON0o3uDipxqGK2iRLTvcgAnNDegseOS+i0aJE”
“nNSl663ywRBp/QKezhUC7cnbqR/H8dz8pEOjeawNN3nexdHGsk”
“+RaafYvCFvU+70CQORcsk+mxb74SwGT2CGHWxVywQA9yrV+sYk”
“JpxaufZLo6xp0Z7RZmbf1eGlCAdhkEy+KYQpQkw2Cdl7iKIK4+”
“17gr+XZOrfFLJ5IwpVK/a19m3BLxADf0Kh3oZwIDAQAB” )

Wildcards

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    1.2.3.4

The above example says that any subdomain under example.com (www.example.com, mail.example.com, whatever.example.com) should be treated as an A record to the IP address 1.2.3.4. 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.

TLSA records

A TLSA record is a DNS record (type TLSA) that binds a TLS certificate or public key to a specific service on a specific host and port, usually protected by DNSSEC. TLSA record is supported by Openprovider DNS service, but not by Sectigo Premium DNS.

To add a TLSA record, you need:

Name: Identifies the service. The format is always _port._protocol.hostname

Type: TLSA

Content: Made up of 4 parts.

Please refer the screen-shot below for ane example:

embedded-image-oagfg6ns.png

In the above example:

port = 25
protocol = tcp
hostname = mail.h*****e.nl (domain name is auto filled)
Type = TLSA
Usage = 3
Selector = 1
Matching type =1 
Certificate association data = e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855

# Note: The above are example values. When adding a TLSA record for your domains, please ensure to use real values specific to the host, port and certificate.

DNS Round-robin

By managing the Domain Name System’s (DNS) answers to address requests from client computers according to an acceptable statistical model, round-robin DNS is a technique of load distribution, load balancing, or fault-tolerance delivering multiple, redundant Internet Protocol service hosts, e.g., Web server, FTP servers.

Drawbacks : 

  • Although simple to set up, round-robin DNS has several disadvantages, including record caching in the DNS hierarchy and client-side address caching and reuse, which can be difficult to manage when used together.
  • For service availability, round-robin DNS should not be depended on entirely.
  • If a service at one of the addresses on the list goes down, the DNS will continue to give out that address, and clients will try to contact the broken service.
  • Openprovider does not actively support DNS Round-robin.

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.

ALIAS/ANAME

An ANAME record is like a CNAME record but at the root level. An ANAME record bypasses the problems with CNAME records at the 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

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 that 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

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 to 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 cannot be added to your DNS zone at Openprovider.

Use of '@' symbol

Some DNS providers allow the use of the @ symbol to represent the root domain (e.g., example.com).

However, our system does not support this notation. Instead, please leave the "Name" field blank when editing a DNS zone.

Error CNAME - Cannot save zone record: Duplicate record

Symptoms

The following error is thrown when trying to add a record to a zone:

Cannot save zone record: Duplicate record

or

Error CNAME example.tld found, but other records with same label exist

or

Cannot save zone record: A DNS zone cannot contain a CNAME record for a host which already has another type of record. 

Please check that this zone does not have both CNAME and other types of records for the same host.

Cause

  1. A CNAME record exists with a label of a different record type.
    e.g., the zone for example.tld with the following records would cause an error: 
    www.example.tld CNAME example.tld
    www.example.tld A 1.2.3.4
    As per RFC1912 (section 2.4), A CNAME record is not allowed to coexist with any other data. In other words, if example.tld is a canonical name for www.example.tld, you can't also have an MX record for www.example.tld, or an A record, or even a TXT record.

    Do NOT try to combine CNAMEs and NS records like this!:

    example.com IN NS ns1.domain.com
    example.com IN NS ns2.domain.net
    example.com IN CNAME host.domain.com
    sub.example.com IN A 1.2.3.4

    Since no other records are allowed to coexist with a CNAME, the NS entries are ignored. Therefore all the hosts in the example.com domain are ignored as well!

    If you want to have your domain also be a host, do the following:

    example.com IN NS ns1.domain.tld
    example.com IN NS ns2.domain.tld
    example.com IN A 1.2.3.4
    sub.example.com IN A 1.2.3.4
  2. CNAME with a label that equals hostname exists: 
    example2.tld CNAME example2.tld.

3.  There is a subdomain on a lower level, for example:

You want to add sub1.domain.ext as a CNAME, but there is a record on sub2.sub1.domain.ext.

While this configuration is not prohibited, it can cause a validation error.

In this case, remove or rename the sub2.sub1.domain.ext record, and add the sub1.domain.ext CNAME, or make sure you add CNAMES first.

Error Duplicate record found in rrset: example.tld when modifying a zone

Symptoms

The following error is thrown when modifying a DNS zone:

Error TTL mismatch in rrset: example.tld

Cause

A given record appears twice in the zone. For example:

example.tld A 1.2.3.4
example.tld A 1.2.3.4

Resolution

Remove duplicate records.

Error No NS record at zone apex in zone example.tld when modifying a DNS zone

Symptoms

The following error is thrown when modifying a DNS zone:

Error No NS record at zone apex in zone example.tld

Cause

There are no records of NS type in the zone.

If Openprovider nameservers are being used, these records are automatically added.

The error can occur when 'custom nameservers' / 'vanity nameservers' / 'whitelabled nameservers' functionality is enabled within a reseller account.

Resolution

Add NS records to the zone, which correspond to the nameservers that are assigned to the domain.

Glue Records

¿Qué es un Glue Record?

Los Glue Records son las entradas que se deben crear en el registro para que un dominio pueda actuar como servidor de DNS.

Por ejemplo, imaginemos que hemos registrado el dominio ejemplo.com y que lo queremos utilizar como servidor DNS para crear ns1.ejemplo.com y ns2.ejemplo.com. El problema es que siempre que alguien quiera acceder a ejemplo.com tendrá que consultar ns1.ejemplo.com o ns2.ejemplo.com para resolver la dirección. Esto se transforma en un bucle ya que para llegar a B se tiene que pasar a A, pero para llegar a A se tiene que pasar por B.

La solución son los Glue Records. Lo que hace el registro es crear entradas "A" en sus servidores para que al intentar resolver ns1.ejemplo.com tengamos su IP.

Aunque se creen los Glue Records también hay que crear las entradas "A" a las respectivas IP de los hosts (ns1.ejemplo.com y ns2.ejemplo.com) en la zona DNS del dominio.

¿Se pueden crear los Glue Records en Openprovider?

Sí, siempre y cuando el dominio esté registrado en Openprovider, puedes crear un Glue Record desde aquí.

embedded-image-vvihjzkg.png

IMPORTANTE: Mediante esta herramienta puedes crear un Glue Record de un dominio pero NO puedes añadirle una IP al nameserver. Esto es algo que debe hacerse desde el servidor donde esté alojado el dominio, no desde nuestro panel.

Nuestro sistema coge la IP del nameserver, la que aparece haciendo un dig a la DNS. Nuestro sistema chequea varias veces al día las IPs de los nameservers, por lo que el cambio no es instantáneo.

How do I create a DKIM DNS record?

This article introduces the DomainKeys Identified Mail or DKIM record to you - a type of DNS record that allows for digitally signing of (parts of) an e-mail. It is a useful e-mail security tool to identify the sender of the e-mail and authenticate the contents of the message.

Together with SPF and DMARC, DKIM is a crucial element of e-mail security.

This article contains the following sections:

Introduction: the purpose of DKIM

The DKIM technology uses a very common protocol to verify that an e-mail was sent from an authorised server: it uses "public key cryptography", a standard that everybody knows from SSL certificates.

If DKIM is enabled, the sending mail server will digitally sign (a part of) the e-mail before it's transmitted to the recipient. The receiving mail server uses publicly available DNS records to verify the signature. If the verification succeeds, the recipient knows for sure that the e-mail was untampered with.

The idea behind public key cryptography is, that the signing key consists of two elements: a private key that nobody knows except the owner, and a public key that is available to everybody. Those two keys are related to each other: only a text encrypted with the private key can be decrypted with the public key; and a text encrypted with the public key can be decrypted with the private key only. In other words: if you can decrypt the message with the public key, you are sure it was signed with the private key that only the owner knows. And if you encrypt a message with the public key, you are sure that nobody except the owner of the private key can decrypt it.

The signature that the sending mail server adds, is included as a header to the e-mail. The receiving mail server can read in this header which parts of the e-mail it should verify, and where it can find the public key for verification.

Important note: if you want to use DKIM, your mail server must be capable of it. Check with your hosting provider or system engineer for details on activating DKIM on your mail server. A useful read is the blog of registry SIDN, who has published how-tos for Exim and Postfix that you might want to refer to. This article only describes the DNS records involved in DKIM validation.

Note on e-mail forwarding: e-mail forwarding and DKIM is a tricky combination. E-mail forwarding often changes parts of the e-mail: the sender changes, the body can change (for example because a virus scanner adds a note), and so on. If your DKIM implementation signs parts of the e-mail that change during the forwarding, the DKIM signature check can no longer be performed. Keep this in mind when configuring DKIM.

DKIM records in Openprovider

The Openprovider DNS management supports the TXT type for DNS records, that can be used to store DKIM information. The contents of the DKIM record depends on the sending mail server; your provider or system engineer is able to provide you with the correct record.

The name of the record is also important: DKIM information is not stored at the highest level, but as a subdomain which includes _domainkey:

default._domainkey

or, more general,

something._domainkey

The DKIM record now is available through default._domainkey.yourdomain.com or something._domainkey.yourdomain.com.

DKIM record syntax

Note that in most cases, your outgoing mail server provider will send you the exact contents to put in the DNS record. For understanding the syntax of this record, these are the most important elements of a DKIM record:

Putting all this together, a valid DKIM record in the DNS may look like this:

default._domainkey.yourdomain.com    TXT    "v=DKIM1; t=y; k=rsa; p=MIGfMA0GCSqGS[...]A2CA;"

DKIM for domains without e-mail

DKIM is useful as well if a domain is not intended to send e-mail. In that case, declare the following DKIM record in your DNS:

*._domainkey TXT "v=DKIM1; p="

Useful documentation

How do I create a DMARC DNS record?

This article introduces the Domain-based Message Authentication, Reporting & Conformance or DMARC record to you - a type of DNS record, related to e-mail security, that uses the results of SPF and DKIM checks to apply a certain policy. Furthermore, its reporting capabilities allow for streamlining your e-mail infrastructure.

This article contains the following sections:

Introduction: the purpose of DMARC

Before understanding DMARC, it is very important to understand the purpose of SPF and DKIM (click the links for full information):

DMARC is the technology that combines those two record types, and is the missing link for a 100% trustworthy e-mail validation. DMARC can be configured in such a way that all e-mails that fail SPF and/or DKIM checks is quarantined or blocked by default.

However, DMARC can also be used for reporting if it is configured with a much more relaxed policy - in such a way that e-mail delivery is not affected. This approach is very useful to get insight in your e-mail infrastructure: which servers send e-mail in your name, and are those servers configured correctly? Use that analysis to optimise your e-mail settings. Once done, you may change the policy to improve the quality of your e-mail delivery.

DMARC records in Openprovider

The Openprovider DNS management supports the TXT type for DNS records, that can be used to store DMARC information. The contents of the DMARC record depends on how strict you want the policy to be and your reporting settings.

A DMARC record always is placed on a subdomain which starts with _dmarc:

_dmarc

The DMARC record now is available through _dmarc.yourdomain.com.

DMARC record syntax

Each DMARC record starts with a version number, followed by a policy definition and reporting settings. A simple example is the following DNS record:

"v=DMARC1; p=none; rua=mailto:reporting@yourdomain.com;"

which defines the policy to be none (e-mail delivery is not affected) and asks receiving mailservers to send aggregated reports to reporting@yourdomain.com. 

NB! Please put your record between quotation marks every time you specify an DMARC record with any DNS zone configured within Openprovider, and always and a DMARC record with a semicolon (;).

Read on for more details about the syntax. 

Version number

Each DMARC record starts with a version number, followed by a space. At this moment, the version number is always the same: v=DMARC1. Be careful with capitalisation: DMARC is all in uppercase!

Policy

Immediately after the version number, the policy is defined in the parameter p. The following values are available:

It's important to understand that the receiving mail server is not obliged to follow this policy. Some mail servers ignore quarantine or reject policies and just deliver e-mail normally.

Filtering part of the e-mails

If you are not yet 100% confident about your e-mail flows, you can only let a percentage be filtered by using the pct parameter. The rest of the e-mails is treated with a policy that is one level lower. The following example shows a reject policy, but only for 25% of the e-mails. The other 75% of the e-mails are treated with policy quarantine:

"v=DMARC1; p=reject; pct=25;"

Each receiving mail server will randomly select those 25% of the e-mails.

Sub domain policy

The sp parameter defines how the receiving mail server should validate e-mails sent from a sub domain, for example name@sub.domain.com. If you never send e-mail from such domain, set sp=reject. The other values, quarantine and none, are also possible. An example:

"v=DMARC1; p=quarantine; sp=reject;"

Reporting

Receiving mail servers send two types of reports: aggregated reports (parameter rua), normally once every 24 hours, that contain summaries of the filtered e-mails; and forensic reports (parameter ruf) which can be used to investigate flagged e-mails in more detail. The value of both parameters is an e-mail address.

"v=DMARC1; p=quarantine; rua=mailto:reporting@yourdomain.com; ruf=forensics@yourdomain.com;"

DMARC for domains without e-mail

DMARC is useful as well if a domain is not intended to send e-mail. In that case, declare the following DMARC record in your DNS:

"v=DMARC1; p=reject"

Reporting tools

A domain configured according to this last example will generate reports directly to the two @yourdomain.com e-mail addresses. Although they contain a lot of useful information, those reports are not easy to read. There are tools available that process the reports for you.

An example is dmarcian, which we use for a couple of our own domains. Setting up this, or any other, tool is very easy - they will inform you which rua and ruf parameters to configure. For example, a very basic configuration (no policy, only aggregated reports) for openprovider.com would be something like:

"v=DMARC1; p=none; rua=mailto:jfzcxlmo@ag.dmarcian-eu.com;"

jfzcxlmo@ag.dmarcian-eu.com is an e-mail address provided by dmarcian. Analysis of the reports is done by dmarcian and the results are presented visually through a dashboard.

Based on this analysis, you can identify the incorrectly configured servers or SPF records.

dmarcian-domain-overview.jpg

Apart from commercial solutions, there are also open source solutions available.

Useful documentation

How do I create an SPF (Sender Policy Framework) DNS record?

This article introduces the Sender Policy Framework or SPF record to you - a type of DNS record that strictly defines which servers can send e-mail in your name. It is a useful e-mail security tool in preventing spam or phishing attacks and after reading this article, you will discover that there is no reason not to implement SPF records for your domain!

Together with DKIM and DMARC, SPF is a crucial element of e-mail security.

This article contains the following sections:

Introduction: the purpose of SPF

Let's come straight to the point: you cannot trust e-mail senders. The e-mail protocol is set up in such a way, that everyone can use any "From" address that he likes. See for an example our article about testing your e-mail configuration. While this opens a lot of opportunities, it's also abused to make unsolicited e-mail look like coming from a trusted source.

The Sender Policy Framework project was started to prevent exactly this from happening. The outcome of this project is a specific type of DNS record, the SPF record. An SPF record simply defines which servers are allowed to send from a specific "From" address. If an e-mail comes from a different server, the receiving mail server may choose to reject specific e-mails or mark them as suspicious.

Although the name "SPF record" suggests that it's a special record type in a DNS zone, SPF records are always stored inside regular TXT records. "Real" SPF records were removed from the standards in RFC 7208.

SPF records in Openprovider

The Openprovider DNS management supports the TXT type for DNS records, that can be used to store SPF information. Ensure that your record contents is encapsulated by "straight quotes" and follows the correct syntax rules as described in this article.

SPF record syntax

Each SPF record starts with a version number, followed by one or more trust-definitions and ends with an "all-others" statement. An example is the following DNS record:

"v=spf1 a mx ip4:185.87.187.6 -all"

which tells the receiving mailserver to accept e-mail from servers that match the domain's A- and MX-records and e-mail from the server with IP address 185.87.187.6. All other e-mail should be considered as invalid.

NB! Please put your record between quotation marks every time you specify an SPF record with any DNS zone configured within Openprovider. Incorrect SPF record specification may lead to the domain name unavailability.  

Read on for more details about the syntax. 

Version number

Each SPF record starts with a version number, followed by a space. At this moment, the version number is always the same: v=spf1

Mechanisms

Immediately after the version number, the set of hosts which are designated outbound mailers for the domain are defined. Those are called mechanisms. Mechanisms are evaluated from left to right and evaluation stops as soon as a mechanism results in a hit. That makes the order of the mechanisms important. The so-called qualifier that prefixes the mechanism defines what the validator should do at that moment.

Qualifiers

A quantifier defines what the receiving mail server should do in case that specific mechanism results in a hit. The available options are:

If no qualifier is given for a certain mechanism, the "+" qualifier is assumed. That means that the following two SPF records are exactly similar:

"v=spf1 +a +mx +ip4:185.87.187.6 -all"
"v=spf1 a mx ip4:185.87.187.6 -all"

The "ip4" and "ip6" mechanisms

Use the "ip4" and "ip6" mechanism to specify a single IP address or an IP range. Needless to say, "ip4" tests IPv4 address and "ip6" tests IPv6 addresses. The following example SPF records will allow any IP addresses between 192.168.0.1 and 192.168.255.255 (first example) or any IPv6 addresses between 1080::8:800:0000:0000 and 1080::8:800:FFFF:FFFF (second example) and will reject all others.

"v=spf1 ip4:192.168.0.1/16 -all"
"v=spf1 ip6:1080::8:800:68.0.3.1/96 -all"

The "a" and "mx" mechanisms

Use the "a" mechanism to test against the domain's A record(s) and the "mx" mechanism to test against the domain's MX record(s). It's also possible to add another domain instead of the parent domain. The following example SPF records will allow any e-mail that originates from an IP address listed in the sender's domain's A records (first example), listed in the sender's domain's A and MX records (second example) or listed in example.com's A records (third example) and will reject all others.

"v=spf1 a -all"
"v=spf1 a mx -all"
"v=spf1 a:example.com -all"

The "include" mechanism

Use the "include" mechanism to use another domain's SPF record for validation. This is useful, for example, if you allow third-party mailinglist software to send mailings with your own e-mail address as sender. The following example SPF record will allow any e-mail that originates from the domain itself, but also allows MailChimp to send e-mail on your behalf.

"v=spf1 a mx include:servers.mcsv.net -all"

Note: this is just an example based on information that is valid on the moment of writing. If you indeed want to include MailChimp in your SPF record, check the MailChimp documentation for the correct SPF mechanisms to use!

Be aware that the maximum number of DNS lookups that can be done in an SPF record is 10. This includes recurring lookups. So if you include two locations that each include 6 other locations, SPF validation will break. The SPF standard included this mechanism to prevent delays through too many DNS lookups. Fall back to IP addresses if the number of DNS lookups is more than ten.

The "all" mechanism

Use the "all" mechanism to correctly close the parsing instructions. This mechanism usually is put at the end of the SPF record and defines what to do in case none of the previously parsed mechanisms resulted in a hit.

All of the above examples contain a "-all", which means that the e-mail should be rejected if none of the previous mechanisms results in a hit. This is the safest qualifier. Alternatively, use the neutral ("?") or softfail ("~") qualifier if you want your e-mail be delivered anyway but with some additional care. Use of the "pass" qualifier ("+all") is not recommended ever, because it reduces the benefit of your SPF record to zero.

The "exists" mechanism

A special mechanism is the "exists" mechanism. While in the basic form it's not so exciting (it just looks up the existence of a hostname), the combination with macros in SPF makes it a great tool for monitoring which senders send e-mail from your domains.

A macro is a specific string in the record that will be replaced by another value. Some examples are:

An excellent example of use of those macros is the Dutch tax authority. Their SPF record looks as follows:

$ dig _spf.belastingdienst.nl in any
_spf.belastingdienst.nl. 599 IN TXT "v=spf1 exists:_i.%{i}._h.%{h}._o.%{o}._spf.belastingdienst.nl -all"

Every time an SPF record is checked by the receiving e-mail server, it will lookup the hostname in the exists mechanism. As this hostname is dynamically created, it will provide information about the sending mail server, for example:

_i.192.87.102.75._h.filter5-ams.mf.surf.net._o.belastingdienst.nl._spf.belastingdienst.nl.

If the tax authority security department runs a DNS logger, they will see requests for such (non-existing) sub domains and they can filter out unauthorized entries for further investigation based on the sender IP address and the HELO/EHLO domain.

Other mechanisms and modifiers

Apart from the mechanisms described above, one can also use a "ptr" mechanism. The optional modifier "redirect" or "exp" is another structure that can be used in an SPF record. Please refer to the OpenSPF website for full information about those mechanisms and modifiers. This website contains also extended information about the mechanisms described in this article.

SPF for domains without e-mail

SPF is useful as well if a domain is not intended to send e-mail. In that case, declare the following SPF record in your DNS. This record only has an "all" mechanism, rejecting any sender. An SPF validator will reject the sender in all cases.

"v=spf1 -all"

SPF Limitations

There are a number of limitations on your SPF-record.

Since it's a TXT record, there is a limit of 255 characters.

You can work around this somewhat by using includes, but each SPF check has a limit of 10 DNS-lookups, so 1 for the main record and 9 includes.

Useful documentation

How do I secure my e-mail delivery?

Every day, millions of e-mails are sent, of which many are abusive: spam, scam, phishing, ... How can you configure your e-mail in such a way, that the risk of e-mail abuse is minimized for your domain?

Below we quickly introduce you to DNSSEC, DMARC, SPF and DKIM. Let this information not overwhelm you: you can start gradually and even skip some parts. It will at least make your e-mail more secure than without any precautions!

0. DNSSEC

It all starts with DNSSEC. Simply because all of the e-mail security mechanisms described below rely on the DNS. With DNSSEC activated, no-one can mess with the DNS records and the e-mail security checks can be considered valid.

Enabling DNSSEC is very easy if you use the Openprovider nameservers: just enable it by updating your domain name.

If you use your own nameservers, or the nameservers of a third party, you will need to retrieve the DNSSEC key data and submit those to Openprovider by updating your domain name.

For more information about DNSSEC, you can read this article.

1. Enable reporting through DMARC

A good and very easy starting point is to enable reporting: using the DMARC protocol, receiving mailservers validate e-mails that are sent from your @domainname.com and send their findings to an e-mail address. There are many great tools available that process those reports and present them in a visually attractive and useful way. An example of such a tool is EasyDMARC.

All tools will guide you through the creation of the DMARC DNS record, so no knowledge is required yet. Just a simple TXT record in your domain's DNS record. Further down, we will come back to this.

The only important thing to take care of, is that the so-called policy in the DMARC record is set to none; your DMARC record should contain p=none. Using this value, your e-mail delivery will not be affected.

Once everything is set up completely, you will change this policy to make e-mail delivery more secure (see §5 below).

If you want to know more about DMARC, read our article about it.

2. Define who is allowed to send e-mails from your domain name with SPF

The next step is to define where your e-mail may come from. In other words: who is allowed to send e-mail from your @domainname.com. This is something that we cannot guide you through, but don't worry: you can start simple and keep tuning! It's done through the SPF (Sender Policy Framework) DNS record, and an example is the following:

domain.com.   IN   TXT   "v=spf1 a mx ~all"

The above record says that if the e-mail arrives from the IP address that's configured in the domain's A- or MX-records, it's trusted. Otherwise, let the receiving mailserver decide what to do.

The first task is to get an overview of what other servers you use to send your e-mails. That could include, for example, third party applications like mailing list or help desk software. Such application normally provides clear documentation about what should be added in an SPF record.

Read more about SPF records in this article.

You can generate, check and look up your SPF records using free online tools, such as this tool from EasyDMARC.

During the first weeks or months, you will (by the DMARC reports) find out if you omitted any sender, and tune your SPF record until it covers everything (see §5 below).

3. Sign (parts of) your e-mail with DKIM

Now that we have defined who is allowed to send e-mails from your @domainname.com, it's important to guarantee that the contents is not tampered with. This is done by signing parts of your e-mail in combination with the DKIM protocol. The receiving mail server will check if the signatures are correct.

DKIM must be configured on the mail server(s) that is/are used for sending e-mails. We cannot guide you through the settings of all such servers, but you can refer to our article about DKIM records for more information and hands-ons.

If you have difficulty enabling DKIM, remember that you can continue as well without it, you can always add it later!

4. Investigate DMARC reporting

Now all DNS records (SPF, DKIM or both) are set up correctly, it makes sense to check the DMARC reports. Remember: DMARC reports are gathered by the receiving mail server. Most DMARC tools will report the number of compliant and non-compliant e-mails.

Understanding report statuses

The compliant ones are the e-mails for which the receiving mail server could validate SPF and/or DKIM. Everything is in order, there's no need for you to analyse this further.

The non-compliant ones are most interesting: this report lists the e-mails that were sent from your @domainname.com domain, but did not pass the SPF and/or DKIM checks. For example, they were sent by a server that you forgot to include in your SPF record, or the signature check failed against the DKIM record, because someone forwarded the e-mail which caused the body to change.

And of course, it contains the e-mails that truly are worth reporting: the e-mail from the phishing sender, for example.

Improve configuration

Use this information to fine tune your SPF record and/or DKIM configuration. For example, add the IP address of the server you forgot to the SPF record, and change the DKIM settings so that no longer the full body is signed, but only the subject and the sender (for example).

Next time an e-mail is validated by a receiving mail server, such e-mail will be marked compliant.

Over time, you will discover that the number of non-compliant e-mails reduces, and in the end you'll see illegitimate e-mails only. All legitimate e-mails are marked compliant and you know your settings are correct.

Depending on the number of e-mails that you send, it might take up to many months before you are at this point.

5. Tightening SPF and DMARC policies

Now everything is in order, you can make validation stricter. This can be done in the SPF and the DMARC records:

It's good to know that each receiving mail server may or may not follow the policies that you configured. It might be that a mail server accepts an e-mail, even while the SPF, DKIM or DMARC check fails! That is out of your control. Luckily, the majority of e-mails will be validated correctly.

6. Keep your configuration up to date

From now on, it's important to keep disciplined in updating your configuration. You won't be the first one that adds a server or changes his mailing list provider, and find that your e-mails are not delivered anymore because you forgot to update your SPF record.

With every change in infrastructure and applications, consider the potential impact on e-mail delivery and make the necessary updates.

The DMARC reporting remains a great tool to catch such issues: if you suddenly see a lot of e-mails being reported, that should be legitimate, it's time to change your settings!

How does DNS infrastructure of Openprovider work?

Question

How does DNS infrastructure of Openprovider work?

Answer

DNS management is a service that is available free of charge to Openprovider customers. One can decide to what extent to use Openprovider nameservers:

Geographically separated

Openprovider operates domain name servers from geographically separated locations (Ireland, United Kingdom and Germany), in separate subnets, using hardware of the highest quality. This allows the system to recover immediately if any failures occur, ensuring that your web sites and email continue operating.

Service level agreement

The use of the free Openprovider nameservers comes without service level agreement (SLA). Openprovider does its best to keep the services up at any moment, but a maximum downtime cannot be guaranteed.

Attacks on nameservers (DDoS)

A DDoS (distributed denial-of-service) happens when thousands of queries per second are executed (usually from different IP-addresses) on 1 domain name. When the amount of queries are higher than the capacity to process those queries and the requests keep coming, the availability of the nameservers may be affected.  

Every system which will process queries could be affected by a DDoS attack. This can not be fully prevented by the administrator of the service. More information about DDoS attacks can be found here.

Precautions to prevent those attacks

Although Openprovider can not fully prevent DDoS attacks, several precautions have been taken to reduce the risks.

To prevent those attacks a fair limit on the number of queries per second per IP address have been placed. This limit will is reviewed on a regular basis.

If the monitoring service detects more queries that are allowed from 1 IP address, those queries will be banned in order to prevent possible problems.

How soon DNS records propagate from master nameserver to Openprovider slave

Question

How quickly one's records will propagate to Openprovider DNS servers when using the latter as slave nameservers?

Answer

In general, new slave zones copy the data of the master zone file within a minute.

Changes on one's nameserver are copied automatically by Openprovider slave servers when the refresh time of the SOA record expires. Openprovider load balancing nameservers (ns1, ns2, ns3) do not support the NOTIFY command to update a slave record.

In case Openprovider slave does not synchronize correctly with the master nameserver, check master's configuration.

How to change nameservers of a domain

Question

How to change nameservers of a domain in ones portfolio?

Answer

When a domain is registered or a transfer is requested, it is required to select the nameservers that will be connected to the domain.

In order to change nameservers of a particular domain one should navigate to that domain's Details page from Control Panel Dashboard >> Domains Overview > Domains Overview > Search the domain and click on the name and click on Edit domain data button (pencil icon):

embedded-image-fs4udp3y.png

It is possible to use external nameservers (nameservers from your hosting provider, DNS provider, or your own custom nameservers like - ns1.mydomain.tld) but also it is possible to use Openprovider nameservers if you don't have nameservers or if you would like to manage DNS of a domain from your Openprovider account (via control panel or API).

External Nameservers

You can use your own nameservers either by clicking on "No nameserver group" and writing them in the fields or selecting the nameserver group you have created under Nameserver group management (to create a new Nameserver group for your own/custom nameservers, click here). Our system will retrieve automatically the IPs of every nameserver.
The zone for the domain needs to be configured on the nameservers you enter here.

NS1.png

Note: When using external nameservers, please ensure the DNS zone for the domain is configured at your hosting platform (hosting server/hosting control panel) or DNS provider. If you don't know how to do it, please seek help from your hosting provider, DNS provider, or your IT administrator to create a DNS zone. 

Openprovider Nameservers

You can also use the Openprovider Nameservers by clicking on "Nameservers of Openprovider".

NS2.png

If you use the Openprovider Nameservers you will need to configure the DNS zone of the domain by clicking on "DNS Management > DNS zones overview > Add DNS zone" or clicking here. 
You will be able to add the records you want and configure the DNS zone of your domain. 
An alternative is creating a new zone based on a predefined template.

See this article for more explanation.

Here you have information about the different DNS records you can use.

Nameserver group

When selection this option, you will see all nameserver groups which you can predefined in your control panel via "DNS Management > Manage nameserver groups" or clicking here.
This will prevent typos when using external nameservers and simplifies domain management greatly. A change in your nameserver group will be processed for all your domains that are using this group, without having to update each single domain. 

You cannot delete a nameserver group while it is still in use by a domain. No domains should be attached to the NS group during deletion.

How to create a zone?

This articles contains the information about how you can create a zone in Openprovider.

Question :

How do I create a zone in Openprovider ?

Answer : 

You can create a zone in two ways :

1. Via Reseller Control Panel (RCP);

2. Via API

Creating a zone via Reseller Control Panel (RCP)


There are 2 options how to create a zone via the Reseller Control panel

1. Via DNS management

2. Via Domain detail page


1. Via DNS management

image__42_.png

  • Choose the type of nameservers you want to use (Master or Slave) , here you have the option to choose a template, or make a completely new zone from scratch.
  • In the next step, you can start to define the records you need
  • Once finished, click Add DNS zone.
image__43_.png
  • Not sure what type of records to enter, have a look here !


2. Via Domain detail page

When you are registering or transferring a domain, you will be asked in the last step to define the nameserver you want to use. If you select the openprovider or Sectigo DNS nameservers, the system will automatically create a new zone, only containing the SOA and NS record.

You can also select a template here (optional), in order to create your zone in a pre-defined format. Be aware - this will not overwrite any zone and therefore will only work when there is no existing zone yet.


Screen_Shot_2021-10-14_at_15.02.50.png

Creating a zone via API

DNS Zone can also be created via Openprovider API.

NOTE: Please review the Terms and Conditions of Openprovider DNS service here before creating new zones for external domains.

How to create email forwarders (Inforbusiness-only)

IMPORTANT NOTE: Openprovider does not offer e-mail forwarding at this moment. Customers from our Inforbusiness platform that were migrated to Openprovider can contact support@openprovider.com asking for a limited reactivation of their Inforbusiness account, so that they can create and manage e-mail forwarders.

If you have access to your Inforbusiness account, this article describes how to set up e-mail forwarding for domains that you manage in Openprovider.

1. Create a dummy domain

In your dashboard, move to the menu Domain names > My domains. This list is empty - all your domains moved to your Openprovider-account. Click the Add button to add a new dummy domain.

2_-_Domain_overview.png

It's important to select the configuration as in the screenshot below:

3_-_Setup_1.png

2. Create a forwarder

Click the Request domain service button and select the Request forwarder option.4_-_Setup_2.png

In the next dialogue, create your first forwarder (you can change this, or add catch-all, in a later step). Do not configure website forwarders, that will not work and it will cause asynchronities with Openprovider. If you want website / domain forwarding, order it in your Openprovider control panel. Use the configuration as in the following screenshot:5_-_Setup_3.png

3. Update the DNS

You need to update the MX records in your DNS zone in order to use the e-mail forwarding. The MX records that you should add, are the following:

If you use the Openprovider nameservers, this is how you configure the MX records in the Openprovider control panel. Ensure that there are no other MX records left, otherwise mail behaviour can be unexpected.

8_-_DNS_configuration.png

You may need to wait some time for the DNS changes to propagate, so if you don't receive e-mails on the new forward immediately, don't panic. This can take up to 24 hours.

4. Configure your forwarder

If this newly created forwarder needs tuning (for example setting up additional forwarders for this domain, or creating a forwarder for catch-all), you can do this from the menu Hosting > My forwarders. This page will show you a list of activated forwarders. Click on the forwarder to open the configuration dialogue.6_-_Forwarders_overview.png

Here, you can enable catch-all (if required) and add, manage or remove single-recipient forwarders.

7_-_Setup_4_catch-all.png

How to import external DNS zones to Openprovider nameservers?

Question

How to import existing DNS zones that are hosted elsewhere to Openprovider nameservers?

Answer

Using Openprovider API to create DNS zones

In order to populate multiple zones at once with a number of records it is highly advised to utilise Openprovider API modifyZoneRequest method.

For each domain and each zone, one should follow these steps:

  1. Get current contents of a DNS zone
  2. Create a DNS zone in Openprovider, to create zone and add records.
  3. Update the domain
    Once the zone is available in Openprovider, you can update the nameservers that are linked to the domain name. The only required variables here are the domain and the ns_group, which must be set to dns-openprovider.

NOTE: If you want to use Premium Global Anycast DNS Service by Sectigo, use "provider":"sectigo" when creating the zone in step 2. And in step 3, you can use dns-sectigoas the ns_group instead of dns-openprovider.

Updating domains

Once the import is finished, update the domains via bulk operation tool to use dns-openprovider nameserver group. For Sectigo DNS, use dns-sectigo nameserver group for domains to start using Sectigo premium DNS.

How to meet registry's DNS zone requirements

Question

Which registries require DNS zone pre-configuration before registering a domain?

Answer

Some registries check whether a DNS zone of a domain responds authoritatively. This means that for some extensions the configuration of nameservers must be done before the registration, transfer or update of the domain in question.

If the configuration is invalid, domain's host objects will not pass registry check and will not be updated. Some of the extensions that require DNS pre-configuration are, among others, .de, hu, .pt and .it.

How to setup domain forwarding?

Question

How to forward a domain to another domain?

Answer

NB: Currently domain forwarding comes with the following caveats:

Domain forwarding can be enabled on the second step of the domain registration wizard by clicking on the Domain forwarding checkbox or for existing domains by clicking on the edit button on the details page.

NOTE:

- The domain forwarder subscription starts at the date when it is activated, and not related to domain renewal cycle. Domain expiration, quarantine, or renewal status does not affect the forwarding subscription.
- The forwarder service operates independently of the domain renewal cycle, meaning that charges for the forwarders can still apply even if the domain has expired.

Why is the checkbox greyed out when disabling or updating domain forwarding?

If the checkbox is greyed out, it indicates that forwarding activation or deactivation is pending. Activation and deactivation of forwarding are not instant and can take some time.

Please wait a while and try again later.

embedded-image-gj3ihtru.png

embedded-image-p0p8wyf3.png

* Domain forwarding is free with membership plans.

 

In order to configure it, click on Click to configure and navigate down to the Domain forwarding section.

embedded-image-6nfn12hm.png

Choose the Forwarding type and enter the destination URL.

NB: Be sure to add the protocol name (http://, https://, etc.) to the URL! The destination URL can be either http (without SSL) or https (with SSL). 

Forwarding type: permanent (301) vs temporary (302)

A 301 redirect means that the page has permanently moved to a new location. 
A 302 redirect means that the move is only temporary. Search engines need to figure out whether to keep the old page or replace it with the one found at the new location. More information is available online.

Permanent

Permanent forwarding (HTTP status code: 301) indicates to search engines that the page has permanently moved to a new location. It almost fully passes page authority from an old URL to a new URL. While a visitor won’t notice the difference between temporary and permanent forwarding, for a search engine, these are completely different signals. Be careful about using 301 forwarding when it isn't permanent. If you remove a 301 redirect, be prepared to wait several weeks or even months to see the redirected URL back in the search engines' indexes. 

Temporary

Temporary forwarding (HTTP status code: 302) indicates that the page move is only temporary. By default, temporary forwarding does not pass any page authority from the old URL to a new URL. This forwarding type is rarely used, since in most cases you want to pass a page's authority, and only the 301 type will let you do that. Over time though, if temporary forwarding is in place for a long time - search engines start to regard the 302 forwarding as a 301 type, due to its permanent nature.

 

Important: If you use the Openprovider nameservers, an A-record will be set up automatically. In case third-party or your own nameservers are used, please ensure that the A-record for this domain in your DNS zone points to IP address 34.90.130.132.

Deleting or Updating forwarders

Already created forwarders can be updated or deleted through RCP (Reseller Control Panel) but please keep in mind that these changes are not real-time.

  1. Navigate to Domains Overview
  2. Search and click on the domain with forwarding enabled.
  3. Click on Edit (pencil button)
  4. Scroll to Domain forwarding section:
    1. Uncheck the 'Enable' option to delete forwarder**. 
    2. To update forwarding, select required 'Forwarding type' from drop-down and enter the new 'Destination URL' replacing the current one.
  5. Click on 'Save changes'.

** If you are not using Openprovider nameservers for the domain, you will need to manually update the A record (34.90.130.132) for the domain after disabling domain forwarding. 

embedded-image-ytao7dnx.png

Troubleshooting

If forwarding doesn't within 24 hours, please run through the checklist below to make sure the configuration is finalized:

  1. Make sure the A-record in the DNS zone of the domain is set to 34.90.130.132
  2. Make sure (e.g. via the dig command line tool) that the A-record change is already replicated through the DNS hierarchy (can take up to 24 hours depending on your TTL settings on the DNS zone record)
  3. If the above checks are successful - enter the domain name in your browser and confirm that it forwards to the right destination. In the case of browser caching, it is more safe to check via any public service that can show HTTP headers.
  4. www. domain is not forwarding: create a CNAME record forwarding from www. to the naked domain.

Limitation

Forwarding works only from HTTP websites (source). This limitation arises from the specifics of the forwarding implementation. To configure redirects from HTTPS, we would need to store all of our customers' certificates on our servers - both during the initial setup of the forwarding and whenever SSL certificates are renewed. Unfortunately, this is not feasible at the moment.

 

The redirect only works for the "naked domain" and the domain with www. Subdomains are not supported.

How to use DNS templates

Question

What are Openprovider DNS templates and how to apply them to zones in one's reseller account?

Answer

A DNS template is a pre-defined format of a DNS zone. One can define multiple DNS templates, for example when managing multiple servers. When creating a new zone, one can choose which template should serve as the basis.

VERY IMPORTANT: a template is only used during the creation of a zone and can not be used to update all zones that were created using the specific template. Summarizing:

- If the domain has already any DNS zone created in Openprovider: template CAN NOT be updated.
- If the domain doesn't have any DNS zone created in Openprovider: template can be add when updating the nameservers.

If the domain has already any DNS zone created in Openprovider, we recommend you to delete the DNS zone before updating the nameservers with the template.

Creating a template

To create a DNS Template click here and click on Add DNS template button.

The contents of a template are exactly the same as the contents of any DNS zone. The only difference is, that one can use placeholder variables and wildcards to substitute a domain name.

For instance, to refer all subdomains to the top level domain, the record for a regular DNS zone will look as follows:

*.example.tld CNAME example.tld

In a template, a specific domain name can be references by a %domain% variable:

*.%domain% CNAME %domain%

NB: %domain% variable already includes domain's extension.

Define the records on Add DNS template page:

embedded-image-ac1qcu26.png

Using a template

Select the desired template from the drop-down menu in the Nameserver settings section when registering a domain:

embedded-image-6yhcw8bw.png


Note: DNS templates created via RCP (Reseller Control Panel) or API are meant for DNS zones created in  Openprovider. If you are using external/custom nameservers, you should check with your DNS provider on creating DNS templates in their platform.

How to use Openprovider nameserver as slave

Question

How to use Openprovider nameservers to host zones from another master server?

Answer

In order to use Openprovider nameservers as slaves, one has to configure Access Control Lists on the master nameserver to allow AXFR transfers from the following IP addresses:

35.157.8.190
18.203.73.190
185.27.175.218
2a00:f10:121:400:4be:60ff:fe00:526
2a05:d014:f80:6e00:c937:174c:45eb:a5f7

The above IP addresses need to be added to the server software if the reseller is using hosting control panels like Plesk, cPanel, etc.

To check whether or not Openprovider can read one's master server navigate to DNS management > DNS Checks and select Check whether the Openprovider nameserver can be used as slave radio button. Enter the domain name and the IP address of the master nameserver, to see the result of the check.

 

embedded-image-0cnhexbz.png

Last but not least, the zone file of the master nameserver should contain the NS record of Openprovider - ns1.openprovider.nl.

The interface of zone adding is almost the same as for the master ones. Navigate to DNS management > New DNS zone page in RCP and choose the appropriate type of zone:

 

embedded-image-xq2bxjev.png

Once done with the name, proceed to the next steps where you can configure the IP address of the master server:

 

embedded-image-5wnajhs3.png

The records will propagate within a couple of minutes.

Note: The first time you've whitelisted the IP address in your software it can take up to 1 hour before the slave zone will start propagating. 

How to use non 'default' DKIM identifier

Question

How to use a non default DKIM identifier?

Answer

To use another non default DKIM identifier you can create a CNAME record in the DNS with target dkim.registrar.eu with the desired identifier, for example "domreg", so the record becomes: domreg._domainkey.[your domain.ext].

Eg:

Set the CNAME record for domreg._domainkey.domain.tld to:

dkim.registrar.eu

When the records are made, please contact support (support@openprovider.com) and state the record you made. Support Team will then change the default for your domain.

Note: This is a new functionality, and not visible in your control panel. However, if the record is made correctly it is possible to validate your domain in the control panel.

For more information about how to create a DKIM DNS record, please go here.

Nameserver creation or update failed: 2201, Authorization error

Symptoms

When trying to change nameservers for a Verisign (.com, .net) domain, the following error is thrown:

Nameserver creation or update failed:
ns1.example.com, 2201, Authorization error

or when trying to register/update a SIDN (.nl) domain with nameservers whose glue records have a domain that belongs to another registrar:

Nameserver creation or update failed: 
ns1.example.nl, 2201, A superordinate name server can only be registered by the managing registrar.

Cause

The registry doesn't allow creating or updating nameserver host records using domain names that aren't managed by the same registrar. E.g., if you are trying to use ns1.domain2.com and ns2.domain2.com as nameservers for your domain where domain2.com is registered with another provider/registrar and if the nameserver objects/hosts (glue records) ns1.domain2.com and ns2.domain2.com aren't already created at the registry.

In other words, "Authorization error" message pops up if you try to assign nameservers based on a domain that is registered with another provider/registrar.

Resolution

If it is necessary to use nameserver hosts based on a domain that is not in your reseller account, consider first creating host objects (domain name - ip address pairs) at the registrar/provider where the domain name is registered and then updating nameservers at Openprovider account.

You may use this tool to check registration of nameservers/glue records for .com and .net domains.

October 4, 2022: Changes to Openprovider Standard DNS

Our mission is to provide you with top-quality products for an attractive price. It is our goal to maintain high-security standards to guarantee an excellent quality of service.

On October 4th, new policies to our Standard DNS product were applied. The main change was that we will not offer Standard DNS zones for domains that are not registered in Openprovider. For security reasons, we cannot keep them alive anymore.

Action required

What action do you need to take:

  1. For all domains that are registered in Openprovider and use our free DNS service - NO action is required, our DNS will be free and working for you.
  2. For all domains that are not registered in Openprovider and that do not use our free DNS anymore or are not active anymore - NO action is required, we will clean up the DNS entries
  3. For all domains that are not registered in Openprovider, are active and use our free DNS - TAKE ACTION NOW

If point 3 applies this is what you need to do:

  1. Transfer the domains to Openprovider within 30 days of the zone creation. DNS will be free for you. Or if that is not possible,
  2. Buy a Premium DNS subscription in your account for these domains and you do not have to transfer them. Make sure to update the domain at the current provider to the Premium DNS nameservers* once the zone is activated.

From October 4th, 2022 it is no longer possible to use our nameservers for domains registered outside of Openprovider, so please check your account and take action if needed.

How can I know which zones are affected?

You can download the list of your Domains registered in Openprovider, and the list of Standard DNS zones created in Openprovider from the Reseller Control Panel. Cross-checking these two lists, you will be able to know which zones are from domains not active in your account.

If you need help, you can always contact our Support Department. 

Grace period for new Standard DNS zones

We will apply a grace period for Standard DNS zones created after October 4th of 30 days. If you want to set up the zone before transferring the domain to Openprovider, you will be able to do it. But remember, you will have to transfer the domain to Openprovider during the first 30 days, if not, zone will be parked.

I need help

If you need help identifying your Standard DNS zones affected by this change or have any question, please contact our Support Department.

If you need more information about our Premium DNS product, help transferring a big amount of domains to Openprovider or any other sales related question, please contact our Sales Department.

* In case a premium dns zone was activated for a domain outside of Openprovider, make sure to update the domain at the current provider and point it to the nameservers of the Premium DNS.
Please use the following nameservers:

ns1.sectigoweb.com
ns2.sectigoweb.com
ns3.sectigoweb.com
ns4.sectigoweb.com

Openprovider DNS: SOA record and expire value

You might have noticed that our nameserver configuration includes a Serial Number, Refresh, Retry, Expire, and Minimum TTL (Time To Live) value in the SOA record. Some of you have specifically inquired about the Expire value being set to 7 days (604800 seconds). This FAQ entry explains what the SOA record is and why we have chosen this particular value.

What is an SOA Record?

The Start of Authority (SOA) record is a crucial part of every DNS zone. It stores essential administrative information about the domain, including:

Why is our Expire value set to 7 days (604800 seconds)?

Our Expire value is intentionally set to 7 days (604800 seconds) for the following key reasons:

What does this mean for you?

In most normal operating conditions, you will not experience any impact from this 7 day expire value. Our monitoring systems and infrastructure are designed to ensure continuous and reliable DNS service. The 7 day value is a safety mechanism to prevent the propagation of stale DNS data in the unlikely event of a prolonged outage affecting the primary nameserver and its ability to communicate with the secondaries.


In summary, our 7 day (604800 seconds) expire value in the SOA record is a deliberate choice that prioritizes data consistency and reliability within a robust and well-maintained DNS infrastructure.

Premium Global Anycast DNS Service


In collaboration with Sectigo, an industry leader in SSL certificates and web security products, Openprovider introduces a Premium Global Anycast DNS service that will be the perfect complement to our current, free of charge, DNS offering. In the article below you can find a summary of the benefits of the service and a FAQ.


HOT TIP:
How to copy an existing Openprovider DNS zone to the Sectigo Premium DNS and update the domain


General:

Premium Global Anycast DNS Benefits

How can I enable the Premium Global Anycast DNS service for a new domain registration using the Reseller Control Panel?

How can I enable the Premium Global Anycast DNS service for an existing domain using the Reseller Control Panel?

Does the Premium Global Anycast DNS service support DNSSEC?
Can I enable the Premium Global Anycast DNS service when transferring a domain to Openprovider or when trading a domain?

Can I transfer my Premium Global Anycast DNS subscription from one domain to another?

How do I disable the Premium Global Anycast DNS service for a given domain using the Reseller Control Panel?

What DNS record types are supported by the Premium Global Anycast DNS service?

Can I use the Premium Global Anycast DNS service if my domain is not managed by Openprovider?

How do I delete the Premium Global Anycast DNS zone and prevent further billing?

I see now 2 zones in my overview. Is that ok or do I need to remove one?


Billing:

How does billing work for the Premium Global Anycast DNS service?

What happens to my subscription if I disable the Premium Global Anycast DNS service for a domain?

What happens to my subscription if I delete my domain, I transfer it out or my domain expires?

Pricing:

You can find the actual price for Premium Global Anycast DNS in your Control Panel under pricing.

API:

Is the Openprovider API compatible with Premium Global Anycast DNS?

How can I enable the Premium Global Anycast DNS service when registering a new domain programmatically using the API?

How can I enable the Premium Global Anycast DNS service for an existing domain programmatically using the API?

How can I disable the Premium Global Anycast DNS service for one of my domains programmatically using the API?

How I can move to Sectigo DNS and move all record from OpenProvider DNS to Sectigo DNS?


Errors
Known errors and how to resolve them

Premium Global Anycast DNS Benefits

How can I enable the Premium Global Anycast DNS service for a new domain registration using the Reseller Control Panel?

Enabling Premium Global Anycast DNS for a new domain registration is simple. Simply check the ‘Premium Anycast DNS by Sectigo’ box during the registration process. When you do that, the Sectigo nameserver group will be selected automatically in the ‘Nameserver settings’ section.

embedded-image-mlvhlqbt.png

embedded-image-ttwjo4l7.png

**NOTE:

The Premium Global Anycast DNS by Sectigo are separate nameservers from the free Nameservers of Openprovider.
Activating these nameservers means a new, empty zone will be created on the Sectigo servers, and any records you want to use have to be created in the new zone of Sectigo! If you already have a standard (active) Openprovider DNS zone for this domain name, we recommend using the flow described below.

How can I enable the Premium Global Anycast DNS service for an existing domain using the Reseller Control Panel?

You can achieve this in 2 different ways.


OPTION 1
Please use the first option when the domain is currently actively running on the Openprovider DNS and you would like to create a matching zone on the Sectigo DNS service.

  1. Create the Premium DNS zone for that domain directly in the ‘DNS management’ area.



    dns3.png


    In case a standard zone for this domain already exists in your account, the system will give you the option to copy the records the records to the new zone.

    Screen_Shot_2022-07-11_at_12.39.57.png

    We advise to wait until the zone is active (can be found / pinged via online tools) , before you update the domain to the Sectigo nameservers via the detailpage of the domain.
    (Detailpage = page with all the details of the domainname itself found via Domain Overview)

    Click on "edit details" on the domain detail page and scroll down to the nameserver section.
    The Sectigo nameservers will be shown in the dropdown, once a premium zone exists for the domain.

    Screen_Shot_2022-07-22_at_14.58.18.png



OPTION 2
The following option can be used when a domain is not currently actively using the Openprovider nameservers. Because the update of the NS will be triggered before the zone is created and resolves, which might cause downtime on the domain itself.

  1. Edit the domain details via the domain detailpage, check the ‘Premium DNS by Sectigo’ box in the domain details view and save your changes.
    This will automatically create a new Premium Global Anycast DNS zone for that domain and will select the Sectigo nameserver group in the ‘Nameserver Settings’ section.

    You will also see the option to select a template for the new zone that you will be creating.

    Once saved, the domain is updated and the zone is created
    Please go to DNS Management > DNS Zones overview.
    From here you can find the zone. You will see "provider" = Sectigo.

Does the Premium Global Anycast DNS service support DNSSEC?

Yes, DNSSEC is fully supported by the Premium Global Anycast DNS service.

Can I enable the Premium Global Anycast DNS service when transferring a domain to Openprovider or when trading a domain?

No, the Premium Global Anycast DNS service is not available in these cases just yet, but we are planning to add support for them in the near future. Once a domain has been successfully transferred to Openprovider, Premium Global Anycast DNS can be enabled via a domain update action. 

Can I transfer my Premium Global Anycast DNS subscription from one domain to another?

No, the Premium Global Anycast DNS service is tied to a specific domain and cannot be transferred between domains.

How do I manage the Premium Global Anycast DNS service from the Reseller Control Panel?

You can manage your premium DNS zone in the same way you manage your standard DNS zones, i.e. from the domain details page or from the ‘DNS Management’ section.

You can also manage your Premium DNS zone using the "Single domain DNS Panel" (dnspanel.io).

How do I disable the Premium Global Anycast DNS service for a given domain using the Reseller Control Panel?

Please follow these steps:

  1. In the domain details view, select the edit option and disable Premium Anycast DNS by Sectigo by toggling the button.

    When Premium Anycast DNS by Sectigo     is enabled: 
    embedded-image-7zteried.png
    When Premium Anycast DNS by Sectigo is disabled:
    embedded-image-d94jpxmt.png

    After toggling the button, nameserver group will be automatically switched to Openprovider nameservers (nameservers won't be changed until you click on Save changes). Change the nameservers to the ones that correspond to the DNS service you will be using after cancelling the Premium DNS service. If you wish to use Openprovider’s standard DNS service, just select the Openprovider nameserver group. If you plan on using a third party provider, please select the corresponding nameserver group or choose No nameserver group from the dropdown and manually enter the corresponding nameservers.

    embedded-image-pzdh8oeu.png

    In this case, please ensure that the new DNS zone is available and zone records are copied from Sectigo zone before performing the migration.
  2. Save your changes.
  3. Wait for 24-48 hours to ensure that the changes are propagated globally.
  4. Go back to the domain details view, edit the domain and uncheck the ‘Premium DNS by Sectigo’ box.
  5. Save your changes.
  6. In order to cancel the subscription itself, delete the zone via the domain management menu.

What DNS record types are supported by the Premium Global Anycast DNS service?

The Premium DNS service supports for 95% the same record types as our standard DNS service.

Unsupported records:

The TLSA and SPF type (record type SPF is deprecated) records that are supported by our standard DNS service but not by the Premium DNS service. If you are currently using a TLSA record for one of your domains and wish to enable the Premium DNS service for that domain, please ensure you remove the TLSA record first or get in touch with our support team. If you have a DNS record of type 'SPF', please convert it to a TXT record before importing/copying records to the Premium DNS service.

Not Supported
mceclip0.png

Supported
mceclip2.png

You cannot have two MX records that are the same with different priorities as that is redundant.

Not Supported

Priority Content
30 mail.domain.tld.
10 mail.domain.tld.

So for example, you could do:

Supported

Priority Content
30 mail.domain.tld.
10 mail1.domain.tld.

Because that’s saying if mail1 fails then fallback to mail. Otherwise, it’s the same thing just different priorities so it becomes superfluous.

Can I use the Premium Global Anycast DNS service if my domain is not managed by Openprovider?

Yes, you can create a Premium DNS zone for a domain even if that domain is currently not managed by Openprovider.

How do I delete my Premium DNS zone and prevent further billing?

There are 2 options to delete your Sectigo Premium DNS zone.

- You can disable the auto renewal (Set to "on" by default, this can not be changed at this moment)
- You can delete the zone by clicking on the red bin icon. Please note, the zone will be deleted immediately  and the zone will stop resolving.

As long as the zone exists, the billing will take place every year.

Screen_Shot_2021-09-08_at_13.41.03.png

I now see 2 zones in my overview. Is this alright or do I need to remove one?

It can happen that you find 2 zones for the same domain in your overview. In the column "DNS Provider" you can see on which platform this zone is managed (Openprovider or Sectigo)
It is not a problem that there are 2 zones for the same domain, the domain itself will only be connected to 1 zone. The other will not be used.
We advise to keep the Openprovider zone just after the update. In case something goes wrong, you can directly switch back to the Openprovider zone.

Deleting the zone afterwards is up to the reseller itself.
You could decide to delete the zone later, so there is no confusion for yourself or your colleagues in which DNS zone the record changes should take place.

Removing the not-used zone could help in keeping the overview clean and organised.
But keeping the zone might be interesting if you ever want to switch back or would like to know the previous used records.

Please note that both zones will be operating on completely different platforms.
So changes and updates which are made in the Sectigo zone on the Sectigo platform will NOT be automatically synchronised in an (old) Openprovider zone and so the same goes for the other way around.

Screen_Shot_2022-07-28_at_14.52.03.png


Billing

How does billing work for the Premium Global Anycast DNS service?

The Premium DNS service is a yearly subscription service, and it is automatically renewed every year unless the Premium DNS zone is deleted or the auto renewal is disabled.

You can find the renewal date of the zone in the DNS management --> Zone overview.

Screen_Shot_2021-09-08_at_13.55.04.png

What happens to my subscription if I delete the Premium Global Anycast DNS service for a domain?

If you delete a Premium DNS zone, the subscription to that zone will be cancelled immediately and you will not be billed for that zone anymore in the future.

Note that if you delete your Premium DNS zone before the current billing cycle has come to an end, you will not get a refund for the rest of the 1-year period you paid for as mentioned in the signed Terms and Conditions.

Click here to read how to delete your Premium DNS zone.

What happens to my subscription if I delete my domain, I transfer it out or my domain expires?

Your Premium DNS zone is not deleted automatically if you transfer your domain out of Openprovider, when you delete your domain or when the domain expires.
It is important that if you want to stop the Premium DNS service, you have to explicitly delete that zone from the Openprovider platform to stop the subscription or disable the auto renewal.

As long as the zone is present in the control panel, the subscription is active and will be invoiced on a yearly basis. There will be no refund provided, also not when it was not actively used or connected to a non active domain, as mentioned in the signed Terms and Conditions.

Click here to read how to delete your Premium DNS zone.

API

Is the Openprovider API compatible with Premium Global Anycast DNS?

Yes, the Openprovider DNS API is fully compatible with the Premium DNS service and can be used to create, manage and delete your Premium DNS zones and records programmatically, just as you do with your standard DNS zones. Please refer to our API documentation for more details on how to manage this service.

How can I enable the Premium Global Anycast DNS service when registering a new domain programmatically using the API?

Just add the ‘isSectigoDnsEnabled’ => 1 parameter to your createDomainRequest. If you are using the  PHP library for our XML API:

$request = new OP_Request;

$request->setCommand('createDomainRequest')
->setAuth(array('username' => '***', 'password' => '***'))
->setArgs(array(
'ownerHandle' => 'AB123456-NL',
'adminHandle' => 'AB123456-NL',
'techHandle' => 'AB123456-NL',
'domain' => array(
'name' => 'example',
'extension' => 'tld'
),
'period' => '1',
'nameServers' => [
0 => ['name' => 'NS1.sectigoweb.com'],
1 => ['name' => 'NS2.sectigoweb.com'],
2 => ['name' => 'NS3.sectigoweb.com'],
3 => ['name' => 'NS4.sectigoweb.com'],
],
'isSectigoDnsEnabled' => 1,
));

How can I enable the Premium Global Anycast DNS service for an existing domain programmatically using the API?

Add the ‘isSectigoDnsEnabled’ => 1 parameter to your modifyDomainRequest. PHP example:

$request = new OP_Request;

$request->setCommand('modifyDomainRequest')
->setAuth(array('username' => '***', 'password' => '***'))
->setArgs(array(
'domain' => array(
'name' => 'example',
'extension' => 'tld'
),
'isSectigoDnsEnabled' => 1,

));

This will enable Premium Global Anycast DNS service for the domain and will create a default Sectigo zone (with just NS and SOA records). To change nameservers to Sectigo ones, it will need to be another modifyDomainRequest after populating the Sectigo DNS zone. Please refer to How I can move to Sectigo DNS and move all record from OpenProvider DNS to Sectigo DNS?

How can I disable the Premium Global Anycast DNS service for one of my domains programmatically using the API?

Add the ‘isSectigoDnsEnabled’ => 0 parameter to your modifyDomainRequest. PHP example:

$request = new OP_Request;

$request->setCommand('modifyDomainRequest')
->setAuth(array('username' => '***', 'password' => '***'))
->setArgs(array(
'domain' => array(
'name' => 'example',
'extension' => 'tld'
),
'isSectigoDnsEnabled' => 0,

));

This will disable the Premium Global Anycast DNS service for the domain and delete the Sectigo DNS zone. Please note that this won't change the nameservers of the domain. To change nameservers while disabling the Premium Global Anycast DNS service, you will need to specify new nameservers in the modifyDomainRequest along with 'isSectigoDnsEnabled' => 0.

Please note that the 'isSectigoDnsEnabled' parameter must only be used to enable or disable the Premium DNS service. It must be omitted from the API calls with which you don’t intend to toggle the Premium DNS service.

How I can move to Sectigo DNS and move all record from OpenProvider DNS to Sectigo DNS?

Yes, You can search for the zone matching a certain name pattern and provider with the query parameters : `name_pattern=example.domain&provider=openprovider`


So the full command would look like :

curl -X  GET "https://api.openprovider.eu/v1beta/dns/zones?name_pattern=example.domain&provider=openprovider" \
                                   -H 'Authorization: Bearer <API TOKEN>'

response will have the target records.

Then add the desired records to the zone :

curl -X  PUT "https://api.openprovider.eu/v1beta/dns/zones/example.domain" \
                                   -H 'Authorization: Bearer <API TOKEN> ' \
                                   -H 'Content-Type: application/json' \
                                   -d '
                                   {
                                     "id": 12275390,
                                     "name": "example.domain"
                                           "provider": "sectigo",
                                     "records": {
                                       "add": [
                                         {
                                           "name": "",
                                           "ttl": "900",
                                           "value": "127.0.0.2",
                                           "type": "A"
                                         }
                                       ]
                                     }
                                   }

Errors (section under construction)

Known errors and how to resolve them

Error 869 - An unknown Sectigo DNS error has occurred; please contact Openprovider.
This error can appear when you are creating a zone that contains an invalid record. For example, this could be an MX record with an IP address or the DNS zone containing a record with type SPF (record type SPF is deprecated. See this section). Please check and adjust your zone and try it again.

Error 866 - This type of record is not supported by Sectigo yet.
This error can appear when you are creating a zone with unsupported records. An example is TSLA, which is a record type that is not supported.

Error 864 - This zone is already active on Sectigo side.
Please contact Support.

Cannot save zone record: Duplicate record

This error can appear when you have a duplicate record in the zone. Please review this section and check if you perhaps have 2 MX records in your zone with identical content.

Invalid SOA record?

DNS checks using external tools like MXToolbox may flag the Sectigo SOA record as invalid. This is because the SOA serial number format used by Sectigo does not follow the typical YYYYMMDDnn format. MXToolbox and some other external tools enforces stricter format expectations and may treat deviations as errors.
However, the SOA serial number returned by Sectigo is valid, functional, and compliant with relevant RFC specifications:

Single Domain DNS panel

The Openprovider single domain DNS panel allows you to delegate access to a specific DNS zone hosted on the Openprovider nameservers. The panel is suitable to supply to end users, without any Openprovider branding or logos, and is hosted on the URL “dnspanel.io”. A clean and simple design makes it easy to manage the DNS records of domains in your Openprovider portfolio, including on mobile devices.

There are 2 options to access the panel.
- Use the Openprovider API to generate a unique URL to share with the user. The URL will be active for ten minutes or until a new token is generated.
- From the reseller control panel, you can open a single domain DNS panel from the “domain details” page.

Screenshot_2020-06-25_at_17.53.31.png

Use Cases:

Suppose you want to allow a given user to edit DNS zones for a domain in your Openprovider portfolio, but without giving them access to the reseller control panel. For example, end users, or employees who need limited access to your portfolio. Simply generate a link to the DNS panel and provide this to the desired user.
If you use the old control panel, you can right-click on "open DNS zone in DNS panel", copy the link behind it and share this with the user.

Using the panel

Add a new record by clicking the “+ New Record” button at the top left corner

Selection_323.png

Add the desired details and click “create”.

Selection_324.png

If the zone is not correct, you’ll get descriptive error messages.

Selection_325.png

Modify or delete zones with the corresponding icons.

Selection_326.png

Selection_328.png

Find specific records quickly via the search bar.

Selection_329.png

Accessing the Panel via the REST API

The REST API offers the method domain-token that returns a URL to the single domain DNS panel.
The method can be found here:
https://docs.openprovider.com/doc/all#tag/DomainToken

Usage scenarios of Openprovider nameservers (Master/Slave configurations)

Question

What are the usage scenarios of Openprovider DNS servers?

Answer

When using Openprovider nameservers, you can use them either as master (DNS zone will be created and managed on Openprovider DNS servers) or as a slave (DNS zone will be created on your own or a 3rd party DNS server and a copy of the records from master server will be copied to Openprovider DNS servers via AXFR transfers (a special automatic updating mechanism).

The Master DNS server (primary DNS server) is a server that stores the original copies of all zone records. In contrast, a slave DNS server (secondary DNS server) is just a backup server that uses a special automatic updating mechanism (AXFR transfers) to communicate with the master server to maintain an identical copy of data similar to the master server. 

Master configuration (default)

When registering or transferring-in a domain name with Openprovider, one can choose to use Openprovider nameservers. If you do not have your own DNS servers and just need to host the DNS zones of your domains registered with Openprovider, you can choose the master DNS zone type.

In case a DNS zone for the domain that is being registered does not yet exist, a master zone will be created automatically based on the selected template.

NB: Master zones can be created before domain registration/transfer-in.

Slave configuration

The purpose of the DNS slave-master configuration is to improve the reliability and availability of DNS services. By having multiple servers distributing the workload and serving as backups, it helps ensure that DNS resolution for a domain remains uninterrupted even if one of the servers fails or goes offline. It also helps distribute the DNS traffic across multiple servers, improving the overall performance and response times for DNS queries. If you already have your own DNS server or a 3rd party DNS server for hosting DNS zones of your domains, you may add Openprovider nameserver as a slave DNS server. You can find instructions to configure Openprovider nameserver as a slave DNS server here.

Slave zones have to be created prior to domain registration since record synchronization between Openprovider and one's master server can take up to a minute.

NB: it is not possible to run one's own slave nameserver and use Openprovider as a master nameserver. In order to support such a configuration, Openprovider would have to open its master nameserver, including all DNS zones that it stores.

What are Terms & Conditions of Openprovider DNS service

Question

Are there special Terms & Conditions for using Openprovider DNS infrastructure?

Answer

The usage of DNS management in Openprovider is bound to the following terms and conditions:

The general terms and conditions of Openprovider also apply to the DNS management service.

What does TTL mean?

Question:

What does TTL mean? Why is my updated DNS record not directly visible and resolving online?

Answer

TTL stands for "Time To Live".

TTL is a value that determines how long a DNS cache server will present the same values before reaching out to the authoritative DNS server and getting a new copy of the record.

This means that once information in the DNS zone is updated, it will not directly be visible online.

In case an existing record is updated, the TTL of that specific record needs to expire, before the new value will be picked up.

In case a new record is added to the zone, the new record should be available rather quickly.

Shorter TTLs can cause heavier loads on an authoritative name server, but can be useful when changing the values of critical services and therefore are often lowered by the DNS administrator prior to a service being moved or updated, in order to reduce possible disruptions.

Available TTL values in The Openprovider Control panel:

In case you want a different TTL value, please use the API and set the TTL according to your own wishes (current minimum supported value is 600 seconds).

Website/server changes – 300 seconds (5 minutes)

Email (MX) – 3600 to 86400 seconds

CDN/dynamic services – 300 to 600 seconds

Static websites – 86400 seconds (1 day)

Please note: These values are general recommendations. You should always choose a TTL that matches how frequently your records are updated and how important the related service is.


What to do if the update is not processed after the TTL is expired?

If the nameservers do not reflect the changes of your zones (for example after updating an IP address of an A record) you might want to flush Google public DNS cache for that specific record.

Google has published a special tool which can help on https://developers.google.com/speed/public-dns/cache. If your record is still not visible after that, please check this article

When you change the TTL of a record it will take the previous TTL time + 1 hour before it is synced on all the nameservers op Openprovider.

Can Openprovider help speed this up further?

Unfortunately, no. Openprovider can not speed up the DNS resolving.

Unfortunately the TTL is not always implemented perfectly by all resolvers, so it might be that they serve the cached value, even after expiration of the TTL. That is not something you can control. If this happens on your local machine (e.g. your laptop or desktop), it may help to flush your local DNS caching.

What is the difference between shadow DNS zones and live zones

Question

What is the difference between shadow DNS zones and live zones in RCP?

Answer

A DNS server can contain only one record for a given domain name. It is technically impossible to have, for example, two DNS records for example.com on the same nameserver. A zone which is being served by Openprovider DNS servers and made available by the nameserver group that's called a live zone. When you have the corresponding domain in your account or no other DNS zone exist for this domain yet, your zone will be automatically a live zone.

However, there's also an option to create a shadow zone for a domain which is not yet in one's account. A shadow zone is simply a DNS resource which we store in our database, but is not yet active on our nameservers.

Creating, updating and deleting zones are done the same way for both live and shadow zones. Shadow zones become live as soon as one registers or transfers in the corresponding domain. In most cases, an active zone will become a shadow zone soon after the corresponding domain has left your control.

When another reseller creates a zone for a domain in your account, his or her zone will be created as a shadow zone and a message will appear in the DNS zone. This zone will not be active, until the domain name is transferred into this account.

Screen_Shot_2018-09-19_at_13.19.09.png

In case the domain name is not registered with Openprovider and multiple zones exist for the domain name, then the first created zone will be the active zone and can be used when the domain has the Openprovider nameservers assigned to it.

Please be aware of the terms and conditions when using the Openprovider nameservers without the domain being in the domain portfolio.

How to activate a shadow zone?

In case there is a message in your control panel that the zone is a shadow zone, simply transfer in the domain name to your account, and your zone will be automatically activated.

This cannot be manually switched by support department.

White label/vanity nameservers

We do not offer vanity/white-labeled nameserver service at this time. This feature was disabled as we had reports of unexpected DNS behavior while using vanity/white-labeled nameservers. 

You can still create your own nameservers for domains that are registered in your Openprovider account if you have DNS servers. 

Nameserver IP
ns1.yourbrand.tld IP address of your DNS server
ns2.yourbrand.tld IP address of your DNS server

You can do nameserver object registration (for domains registered in your Openprovider account) at registry from Domain management > Nameserver management.

Note: Please be aware that creating nameservers using Nameserver management way will not make them accessible in the DNS and it is only intended to provide functionality for registering nameserver objects at a given registry. You can read more about it in this article. 

Why zone changes are not propagated across public DNS resolvers (Google, Cloudflare, etc)

Question

Why DNS zone changes are not propagated across Google public resolvers? Do I really have to wait 2 days for everything to update?

Answer

As with most internet protocols, not everything obeys the DNS specification. Some ISP DNS servers will cache records for longer than the TTL specifies, for instance for 2 days instead of 5 minutes.

In practice, when updating a DNS record with a 5 minute TTL, a large percentage of clients will move over to the new IPs quickly (within 15 minutes), and then there will be some percentage of users that slowly update over the next few days.

If the Google nameservers (8.8.8.8 and 8.8.4.4) do not reflect the changes of your zones (for example after updating an IP address of an A record) you might want to flush Google public DNS cache for that specific record.

Google has published a special tool on https://developers.google.com/speed/public-dns/cache.

If the Cloudflare nameserver (1.1.1.1) doesn't reflect the changes of your zones, you may try to purge Cloudflare public DNS cache for that specific record.

Cloudflare's special tool for purging DNS cache can be accessed at: https://1.1.1.1/purge-cache/

Credit goes to Julia Evans.