DNS

The DNS view contains the scaffolds to configure the rXg core services related to the domain name system.

The rXg integrates a dynamic DNS client that supports all of the major third party dynamic DNS services. Dynamic DNS is an essential part of deploying an rXg in an environment where the uplink address is dynamically assigned and may change.

Many of the rXg services (most notably, the forced browser redirect), require DNS resolution of a domain name to the IP address of the WAN uplink. If the IP address of the WAN uplink is configured via DHCP, it is critically important to reconfigure the DNS whenever the assigned IP address changes. The simplest way to accomplish this is to use the rXg dynamic DNS client.

The rXg also incorporates a fully featured DNS server. The operator can configure the rXg to be a primary, secondary or tertiary domain name server for any domain. Before using the DNS server features of the rXg, it is highly recommended that the administrative staff be familiar with the deployment and operation of the domain name system. Incorrect configuration may render the rXg inoperable. An excellent reference on the domain name system is DNS and BIND (ISBN 0596100574) by Cricket Lui and Paul Albitz.

To configure the rXg as a primary domain name server, the DNS glue records for the domain name must contain the IP address of an rXg uplink. To configure the rXg as a secondary name server, create a DNS zone specifying the primary name server in the master hostname field.

When using the rXg as a primary domain name server, proper DNS glue records must be in place. Most DNS registrars have a web application that enables glue record changes. Updates to glue records sometimes take days to propagate so it important to use a manually assigned static IP address for the rXg uplink.

With the DNS glue records in place, a new entry must be added to the DNS zone scaffold. Set the master hostname to the host name of the rXg and the hostmaster email to something appropriate. At a minimum, two entries must be added to the DNS records scaffold (the nameserver and address records for the rXg itself). Additional resource records may be added so that the rXg provides resolution of desired hostnames.

Dynamic DNS Clients

An entry in the Dynamic DNS scaffold enables the rXg to update third-party dynamic DNS services with the latest WAN IP address configuration. In most cases, a DNS record must be created on the third party dynamic DNS service before updates can be made by the rXg.

The name field is an arbitrary string descriptor used only for administrative identification. Choose a name that reflects the purpose of the record. This field has no bearing on the configuration or settings determined by this scaffold.

The protocol field determines the communication protocol that will be used to perform dynamic DNS updates. Most of the popular dynamic DNS services have developed their own proprietary protocols. In most cases, the protocol is synonymous with the service, making the choice obvious.

The login and password fields are the authentication credentials that are supplied to the dynamic DNS service when sending updates. These credentials must match those of the account at the third party service in order for updates to be authenticated and accepted.

The hosts field is a comma-delimited list specifying the DNS name(s) that are to be updated. Typically this will be the same DNS name that is specified in the domain name field of the device options scaffold.

The static and wildcard checkboxes modify the payload of the update message sent to the dynamic DNS service. Some services permit automated update of statically configured IP addresses. Usually there is a stipulation that the update frequency must be much lower than that of a dynamic IP. In addition, some services permit the use of wildcard DNS names so that a single entry can cover several hosts. If either kind of record is established on the third party dynamic DNS service, the appropriate checkbox must be set.

The protocol server field is an optional parameter that can be used to specify an alternate destination for dynamic DNS update messages. Since most dynamic DNS services use their own proprietary protocol, selecting a protocol usually determines the destination for the messages. This field enables the operator to override the default destination.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

The IP address sent to the dynamic DNS service in an update message is the uplink IP address of the default rXg route. In single uplink scenarios, this is the network address that is statically associated with the uplink or the dynamic address acquired by the uplink via DHCP. In multiple uplink scenarios, the choice of the default route is controlled by the priority setting of the uplink.

DNS Zones

An entry in the DNS zones scaffold defines a new domain that the rXg integrated DNS server will respond to.

The domain name field configures the domain that this record will enable responses to.

The master hostname must be set to the fully qualified domain name of the primary master nameserver for this domain. If the rXg is to be the primary master nameserver for the domain, an address record must be configured in the DNS records scaffold.

