Loading color scheme

Domains

Configuration article

This article shows FAQs, instructions and management settings for Domains. Before start to manage your domain(-s) please make sure you have read Help Center documentation.

Domains FAQs

Domain - a domain name is your personal or business home on the Internet, it’s a piece of online real estate that you control completely—as long as you own the rights to that name. Domain names can be fanciful or transparently descriptive, used for everything from a personal blog to a multinational company’s public site, and having one or more is essential for being visible in a crowded online world. Knowing how domain names work, and why they’re needed, can help you choose the right name for your business or personal site.

Every domain must have a unique name that distinguishes it from all others and points only to a single website. That’s why anyone buying and registering a domain name needs to carefully research the desired name to find out if it’s already in use. If so, it’s off-limits, unless the owner is willing to sell it.

If a domain name is available, any Internet user can buy it—which really means paying a fee for exclusive rights to that name for a period of time that can range from one year to more than a decade. After registering a domain name it becomes the owner’s public address on the Internet, and the gateway to accessing the website attached to the name. But a domain name is only a proxy for the real locator—the IP address.

DNS - the Internet at large runs on numbers, IP addresses, that are great for computers to work with but difficult for people to remember. To help with this, we assign names to these numbers using the Domain Name System, or DNS for short. Domain name records are used as a naming system for computers, servers, and other services on the Internet, much like a phone book that matches names with numbers.

Name servers - a name server is a specialized server on the Internet that handles queries or questions from your local computer, about the location of a domain name’s various services. A great simple way to think about name servers is using a phone book analogy. If you were trying to call eServices.Business you might have remembered our phone number, but more than likely you’d want to look it up before just guessing at numbers.

Zones - A DNS zone refers to a certain portion or administrative space within the global Domain Name System (DNS). Each DNS zone represents a boundary of authority subject to management by certain entities. The total of all DNS zones, which are organized in a hierarchical tree-like order of cascading lower-level domains, form the DNS namespace.

The authority over each DNS zone is delegated to a legal entity or organization (i.e. a country-code top-level domain registry) or a company/individual registered to use a certain sub-domain within the system. Depending on the administrative rights delegated to a certain entity, DNS zones may consist of only one domain, or of many domains and sub-domains. Further authority over a sub-space could be delegated to other parties, if necessary.

Records - DNS refers to the large-scale system of information that contains the IP addresses, domain names, hosting, and other registration information across every site on the Internet. Before this system was created the only way for people to access your website would be by typing in your IP address.

DNS records act as instructions for the DNS server, so it knows which domain names each IP address is associated with.

DNS records contain a lot of different syntax and commands for how the server should respond to the request. Some of the most common forms of syntax are highlighted below:

Address Mapping records (A)
The record A specifies IP address (IPv4) for given host. A records are used for conversion of domain names to corresponding IP addresses.

IP Version 6 Address records (AAAA)
The record AAAA (also quad-A record) specifies IPv6 address for given host. So it works the same way as the A record and the difference is the type of IP address.

Canonical Name records (CNAME)
The CNAME record specifies a domain name that has to be queried in order to resolve the original DNS query. Therefore CNAME records are used for creating aliases of domain names. CNAME records are truly useful when we want to alias our domain to an external domain. In other cases we can remove CNAME records and replace them with A records and even decrease performance overhead.

Host Information records (HINFO)
HINFO records are used to acquire general information about a host. The record specifies type of CPU and OS. The HINFO record data provides the possibility to use operating system specific protocols when two hosts want to communicate. For security reasons the HINFO records are not typically used on public servers.

Note: Standard values in RFC 1010

Integrated Services Digital Network records (ISDN)
The ISDN resource record specifies ISDN address for a host. An ISDN address is a telephone number that consists of a country code, a national destination code, a ISDN Subscriber number and, optionally, a ISDN subaddress. The function of the record is only variation of the A resource record function.

Mail exchanger record (MX)
The MX resource record specifies a mail exchange server for a DNS domain name. The information is used by Simple Mail Transfer Protocol (SMTP) to route emails to proper hosts. Typically, there are more than one mail exchange server for a DNS domain and each of them have set priority.  

Name Server records (NS)
The NS record specifies an authoritative name server for given host.

