Basic Zone Management

Create and edit DNS records easily

Logging in to DNS Management

When you subscribe to a Conexim Managed DNS Service, you will be provided with an email detailing the username and password to login to My Conexim.

To access DNS Management, simply visit and enter your email address and assigned password. Once logged in, there are two ways you can access DNS Management – either from the home page, or the icon on the front dashboard.


Basic Zone Management

The screen below displays a typical display of current DNS Zones that are configured for the service.


Creating a New Zone

Conexim DNS allows you to create three types of zones:

  • Standard Zone (Default): There are no primary or secondary DNS servers other than those run as part of Conexim’s platform.
  • Master Zone with Slaves: Select this option if you wish to use Conexim’s DNS platform to act as a DNS Master server, with your own server(s) operating as slaves.
  • Slave Zone: If you already operate a DNS server operating as a Master and wish to use Conexim’s DNS platform as a Slave, select this option.

With the exception of very specific use cases, Standard Zone suits most situations. See the sections on Managing Master and Slave Zones for details on additional configuration required for each of these options. When creating a new DNS Zone, you are provided with several options for creating the zone:


Once you’ve entered the name for the new zone to be created, there are several options for populating the zone with an initial set of records. These are:

Empty Zone: Creates only the NS records and sets up the SOA.

Web and Mail Records: If you know the IP address (IPv4 and/or IPv6) of the web server and also the MX (mail exchanger) server details, select this option.

Conexim cPanel Hosting: Sets up hosting for Conexim cPanel Shared Hosting Services.

Conexim Hosted Exchange: Sets up the appropriate DNS records for Hosted Microsoft Exchange.

Conexim DNS also contains a template for Google Apps, allowing you to set up a zone for running Google Apps in a single operation. This configures the appropriate MX records, CNAME and also prompts you to enter the Google Apps Domain Verification TXT Record if you have one.

Resource Records

Each DNS zone contains a collection of Resource Records (RRs). In their simplest form, Resource Records define mappings between names and IP addresses (A and AAAA Records), define aliases between names (CNAMEs) or provide Email Server (Mail Exchanger / MX) information.

Conexim DNS supports a standard set of RR types as described below, but in addition, supports virtually any RR type that may be defined in the future by supporting RFC 3597.

For each type of Resource Record that Conexim DNS directly supports, thorough validation of entries (where possible) is performed to ensure that common mistakes are avoided.


A: IPv4 address – maps a name to an IPv4 address.

AAAA: Equivalent of an A Record, but for an IPv6 address. If the server supports both IPv4 and IPv6 (Dual-Stack), you must crease both an A and an AAAA record.

CNAME: Aliases one record to another. For example, www.yourdomain.tld may be aliased to server

NS: Name Server records define the servers that respond to DNS queries for the zone.

MX: Mail Exchanger records define hosts that will accept email on behalf of the domain.

TXT: Text Records serve multiple purposes, but at their lowest level contain text. They are commonly used for DKIM (DomainKeys) Email Signing and SPF (Sender Policy Framework).


SRV: Service Records define the location (specifically, the hostname and port number) of servers for specified services. Common uses for SRV records are SIP (IP telephony), Microsoft Exchange, Lync and Active Directory. Conexim DNS provides a single form to assist in correctly setting up each of the attributes of an SRV record.

SPF record

SPF: Sender Policy Framework records define a list of servers or networks that are allowed to send emails on your domain’s behalf. Conexim DNS includes a single form for managing SPF records.

If there is a Resource Record type that does not exist in the list above, it can be created by selecting Other (RFC 3597). From here, you can enter any type desired. This can be used for creating new types of resource record or specifying rarely used RR types such as HINFO, SSHFP, LOC, AFSDB and NAPTR.

Naming Resource Records

A record

If you are familiar with other types of DNS server such as BIND, you will note that zone files typically allow you to specify the complete fully qualified domain name ( or just the name of the record itself (www). Conexim DNS requires that you enter the name of the record itself or leave the name field blank if you wish to create the record on the base (apex) of the domain.

The Time to Live (TTL) Attribute

In addition to the record-specific attributes that RRs contain, there is also a TTL (Time to Live). The TTL defines for how long a caching nameserver should keep the current version of the record before a new request is made to the authoritative Nameserver.

It is important to set the TTLs for records appropriately to ensure you can take advantage of a caching nameserver’s ability to quickly respond to DNS requests and at the same time, ensure that the setting is such that records that are likely to need to be changed quickly are not inhibited by delays in caching Nameservers serving the updated record.

While the settings will depend on your exact implementation, Conexim offers the following guidance in setting DNS records:

Record Type TTL Comment
NS 86400 (24h) Name Servers are unlikely to change often and can usually be planned with some notice.
MX 86400 (24h) The nature of email being able to store and forward allows for longer TTLs.
A and AAAA 300-3600-86400 (5m-1h-24h) Depending on the purpose of the record A/AAAA records are more likely to require a change. If the record may need to be changed as part of Disaster Recovery – these must be set lower.
SPF 86400 (24h) SPF records are unlikely to experience frequent change.

Priority Attribute

Both MX and SRV records contain a priority attribute. Where there are multiple servers serving mail or providing a specific service, configure multiple records with the same name (usually blank for MX), the record with the lowest priority number is the more preferred.