3.6. DNS

Nubus for UCS integrates BIND for name resolution through the domain name system (DNS). The DNS server provides name resolution for the local network. BIND is available on all Nubus for UCS Directory Node roles. Nubus for UCS doesn’t support the installation of BIND on other system roles.

For information about configuring the name servers that a Nubus for UCS system uses, see Network configuration.

3.6.1. DNS zones

DNS zones organize authoritative DNS data. Each DNS zone has a primary name server that provides the original zone data. Secondary name servers can obtain zone data through zone transfers. An SOA record marks the start of a zone of authority and contains parameters for managing the zone.

Forward lookup zone

A forward lookup zone contains information for resolving DNS names into IP addresses.

Reverse lookup zone

A reverse lookup zone contains information for resolving IP addresses into DNS names.

See also

For the management modules for DNS zones, see the following in Nubus Manual 1.x [3]:

• Forward lookup zone

• Reverse lookup zone

3.6.2. DNS records

DNS records contain information about DNS names. For information about how to manage DNS records, see DNS module in Nubus Manual 1.x [3].

MX record

The MX record of a forward lookup zone provides DNS information for email routing. It points to the computer that accepts email for a domain.

CNAME record

A CNAME record, also called an alias record, refers to an existing, canonical DNS name. For example, you can create an alias entry mailserver for the actual hostname of a mail server and enter the alias in mail clients. Any number of CNAME records can map to one canonical name.

A and AAAA records

An A record assigns an IPv4 address to a DNS name. An AAAA record assigns an IPv6 address to a DNS name. In Nubus for UCS, a host record can contain IPv4 and IPv6 addresses.

PTR record

A PTR record (pointer record) resolves an IP address into a hostname. In a reverse lookup zone, it’s the equivalent of a host record in a forward lookup zone.

SRV record

An SRV record, called a service record in Nubus for UCS, stores information about available system services in DNS. In Nubus for UCS, service records make LDAP servers or the Primary Directory Node known domain-wide, among other uses.

TXT records

TXT records include human-readable text and can include descriptive information about a forward lookup zone.

See also

For the management modules for DNS records, see the following in Nubus Manual 1.x [3]:

• CNAME alias records

• A/AAAA host records

• Service records

• Pointer record

• MX records tab - DNS forward lookup zone

• TXT records tab - DNS forward lookup zone

3.6.3. Configuration of the BIND name server

The following sections describe how to configure BIND debug output, the data backend, and zone transfers.

3.6.3.1. Configuration of BIND debug output

Use the UCR variables dns/debug/level and dns/dlz/debug/level to configure the level of detail in BIND debug output. The latter applies to the Samba backend. Possible values range from 0 to 11. Level 0 deactivates debug output. Higher BIND debug levels provide more detailed output. For information about BIND debug logging, see The channel phrase in BIND 9 Administrator Reference Manual [7].

For information about setting and checking a UCR variable, see Set a UCR variable. After changing either debug variable, restart the BIND service as root user, as shown in Listing 3.10.

Listing 3.10 Restart BIND after changing the debug level

$ systemctl restart named

3.6.3.2. Configuration of the data backend

In a typical BIND installation on a non-Nubus for UCS system, you configure BIND by editing zone files. In Nubus for UCS, you manage DNS zones and records through management modules. These modules store the DNS data in the LDAP directory.

BIND can use two different backends for its configuration:

LDAP backend

The LDAP backend is the standard backend and accesses data in the LDAP directory. With this backend, the DNS service uses two servers. The BIND proxy uses the standard DNS port 53. A second server runs in the background on port 7777 and obtains zone data from LDAP. The BIND proxy acts as a secondary server and obtains zone data from the second server through zone transfers.

Samba backend

Samba/AD provides an Active Directory domain. Active Directory relies on DNS for purposes such as DNS updates from Windows clients and the discovery of NETLOGON shares. With the Samba backend, Samba directly updates the DNS data in its internal LDB database. BIND then accesses the Samba DNS data through its Dynamically Loadable Zones (DLZ) interface.

With the Samba backend, each DNS request triggers an LDAP search. With the LDAP backend, a directory service search occurs only if the DNS data has changed. The LDAP backend can therefore reduce the system load on Samba/AD systems.

The UCR variable dns/backend selects the DNS backend. The value ldap selects the LDAP backend, and samba4 selects the Samba backend. On Directory Nodes running Samba 4, don’t set the backend to ldap.

You use management modules to administer DNS with either backend.

3.6.3.3. Configuration of zone transfers

By default, the Nubus for UCS name server allows zone transfers of DNS data. If the Nubus for UCS system is reachable from the internet, anyone can request a list of all computer names and IP addresses.

Depending on the configured data backend, the method to restrict zone transfers differs:

LDAP backend

If you use the LDAP backend, you can deactivate zone transfers or restrict them by setting the UCR variable dns/allow/transfer to none or a list of allowed IP addresses.

After changing the variable, restart the BIND service as root, as shown in Listing 3.10.

Samba backend

Important

For the Samba backend (Samba DLZ), the dns/allow/transfer variable and standard BIND allow-transfer options are not enough to control zone transfers.

For more information about this limitation and its current status, see Bug #55047.

To verify whether the server allows or denies zone transfers, use the dig command from a client machine, as shown in Listing 3.11. Replace the following:

• SERVER_IP with the IP address of the name server, for example 192.168.1.1.

• DOMAIN_NAME with the name of the zone, for example domain.lan.

If the server allows the transfer, it returns the full list of zone records. If the server denies the transfer, the output shows a Transfer failed or REFUSED message.

Listing 3.11 Verify DNS zone transfer

$ dig @SERVER_IP DOMAIN_NAME axfr