Skip to content

Public DNS

Introduction

About this Document

In this guide, we explain how to configure the AXS Guard Public DNS server. This document is intended for system administrators or technical personnel with a thorough knowledge of DNS and RR types.

Note that the AXS Guard appliance also runs a separate, internal DNS server so that clients in your secure LAN can resolve names of internal systems; i.e. systems running in your secure LAN and DMZ. The concepts and configuration of the internal DNS server are explained separately in the AXS Guard System Administration How To, which can be accessed via the Documentation button in the Administrator Tool.

Examples used in this Guide

All setups and configuration examples in this guide are executed as an advanced administrator. Some options are not available if you log in as a full administrator or a user with lower access privileges.

As software development and documentation are ongoing processes, the screenshots shown in this guide may slightly deviate from the current user interface.

Configuring the AXS Guard DNS Server

Overview

In this chapter we will cover:

  • How to activate the Public DNS Feature on your appliance

  • How to allow DNS zone transfers

  • How to add and configure primary forward lookup zones

  • How to add and configure primary reverse lookup zones

  • How to add and configure secondary zones

  • How to visualize DNS records per domain

Feature Activation

  1. Log in to the AXS Guard appliance.

  2. Navigate to System > Feature Activation.

  3. Expand the Network tree.

  4. Check the Do you use the AXS Guard Public DNS Service? option.

  5. Update your configuration.

    DNS Feature Activation

Zone Transfer Configuration

About

The specifications of DNS define two types of nameservers: primary and secondary nameservers.

A zone’s primary nameserver reads the data for the zone from a local storage system on its host. A zone’s secondary nameserver gets the zone data from the primary nameserver and is used as a backup in case the primary server fails. A secondary nameserver can also load zone data from another secondary nameserver. When a secondary nameserver starts up, it contacts the primary nameserver and, if necessary, retrieves the zone data. This is referred to as a zone transfer. Both the primary and the secondary nameservers of a zone are authoritative for that zone.

Configuration Overview

The following requirements must be met to allow zone transfers on the AXS Guard appliance:

  1. Zone transfers must be enabled.

  2. The AXS Guard firewall must be specifically configured to allow zone transfers.

  3. DNS servers which are allowed to perform zone transfers must be configured in the primary zones.

(1) Enabling Zone Transfers:

  1. Navigate to Network > DNS > Public DNS > Zone Transfers.

  2. Enter the public IP address(es) of the AXS Guard DNS server.

  3. Update your configuration.

    image

Field Description

IP address to listen on for zone transfers

Enter the AXS Guard Internet IP address(es) that should accept zone transfer requests. Note that connections to TCP port 53 must be allowed by the firewall.

(2) Allowing Zone Transfers in the Firewall:

  1. Go to Firewall > Policies > Static.

  2. Add the int-dns-tcp firewall rule to the stat-int firewall policy to allow zone transfers.

  3. Update your configuration.

    Adding the int-dns-tcp firewall rule to allow DNS zone transfers

(3) Add IP(s) of DNS servers allowed to perform zone transfers:

  1. Go to Network > DNS > Public DNS > Primary Zones.

  2. Select the zone from which you want to allow zone transfers.

  3. Add the IP address(es) of the server(s) that are allowed to perform zone transfers.

    image

Checking your configuration

To test DNS zone transfers, use the following command:

dig axfr domain_to_check @AXS_GUARD_Public_IP

Replace domain_to_check with the domain name you want to test and AXS_GUARD_Public_IP with the appropriate IP address.

Example:

~$ dig axfr testdomain.com @192.168.100.226

; <<>> DiG 9.18.28-0ubuntu0.22.04.1-Ubuntu <<>> axfr testdomain.com @192.168.100.226
;; global options: +cmd
testdomain.com.     86400   IN  SOA ns.testdomain.com. admin.testdomain.com. 2024080901 3600 1200 2419200 7200
testdomain.com.     86400   IN  NS  ns.testdomain.com.
testdomain.com.     86400   IN  SOA ns.testdomain.com. admin.testdomain.com. 2024080901 3600 1200 2419200 7200
;; Query time: 0 msec
;; SERVER: 192.168.100.226#53(192.168.100.226) (TCP)
;; WHEN: Fri Aug 09 08:31:42 CEST 2024
;; XFR size: 3 records (messages 3, bytes 255)

Primary Forward Lookup Zones

About

A DNS zone is any distinct, contiguous portion of the domain name space in the Domain Name System (DNS) for which administrative responsibility has been delegated to a single manager. The domain name space of the Internet is organized into a hierarchical layout of subdomains below the DNS root domain.

Two types of zones are supported by the AXS Guard DNS server:

  • Primary Zones: Zones for which a master authoritative copy of data is held in persistent local storage by the AXS Guard DNS server.

  • Secondary Zones: Zones for which an authoritative read-only copy of data is hosted by another DNS server.

