1.3 Novell DNS Services

The DNS software in Novell DNS/DHCP Services integrates DNS information into the Novell eDirectory database. Previously, DNS used Btrieve* as its database for configuration information. Integrating DNS with eDirectory moves all the information currently held in Btrieve files 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, Novell has shifted the concept of a primary or secondary away from the server to the zone itself. After you have configured the zone, the data is available to any of the Novell DNS servers you select to make authoritative for the zone. The Novell DNS server takes advantage of the peer-to-peer nature of eDirectory by replicating the DNS data.

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

Novell DNS/DHCP Services provides the following DNS features:

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 (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 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 will 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.

DNS/DHCP Global eDirectory Objects

When you select Novell DNS/DHCP Services during the NetWare 6.5 installation, the eDirectory schema is extended to enable the creation of DNS and DHCP objects and the following objects are created:

  • DNS/DHCP Locator object
  • DNS/DHCP Group object
  • RootSrvrInfo Zone

Only one copy of these objects exists in an eDirectory tree. The DNS servers, DHCP servers, iManager, and Management Console must have access to these objects.

The DNS/DHCP Group object is a standard eDirectory group object. The DNS and DHCP servers gain rights to DNS and DHCP data within the tree through the Group object.

The DNS/DHCP Locator object is created during the NetWare 6.5 installation, if the DNS/DHCP option is chosen. The creator of the Locator object will grant Read and Write rights to this object to the network administrators.

The DNS/DHCP Locator object contains global defaults, DHCP options, and a list of all DNS and DHCP servers, subnets, and zones in the tree. The iManager utility and Management Console use the Locator object contents instead of searching the entire tree to display these objects. The Locator object is basically hidden by the iManager utility and Management Console.

The RootSrvrInfo Zone is a Zone object, 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 RootSrvrInfo Zone object is the equivalent of the BIND db.root file.

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

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

All “.” will be replaced by “_“ and all “_” will be 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 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, DNS clients, etc. DDNS eliminates the need for any additional configuration of DNS for each host address change. Novell DNS server supports the following DDNS mechanisms:

  • Novell DDNS, a mechanism by which Novell DHCP servers update Novell DNS servers
  • RFC 2136-based dynamic updates

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

NOTE:Do not edit the contents of the journal file.

Novell DDNS

The Dynamic DNS (DDNS) feature of Novell DNS/DHCP Services provides a way to update DNS with accurate Address (A) records and Pointer (PTR) records for address assignments made by a DHCP server. Address (A) records map a domain name to an IP address. A Pointer (PTR) record specifies a domain name that points to some location in the domain namespace. These resource records are required for both name-to-address and address-to-name resolutions.

When DDNS is active, the DHCP server updates the DDNS server for the zone, adding or deleting the corresponding Address and Pointer records. The DHCP server also notifies the DDNS server when leases expire, causing the A and PTR records to be deleted.

When the DHCP server grants a lease to a client that is subject to DDNS updates, the DHCP server updates its IP address database and eDirectory to store the transaction. The DHCP server also contacts the DNS server and submits a request for a DNS update.

For DDNS updates, the DNS server requires the fully qualified domain name (FQDN) and the IP address of the client. The DHCP server knows the IP address, but it must assemble the FQDN from the hostname and the subnet’s domain name.

The DNS server usually maintains two resource records for each client. One maps FQDNs to IP addresses using A records. The other maps the IP address to the FQDN using PTR records. When DDNS is enabled and a client receives an address from the DHCP server, the DNS server updates both of these records.

When a client loses or ends its lease and is subject to DDNS updates, the DNS server receives the DDNS update request and deletes the PTR and A records associated with the client.

NOTE:While using the Novell DHCP server, both the forward and reverse zones must be designated primary on a single server.

2136 Dynamic Update

Novell DNS server supports dynamic updates complying the RFC 2136 standards. This support provides the ability to update various types of resource records into DNS under certain specified conditions. Dynamic update is fully described in RFC 2136.

2136 dynamic update can be enabled or disabled on a zone-by-zone basis, by specifying the allow-update filter for the zone. It grants permission to the clients to update any record or name in the zone.

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 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:

NOTE:No zone transfers-in will be initiated if it fails while the zone transfer is taking place. The changed data will be overwritten during the next zone transfer.

Full-Zone Transfer-In

The secondary server receives a full zone transfer-in (AXFR) into a different zone database. After the complete zone data is received, the server will replace the old database with the new one, and will try to identify the difference between the existing zone database and the new database that is received. This difference is then applied to eDirectory for better performance.

For more information on DNS AXFR, refer to RFC 1034.

Incremental Zone Transfer-In

Incremental zone transfer-in (IXFR) is considered to be a more efficient zone transfer mechanism than AXFR because it transfers only the changed data of the zone. IXFR transfers only the modified data using the journal file maintained by the DNS server. When a server gets an IXFR request (which has the current SOA serial number of the requester), the server looks into the JNL file to get the modified data from that SOA serial number to the latest SOA serial number and returns the data to the requester.For more information on DNS IXFR, refer to RFC 1995.

1.3.6 ICE Zone Handlers

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 using the command line interface, which will be 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. 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.

Operation

Source Handler

Destination Handler

Import (read from file)

Zone

LDAP

Export (read from eDirectory)

Zone

Zone

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 will automatically detect and update 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.

NOTE:During fault tolerance mode operation, eDirectory might not be available for all zones. Operations other than dynamic update and zone-in are supported for zones that are unavailable.

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 (version) SOA serial number of the zone (sent through the notify mechanism) is the newer compared to the current (version) 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 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. 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 will randomly shuffle 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; and 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 will forward to the server that can do it, and that server will query 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. So 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 will be forwarded to 10.10.10.2. See DNS Namespace. Now forwarding is possible at zone level as well. When forwarders are are configured at zone level, they override the forwarders list configured at server level.

NOTE:The forwarding list syntax is different from the Bind 9.2 syntax for forwarders.

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 is 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, 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 will block 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:

  • Centralized eDirectory-based DNS configuration and management. Configuration must typically be done on a per-server basis with non-Novell DNS servers.
  • DNS data is centrally managed in eDirectory. So, all servers associated with a zone become primary or secondary. That is, you get the benefit of all zones being primary, as opposed to a single zone being primary.
  • DNS zone data is replicated using eDirectory replication, which eliminates the need for explicit DNS replication.