Adding a domain you own to your ZERBITZARIA account lets you manage the domain’s DNS records with the control panel and API. Domains you manage on ZERBITZARIA  integrate with ZerBitZaira automatic SSL certificate management.

Each type of DNS record has its own values and settings, and the sections below explain what each of these records are used for and what goes into the fields they contain.

All DNS records have one value in common: TTL, or time to live, which determines how long the record can remain cached before it expires. Loading data from a local cache is fast, but visitors won’t see DNS changes until their local cache expires and updates with a new DNS lookup. As a result, higher TTL values give visitors faster performance and lower TTL values ensure that DNS changes are picked up quickly. All DNS records require a minimum TTL value of 30 seconds.

Create, Update, and Delete Records Using the Control Panel

You can add, modify, and delete DNS records for a domain from the Networking page. From the control panel, click the Networking in the main menu, then click on the domain you would like to manage.

To create a record, select the record type below the heading, fill in the fields required for that record type, and click Create record. The supported record types sections below have detailed instructions for each type of record.

To modify or delete a record, open the record’s More menu.

Click Edit record to change the values for that record. To permanently delete the record, click Delete, then click Delete Record in the confirmation window.

These records will not take effect until you have updated your name servers with your domain registrar and those changes have propagated, which can take up to 48 hours.

Supported Record Types

A Records

An A record maps an IPv4 address to a domain name. This determines where to direct any requests for a domain name.

On ZerBitzaria, A records have the following fields.

• HOSTNAME, which can be set to:
  • The apex domain (@). To map an apex domain, like example.com, to an IPv4 address, enter the @ symbol.
  • A subdomain prefix (for example, www). To create a subdomain, enter a subdomain prefix. For example, to create www.example.com, you would enter www.
  • A wildcard (*). Wildcard records direct requests for a non-existent subdomain to a specified resource or IP address. For example, if you type help.example.com into your browser and the domain example.com doesn’t have a defined DNS record for the subdomain help.example.com, the wildcard record directs you to the defined resource or IP address in its WILL DIRECT TO field. However, if any kind of DNS record exists for a subdomain, the wildcard will not apply; you will need to explicitly create an A record for it. To create a wildcard record, enter a * into the HOSTNAME field.

subdomain prefix test for the hostname. This will make DNS lookups for test.zerbitzaria.com will redirect to the what we’ve chosen named ubuntu-1gb-sfo2-01 with the IPV4 address 203.0.113.5.

AAAA Records

An AAAA record, also called a Quad A record, maps an IPv6 address to a domain name. This determines where to direct requests for a domain name in the same way that an A record does for IPv4 addresses.

On ZerBitZaria, AAAA records have the following fields.

• HOSTNAME, which can be set to: 
  • The apex domain (@). To map a apex domain, like example.com, to an IPv6 address, enter the @ symbol.
  • A subdomain prefix (for example, www). To create a subdomain, enter the subdomain prefix. For example, to create www.example.com, you would enter www.
  • A wildcard (*). Wildcard records direct requests for a non-existent subdomains to a specified resource or IP address. For example, if a user types in help.example.com into their browser and the domain example.com doesn’t have a defined DNS record for the subdomain help.example.com, the wildcard record directs the user to the defined resource or IP address in its WILL DIRECT TO field. However, if any kind of DNS record exists for a subdomain, the wildcard will not apply; you will need to explicitly create an A record for it. To create a wildcard record, enter a * into the HOSTNAME field.

subdomain prefix test for the same hostname from the A record example, zerbitzaria.com. This will make DNS lookups for test.zerbitzaria.com will redirect. we’ve chosen named ubuntu-1gb-sfo2-01 with the IP address 2001:0d8:2:d0::24:9001.

CNAME Records

A CNAME record defines an alias for an A record; it points one domain to another domain instead of to an IP address. When the associated A record’s IP address changes, the CNAME will follow to the new address.

On ZerBitZaria, CNAME records have the following fields.