Adding Primary Forward Lookup Zones

  1. Navigate to Network > DNS > Public DNS > Primary Zones.

  2. Click on Add New.

  3. Enter and edit the records by navigating through the tabs as explained in the following sections and tables.

  4. Save your configuration.

    Adding a Forward Lookup Zone

Info

Consult the RFCs for detailed information about a particular DNS record.

DNS Record Case Sensitivity

To ensure consistency and avoid potential issues with DNS record processing, it is strongly recommended that all DNS labels and record types be entered in lowercase characters. While DNS labels are case-insensitive, maintaining a lowercase convention helps prevent confusion and ensures uniformity across different systems and tools. Please ensure that all DNS entries follow this convention unless explicitly stated otherwise.

Shared Zone Settings

The following parameters are shared by all records of a given zone.

Parameter

Description

Domain

The domain for which DNS records must be created, e.g. yourdomain.com

Enabled

Check to enable the zone.

Type of the zone

  • Forward: A forward lookup zone is the most common type of zone. DNS clients can use this zone to obtain such information as IP addresses that correspond to DNS domain names or services that are stored in the zone.

  • Reverse: A reverse lookup zone provides mapping from IP addresses back to DNS domain names.

Default TTL

The default Time To Live (TTL) for the zone, expressed in seconds. The Time To Live determines how long a record can be retained in the DNS cache. When the TTL expires, nameservers must discard the cached data and query the authoritative nameserver for the latest record updates, if any. The TTL can be superseded for all DNS records, except the SOA record.

Secondary Name Servers for this Domain

The secondary name servers used by the specified domain. The specified name servers get their zone data from the AXS GUARD DNS server. Note that zone transfers must be allowed and configured under Network > DNS > Public DNS > General.

Supported RR Types

Record Type Description

SOA

Defined per RFC 1035. The State of Authority record (SOA) defines global parameters for the zone or domain, such as who is the person responsible for the domain and some address information. Only one SOA record is allowed per zone.

NS

Defined per RFC 1035. An NS record declares that a given zone is served by a given name server. Every NS record is either a delegation record or an authority Record. If the name of the NS record is the name of the zone it appears in, it is an authority record. If the name of the NS record is that of a descendant zone, then it is a delegation record.

A

The A record is defined per RFC 1035. An A Record contains the IP address of a Fully Qualified Domain Name.

CNAME

The CNAME Record is defined per RFC 1035. A CNAME Record or Canonical Name Record is a type of resource record in the Domain Name System (DNS) that specifies that the FQDN is an alias of another, canonical FQDN. CNAME records are often used when running multiple services on a single host (like an FTP and a webserver; each running on different ports). Each service can then have its own name in DNS (like ftp.example.com. and www.example.com.), pointing to the same IP address. Network administrators also use CNAME records to host web content of different sites residing on the same physical host.

MX

The MX Record is defined per RFC 1035. An MX record or Mail Exchanger record is a type of resource record in the Domain Name System (DNS) that specifies where e-mail must be sent for a given domain. Each MX record contains a priority and a host name. The priority indicates to which server e-mail must be sent first.

PTR

The PTR Record is defined per RFC 1035. A DNS Pointer Resource Record is used in in-addr.arpa records for the translation of addresses to names. PTR Records should always refer to the official (canonical) names and not the aliases.

TXT

A TXT (text) record is used to hold some text information and is defined per RFC 1035. You can put virtually any free text you want in a TXT record. This record more often carries machine-readable data, such as specified by RFC 1464.

SPF

The SPF record is in fact a TXT record. SPF was invented to enable the validation of legitimate e-mail senders of a domain and is now an IETF standard (RFC 4408).

SRV

SRV Records extend DNS functionality to enable location of services outside of the standard record types supported in DNS. Various protocols such as SIP and XMPP use SRV records to allow discovery of the service endpoint for a particular domain. The SRV record is defined in RFC 2782.

SOA Record Settings

SOA Record Options

Options

Description

Primary Name Server

The hostname of the primary nameserver for the given domain, e.g. ns1. The domain is automatically appended.

Domain Contact E-mail Address

The e-mail address of the domain administrator.

Type of Serial

This number is incremented each time a DNS record is updated. It allows secondary nameservers or a DNS cache to detect if a given DNS record is expired. Select the desired type or leave as is.

  • RFC 1912

  • Seconds since Jan 1st 1970

  • Custom

Refresh

The SOA record of the primary server is checked every "refresh" time by the secondary servers; if it has changed, a zone transfer is done (RFC 1537).

Retry

If a secondary server cannot reach the primary server, it tries it again every "retry" time (RFC 1537).

Expiry

If for "expire" time 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 (RFC 1537).

Minimum

The default TTL value for all records in the zone; a different TTL value may be given explicitly in a record when necessary (RFC 1537).

NS Record Settings

Important

Use only to delegate sub-names of your own domain name (such as subdomain.yourdomain.com) to other DNS servers.

NS Record Options

Option Description

Domain Name

