DNS

Introduction

The DNS (Domain Name Service) client provides the ability to resolve IP addresses to hostnames and vice versa, and is always enabled on the appliance. Optionally, secondary hostname resolution via NIS and/or LDAP, if configured and enabled, may be requested for hostnames and addresses that cannot be resolved using DNS. Hostname resolution is used throughout the appliance user interfaces, including in audit logs to indicate the location from which a user performed an auditable action and in Analytics to provide statistics on a per-client basis.

The configurable properties for the DNS client include a base domain name and a list of servers, specified by IP address. You must supply a domain name and at least one server address; the server must be capable of returning an NS (NameServer) record for the domain you specify, although it need not itself be

authoritative for that domain. You will receive an error message if your DNS server(s) do not meet this requirement.

Properties

Changing services properties is documented in the BUI and CLI sections of Services.

CLI

The CLI includes builtins for nslookup and getent hosts, which can be used to test that hostname resolution is working:

caji:> nslookup deimos
192.168.1.109   deimos.sf.fishworks.com
caji:> getent hosts deimos
192.168.1.109   deimos.sf.fishworks.com

Logs

To view service logs, refer to the Logs section from Services.

Active Directory and DNS

If you plan to use Active Directory, at least one of the servers must be able to resolve hostname and server records in the Active Directory portion of the domain namespace. For example, if your appliance resides in the domain example.com and the Active Directory portion of the namespace is redmond.example.com, your nameservers must be able to reach an authoritative server for example.com, and they must provide delegation for the domain redmond.example.com to one or more Active Directory servers serving that domain. These are requirements imposed by Active Directory, not the appliance itself. If they are not satisfied, you will be unable to join an Active Directory domain.

Non-DNS Resolution

DNS is a standard, enterprise-grade, highly-scalable and reliable mechanism for mapping between hostnames and IP addresses. Use of working DNS servers is a best practice and will generally yield the best results. In some environments, there may be a subset of hosts that can be resolved only in NIS or LDAP maps. If this is the case in your environment, enable non-DNS host resolution and configure the appropriate directory service(s). If LDAP is used for host resolution, the hosts map must be located at the standard DN in your database: ou=Hosts,(Base DN), and must use the standard schema. When this mode is used with NFS sharing by netgroups, it may be necessary for client systems to use the same hostname resolution mechanism configured on the appliance, or NFS sharing exceptions may not work correctly.

When non-DNS host resolution is enabled, DNS will still be used. Only if an address or hostname cannot be resolved using DNS will NIS (if enabled) and then LDAP (if enabled) be used to resolve the name or address. This can have confusing and seemingly inconsistent results. Therefore, if you must use non-DNS resolution, best results will likely be achieved by disabling DNS (see next section) and using NIS or LDAP exclusively for host resolution. You can validate host resolution results using the 'getent' CLI command described above.

Use of these options is strongly discouraged.

DNS-Less Operation

If the appliance will be unable to access any DNS servers from its installed location in the network, you may elect to operate without DNS by supplying the server 127.0.0.1. Use of this mode is strongly discouraged; several features will not work correctly, including:

• Analytics will be unable to resolve client addresses to hostnames.

• The Active Directory feature will not function (you will be unable to join a domain).

• Use of SSL-protected LDAP will not work properly with certificates containing hostnames.

• Alert and threshold actions that involve sending e-mail can only be sent to mail servers on an attached subnet, and all addresses must be specified using the mail server's IP address.

• Some operations may take longer than normal due to hostname resolution timeouts.

These limitations may be partially mitigated by using an alternate host resolution service; see "Non-DNS Resolution" above.