• HOSTNAME, which should be set to the subdomain prefix for the new alias you want to create.
• IS AN ALIAS OF, which should be set to the hostname where the alias should point. For the alias to work, the hostname must have an A record or be handled by a wildcard A record. This can be:
  • The apex domain (@). To map a apex domain, like example.com, enter the @ symbol.
  • A subdomain (for example, site.example.com).

the subdomain prefix staging for the hostname and @ for the hostname to redirect to. This will make DNS lookups for love.zerbitzaria.com will redirect to the apex domain, zerbitzaria.com.

MX Records

An MX record specifies the mail servers responsible for accepting email on behalf of your domain. Providers often make multiple name servers available so that if one is offline, another can respond. Each server needs its own MX record.

On ZerBitZaria, MX records have the following fields.

• HOSTNAME, which determines which host should accept email. In most cases, the hostname field should be set to @ so that it applies to the apex domain.
• MAIL PROVIDERS MAIL SERVER, which points to the hostname with the A record for the mail server.
• PRIORITY, which indicates the order in which the mail servers should contacted. This field takes a positive whole number where 1 is the highest priority.

The Add Gmail MX Records will add records for each of Google’s mail servers automatically for use with G Suite. You’ll see entries like aspmx.l.google.com.

TXT Records

A TXT record is used to associate a string of text with a hostname. These are primarily used to verify that you own a domain.

On ZerBitZaria, TXT records have the following fields.

• VALUE (for example, example_name=example_value), which is a name-value pair separated by an equal sign, =.
• HOSTNAME, which can be set to:
  • The apex domain (@). To map a apex domain, like example.com, to an IPv4 address, enter the @ symbol.
  • A subdomain prefix (for example, www). To create a subdomain, enter the subdomain prefix. For example, to create www.example.com, you would enter www.

verification token google-site-verification=EXAMPLEV0vtDHmdYgP4H4eHxjgoM8LHtkfRcKmt_5Rt to our apex domain to prove domain ownership for G Suite.

SPF Records

Sender Policy Framework (SPF) records contain lists of email servers that are authorized to send email on behalf of your domain. SPF records increase your email sending reputation with inbox providers by providing a means to check that your emails are being sent from your domain and not by a malicious user.

SPF records are special TXT records. You can create them using the TXT record option in the control panel.

SPF record information v=spf1 a ip4:198.51.100.0/24 include:email-provider.net -all to the apex of the domain. The record authorizes an IP address (in CIDR notation) and an email provider to send email on example domain’s behalf.

DKIM Record

Domain Keys Identified Mail (DKIM) records contain public keys used to authenticate email arriving from a domain. When you use DKIM on your email server, your server signs emails with a private key that receiving email servers then validate using the public key contained in a DKIM DNS record. DKIM records increase your email sending reputation with inbox providers by providing a means to check that no one has intercepted or altered the email during transit.

DKIM records are special TXT records. You can create them using the TXT record option in the control panel.

 DKIM public key to the hostname should be like dk1024._domainkey.example.com.

NS Records

An NS record specifies the name servers, or servers that provide DNS services, for a domain or subdomain. You can use these to direct part of your traffic to another DNS service or to delegate DNS administration for a subdomain.

On ZERBITZARIA, NS records have the following fields.

• HOSTNAME, which can be set to:
  • The apex domain (@). To map a apex domain, like example.com, to an IPv4 address, enter the @ symbol.
  • A subdomain prefix (for example, www). To create a subdomain, enter the subdomain prefix. For example, to create www.example.com, you would enter www.
  • A subdomain prefix (for example, www). To create a subdomain, enter the subdomain prefix. For example, to create www.example.com, you would enter www.
  • A wildcard (*). Wildcard records direct requests for a non-existent subdomains to a specified resource or IP address. For example, if a user types in help.example.com into their browser and the domain example.com doesn’t have a defined DNS record for the subdomain help.example.com, the wildcard record directs the user to the defined resource or IP address in its WILL DIRECT TO field. However, if any kind of DNS record exists for a subdomain, the wildcard will not apply; you will need to explicitly create an A record for it. To create a wildcard record, enter a * into the HOSTNAME field.
• WILL DIRECT TO, which should be set to the name server.