The name of a subdomain, e.g. sales. The domain is automatically appended to the name you enter, e.g. if your domain is mydomain.com and you enter the domain name sales, an NS record will be created for sales.mydomain.com.

Name Server

The host name of the name server. A corresponding A record must exist.

TTL

Standard DNS meaning (RFC 1035).

A Record Settings

A Record Options

S

Options

Description

Domain Name

Enter the host name only, e.g. myhost. The domain name is automatically appended when the record is created, e.g. myhost.mydomain.com

IP address

The IP address of the corresponding host.

Active when

Select the appropriate option to provide load balancing or fault tolerance (failover).

  • Active when = Always: Provides load balancing if another A record exists, i.e. an A record with a different IP pointing to the same FQDN. At least two A records must exist to allow load balancing, failover or round robin.

  • Active when = Device ethx down: The DNS server will only return the IP address in this record when ethx is down, to ensure the continuity of service(s) normally provided by ethx. Ensure to enter a TTL that is low enough to avoid DNS caching problems.

  • Active when = Device ethx up: The DNS server will always return the IP address of device ethx, unless it is down. This option does not provide load balancing. Failover is only possible if another A record, pointing to an alternate network device, is present. Ensure to enter a TTL that is low enough to avoid DNS caching problems.

TTL

Standard DNS meaning (RFC 1035).

CNAME Record Settings

Important

  • CNAME records that point to other CNAME records must be avoided, because this allows to create infinite CNAME loops and other error conditions.

  • Other record types, such as NS, MX, PTR, etc. must never point to a CNAME (see RFC 1912).

Example 1: CNAME Loop

foo.example.com: CNAME = bar.example.com.

bar.example.com: CNAME = foo.example.com.

Example 2: Other constructs that must be avoided

foo.example.com: CNAME = host.example.com.

host.example.com: A = 192.0.2.1

example.com: MX = foo.example.com.

CNAME Record Options

Options Description

Domain Name

Enter the name only, e.g. alias. The domain is automatically appended to the entered name, e.g. alias.mydomain.com.

Target Domain

The actual host the alias is pointing to, e.g. real. The domain is automatically appended, e.g. real.mydomain.com

TTL

Standard DNS meaning (RFC 1035).

MX Record Settings

MX Record Options

Options Description

Domain Name

The prefix of the domain for which the mail server is authoritative. E.g. if you enter subdomain in this field and mydomain.com in the domain field, the mail server in this MX record will be authoritative for subdomain.mydomain.com. Leave this field empty if you want to enter a mail server record for your top-level domain (which is provided in the domain field). Note that an A record must be created separately for each MX record.

Priority

The lower this value, the higher the priority and vice versa, e.g. use 10 for a high priority and 20 for a lower priority.

Mail Server

Enter the Unqualified Domain Name of the mail server as entered in the A record, e.g. mail. The domain is automatically appended.

TTL

Standard DNS meaning (RFC 1035).

Example of priorities in MX records

$ dig mx gmail.com @10.32.64.1

; <<>> DiG 9.7.3 <<>> mx gmail.com @10.32.64.1
;; global options: +cmd
;; Got answer:
;; >>HEADER<<- opcode: QUERY, status: NOERROR, id: 4172
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;gmail.com.                     IN      MX

;; ANSWER SECTION:
gmail.com.              3594    IN      MX      10 alt1.gmail-smtp-in.l.google.com.
gmail.com.              3594    IN      MX      5 gmail-smtp-in.l.google.com.
gmail.com.              3594    IN      MX      30 alt3.gmail-smtp-in.l.google.com.
gmail.com.              3594    IN      MX      20 alt2.gmail-smtp-in.l.google.com.
gmail.com.              3594    IN      MX      40 alt4.gmail-smtp-in.l.google.com.

;; Query time: 0 msec
;; SERVER: 10.32.64.1#53(10.32.64.1)
;; WHEN: Thu Oct 20 12:03:11 2011
;; MSG SIZE  rcvd: 150

SRV Record Settings

SRV Record Options

Options

Description

Service Name

The symbolic name of the desired service, as defined in Assigned Numbers STD 2 or locally. An underscore (_) is prepended to the service identifier to avoid collisions with DNS labels that occur in nature.

Protocol

The symbolic name of the desired protocol, with an underscore (_) prepended to prevent collisions with DNS labels that occur in nature. _TCP and _UDP are at present the most useful values for this field, though any name defined by Assigned Numbers or locally may be used (as for Service). The Protocol is case insensitive.

Port

TCP or UDP port on which the service is to be found.

Domain Name

The domain this RR refers to. The SRV RR is unique in that the name one searches for is not this name.

TTL

Standard DNS meaning (RFC 1035).

Priority

The priority of this target host. A client MUST attempt to contact the target host with the lowest-numbered priority it can reach; target hosts with the same priority SHOULD be tried in an order defined by the weight field. The range is 0-65535. This is a 16-bit unsigned integer in network byte order.

Weight