Reverse-lookup Pointer records (PTR)
As opposed to forward DNS resolution (A and AAAA DNS records), the PTR record is used to look up domain names based on an IP address.

Start of Authority records (SOA)
The record specifies core information about a DNS zone, including the primary name server, the email of the domain administrator, the domain serial number, and several timers relating to refreshing the zone.

Text records (TXT)
The text record can hold arbitrary non-formatted text string. Typically, the record is used by Sender Policy Framework (SPF) to prevent fake emails to appear to be sent by you.

https://en.wikipedia.org/wiki/List_of_DNS_record_types

Should my company need a domain?

Yes! Think of your business' domain name as your own, branded corner of the internet. It is the space you own for business-related web and email traffic.

In today’s digital economy, most businesses own a custom domain for their website. However, it’s surprising how many aren’t using a custom domain for email and instead use generic email addresses like gmail.com, yahoo.com, aol.com, etc. Even if you have not yet registered a custom domain, the process is relatively simple and inexpensive, and the benefits to your business are significant.

Your company and employee email addresses make a statement about you and your business. What would you think of a job applicant whose email address is alwaysgettingfiredfreddy@gmail.com?

When your business email is mybusiness@yahoo.com, potential customers may perceive you as behind the times, unprofessional, or simply someone who doesn’t take their business seriously.

A custom domain sends a message that you are established and committed to staying around for a while. Custom domains also offer a perception of increased security and trust. People have more trust that they’re communicating with you and not with someone posing as you.

Should we need to use eServices Business Domain management?

Yes! You can register domain names with different domain registrars, but you require a central management tool from eServices Business.

What name servers should we use?

dns1.eservices.business
dns2.eservices.business
dns3.eservices.business

Should we create a DNS Zone?

Yes! The DNS zone definition states that this is a segment of the entire domain name system that is under the managerial authority of a single administrator, be that a legal or private entity.

Should we need to add DNS records?

Yes! Once you own that domain name, your web host must store its information within the DNS records to serve it up when the domain is entered.


Getting started

Change nameservers

To change the name servers of your domain, do following:

1) Open Your Domain registrar web page, for example: https://www.name.com/account/login.php;

2) Login in portal;

3) From Your domain list click on appropriate domain;

4) Click on Manage Nameservers;

5) Remove ns4.name.com name server;

6) Change ns1.name.com to dns1.eservices.business, ns2.name.com to dns2.eservices.business, ns3.name.com to dns3.eservices.business;

7) Apply Changes.

Add DNS zone

1) Login to portal https://mydomains.eservices.business:8080/index.php;

2) Click on DNS;

3) Click Add new DNS Zone with Wizard;

4) Fill the fields, for example:

5) Click Create DNS-Record.


Manage DNS records

1) Login to portal: https://mydomains.eservices.business:8080/index.php;

2) Click on DNS;

3) Click on your Domain;

4) Click Records;

5) Click on DNS record which you want to change or add DNS record by clicking to a appropriate green button.

 

Instructions

DNS

On this tab you can create zones and DNS records for your domains. You can either do this by using the DNS Wizard (DNS > DNS Wizard > Add DNS Zone) which will automatically create a set of common DNS records for your domain (like www, mail, ns records, etc.), or you create the zones and records manually under DNS > DNS > Zones - you will also have to go there if you want to create further DNS records that are not created by the DNS Wizard.

DNS Wizard > Add DNS Zone
This is the wizard to create a new DNS zone. The form has the following fields:

  • Template: This refers to the templates that exist under DNS > DNS Wizard > Templates. These templates define what records will be created by default if you use the DNS Wizard. Let's assume we create a zone for the domain example.com - the Default template will create A records for example.com, www.example.com, and mail.example.com, two NS (nameserver) records, plus an MX (mail exchanger) record for example.com that points to mail.example.com.
  • Server: If more than one server is available, you can select the server on which the DNS zone will be located.
  • Client: Here you select the client that owns the new DNS zone.
  • Domain: Fill in the domain for which you want to create the zone, e.g. example.com - please note that you don't need a dot at the end, i.e., example.com. would work as well, but example.com (without the trailing dot) is sufficient.
  • IP Address: Fill in the IP address that example.com should point to - please note that www.example.com and mail.example.com will also point to that IP address (you can change that later on under DNS > DNS > Zones).
  • NS 1: Specify the hostname of the primary nameserver for the domain, e.g. ns1.somedomain.com. Again, no trailing dot is needed. ns1.somedomain.com must point to the server that you selected in the Server field.
  • NS 2: Specify the hostname of the secondary nameserver for the domain, e.g. ns2.somedomain.com. Again, no trailing dot is needed.
  • Email: Specify the email address of the zone administrator, e.g. zonemaster@somedomain.com.