The hostmaster email field specifies the administrative email address that is reported by the DNS server.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

DNS Records

An entry in the DNS records scaffold creates a new record in a zone specified in the DNS zones scaffold.

The host is the host name for this record. The host name is the parameter that is matched when a DNS query is made.

The type field determines the DNS resource record type. The list of dns record types and their function is defined by a series of RFCs published by the IETF.

The dynamic data and data fields define the payload for the DNS resource record. The use of dynamic data and data are mutually exclusive. If a dynamic data field is chosen from the drop down, the response to a query matching the host specified in this record will be the IP address of the uplink specified by the drop down. If data is populated and no dynamic data field is specified, then the response will contain the static payload configured in the data field.

The zone field specifies the DNS zone that this record will be attached to. If "DNS Override" is selected, the rXg will resolve this specific record to the data listed, but all other requests for the same domain will be forwarded on for normal DNS lookup via upstream providers. This avoids having to maintain all records for a domain when attempting to override a single A record.

Domains may be "black-holed" by creating two CNAME DNS Override records, one for domain.com and one for *.domain.com, and setting the data field for both records to "." (no quotes).

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

A complete reference of DNS resource records is found in BIND 9 DNS Administration Reference Book (ISBN 0979034213) by Jeremy Reed.

DNS Server

Entries in the DNS Server scaffold define configuration profiles for the rXg integrated DNS server.

The active field enables an option set. Exactly one option set may be active at any time. Enabling a particular option set will automatically disable another existing active option set.

A properly configured DNS server takes part in a hierarchy of servers starting with the operator of the next hop network all the way to the root DNS servers. By default, the rXg is properly configured to forward requests to the next hop DNS servers. Clearing the request forwarding check box will force the rXg DNS server to make requests directly to the root. Avoid this configuration when possible.

The request forwarding order drop down menu determines the which DNS servers the rXg will query as the next hop. Dynamic servers are those that have been provided via WAN DHCP configuration. Static servers are those that have been manually configured by the operator using the DNS Servers scaffold of the WAN view of the rXg console. Choosing the dynamic,static option tells the rXg to query the dynamically assigned servers first and then the statically assigned servers. Choosing the static or dynamic options tells the rXg to limit queries to the selected set of servers. When multiple uplink control is deployed, the set of dynamic DNS servers is limited to those that are presented by the DHCP server of each pipe. Furthermore, the set of statically configured servers must be accessible via all pipes. This drop down has no effect unless request forwarding is enabled.

The originate queries from port 53 check box configures the DNS server so that upstream UDP queries originate from port 53. This setting may be required if a strict firewall is positioned between the rXg and the upstream DNS server(s).

By default, access to rXg services are either limited to the LAN or disabled entirely. In certain cases, the operator may desire to permit accessibility to services over the WAN and/or LAN. To enable access to rXg services over the WAN, the operator should specify one or more WAN targets containing the list of allowed hosts and then set the visibility appropriately. If no WAN target is specified and WAN visibility is enabled, any node on the WAN may connect to the service. It is highly recommended that this wide-open configuration be avoided to ensure system security. If LAN visibility is included then all authenticated nodes on the LAN may access this service.

The note field is a place for the administrator to enter a comment. This field is purely informational and has no bearing on the configuration settings.

Example: Setup CloudFlare Dynamic DNS

Before we begin we must obtain an API Key from CloudFlare. Navigate to their site and login with your credentials. Click on the person icon in the upper right-hand corner.

Click on "My Profile".

Click on "API Tokens".

Click "View" on the "Global API key".

Enter your CloudFlare password when prompted.

Copy your API Key.

In the rXg navigate to Services::DNS and create a new Dynamic DNS Client.

Give the record a Name. Change the Protocol field to CloudFlare. Enter your email address into the Login field. Enter your API key into the Password field. The Host field is the FQDN to be updated in CloudFlare, and the Zone field is the root domain of the FQDN. Click Create.

When setup the scaffold will update when there is a change.