1.2 DNS Service

The DNS software in Open Enterprise Server integrates DNS information into eDirectory.

Integrating DNS with eDirectory greatly simplifies network administration by enabling you to enter all configuration information into one distributed database. The DNS configuration information is replicated just like any other data in eDirectory.

By integrating DNS into eDirectory, the concept of a primary or secondary has been shifted away from the server to the zone itself. After you have configured the zone, the data is available to any of the OES DNS servers you select to make authoritative for the zone. The OES DNS server takes advantage of the peer-to-peer nature of eDirectory by replicating the DNS data.

The OES DNS Service interoperates with other DNS servers. The OES DNS server can act as either a master DNS server or a secondary DNS server in relation to non-OES DNS servers. The OES DNS server can act as the master DNS server and transfer data to non-OES secondary servers. Alternatively, one OES DNS server can act as a secondary DNS server and get transferred data from a non-OES master server. All OES DNS servers can then access the data through eDirectory replication.

DNS is integrated into eDirectory by extending the eDirectory schema and creating new eDirectory objects to represent zones, resource records, and DNS name servers. Integrating these new objects into eDirectory simplifies the administration of DNS, enabling centralized administration and configuration.

A Zone object is an eDirectory container object that holds RRSet objects, which are leaf objects. A DNS server object is a leaf object. For detailed information about these objects, see Understanding DNS and DHCP Services.

In traditional DNS, all data changes are made on a single primary name server. When changes are made, the secondary name servers request transfers of the changes from the primary name server. This process is called a zone transfer. The master-slave approach has several disadvantages, the most significant being that all changes must be made at the primary server.

Using the primary and secondary zone concept, the approach allows changes from anywhere in the network through eDirectory, which is not dependent on one server. Zone data is stored within eDirectory and is replicated just like any other data in the eDirectory tree.

Our implementation of DNS supports the traditional primary-secondary DNS name server approach to moving DNS data in and out of eDirectory. Although all OES servers can recognize DNS data after the data is placed in the directory through eDirectory replication, only one server is required for a zone transfer. The server assigned to perform this function in a secondary zone is called the Zone-in (Designated Secondary) DNS server.

In a secondary zone, the Zone-in server is responsible for requesting a zone transfer of data from the external primary name server. The Zone-in server determines which data has changed for a zone and then makes updates to eDirectory so that other servers are aware of the changes.

A Forward zone, acts as a forwarder and forwards all queries on zones to primary or secondary servers of the zone.

The Designated DNS (DDNS) server is a server identified by the network administrator to perform certain tasks for a primary zone. The DDNS server for a primary zone is the only server in that zone that receives dynamic updates from a DHCP server to perform Dynamic DNS (DDNS) updates. These updates cause additions and deletions of resource records and updates to the zone’s serial number.

Figure 1-6 illustrates an OES server as the primary and secondary DNS name server and also illustrates primary and secondary zones within eDirectory. In this example, there are two zones. Any of the OES DNS servers assigned to a zone is able to respond authoritatively to queries for the zone. For each zone, one server is designated by the administrator to act as the DDNS server. S1 is the Designated Primary DNS server for Zone 1 and S3 is a Passive Primary server. S1 accepts the Dynamic updates from the DHCP server. S2 is the Zone In (Designated Secondary) server and S4 is the Passive Secondary server for the secondary zone zone2, called the Foreign Zone. S2 occasionally requests zone transfers from the foreign server and places the modified zone data into eDirectory, where any of the OES servers can respond to queries for it. S3 and S4 will get the latest data through eDirectory.

Figure 1-6 OES Server As a Primary/Secondary DNS Server

Figure 1-7 shows a representation of eDirectory objects within a DNS zone.

Figure 1-7 DNS Zone

The eDirectory schema extension defines additional objects needed for DNS.

DNS eDirectory Objects and Attributes

When you select the OES DNS Service during the OES installation, the eDirectory schema is extended to enable the creation of DNS objects and the following objects are created:

• DNS-DHCP (Locator object)

• DNSDHCP-Group (Group object)

• RootServInfo

Only one copy of these objects exists in the context that is specified during OES installation. The DNS servers, DHCP servers, and Management Console must have access to these objects.

The DNSDHCP-Group object is a standard eDirectory group object. The DNS servers gain rights to DNS data within the tree through the Group object.

The DNS-DHCP Locator object is created during the OES installation, if the DNS option is chosen. The creator of the Locator object grants Read and Write rights to this object to the network administrators.

The DNS-DHCP Locator object contains global defaults, DNS options, and a list of DNS servers and zones in the tree. Java Management Console uses the Locator object contents instead of searching the entire tree to display these objects. The Locator object is hidden by the Java Management Console.

The RootServInfo is a Zone object, which is an eDirectory container object that contains resource records for the DNS root servers. The resource record sets contain Name Server records and Address records of name servers that provide pointers for DNS queries to the root servers. The RootServInfo object is the equivalent of the BIND db.root file.

The following new eDirectory objects are also required for DNS:

• DNS Server Object

• DNS Zone Object

• DNS Resource Record Set Object

• DNS Resource Records

Figure 1-8 shows an example of a tree with DNS objects.

Figure 1-8 eDirectory Objects for DNS

DNS Server Object

The DNS server object (or dnipDNSServer object) is created during installation. It is created in same context as the NCP server, contains DNS server configuration parameters, and includes the following:

• Zone List

• DNS Server IP Address

• Domain Name of the DNS Server

• DNS Server Options

• Forwarding List

• No-Forwarding List

• Key List

• Access Control List for zone transfer, query, recursion, notify, etc.

• Other additional advanced options to fine-tune the DNS server

DNS Zone Object

The DNS Zone object is a container object that contains all the data for a single DNS zone. A Zone object is the first level of the DNS zone description. A Zone object can be contained under an Organization (O), Organizational Unit (OU), a Country (C), or a Locality (L).

Multiple DNS zones can be represented within eDirectory by using separate, independent DNS Zone objects. A network administrator can support multiple DNS zones on a single OES server by creating multiple DNS Zone objects and assigning the server to serve those zones.

The DNS Zone object contains data that correlates to a DNS Start of Authority (SOA) resource record (RR) and a member list of all eDirectory-based DNS servers that serve the zone.

The DNS namespace hierarchy is not represented within the eDirectory hierarchy. A zone and its child zone might appear as peers within the eDirectory hierarchy, even though they have a parent-child relationship within the DNS hierarchy.

DNS object names are created using the DNS Zone names.

Valid characters for domain names according to RFC 1034/RFC 1035 are a-z (case insensitive), 0-9, and hyphens. For example, the name of the Zone object for newyork.companya.com zone, which exists in an eDirectory context sjf.us., shall be newyork_companya_com.sjf.us

NOTE:OES DNS supports underscore character in domain names and Resource Records using OES DNS server check-names statement for co-existence with Windows DNS servers.

DNS Resource Record Set Object

The DNS Resource Record Set (RRSet) object is an eDirectory leaf object contained within a DNS Zone object. An RRSet object represents an individual domain name within a DNS zone. Its required attributes are a DNS domain name and resource records (RRs).

Each domain name within a DNS zone object has an RRSet object. Each RRSet object has one or more resource records beneath it that contain additional information about the zone data.

DNS Resource Records

A DNS resource record (RR) is an attribute of an RRSet that contains the resource record type and data of a single RR. RRs are configured beneath their respective RRSet objects. Resource records describe their associated RRset object.

The most common resource records are Address (A) records, which map a domain name to an IP address, and Pointer (PTR) records, which map an IP address to a domain name within an in-addr.arpa zone.

Dynamic DNS (DDNS) provides a way to dynamically update DNS with resource records from applications such as DHCP servers, and DNS clients. DDNS eliminates the need for any additional configuration of DNS for each host address change. A OES DNS server supports the following DDNS mechanisms:

All changes made to a zone through dynamic updates are stored in the zone's journal file. This file is automatically created by the server in a binary format when the first dynamic update takes place. The journal file name has the .jnl extension. This file is also used for IXFR. We recommend that you do not edit the contents of the journal file.

Zone transfer is essential for maintaining up-to-date zone data in the server. When an OES server is designated as primary, all the changes made by the designated primary to eDirectory are reflected in the eDirectory replicas, using the eDirectory sync property. When an OES server is designated secondary, zone transfer is needed for receiving the most up-to-date zone data from any primary servers.

The designated secondary server sends a zone-in request after the refresh time interval or after receiving a notification from the primary server. The zone transfer-in requests are not triggered if the eDirectory services are not available.

The final step in a successful zone transfer-in is to update the SOA serial number. The passive secondary servers compare the eDirectory SOA serial number with their own copy to determine whether there is a need to synchronize the data from eDirectory.

The following types of zone transfers are supported:

An OES DNS server supports dynamic reconfiguration. The DNS server automatically detects and updates any change in the server's or zone's configuration data. This enables the server to configure itself with these changes without having the administrator intervene to stop and restart the server. Also, out-of-band data changes (creating, modifying, deleting RRs through management utility) are addressed.

The dynamic reconfiguration is also used to monitor the availability of eDirectory with respect to the individual zones, and to detect and log changes that can be used for fault tolerance.

An OES DNS server supports fault tolerance during an eDirectory service outage. The DNS server loads the configuration and zone data from eDirectory during startup. Also, the dynamic updates received for zone data are updated to eDirectory. It is essential for the DNS server to maintain backup copies of eDirectory so it can get to the zone database during eDirectory unavailability.

The DNS server supports standard DNS queries during fault tolerance mode. However, dynamic updates and zone-in transfers are not supported during this mode because eDirectory cannot be updated.

An OES DNS server supports cluster services with active-passive and cluster-safe modes. When a DNS server is run on any node, it uses a DNS server object in eDirectory. The cluster-enabled DNS service uses the same DNS server object for the other nodes during a node outage.

When there is a node (node1) outage, clustering enables a DNS server to automatically bring up any other node (node2), using the same server object that was used before the outage. The DNS server object contains a reference to the virtual NCP server, which is used to locate the DNS server object. For more information, see Section 14.0, Configuring DNS with OES Cluster Services.

The OES DNS server supports only NSS file systems.

Figure 1-9 Cluster Support

DNS Notify is a mechanism that allows master name servers to notify their slave servers of changes to a zone's data. In response to a notification from a master server, the slave verifies which SOA serial number for the zone (sent through the notify mechanism) is the newer compared to the current SOA serial number. If the serial number is newer, a zone transfer is initiated. For OES DNS servers, receiving Notify is valid only for designated secondary servers. Passive servers receive the latest data through eDirectory replication.

Figure 1-10 Notify

For more information on DNS notify, refer to RFC 1996.

If all resolvers querying for a name get the same response, and if all of them contact the same host, that host becomes overloaded. Primitive load balancing can be achieved in DNS by using multiple records for one name. When a resolver queries for these records, the DNS server shuffles them and responds to the query with the records in a different order.

For example, suppose you have three Web servers with these three different IP addresses:

www 3600 IN A 10.10.0.1

3600 IN A 10.10.0.2

3600 IN A 10.10.0.3

The DNS server randomly shuffles the RRs so that clients randomly receive records in the order 1, 2,3; 2, 3, 1; and 3, 1, 2. Most clients use the first record returned and discard the rest.

The name server can forward some or all of the queries that it cannot satisfy from its authoritative data or cache to another name server; this is commonly referred to as a forwarder.