A server selection mechanism. The weight field specifies a relative weight for entries with the same priority. Larger weights SHOULD be given a proportionately higher probability of being selected. The range of this number is 0-65535. This is a 16-bit unsigned integer in network byte order. Domain administrators SHOULD use Weight 0 when there isn’t any server selection to do, to make the RR easier to read for humans (less noisy). In the presence of records containing weights greater than 0, records with weight 0 should have a very small chance of being selected.

Target Domain

The domain name of the target host. There MUST be one or more address records for this name, the name MUST NOT be an alias (in the sense of RFC 1034 or RFC 2181). Implementors are urged, but not required, to return the address record(s) in the Additional Data section. Unless and until permitted by future standards action, name compression is not to be used for this field. A Target of "." means that the service is decidedly not available at this domain.

SPF Record Settings

About

The purpose of SPF records is to prevent spammers from sending messages with forged "From" addresses to your domain and is now an IETF standard (RFC 4408). The SPF verification flow is explained and illustrated in the AXS Guard e-mail relay how to. Reference material is available on: www.openspf.org.

SPF Record Options

Options

Description

Domain Name

Enter the host name only, e.g. mx. The domain name is automatically appended when the record is created, e.g. mx.mydomain.com.

Allow from A / MX / PTR Record

The A / MX / PTR record(s) of the given domain is / are tested by the SPF-protected recipient.

A / MX / PTR Records of other domains

Allows verification of the A / MX / PTR record(s) of other domains than the one specified in the domain field. For example, if you wish to allow users to send e-mail with their skynet.be address through your mail server without the risk of being rejected by an SPF-protected recipient, add the skynet.be domain to your SPF record.

Allow from Networks

The IPv4 network range which is allowed to send e-mail for the given domain. Use the CIDR notation. If no range is provided, /32 is automatically assumed.

Include SPF Records of domains

The specified domain is searched for a match. If the lookup does not return a match or an error, processing proceeds to the next directive. If the domain does not have a valid SPF record, the result is a permanent error. Some mail receivers will reject based on a PermError.

Fail from other servers

Specifies the intended action when mail is sent from servers that are not authorized to send mail for the given domain.

  • Soft: The SPF record has designated the sending host as not being allowed to send messages for the given domain. Messages originating from this host are marked (e.g. with a spam score).

  • Hard: The SPF record has designated the host as not being allowed to send messages for the given domain. E-mails originating from this host are rejected.

  • No: The SPF record explicitly specifies that nothing can be said about the sending host’s validity. E-mails originating from this host are accepted.

TTL

Standard DNS meaning (RFC 1035).

Important

If at all possible, you should avoid using the PTR mechanism in your SPF record, because it will result in a larger number of expensive DNS lookups. Furthermore, PTR records may be forged.

TXT Record Settings

TXT Record Options

Options

Description

Domain Name

Enter the host name only, e.g. myhost. The domain name is automatically appended when the record is created, e.g. myhost.mydomain.com.

Text

A TXT record can contain any text value, depending on what it’s being used for (also see RFC 1464). For example, Google uses a TXT record to verify that you own the domain you want to use with their enterprise services. Specifically, they ask you to enter a TXT record with the value google-site-verification=rXOxyZounnR1EbUSIQ.... They then query your domain to see if the TXT record is there. If it is, they know you have access to the domain’s DNS settings and must therefore own the domain.

TTL

Standard DNS meaning (RFC 1035)

Primary Reverse Lookup Zones

Things to consider when setting up Reverse DNS

A know problem among system administrators is that they have DNS servers that work fine for their forward lookup zones, but when they add reverse DNS records to their DNS server(s), they don’t seem to work. The problem is most likely that their ISP hasn’t been properly informed and doesn’t know which DNS servers handle reverse DNS queries for their domain. As a result, the DNS servers of the ISP don’t propagate this information to the Internet root servers and nobody will even get to their DNS servers when executing a reverse DNS lookup. It is therefore critical that administrators inform their ISP when planning to add reverse DNS entries for the domain(s) they administer.

Important

Per RFC 1912, all Internet hosts should have a reverse DNS record. Mail servers without a reverse DNS record will have a hard time getting mail to large ISPs.

Myth

If you have added a reverse DNS entry listed to your DNS server, you have reverse DNS properly set up.

Fact

This is often not the case. You need two things in order to properly setup reverse DNS:

  • The reverse DNS entries must be properly added to your DNS servers (or your ISP’s DNS server) and

  • Your ISP or bandwidth provider must set up the reverse DNS on their end, so that DNS resolvers around the world know that your DNS servers are the ones to query when looking up your host names.

Example: Reverse DNS lookup

Assume you are looking for the host name that has the following IP: 192.0.2.25.

The DNS resolver reverses the provided IP address, and adds .in-addr.arpa to it, resulting in 25.2.0.192.in-addr.arpa.

The DNS resolver then starts looking up the PTR record for 25.2.0.192.in-addr.arpa. During this process, the DNS resolver asks the root servers for the PTR record that matches 25.2.0.192.in-addr.arpa.

The root servers refer the DNS resolver to the DNS servers that are in charge of the Class A range, i.e. 192.in-addr.arpa, which covers all IP addresses that start with the 192 prefix. In almost any case, the root servers will refer the DNS resolver to a "RIR" ("Regional Internet Registry"). They are the organizations that allocate IPs. In general, ARIN handles North American IPs, APNIC handles Asian-Pacific IPs, and RIPE handles European IPs. In this case, the DNS resolver will ask the ARIN DNS servers for the PTR record that matches 25.2.0.192.in-addr.arpa.

In turn, the ARIN DNS servers will refer the DNS resolver to the DNS servers of the organization that was originally given the IP range. These are usually the DNS servers of your ISP or bandwidth provider.

The DNS resolver will ask the ISP’s DNS servers what PTR record matches 25.0.2.192.in-addr.arpa.

The ISP’s DNS servers will refer the DNS resolver to the organization’s DNS servers (only if that organization has it’s own DNS servers).

The DNS resolver will then ask the organization’s DNS servers what PTR record matches 25.0.2.192.in-addr.arpa.

Finally, the organization’s DNS servers respond with the name of the server, e.g. host.example.com.

Adding Primary Reverse Lookup Zones

  1. Navigate to Network > DNS > Public DNS > Primary Zones.

  2. Click on Add New.

  3. Enter and edit the records by navigating through the tabs as explained in the following subsections and tables.

  4. Save your configuration.

    Adding a Reverse Lookup Zone

Info

Consult the RFCs for detailed information about a particular DNS record.

DNS Record Case Sensitivity

To ensure consistency and avoid potential issues with DNS record processing, it is strongly recommended that all DNS labels and record types be entered in lowercase characters. While DNS labels are case-insensitive, maintaining a lowercase convention helps prevent confusion and ensures uniformity across different systems and tools. Please ensure that all DNS entries follow this convention unless explicitly stated otherwise.

Shared Zone Settings

The following parameters are shared by all records of a given zone.

Parameter

Description

Domain

The domain for which DNS records must be created, e.g. yourdomain.com

Enabled

Check to enable the zone.

Type of the zone

  • Forward: A forward lookup zone is the most common type of zone. DNS clients can use this zone to obtain such information as IP addresses that correspond to DNS domain names or services that are stored in the zone.

  • Reverse: A reverse lookup zone provides mapping from IP addresses back to DNS domain names.

Default TTL

The default Time To Live (TTL) for the zone, expressed in seconds. The Time To Live determines how long a record can be retained in the DNS cache. When the TTL expires, nameservers must discard the cached data and query the authoritative nameserver for the latest record updates, if any. The TTL can be superseded for all DNS records, except the SOA record.

Secondary Name Servers for this Domain

The secondary name servers used by the specified domain. The specified name servers get their zone data from the AXS GUARD DNS server. Note that zone transfers must be allowed and configured under Network > DNS > Public DNS > General.

NS Record Settings

Important

Use only to delegate sub-names of your own domain name (such as subdomain.yourdomain.com) to other DNS servers.

NS Record Options

Option Description

Domain Name

The name of a subdomain, e.g. sales. The domain is automatically appended to the name you enter, e.g. if your domain is mydomain.com and you enter the domain name sales, an NS record will be created for sales.mydomain.com.

Name Server

The host name of the name server. A corresponding A record must exist.

TTL

Standard DNS meaning (RFC 1035).

PTR Record Settings

Creating a PTR Record

Option Description

IP Address

The remaining digits of the IP specified in the domain field of the zone. For example, if the domain is 83.0.195.in-addr.arpa and you wish to add a PTR record for 195.0.83.2, enter 2 in this field.

Domain Name

The host name that corresponds to the IP.

TTL

Standard DNS meaning (RFC 1035).

Configuring Secondary Zones

  1. Log on to the AXS Guard appliance.

  2. Navigate to Network > DNS > Public DNS > Secondary Zones.

  3. Click + to add a secondary zone.

  4. Enter the options as explained in the table below.

  5. Update your configuration.

    Adding Secondary DNS Zones

Option / Parameter Description

Domain

Enter the domain name.

Enabled

Check to enable / uncheck to disable.

Primary Name Server for this Domain

Enter the IP address of the primary nameserver for the specified domain. Note that DNS zone transfers must be enabled on the target server.

Viewing your DNS Records per Domain

  1. Log in to the AXS Guard appliance.

  2. Go to Network > DNS > Public DNS > Primary Zones.

  3. Click on the + sign to the left of the appropriate domain.

    DNS Zone Configuration Overview

DNS Test Tools

There are several (free) tools to test your DNS records on the AXS Guard. Such tools include, but are not limited to:

  • dig (used in this document)

  • nslookup

  • host

Info

When testing the AXS Guard’s Public DNS server, use its external IP and not one of its internal IPs. The AXS Guard also has a separate, internal DNS server, which is explained in the AXS Guard System Administration How To. This manual is accessible via the Documentation button in the Administrator Tool.

Configuration Examples

Overview

In this section, we provide some practical, step-by-step examples to get you familiarized with the AXS Guard Public DNS configuration.

To configure the AXS Guard DNS server, you are required to log on to the appliance via an Internet browser. This procedure is explained in the AXS Guard System Administration How To, which is accessible via the Documentation button.

Creating a Round Robin A Record

In this example, we explain how to set up round robin DNS for the server rr.mydomain.com with a secondary nameserver.

  1. Navigate to Network > DNS > Public DNS.

  2. Click on Add New.

  3. Enter the domain name, e.g. mydomain.com.

  4. Leave the other settings as they are (defaults).

  5. Select the A Records tab.

  6. Enter the Unqualified Domain Name of the server in the Domain Name field, e.g. rr.

  7. Enter the primary IP address to which rr.mydomain.com should point.

  8. Leave the other settings unchanged.

  9. Click on Add.

    A Record with Round Robin Support

  10. Repeat steps 6 to 9 for the alternate IP address of rr.mydomain.com.

  11. Click on Save when finished.

Result

When queried, the AXS Guard will answer with 1.2.3.4 and 1.2.3.5 alternatively.

$ dig rr.mydomain.com @10.132.8.115

; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> rr.mydomain.com @10.132.8.115
;; global options: +cmd
;; Got answer:
;; >>HEADER<<- opcode: QUERY, status: NOERROR, id: 9350
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;rr.mydomain.com.               IN      A

;; ANSWER SECTION:
rr.mydomain.com.        86400   IN      A       1.2.3.4
rr.mydomain.com.        86400   IN      A       1.2.3.5

;; AUTHORITY SECTION:
mydomain.com.           86400   IN      NS      ns.mydomain.com.

;; Query time: 12 msec
;; SERVER: 10.132.8.115#53(10.132.8.115)
;; WHEN: Mon Apr 11 08:10:49 CEST 2016
;; MSG SIZE  rcvd: 82

Creating a Round Robin MX Record

In this example, we explain how to set up round robin DNS for two mail servers in mydomain.com. An equal priority must be specified for the two mail servers in the MX record, otherwise round robin will not work.

  1. Navigate to Network > DNS > Public DNS.

  2. Click on Add New.

  3. Enter the domain name, e.g. mydomain.com.

  4. Leave the other settings as they are (defaults).

  5. Enter the IP address of the secondary DNS server (if applicable).

  6. Select the MX Records tab.

  7. Leave the domain name empty.

  8. Set the priority to 10.

  9. Enter the Unqualified Domain Name of an authoritative mail server for the domain, e.g. mail5. An A record must exist for this server.

  10. Click on Add.

    MX Record with Round Robin Support

  11. Repeat the steps for the alternate mail server (e.g. mail6.mydomain.com). Make sure to set the priority to the same value as used for the first mail server (10 in this example).

  12. Click on Save.

Result

When queried for the MX record of mydomain.com, the AXS Guard will answer with mail5.mydomain.com and mail6.domain.com alternatively (according to the values used in this example).

$ dig mx mydomain.com @10.132.8.115

; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> mx mydomain.com @10.132.8.115
;; global options: +cmd
;; Got answer:
;; >>HEADER<<- opcode: QUERY, status: NOERROR, id: 55056
;; flags: qr aa rd; QUERY: 1, ANSWER: 2, AUTHORITY: 1, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;mydomain.com.                  IN      MX

;; ANSWER SECTION:
mydomain.com.           86400   IN      MX      10 mail5.mydomain.com.
mydomain.com.           86400   IN      MX      10 mail6.mydomain.com.

;; AUTHORITY SECTION:
mydomain.com.           86400   IN      NS      ns.mydomain.com.

;; ADDITIONAL SECTION:
mail5.mydomain.com.     86400   IN      A       1.2.3.4
mail6.mydomain.com.     86400   IN      A       1.2.3.4

;; Query time: 10 msec
;; SERVER: 10.132.8.115#53(10.132.8.115)
;; WHEN: Mon Apr 11 08:23:33 CEST 2016
;; MSG SIZE  rcvd: 123

Creating a CNAME Record

  1. Navigate to Network > DNS > Public DNS.

  2. Click on Add New.

  3. Enter the domain name, e.g. mydomain.com.

  4. Leave the other settings as they are (defaults).

  5. Enter the IP address of the secondary DNS server (if applicable).

  6. Select the CNAME Records tab.

  7. Enter the Unqualified Domain Name of the domain alias.

  8. Enter the Unqualified Domain Name of the server the alias needs to point to (if the server is located in the same domain. If not, enter the FQDN of the server the alias needs to point to).

  9. Click on Add.

  10. Click on Save.

    Creating a CNAME Record

Result

When queried for alias.mydomain.com, the AXS Guard will answer that it is an alias for real.mydomain.com.

$ dig alias.mydomain.com CNAME @10.132.8.115

; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> alias.mydomain.com CNAME @10.132.8.115
;; global options: +cmd
;; Got answer:
;; >>HEADER<<- opcode: QUERY, status: NOERROR, id: 13277
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;alias.mydomain.com.            IN      CNAME

;; ANSWER SECTION:
alias.mydomain.com.     86400   IN      CNAME   real.mydomain.com.

;; AUTHORITY SECTION:
mydomain.com.           86400   IN      NS      ns.mydomain.com.

;; Query time: 9 msec
;; SERVER: 10.132.8.115#53(10.132.8.115)
;; WHEN: Mon Apr 11 08:59:44 CEST 2016
;; MSG SIZE  rcvd: 72

Creating a PTR Record

The idea is to obtain the FQDN corresponding to IP 195.0.83.2/24 when interrogating the AXS Guard Public DNS server. According to our example, the answer is www.mydomain.com.

  1. Navigate to Network > DNS > Public DNS.

  2. Click on Add New.

  3. Enter the first 3 parts of the IP address in reversed order followed by in-addr.arpa, e.g. 83.0.195.in-addr.arpa.

  4. Select Reverse as the zone type.

  5. Enter the IP address of the secondary nameserver for this domain (if applicable).

  6. Select the PTR Records tab.

  7. Enter the last part of the IP address, e.g. 2.

  8. Enter the FQDN to which the IP address should resolve.

  9. Click on Save.

    Creating a PTR Record

Result

When queried for 195.0.83.2, the AXS Guard will answer that this IP address belongs to www.mydomain.com.

$ dig ptr 2.83.0.195.in-addr.arpa @10.132.8.115

; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> ptr 2.83.0.195.in-addr.arpa @10.132.8.115
;; global options: +cmd
;; Got answer:
;; >>HEADER<<- opcode: QUERY, status: NOERROR, id: 43918
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;2.83.0.195.in-addr.arpa.       IN      PTR

;; ANSWER SECTION:
2.83.0.195.in-addr.arpa. 3600   IN      PTR     www.mydomain.com.

;; AUTHORITY SECTION:
83.0.195.in-addr.arpa.  86400   IN      NS      ns.83.0.195.in-addr.arpa.

;; Query time: 9 msec
;; SERVER: 10.132.8.115#53(10.132.8.115)
;; WHEN: Mon Apr 11 09:17:43 CEST 2016
;; MSG SIZE  rcvd: 88

Creating an A Wildcard Record

In this example, we explain how to create a wilcard A record. The idea is to resolve any nonexistent hosts to which an existing domain suffix is added. The idea is to return the same IP address each time such a qeury is received. The domain used in our example is mydomain.com.

  1. Navigate to Network > DNS > Public DNS.

  2. Click on Add New.

  3. Enter the domain name, e.g. mydomain.com.

  4. Leave the other settings as they are (defaults).

  5. Enter the IP address of the secondary DNS server for the domain (if applicable).

  6. Select the A record tab.

  7. Enter * as the domain name.

  8. Enter the IP address the wildcard should point to, e.g. 1.2.3.4

  9. Click on Add.

  10. Click on Save.

    Creating a Wildcard Record

Result

When queried for somerandomtext.mydomain.com, the AXS Guard will answer that this hostname resolves to IP 1.2.3.4.

$ dig somerandomtext.mydomain.com @10.132.8.115

; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> somerandomtext.mydomain.com @10.132.8.115
;; global options: +cmd
;; Got answer:
;; >>HEADER<<- opcode: QUERY, status: NOERROR, id: 57587
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;somerandomtext.mydomain.com.   IN      A

;; ANSWER SECTION:
somerandomtext.mydomain.com. 86400 IN   A       1.2.3.4

;; AUTHORITY SECTION:
mydomain.com.           86400   IN      NS      ns.mydomain.com.

;; Query time: 11 msec
;; SERVER: 10.132.8.115#53(10.132.8.115)
;; WHEN: Mon Apr 11 09:24:16 CEST 2016
;; MSG SIZE  rcvd: 78

Creating an SPF Record

In this example, we explain how to create an SPF record for one of your domains. The idea is to allow verification of the MX record of a domain for which your AXS Guard DNS server is authoritative.

  1. Navigate to Network > DNS > Public DNS > Primary Zones.

  2. Select the domain for which you want to create an SPF record, by clicking on the domain name in the table.

  3. Select the SPF Records tab .

  4. Check the Allow from MX Records option.

  5. Leave the Fail from other servers option unchanged

  6. Click on Add. The Allow from MX Records option will be unchecked after this, as shown in the image below. Details about the generated SPF record string is available on http://www.openspf.com

  7. Click on Update.

    Creating an SPF Record

Result

When an e-mail is sent from your domain and the receiving MTA has SPF checking capabilities, an SPF record query will indicate that the IP address(es) of the sending MTA are valid and authorized to send e-mail for your domain. If the IP address of the sending MTA is not authorized to send e-mail for your domain, the receiving MTA will mark the message, e.g. tag it with a spam score (also see SPF Record Settings).

