1.3.1 Novell eDirectory Objects for DNS

Novell has integrated DNS 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 eDirectory Objects and Attributes for DNS.

By integrating DNS into eDirectory, Novell has shifted away from the traditional concept of primary or secondary DNS name servers to the concept of a primary or secondary zone.

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 Novell 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.

The Novell implementation of DNS supports the traditional primary-secondary DNS name server approach to moving DNS data in and out of eDirectory. Although all Novell 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 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 a Novell 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 Novell 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 Novell servers can respond to queries for it. S3 and S4 get the latest data through eDirectory.

Figure 1-6 Novell 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

1.3.2 eDirectory Schema Extensions for DNS

The eDirectory schema extension defines additional objects needed for DNS and DHCP.

eDirectory Objects and Attributes for DNS

The following new eDirectory objects are required for DNS:

• DNS Name Server object

• DNS Zone object

• DNS Resource Record Set object

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

Figure 1-8 eDirectory Objects for DNS

• DNS Server Object

• DNS Zone Object

• DNS Resource Record Set Object

• DNS Resource Records

DNS Server Object

The DNS server object (or Service object) is created by extending the NetWare Core Protocol™ (NCP™) server object. The DNS server reference is stored in the NCP server during the creation of the server object. A DNS server object can be contained in an Organization (O), Organizational Unit (OU), Country (C), or Locality (L). The DNS server object contains DNS server configuration parameters, including the following:

• Zone List

• DNS Server IP Address

• Domain Name of the DNS Server

• DNS Server Options

• Forwarding List

• No-Forwarding 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 NetWare 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), a member list of all eDirectory-based DNS servers that serve the zone, and Dynamic DNS (DDNS) server information.

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 by using the DNS Zone names as follows:

All “.” are replaced by “_“and all “_” are replaced by “#”. The only supported characters for domain names are a-z, A-Z, 0-9, hyphens, and underscores. For example, the name of the Zone object for new york.companya.com zone, which exists in an eDirectory context sjf.us., would be new#york companya_com.sjf.us.

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.

1.3.3 DNS SNMP Events

SNMP event generation can be set up in a Novell DNS server for all, major, or no events. The default setting is none, which causes the server not to log any event.

SNMP trap flag is a single-valued attribute in eDirectory, which is an optional attribute in the DNS server objects. SNMP trap flag can be set by using the management utilities.

SNMP event generation can be set up either for trapping major events or all events. This can also be disabled for not generating any traps.

1.3.4 Dynamic DNS

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. Novell DNS server supports the following DDNS mechanisms:

All changes made to a zone by using 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.

1.3.5 Zone Transfer

Zone transfer is essential for maintaining up-to-date zone data in the server. When a Novell 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 a Novell server is designated as 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:

1.3.6 ICE Zone Handlers

An ICE zone handler is a utility to import or export the DNS server, zone configuration information, and data to or from the eDirectory database.

The Import-Convert-Export (ICE) utility is a framework provided by Novell that contains the ICE engine, the source handler, and the destination handler. This provides a command line interface to access its functionality and to read the required data. It expects the data processed by the handlers in LDAP format.

The ICE zone handler is plugged into the ICE framework. The required data and the handler information must be provided by using the command line interface, so the information is processed by the zone handler and passed to the ICE engine. The ICE engine migrates this data. ICE has the option of using LDAP Bulk Update/Replication Protocol (LBURP) to increase the speed of data migration.

The zone module handlers consist of a zone source handler and a zone destination handler. By using these handlers, data can be migrated from files to eDirectory (import operation) or from eDirectory to the files (export operation).

A zone source handler that forms the data to be imported and the LDAP destination handler that does the eDirectory update operation are used to import a zone. A zone destination handler that reads the required data from eDirectory and the zone source handler that formats the data and writes into the files are used to export a zone.

The table below describes the source and destination handlers for zone import and export.

Figure 1-9 ICE Framework

For more information, see DNS/DHCP Advanced Features.

1.3.7 Dynamic Reconfiguration

The Novell 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.

1.3.8 Fault Tolerance

A Novell 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 to 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.

1.3.9 Cluster Support

The Novell DNS server supports cluster service 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 7.2, Cluster Support.

Figure 1-10 Cluster Support

1.3.10 Notify

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 the SOA serial number of the zone (sent through the notify mechanism) to see if it is newer compared to the current SOA serial number. If the serial number is newer, a zone transfer is initiated. For Novell DNS servers, receiving Notify is valid only for designated secondary servers. Passive servers receive the latest data through eDirectory replication.

Figure 1-11 Notify

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

1.3.11 Load Balancing

If all resolvers querying for a name get the same response, and if all of them contact the same host, then 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 more information, see the description of the RRset-ordering.

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

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.

1.3.12 Forwarding

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 an Internet firewall. Servers unable to pass packets through the firewall forward to the server that can do it, and that server 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.

The forwarding list is a list of IP addresses for the DNS servers to forward the queries to. 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. Now forwarding is possible at zone level as well. When forwarders are configured at zone level, they override the forwarders list configured at the server level.

1.3.13 No-Forwarding

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-12 No-Forwarding

1.3.14 Benefits of Integrating DNS Server with eDirectory

The primary benefits of integrating DNS server with eDirectory include: