3.10. DNS

Home Prev	cOS Core 14.00.15 Administration Guide	Next

Overview

A DNS server can resolve a Fully Qualified Domain Name (FQDN) into the corresponding numeric IP address. FQDNs are unambiguous textual domain names which specify a node's unique position in the Internet's DNS tree hierarchy. FQDN resolution allows the actual physical IP address to change while the FQDN can stay the same.

A Uniform Resource Locator (URL) differs from an FQDN in that the URL includes the access protocol along with the FQDN. For example the protocol might be specified http//: for world wide web pages.

FQDNs can be used in many parts of a configuration where IP addresses are unknown or where it makes more sense to make use of DNS resolution instead of using static IP addresses.

DNS with cOS Core

To accomplish DNS resolution, cOS Core has a built-in DNS client that can be configured to make use of up to three IPv4 and/or IPv6 DNS servers. These are called the Primary Server, the Secondary Server and the Tertiary Server. For DNS to function, at least the one (the primary) server must be configured. It is recommended to have at least two servers (a primary and a secondary) defined so that there is always a backup server available.

Features Requiring DNS Resolution

Having at least one DNS server defined is vital for functioning of the following features in cOS Core:

Automatic time synchronization.
Access to an external certificate authority server for CA signed certificates.
UTM features that require access to external servers such as anti-virus and IDP.
FQDN Address object resolution.

Example 3.58. Configuring DNS Servers

In this example, cOS Core will be configured to use one primary and one secondary IPv4 DNS server, having IPv4 addresses 10.0.0.1 and 10.0.0.2 respectively.

Command-Line Interface

Device:/> set DNS DNSServer1=10.0.0.1 DNSServer2=10.0.0.2

InControl

Follow similar steps to those used for the Web Interface below.

Web Interface

Go to: System > Device > DNS
Enter the following:
- Primary Server: 10.0.0.1
- Secondary Server: 10.0.0.2
Click OK

Automatic DNS Address Assignment

DNS addresses can also be assigned by enabling DHCP (for IPv6) or DHCPv6 (for IPv6 addresses) for any interface that is connected to an external DHCP server. This is often used when accessing the Internet via an ISP and receiving all the required addresses from the ISP's DHCP server.

The DNS addresses that are received through DHCP on any interface will become the system wide cOS Core DNS servers if no static DNS addresses have already been configured. However, if static DNS addresses have been manually configured then any DNS server addresses received via DHCP on any interface will be ignored and the existing manually configured DNS addresses will not be affected.

Using DHCP for configuring DNS addresses is discussed further in Section 5.2, IPv4 DHCP Client and Section 5.6.1, DHCPv6 Client.

DNS Lookup and IP Rule Sets

In the case of DNS server requests being generated by cOS Core itself, no IP rule set entries need to be defined for the connection to succeed. This is because connections initiated by cOS Core are considered to be trusted. For example, this would be the case if cOS Core is accessing a CA server to establish the validity of a certificate and first needs to resolve the certificate's FQDN to an IP address.

Dynamic DNS and HTTP Poster Clients

A DNS feature offered by cOS Core is the ability to explicitly inform DNS servers when any of the external IP addresses of the firewall has changed. This is sometimes referred to as Dynamic DNS and is useful where the firewall has an external public address that can change.

Dynamic DNS can also be useful in IPsec VPN scenarios where both ends of the tunnel have dynamic IP addresses. If only one side of the tunnel has a dynamic address then the Auto Establish property of the IPsec Tunnel object can solve this problem.

In cOS Core an HTTP Poster client object can be configured to inform DNS servers of IP address changes.

Predefined Dynamic DNS Clients

A Dynamic DNS object is a predefined HTTP Poster client for specific servers. Under Network > Network Services in the Web Interface, a Dynamic DNS client for any of the following dynamic DNS servers can be defined:

duckdns.org
dyn.com
dyns.cx

The Generic HTTP Poster Client

In contrast to the predefined clients, the HTTP Poster object is is a generic dynamic DNS client for posting to any server. This object can also be found in the Web Interface under Network > Network Services.

The following should be noted about the generic HTTP Poster client:

Multiple HTTP Poster objects can be defined, each with a different URL and different optional settings.
The URL can specify HTTP or HTTPS as the protocol.
By default, an HTTP Poster object sends an HTTP GET request to the defined URL. Some servers require an HTTP POST and to achieve this the property use HTTP POST should be enabled. This is usually required when authentication parameters are being sent in the URL.
For the default GET request, the following optional parameter can be added:
```
			ip=$(<address-object>)
```
Here, <address-object> is a cOS Core address book object with a single IP address or simple IP range as its value. An example of using this parameter can be found in Example 3.59, “Creating an HTTP Poster Client”.
By default, HTTP Poster does not automatically send a server request after cOS Core reconfiguration. This behavior can be changed by enabling the property Always Repost.

There is one exception to the default behavior. A request is always sent if the reconfigure involves having a new local IP address on the interface that connects to the DNS server. In that case, cOS Core always waits a predefined period of 20 seconds before reposting following the reconfiguration.
The Repost Delay is the delay between the URL being periodically refetched from the server. Some servers may require a minimum period (for example, a month) between refetches in order to keep the URL active.

The default delay value is 1200 seconds (20 minutes) but this can be changed for HTTP Poster. However, note that all the predefined Dynamic DNS clients have a fixed repost delay which cannot be changed.

	Caution: High rates of server queries might cause problems
	Dynamic DNS services can be sensitive to repeated connection attempts over short periods of time and may blacklist source IP addresses that are sending excessive requests. It is therefore not advisable to query servers too frequently as they may cease to respond.

When to use the Predefined Dynamic DNS Clients

The difference between HTTP Poster and the predefined Dynamic DNS types is that HTTP Poster can be used to send to any URL. The named Dynamic DNS clients are a convenience that make it easy to correctly format the URL needed for a particular service. For example, the http:// URL for the dyndns.org service might be:

   myuid:mypwd@members.dyndns.org/nic/update?hostname=mydns.dyndns.org

This could be sent by using HTTP Poster. Alternatively, this URL could be automatically formatted by cOS Core by using the predefined DynDNS client.

Authenticating HTTPS Response Certificates

Both the generic HTTP Poster and the predefined Dynamic DNS objects have a Certificate property. This property can be set to a certificate that has been uploaded to cOS Core and this will be used with HTTPS to authenticate the certificate sent back from the server. The certificate sent back must be part of the chain of the certificate specified.

Valid HTTP Poster Reply Requirements

The following are the requirements for any replies sent back by the server to any HTTP poster:

The HTTP header must be valid with a response code of 200.
The body of the response must contain some text and cannot be empty. This text will be used in the status message.

HTTP Poster Failure

If cOS Core detects a HTTP Poster failure, it will continue to retry the operation at successively longer intervals. The initial interval is 60 seconds and this interval is multiplied by 2 for each successive retry. When the interval reaches 24 hours, it is not multiplied by 2 any longer but continues retrying until the operation is successful.

Failure Because of Non-Alphanumeric URL Characters

HTTP Poster failure can be caused by non-alphanumeric characters in the URL. This is solved by specifying such characters as hexadecimal. For example, use "%24" instead of the "$" character. This is also discussed in a Clavister Knowledge Base article at the following link:

https://kb.clavister.com/324735768

The httpposter Command

The HTTP Poster generates log messages indicating success or failure. The CLI console command httpposter can be used to troubleshoot problems by seeing what cOS Core is sending and what the servers are returning:

Device:/> httpposter

Forcing an HTTP Poster Repost

A repost for an individual server can be forced with the command:

Device:/> httpposter -repost=<index>

Where <index> is the position of the object in the list of posters. For example, to force a report of the second in the list:

Device:/> httpposter -repost=2

HTTP Posters Have Other Uses

HTTP Poster may be used for other purposes than dynamic DNS. Any requirement for cOS Core to routinely send an HTTP GET or POST message to a particular URL could be met using this feature.

Example 3.59. Creating an HTTP Poster Client

The following example adds an HTTP Poster object which will send a GET request to the IPv4 address 203.0.113.3. The value of the address object wan_ip will be added as a parameter.

Command-Line Interface

Device:/> add HTTPPoster URL=http://203.0.113.3/test.html?ip=$(wan_ip)

InControl

Follow similar steps to those used for the Web Interface below.

Web Interface

Go to: Network > Network Services > HTTP Poster > Add
In the URL field, enter the value: http://203.0.113.3/test.html?ip=$(wan_ip)
Click OK

Configuring Multicast DNS

Multicast DNS (mDNS) is a type of DNS service that is typically used on smaller private networks to locate a device or service by name, without the need for a central DNS server. Instead, clients send multicast mDNS requests to all members of a network and the received replies allow the client to determine the IP of the device or service being sought. The mDNS concept was originally developed by Apple under the name "Bonjour" and is now officially defined by RFC-6762. A typical application of mDNS might be locating a shared network printer by clients on the network.

The following are the key considerations when configuring cOS Core to allow traversal of mDNS packets:

Use transparent mode on the interfaces so that the Decrement TTL option can be disabled. The TTL of mDNS packets should not be changed by cOS Core and this is a way to do that.
Create two Multicast Policy entries in the IP rule set for UDP traffic so that mDNS packets are allowed to flow in both directions. The policy's Require IGMP option should be disabled.

Make sure that the relevant port numbers are allowed in the policy (for example, the Internet Printing Protocol uses port 631).

Using mDNS with cOS Core is discussed further in a Clavister Knowledge Base article at the following link:

https://kb.clavister.com/310004298

Forwarding DNS Queries from Internal Clients

cOS Core can be configured to forward DNS queries from clients on an internal network behind the firewall to public DNS servers on the Internet. Doing this is discussed in a Clavister Knowledge Base article at the following link:

https://kb.clavister.com/354849847