Forwarders are typically used when all servers at a given site should not be allowed to interact directly with the rest of the Internet servers. A typical scenario involves a number of internal DNS servers and Internet firewall servers unable to pass packets through the firewall. They forward to the server that can do it, which queries the Internet DNS servers on the internal server's behalf. An added benefit of using the forwarding feature is that the central machine develops a much more complete cache of information that all of the clients can take advantage of. Forwarding occurs only on those queries for which the server is not authoritative and does not have the answer in its cache.

A forwarding list is a list of IP addresses for the DNS servers to forward the queries to. For example, if a name server is configured to forward queries to 10.10.10.2, all queries that do not have resolutions to the name server are forwarded to 10.10.10.2. (See DNS Namespace). Forwarding is also possible at the zone level. When forwarders are configured at the zone level, they override the forwarders list configured at server level.

No-Forwarding is blocking queries to the list of DNS domains. The No-Forward list is the list of domain names whose unresolved queries are not forwarded to other DNS servers.

On a query from the client, the authoritative database is first checked. If the domain name is not found, the No-Forward list is checked. If the No-Forward list contains the entry, the query is not answered and the response domain does not exist (NXDOMAIN) is sent to the client. See Name Resolution.

For example, having the domain name “abc.com” in the No-Forward list blocks the queries to “abc.com”, “support.abc.com”, or any other subdomain of abc.com.

Wildcard characters are not supported in the No-Forward list. An asterisk or a root domain in the No-Forward list cannot be used to block queries to all domain names.

For example, developer.*.com cannot be used to block the queries to developer.novell.com or developer.xyz.com, etc.

Figure 1-11 No-Forwarding

The primary benefits of integrating a DNS server with eDirectory include:

BIND includes the rndc utility that allows you to administer the named daemon, locally or remotely, with command line statements. The rndc program uses the /etc/rndc.conf file for its configuration options, which can be overridden with command line options.

For more details on the options supported by rndc, enter rndc at the command prompt.

The following rndc commands are not supported:

This section provides information about managing DNS objects using the Java Management Console.

Java Management Console

The Java Management Console can be used to configure and manage eDirectory-based DNS objects. It is supported on Windows 7, Windows (XP and Vista), and Linux. It is an independent executable Java application. To launch Java Console:

On Windows: Click Start > Programs > DNS-DHCP Management Console > DNSDHCP. It can also be launched by double-clicking the DNSDHCP shortcut icon created on the desktop.

On Linux: Open a terminal console and run the command./dnsdhcp-jc-launch.sh from the location /opt/novell/dnsdhcp/console/.

When the Java Management Console is launched, it prompts you to select a tree as the target eDirectory context.

To manage objects in a different eDirectory tree, the administrator must exit the utility, change the context to the other eDirectory tree, and launch the utility again. The current eDirectory tree name is displayed in the utility's caption bar.

The Java Management Console manages one tree at a time. You can manage both DHCP and DNS services in the Java Management Console. Figure 1-12 shows the main user interface window for DNS services.

Figure 1-12 DNS Java-based Management Console User Interface

For more information, see:

• DNS Service

• Toolbar

• Status Bar

• Server Status

• Object Creation Rules

DNS Service

DNS objects can be accessed via the DNS Service tab. There are three panes within each tab page. The left pane displays the managed DNS objects in tree form. The right pane displays the detailed information about the selected object in the left or bottom pane. The bottom pane lists the DNS servers configured to provide necessary services.

Resources are organized according to the object hierarchy and the implicit ordering of objects. In the DNS Services pane, all zones or resource records within a zone are listed in alphanumeric order.

All DNS objects are created as eDirectory objects and are subject to Linux Administrator conventions. Therefore, when creating a new object, you should always name the object first in each Create dialog box.

The Create dialog box of these objects has browsing capability in the eDirectory tree, so an administrator with Write or Supervisor rights can select a specific context.

A newly created object's button on the toolbar is context-sensitive in relation to the selected item in either service's left tree pane. Your rights to the DNS objects are not verified until you perform an update, delete, or create against the target objects.