Enter (YOUR PREFERRABLE NAME) as the hostname and dns1.example.com as the name server. This means that DNS lookups for YOUR_PREFERABLE_NAME.domain.com will be directed to dns1.example.com.

SRV Records

A SRV record specifies a hostname and port number for a specific service to direct certain types of traffic to particular servers. Some services, like SIP (Session Initiation Protocol) and XMPP/Jabber (Extensible Messaging and Presence Protocol), require SRV records.

On ZerBitZaria, SRV records have the following fields.

• HOSTNAME (for example, _service._protocol), which should be set to the service, like SIP, and protocol, like TCP or UDP. This field needs to begin with an underscore, _, and the service and protocol must be separated by a period and underscore, ._, resulting in an entry like _sip._udp.
• WILL DIRECT TO, which can be set to:
  • The apex domain (@). To map a apex domain, like example.com, to an IPv4 address, enter the @ symbol.
  • A subdomain prefix (for example, www). To create a subdomain, enter the subdomain prefix. For example, to create www.example.com, you would enter www.
  • A fully qualified domain name, or FQDN (for example, fqdn.example.com.). To use an FQDN, enter the FQDN with a period (.) at the end. This distinguishes it from a subdomain prefix.
• PORT (for example, 5060), which should be set to the port that the service listens on.
• PRIORITY (for example, 10), which indicates the importance of the host. This field takes a positive whole number where 1 is the highest priority.
• WEIGHT (for example, 100), which indicates the relative importance of the host between multiple records with the same priority. This field takes a positive whole number where the higher the number is, the more preference the record is given.

service uses SIP over UDP on port 5060, and we entered a subdomain prefix sip. This means that SIP requests will be directed to sip.zerbitzaria.com.

CAA Records

A CAA record specifies which certificate authorities are permitted to issue certificates for a domain. You can use them to reduce the risk of unintended certificate mis-issue. This section is only a brief overview; our detailed CAA record documentation has more information.

On ZerBitZaria, CAA records have the following fields.

• HOSTNAME, which can be set to:
  • The apex domain (@). To map a apex domain, like example.com, to an IPv4 address, enter the @ symbol.
  • A subdomain prefix (for example, www). To create a subdomain, enter the subdomain prefix. For example, to create www.example.com, you would enter www.
  • A subdomain prefix (for example, www). To create a subdomain, enter the subdomain prefix. For example, to create www.example.com, you would enter www.
  • A wildcard (*). Wildcard records direct requests for a non-existent subdomains to a specified resource or IP address. For example, if a user types in help.example.com into their browser and the domain example.com doesn’t have a defined DNS record for the subdomain help.example.com, the wildcard record directs the user to the defined resource or IP address in its WILL DIRECT TO field. However, if any kind of DNS record exists for a subdomain, the wildcard will not apply; you will need to explicitly create an A record for it. To create a wildcard record, enter a * into the HOSTNAME field.
• AUTHORITY GRANTED FOR, which can be set to:
  • The domain name for the certificate authority (for example, letsencrypt.org).
  • A valid URI with contact information (for example, https://contact.example.com or mailto:contact@example.com) as either the web address of a contact from or an email address. The iodef flag must be chosen to use this option.
• TAG, which can be set to:
  • One of the three defined CAA tags, which are issue, issuewild, and iodef.
  • Custom tags defined by the certificate authority.
• FLAGS, which is currently used to set an Issuer Critical flag. This is an unsigned integer between 0 and 255 that specifies how a CA should behave when it encounters a tag it doesn’t understand. For example, a zero (0) tells the CA to issue a certificate anyway, and a one (1) tells the CA to refuse.

Enter @ for so that a certificate can be issued for the apex domain, zerbitzaria.com. In the example, we’ve entered letsencrypt.org as the CA to grant them authority to issue certs for the apex domain (@), which is zerbitzaria.com.

PTR (rDNS) Records

A PTR (pointer) record, also known as an rDNS (reverse DNS) record, maps a domain name to an IP address.

We automatically create PTR records for zerbitzaria clients who purchase domain and hosting with us in the control panel.