Friday , 21 October 2016
Breaking News
Home » WWW » Configuring DNS Services

Configuring DNS Services

Now that you understand DNS from a high-level perspective, you also need to understand some DNS specifics, and details on how Mac OS X implements the DNS system.

Using BIND

The primary interface for configuring DNS services on Mac OS X Server is the graphical Server Admin utility. Similar to many other subsystems on Mac OS X Server, and Mac OS X in general, DNS is handled by a freely available, open source product: the Internet System Consortium’s Berkeley Internet Name Domain (BIND). You can configure BIND via Server Admin on Mac OS X Server, or manually on Mac OS X. BIND is the most widely deployed DNS server on the Internet. Mac OS X includes a full installation of BIND, which includes essential utilities such as the named name daemon, which is responsible for handling all queries, and rndc, a utility to control the name server. The DNS service can be configured and run entirely from a command-line shell. Also, by basing this service on a standard, Mac OS X easily interoperates with other DNS name servers both BIND and non-BIND. The DNS system classifies records into different types:

P A: IPv4 address record. Maps a name to an IPv4 address for a forward lookup.

– AAAA: IPv6 address record. Maps a name to an IPv6 address for a forward lookup.

– CNAME: Canonical name. An alias that points to a separate DNS record.

– MX: Mail Exchanger. Supplies the name and priority for a machine that accepts mail for the given domain.

– NS: Name server. Defines a name server for the zone.

– SRV: Service. Stores information about a service.

– HINFO: Hardware info. Stores information about a machine’s hardware and/or software.

– TXT: Text. Provides descriptive text about a record.

– PTR: Pointer record. Maps an IP address to a name, allowing reverse lookups.Basically, a PTR record is the opposite of an A record.

These record types form the database files for each zone created. Database files are created in the /var/named hierarchy on the file system. In Leopard, Apple has chosen to allow a mixed approach: The changes made in Server Admin are written to one set of files, and you can make manual changes to a different set of files. Manual changes update the canonical files, while Server Admin edits some Apple-specific files. Interestingly, this fact shows off Server Admin’s ability to interpret these files. Where past OS versions had a much more straightforward graphical user interface–to–config file relationship, new capability is evident in the main configuration file for BIND: /etc/named.conf.

The latest version of BIND, version 9, supports a concept called views. Views allow a BIND server to present different zones and zone data to different viewers of the data based on several criteria all from a single BIND instance. While Mac OS X Server v10.5 is the first version to explicitly use views, the functionality is not exposed in the graphical user interface. In fact, all zones are simply contained in one master view called ServerAdmin.DNS.public. To understand this better, look at /etc/named.conf:

include “/etc/rndc.key”;
controls {
inet port 54 allow {any; }
keys { “rndc-key”; };
options {
include “/etc/dns/”;
logging {
include “/etc/dns/”;
include “/etc/dns/”;

The comments from this file have been stripped out to show how minimal the code is. Unlike previous OS versions that wrote all configuration options directly into the named. conf file, Leopard puts the “real” directives in external files that are then pulled into the main file via include statements. This same tactic is used for the database files, as discussed below. Piecing the configuration together in order, the file contains three statements:

directory “/var/named”;
forwarders {};
allow-transfer { none; };

The directory statement sets where named should find any zone files referenced in the remainder of the config file. The forwarders statement is set to an empty list, and the allow–transfer statement is disallowed. If you remember the graphical user interface setup for each zone, “Allows zone transfer” is enabled by default So how is the allow-transfer directive set to none in the config file? This goes back to the support for BIND views, which will be covered in the discussion below about the file.

About Emma G.

Working in the marketing industry since 2002. This blog is one of my hobbies.

Leave a Reply