The DNS objects available in the new object dialog's creation list box depend on the selected object in the left tree pane. The following table lists the rules for each container object.

Table 1-3 Rules for Container Objects

Selected Object	Objects that can be created
All Zones	DNS Server, Zone, and DNS Key
DNS Server	DNS Server, Zone, and DNS Key
Zone	DNS Server, Zone, Resource Record, and DNS Key
RRSet	DNS Server, Zone, Resource Record, and DNS Key
Resource Record	DNS Server, Zone, Resource Record, and DNS Key

After a new DNS object has been created, the Java Management Console grants the objects Read and Write rights to the Locator object.

For fast and efficient searching, the distinguished names of newly created zones, DNS servers, and subnets are added to the corresponding attribute of the Locator object. Renaming or deleting these objects is automatically performed by eDirectory because of the built-in feature for eDirectory distinguished names.

After a new DNS object has been created, the Java Management Console gives you the choice of staying in its current focus or setting the focus on the newly created object. The utility also displays its detailed information page in the right pane. This feature is provided as a convenience to administrators and can be used by selecting the Define Additional Properties check box.

Toolbar

The Management Console offers no menu items. All functions are provided by the toolbar. The functions that are relevant for the item selected in the left tree pane or bottom server pane are highlighted to show their availability.

Figure 1-13 Toolbar

If you position the cursor over the icon, the icon's name appears. The following table lists, when the toolbar buttons are enabled in relationship to the selected object.

Table 1-4 Period when the Toolbar Buttons are Enabled

Toolbar Button	Enabled
Create	When Our Network, Subnet, Subnet Address Range, IP Address, Shared Network, All Zones, Zone, DNS Server, RRSet, or Resource Record is the selected object
Delete	When Subnet, Subnet Address Range, Shared Network, Zone, RRSet, Resource Record, or DNS Server is selected
Save	When fields have been changed for updates or changes
Refresh tree	Always enabled
Import	Always enabled
Export	When a zone is selected (except for forward zone)
View events/alerts	When DNS server is selected
View audit trail log	When DNS server is selected
Start/stop service	When DNS server is selected
Move DNS server	When DNS server is selected
Find	When Zone, Resource record, DNS key is selected
Help	Always enabled

Status Bar

The status bar displays two fields in the bottom pane of the Management Console. The first field shows the current database access interface in progress. The second field displays the current selected object or operation status. Figure 1-14 shows the status bar and the DNS server icon. The status bar is at the bottom of the figure.

Figure 1-14 DNS Status Bar

Server Status

Server icons are displayed in the lower portion of the Management Console.

Figure 1-15 shows icons representing two DNS servers. Both servers are operational, novell-named has been loaded and each can communicate with the Java Management Console, but the operation of the server on the right (DNS_JAPAN) has been suspended.

Figure 1-15 DNS Server Icons

Object Creation Rules

These are certain rules that govern the creation and manipulation of objects in the Linux DNS object hierarchy.

The DNS Zone object and DNS server object can be created in the context of an Organization (O), Organizational Unit (OU), Locality (L), or Country (C).

Some objects such as DNS key and DNS zone can be created in any context. For fast and efficient search operations, the distinguished names of the newly created zones and DNS servers are added to the corresponding attribute of the Locator object. Renaming or deleting these objects is automatically performed by eDirectory because of the built-in feature for eDirectory distinguished names.

Java Console lets you create zone objects under Country, Locality, Organization, Organizational unit, and domain containers.

Java Console does not let you select Country and Locality domain containers. You need to specify them manually. After you specify these contexts manually, Java Console creates zone objects under these containers.

Locator object cannot be created from Java Console. However, during installation if these contexts are specified, then you can create the locator object.

Locator object can be created in the Top, tree root, and domain containers along with existing Country, Locality, Organization, and Organizational Unit containers.

DNSServer object is always created under NCP server container. You cannot select a separate container for server object from Java Console.