DNS Zones

Here you can create DNS zones manually (if you are experienced enough with DNS and don't want to use the DNS Wizard) and modify existing DNS zones (that were created, for example, with the DNS Wizard). To create a new DNS zone, click on the Add new DNS Zone (SOA) button. This will lead you to the DNS Zone form with the tabs DNS Zone and Records.

DNS Zone

On this tab you specify the SOA (start of authority) record. It contains authoritative information about a DNS zone, including the primary name server, the email of the domain administrator, the domain serial number, and several timers relating to refreshing the zone.

The form contains the following fields:

  • Server: If more than one server is available, you can select the server on which the DNS zone will be located.
  • Client: Here you select the client that owns the new DNS zone.
  • Zone (SOA): Fill in the domain for which you want to create the zone, e.g. example.com. - please note that other than in the DNS Wizard you need a dot at the end.
  • NS: Specify the hostname of the primary nameserver for the domain, e.g. ns1.somedomain.com. - again, a trailing dot is needed. ns1.somedomain.com must point to the server that you selected in the Server field.
  • Email: Specify the email address of the zone administrator. This should be specified in the mailbox-as-domain-name format where the @ character is replaced with a dot, e.g. zonemaster.somedomain.com. - again, you need a trailing dot.
  • Refresh: The number of seconds after which slave nameservers should check to see if this zone has been changed. If the zone's serial number has changed, the slave nameserver initiates a zone transfer.
  • Retry: This specifies the number of seconds a slave nameserver should wait before retrying if it attmepts to transfer this zone but fails.
  • Expire: If for expire seconds the primary server cannot be reached, all information about the zone is invalidated on the secondary servers (i.e., they are no longer authoritative for that zone).
  • Minimum: The minimum TTL field that should be exported with any record from this zone. If any record has a lower TTL, this TTL is sent instead.
  • TTL: The number of seconds that this zone may be cached before the source of the information should again be consulted. Zero values are interpreted to mean that the zone should not be cached.
  • Allow zone transfers to these IPs (comma separated list): This field can contain one or more IP addresses separated by commas. These IP addresses will be allowed to connect to the server to transfer the zone. If no IP is specified, any server is allowed to connect. Usually, you should list your slave DNS servers for this zone here.
  • Also Notify: This optional field should contain one or more IP addresses separated by commas. These IP addresses will be used to send NOTIFY messages to additional name servers. Notification is sent to all name servers that have NS records in the zone plus any mentioned in this field.
  • Update ACL: This is an optional specifying the ACL (access control list) controlling who can update a zone. You can specify one or more IP addresses separated by commas. This field is useful if the zone contains dynamic IP addresses and you want to allow dynamic DNS updates from a client. If no IP is specified, then dynamic DNS updates are disabled.
  • Active: This defines whether this DNS zone is active or not.

DNS Records

On this tab you can create the following types of records:

  • A
  • AAAA
  • ALIAS
  • CNAME
  • HINFO
  • MX
  • NS
  • PTR
  • RP
  • SRV
  • TXT

A Records
An A record is an IPv4 host address. The IP-Address field should contain the IP address (in numbers-and-dots format) associated with the Hostname. Example: 192.168.1.88

The form contains the following fields:

  • Hostname: The name that this record describes. Wildcard values such as * or *.sub are supported, and this field can contain an FQDN or just a hostname. If you specify an FQDN, the name must end with a dot; if you specify just a hostname, it must not end with a dot.

Examples:

  • foo
  • foo.example.com.
  • www
  • example.com.
  • You can also leave the field empty which has the same meaning as if you'd fill in example.com.

IP-Address: Fill in the IPv4 IP address that the hostname should point to. Example: 192.168.1.88

  • TTL: The time interval (in seconds) that this record may be cached before the source of the information should again be consulted. Zero values are interpreted to mean that the record can only be used for the transaction in progress, and should not be cached.
  • Active: This defines whether this A record is active or not.

AAAA Records
An AAAA record is an IPv6 host address. The IPv6-Address field should contain the IPv6 address associated with the Hostname. Example: 3ffe:b00:c18:3::a

The form contains the following fields:

  • Hostname: The name that this record describes. Wildcard values such as * or *.sub are supported, and this field can contain an FQDN or just a hostname. If you specify an FQDN, the name must end with a dot; if you specify just a hostname, it must not end with a dot.

Examples:

  • foo
  • foo.example.com.
  • www
  • example.com.

You can also leave the field empty which has the same meaning as if you'd fill in example.com.

  • IPv6-Address: Fill in the IPv6 IP address that the hostname should point to. Example: 3ffe:b00:c18:3::a
  • TTL: The time interval (in seconds) that this record may be cached before the source of the information should again be consulted. Zero values are interpreted to mean that the record can only be used for the transaction in progress, and should not be cached.
  • Active: This defines whether this AAAA record is active or not.


ALIAS Records
(Please note the ALIAS records are supported by the MyDNS name server, but not by the BIND name server. If you use BIND, ALIAS records are identical to CNAME records, i.e., if you create an ALIAS record, actually a CNAME record will be created.)

An ALIAS record is a server side alias. An alias is like a CNAME, only it is handled entirely by the server. The Target Hostname field should contain the hostname aliased by Hostname. Aliases can be used in place of A records. The client will only see A records and will not be able to tell that aliases are involved. The target hostname must exist in the database. It can be useful to use aliases for everything. Use A records for the canonical name of the machine and use aliases for any additional names. This is especially useful when combined with automatic PTR records. If a single IP address is only used for one A record, then there will never be any confusion over what the PTR record should be.

Example: albuquerque.example.com. (FQDN)
Example: albuquerque (hostname only)

The field contains the following fields:

  • Hostname: The name that this record describes. Wildcard values such as * or *.sub are supported, and this field can contain an FQDN or just a hostname. If you specify an FQDN, the name must end with a dot; if you specify just a hostname, it must not end with a dot.

Examples:

  • foo
  • foo.example.com.
  • www
  • example.com.
  • You can also leave the field empty which has the same meaning as if you'd fill in example.com.
  • Target Hostname: The hostname that is aliased by the hostname in the Hostname field. Wildcard values such as * or *.sub are supported, and this field can contain an FQDN or just a hostname. If you specify an FQDN, the name must end with a dot; if you specify just a hostname, it must not end with a dot.

Examples:

  • albuquerque
  • albuquerque.example.com.
  • TTL: The time interval (in seconds) that this record may be cached before the source of the information should again be consulted. Zero values are interpreted to mean that the record can only be used for the transaction in progress, and should not be cached.
  • Active: This defines whether this ALIAS record is active or not.

CNAME Records
A CNAME record is the canonical name for an alias. The Target Hostname field should contain the real name of the machine specified by Hostname. Target Hostname may be a hostname or an FQDN.

Example: porcini.example.com. (FQDN)

Example: porcini (hostname only)

The field contains the following fields:

  • Hostname: The name that this record describes. Wildcard values such as * or *.sub are supported, and this field can contain an FQDN or just a hostname. If you specify an FQDN, the name must end with a dot; if you specify just a hostname, it must not end with a dot.

Examples:

  • foo
  • foo.example.com.
  • www
  • example.com.
  • You can also leave the field empty which has the same meaning as if you'd fill in example.com.
  • Target Hostname: The real name of the machine that the hostname in the Hostname field points to. Wildcard values such as * or *.sub are supported, and this field can contain an FQDN or just a hostname. If you specify an FQDN, the name must end with a dot; if you specify just a hostname, it must not end with a dot.

Examples:

  • porcini
  • porcini.example.com.
  • TTL: The time interval (in seconds) that this record may be cached before the source of the information should again be consulted. Zero values are interpreted to mean that the record can only be used for the transaction in progress, and should not be cached.
  • Active: This defines whether this CNAME record is active or not.


HINFO Records
A HINFO record contains host information. The Host Information field should contain two strings which provide information about the host specified by Hostname. The first string specifies the CPU type, and the second string describes the operating system type. The two strings should be separated by a space. If either string needs to contain a space, enclose it in quotation marks.

Example: "Pentium Pro" Linux

The form contains the following fields:

  • Hostname: The name that this record describes. Wildcard values such as * or *.sub are supported, and this field can contain an FQDN or just a hostname. If you specify an FQDN,the name must end with a dot; if you specify just a hostname, it must not end with a dot.

Examples:

  • foo
  • foo.example.com.
  • www
  • example.com.
  • You can also leave the field empty which has the same meaning as if you'd fill in example.com.
  • Host Information: Specify two strings which provide information about the host specified by Hostname. The first string specifies the CPU type, and the second string describes the operating system type. The two strings should be separated by a space. If either string needs to contain a space, enclose it in quotation marks. Example: "Pentium Pro" Linux
  • TTL: The time interval (in seconds) that this record may be cached before the source of the information should again be consulted. Zero values are interpreted to mean that the record can only be used for the transaction in progress, and should not be cached.
    Active: This defines whether this HINFO record is active or not.

MX Records
An MX record describes the mail exchanger for a domain or hostname. The Mailserver hostname field should contain the hostname or FQDN of a mail server which will accept mail for the host specified by Hostname. The Priority field should contain a preference for this mail server. Mail transfer agents prefer MX records with lower values in Priority.

Example: mail.example.com. (FQDN)

Example: mail (hostname only)

The form contains the following fields:

  • Hostname: The name that this record describes. Wildcard values such as * or *.sub are supported, and this field can contain an FQDN or just a hostname. If you specify an FQDN, the name must end with a dot; if you specify just a hostname, it must not end with a dot.If you want email addresses of the form user@example.com, you must fill in example.com. In the Hostname field (or leave it empty); if you want email addresses of the form user@sub.example.com, you must fill in sub or sub.example.com. in the Hostname field.

Examples:

  • foo
  • foo.example.com.
  • www
  • example.com.
  • You can also leave the field empty which has the same meaning as if you'd fill in example.com.
  • Mailserver hostname: The Mailserver hostname field should contain the hostname or FQDN of a mail server which will accept mail for the host specified by Hostname. Please note that this Mailserver hostname must always be an A record - CNAME records are not allowed.

Examples:

  • mail.example.com. (FQDN)
  • mail (hostname only)
  • Priority: The Priority field should contain a preference for this mail server, usually between 0 and 100. Mail transfer agents prefer MX records with lower values in Priority.
  • TTL: The time interval (in seconds) that this record may be cached before the source of the information should again be consulted. Zero values are interpreted to mean that the record can only be used for the transaction in progress, and should not be cached.
  • Active: This defines whether this MX record is active or not.

NS Records
An NS record describes an authoritative nameserver of a zone. A zone can have more than one authoritative nameserver (usually it has at least two so that if one nameserver fails, the zone can still be resolved from the other nameserver), so there can be multiple NS records. The Nameserver Hostname field should contain the hostname or FQDN of a server which should be considered authoritative for the zone listed in Zone.

Example: ns1.example.com. (FQDN)

Example: ns1 (hostname only)

The form contains the following fields:

  • Zone: Fill in the name of the zone, i.e., the domain.

PTR Records
A PTR record is a domain name pointer, i.e., it is used to point from an IP address to a domain or hostname. This is used for reverse DNS lookups. These records, used only with IN-ADDR.ARPA zones, should contain the canonical hostname of the machine referred to in the Canonical Hostname field. Usually the administrator of an IP address/subnet (i.e., your ISP or hoster) creates these for you (or gives you a web interface where you can configure this yourself), so in most cases you can ignore this feature in ISPConfig (unless you're the administrator of your own IP addresses).

Example: webserver.example.com.

Now let's assume you're the administrator of the IP subnet 1.2.3/255.255.255.0 and want to create a PTR record for the IP address 1.2.3.4 that should point to www.example.com. First you create the DNS zone 3.2.1.in-addr.arpa (3.2.1 is our 1.2.3 subnet in reverse order) in ISPConfig and in this DNS zone you create a PTR record for the Name 4 (which is our IP address 1.2.3.4) which points to www.example.com.

The form contains the following fields:

  • Name: Fill in the last part of your IP address. In our example of the 1.2.3.4 IP address, this would be 4 (without any dots).
  • Canonical Hostname: Fill in the domain or hostname that this PTR record should point to. You must use fully qualified domain names here:

Examples:

  • example.com. (FQDN)
  • www.example.com. (FQDN)
  • TTL: The time interval (in seconds) that this record may be cached before the source of the information should again be consulted. Zero values are interpreted to mean that the record can only be used for the transaction in progress, and should not be cached.
  • Active: This defines whether this NS record is active or not.

RP Records
An RP record describes a responsible person for a hostname. The Responsible Person field contains the DNS-encoded email address of the person responsible for the Hostname requested, then a space, then a hostname that should return a TXT record containing additional information about the responsible person. If there is no such TXT record, the second value should contain a dot (.).

Example: webmaster.example.com. contactinfo.example.com.

The form contains the following fields:

  • Hostname: The name that this record describes. Wildcard values such as * or *.sub are supported, and this field can contain an FQDN or just a hostname. If you specify an FQDN, the name must end with a dot; if you specify just a hostname, it must not end with a dot. If you want email addresses of the form user@example.com, you must fill in example.com. In the Hostname field (or leave it empty); if you want email addresses of the form user@sub.example.com, you must fill in sub or sub.example.com. in the Hostname field.

Examples:

  • foo
  • foo.example.com.
  • www
  • example.com.
  • You can also leave the field empty which has the same meaning as if you'd fill in example.com.
  • Responsible Person: The Responsible Person field contains the DNS-encoded email address of the person responsible for the Hostname requested, then a space, then a hostname that should return a TXT record containing additional information about the responsible person. If there is no such TXT record, the second value should contain a dot (.).

Examples:

  • webmaster.example.com. contactinfo.example.com. (This means the responsible person is webmaster@example.com, and there is a TXT record for the hostname contactinfo.example.com which contains additional information about webmaster@example.com. If no TXT record for contactinfo.example.com exists, create one.)
  • webmaster.example.com. . (If no such TXT record exists or you don't want to create one, just fill in a dot for the hostname.)
  • TTL: The time interval (in seconds) that this record may be cached before the source of the information should again be consulted. Zero values are interpreted to mean that the record can only be used for the transaction in progress, and should not be cached.
  • Active: This defines whether this RP record is active or not.

SRV Records
Server location. SRV records specify the location of the server(s) for a specific protocol and domain. The Server Record field must contain three space-separated values. The first value is a number specifying the weight for this entry. The second field is a number specifying the port on the target host of this service. The last field is a name specifying the target host. The Priority field should contain the priority of this target host. Targets with a lower priority are preferred.
Some protocols such as SIP and XMPP require SRV records. SRV records have the form _service._proto.name TTL class SRV priority weight port target.

  • service: The symbolic name of the desired service.
  • proto: The transport protocol of the desired service; this is usually either TCP or UDP.
  • name: The domain name for which this record is valid.
  • TTL: The time interval (in seconds) that this record may be cached before the source of the information should again be consulted. Zero values are interpreted to mean that the record can only be used for the transaction in progress, and should not be cached.
  • class: Standard DNS class field (this is always IN).
  • priority: The priority of the target host, lower value means more preferred (similar to MX records).
  • weight: A relative weight for records with the same priority.
  • port: The TCP or UDP port on which the service is to be found.
  • target: The canonical hostname of the machine providing the service.

E.g.
_sip._tcp.example.com. 86400 IN SRV 0 5 5060 sipserver.example.com. SRV records allow you to achieve a basic form of high-availability and load-balancing (basic because information is static, i.e., current server loads are not taken into account). The priority field is similar the the one of MX record - clients use the server with the lowest priority value first and use other servers only if this server fails. This means oyu can have multiple SRV records and define a fallback server that is used only if the primary server fails by giving the fallback server a higher priority value than the primary server. If there are multiple SRV records with the same priority, clients use the weight field to find out which host to use. The weight value is relevant only in among records with the same priority.

Here's an example of basic high-availability and load-balancing with SRV records:
_sip._tcp.example.com. 86400 IN SRV 10 60 5060 server1.example.com.
_sip._tcp.example.com. 86400 IN SRV 10 40 5060 server2.example.com.
_sip._tcp.example.com. 86400 IN SRV 20 0 5060 server3.example.com.

In the above example, both server1.example.com and server2.example.com have a priority value of 10, so all requests will be shared by them, where server1.example.com gets 60% of the requests and server2.example.com gets the remaining 40% of the requests (because server1.example.com has a weight value of 60 and server2.example.com has a weight value of 40). If server1.example.com fails, all requests will go to server2.example.com. If both server1.example.com and server2.example.com fail, all requests will go to server3.example.com which has a priority value of 20.

For more information, read RFC 2782 and SRV Records on Wikipedia.
The form has the following fields:

  • Hostname: The name that this record describes. This field can contain an FQDN or just a hostname. If you specify an FQDN, the name must end with a dot; if you specify just a hostname, it must not end with a dot.

Examples:

  • _sip._tcp.example.com.
  • _sip._tcp
  • Server Record: The Server Record field must contain three space-separated values. The first value is a number specifying the weight for this entry. The second field is a number specifying the port on the target host of this service. The last field is a name specifying the target host. The target host can be an FQDN or just a hostname. If you specify an FQDN, the name must end with a dot; if you specify just a hostname, it must not end with a dot.

Examples:

  • 0 9 server.example.com. (FQDN)
  • 0 9 server (hostname only)
  • Priority: The Priority field should contain a preference for this SRV record, usually between 0 and 100. Records with lower values are preferred.
  • TTL: The time interval (in seconds) that this record may be cached before the source of the information should again be consulted. Zero values are interpreted to mean that the record can only be used for the transaction in progress, and should not be cached.
  • Active: This defines whether this SRV record is active or not.

TXT Records
TXT records are used to give additional information about a hostname. The Text field contains a text string that is returned only when a TXT query is issued for the host specified by Hostname. TXT records can be used for SPF records. The form contains the following fields:

  • Hostname: The name that this record describes. This field can contain an FQDN or just a hostname. If you specify an FQDN, the name must end with a dot; if you specify just a hostname, it must not end with a dot.

Examples:

  • server1.example.com.
  • server1
  • Text: The Text field contains a text string that is returned only when a TXT query is issued for the host specified by Hostname. TXT records can be used for SPF records. it must not end with a dot.

Examples:

  • "This is a string."
  • "v=spf1 a mx ptr -all" (SPF record)
  • TTL: The time interval (in seconds) that this record may be cached before the source of the information should again be consulted. Zero values are interpreted to mean that the record can only be used for the transaction in progress, and should not be cached.
  • Active: This defines whether this TXT record is active or not.

Secondary DNS

Secondary Zones
Here you can create secondary (slave) zones, i.e., zones for which another server is the primary (master) nameserver. A slave zone will then automatically be transferred from the master to the slave, so that both servers hold the same information about the zone. If the master fails, the slave can still answer DNS requests. To create a new slave zone, click on the Add new secondary DNS Zone button. This will lead you to the Secondary DNS Zone form with the tab Secondary DNS Zone.

The form has the following fields:

  • Server: If more than one server is available, you can select the server on which the secondary DNS zone will be located.
  • Client: Here you select the client that owns the new secondary DNS zone.
  • DNS Zone: Fill in the domain for which you want to create the secondary zone, e.g. example.com. - please note that you need a dot at the end.
  • NS: Specify the IPv4 address of the primary nameserver for the domain, e.g. 1.2.3.4.
  • Allow zone transfers to these IPs (comma separated list): This field can contain one or more IP addresses separated by commas. These IP addresses will be allowed to connect to the server to transfer the zone. If no IP is specified, any server is allowed to connect. Usually, you can leave this field empty because all slave DNS servers for this zone should contact the master DNS server for the zone, not another slave server.
  • Active: This defines whether this secondary DNS zone is active or not.