$ dig @10.132.8.115 mydomain.com txt

; <<>> DiG 9.9.5-3ubuntu0.8-Ubuntu <<>> @10.132.8.115 mydomain.com txt
; (1 server found)
;; global options: +cmd
;; Got answer:
;; >>HEADER<<- opcode: QUERY, status: NOERROR, id: 26691
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;mydomain.com.                  IN      TXT

;; ANSWER SECTION:
mydomain.com.           86400   IN      TXT     "v=spf1 mx ~all"

;; AUTHORITY SECTION:
mydomain.com.           86400   IN      NS      ns.mydomain.com.

;; ADDITIONAL SECTION:
ns.mydomain.com.        86400   IN      A       4.3.2.1

;; Query time: 9 msec
;; SERVER: 10.132.8.115#53(10.132.8.115)
;; WHEN: Mon Apr 11 09:31:05 CEST 2016
;; MSG SIZE  rcvd: 90

Creating an SRV Record

In this example, we explain how to create an SRV record for one of your domains.

  1. Navigate to Network > DNS > Public DNS > Primary Zones.

  2. Select the domain for which you want to create an SRV record by clicking on the domain name in the table.

  3. Select the SRV Records tab.

  4. Enter the parameters as shown in the illustration below.

  5. Click on Add when finished

  6. Click on Update.

    Creating an SRV Record

dig query

$ dig -t SRV _sip._tcp.autodiscover.example.com @192.168.0.170

; <<>> DiG 9.9.5-3ubuntu0.17-Ubuntu <<>> -t SRV _sip._tcp.autodiscover.example.com @192.168.0.170
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63679
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;_sip._tcp.autodiscover.example.com. IN SRV

;; ANSWER SECTION:
_sip._tcp.autodiscover.example.com. 3600 IN SRV 5 5 80 autodiscover.example.com.

;; AUTHORITY SECTION:
example.com.            86400   IN      NS      ns.example.com.

;; ADDITIONAL SECTION:
ns.example.com.         3600    IN      A       192.168.0.170

;; Query time: 6 msec
;; SERVER: 192.168.0.170#53(192.168.0.170)
;; WHEN: Tue Jun 26 10:24:30 CEST 2018
;; MSG SIZE  rcvd: 129

Troubleshooting

Testing your DNS Records

You can test the entries made on your AXS Guard DNS server with free online tools, e.g. http://www.howismydns.com You can also use freely available DNS tools, such as dig, nslookup, host, etc. Make sure to use the AXS Guard’s public IP address when testing the Public DNS service.

The example below shows how to query your DNS server to find an MX record for a given domain with the dig command on a Linux machine.

$ dig mx gmail.com @10.32.64.1

; <<>> DiG 9.7.3 <<>> mx gmail.com @10.32.64.1
;; global options: +cmd
;; Got answer:
;; >>HEADER<<- opcode: QUERY, status: NOERROR, id: 3361
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;gmail.com.                     IN      MX

;; ANSWER SECTION:
gmail.com.              3600    IN      MX      5 gmail-smtp-in.l.google.com.
gmail.com.              3600    IN      MX      10 alt1.gmail-smtp-in.l.google.com.
gmail.com.              3600    IN      MX      30 alt3.gmail-smtp-in.l.google.com.
gmail.com.              3600    IN      MX      40 alt4.gmail-smtp-in.l.google.com.
gmail.com.              3600    IN      MX      20 alt2.gmail-smtp-in.l.google.com.

;; Query time: 150 msec
;; SERVER: 10.32.64.1#53(10.32.64.1)
;; WHEN: Thu Oct 20 15:46:40 2011
;; MSG SIZE  rcvd: 150

I cannot query the AXS Guard public DNS server

Check the AXS Guard firewall settings.

DNS queries require UDP port 53 traffic to be allowed towards the AXS Guard For details about the AXS Guard firewall configuration, see the AXS Guard firewall how to, which can be accessed via the Documentation button in the administrator tool.

DNS zone transfers are failing

Check the AXS Guard firewall settings.

Zone transfers require TCP port 53 to be allowed towards the AXS Guard. For details about the AXS Guard firewall configuration, see the AXS Guard firewall How To, which can be accessed via the Documentation button in the administrator tool.

The created record does not work or returns an undesired response

When creating a DNS record for one of your domains, make sure to use the Unqualified Domain Name. For example, if your domain is mycompany.com and you want to create an MX record for that domain, e.g. mail.mycompany.com, you must enter mail rather than mail.mycompany.com. If you enter the FQDN (mail.mycompany.com) instead, mail.mycompany.com.mycompany.com will be returned in the response.

Support

If you encounter a problem

If you encounter a problem with AXS Guard, follow the steps below:

  1. Check the troubleshooting section of the feature-specific manual.

  2. Check the knowledge base on this site for information about special configurations.

  3. If no solution is available in any of the above sources, contact your AXS Guard vendor.

Contact Information

(+32) 15-504-400
support@axsguard.com