The Novell DNS service provides the following DNS features:
All DNS configuration is stored in eDirectory, facilitating enterprise-wide management.
A Novell DNS server can be a secondary name server to a zone (DNS data loaded into eDirectory through a zone transfer), or it can be a primary name server.
DNS data can be imported using a BIND Master file to populate eDirectory for convenient upgrades from BIND implementations of DNS.
DNS data can be exported from eDirectory into BIND Master file format.
Root server information is stored in eDirectory and shared by all eDirectory-based DNS servers.
Zone transfers are made to and from Novell servers. Full Zone Transfer-In (AXFR) and Incremental Zone Transfer-In (IXFR) are supported when the server is a designated secondary. Any type of server can perform a zone-out transfer.
A Novell DNS server can be authoritative for multiple domains.
Novell DNS servers maintain a cache of data from eDirectory so they can quickly respond to queries.
A Novell DNS server can act as a caching or forwarder server. Forwarding can be configured both at server and zone level. A forwarder specifies how the behavior of queries is controlled if the server is not authoritative and the answers do not exist in the cache
A Novell DNS server supports fault tolerance when there is an eDirectory service outage.
Novell DNS servers support multihoming.
Novell DNS server software supports shuffling responses to queries that have multiple resource records.
Novell DNS servers support dynamic reconfiguration (automatic detection of the configuration and data changes).
The DNS software in Open Enterprise Server 2 Linux integrates DNS information into Novell 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.
The Novell DNS Service 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 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 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 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
The eDirectory schema extension defines additional objects needed for DNS.
When you select the Novell DNS Service during the OES 2 Linux 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)
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 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 2 Linux 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. iManager and the Java Management Console use the Locator object contents instead of searching the entire tree to display these objects. The Locator object is hidden by iManager and 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:
Figure 1-8 shows an example of a tree with DNS objects.
Figure 1-8 eDirectory Objects for DNS
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:
DNS Server IP Address
Domain Name of the DNS Server
DNS Server Options
Access Control List for zone transfer, query, recursion, notify, etc.
Other additional advanced options to fine-tune the DNS server
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 2 Linux 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:Novell DNS supports underscore character in domain names and Resource Records using Novell DNS server check-names statement for co-existence with Windows DNS servers.
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.
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 Novell DNS server supports the following DDNS mechanisms:
Novell DDNS, a mechanism by which NetWare DHCP servers update Novell DNS servers
RFC 2136-based dynamic updates
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.
The Dynamic DNS (DDNS) feature of the Novell DNS service 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.
A 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.
A 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.
DNS Key provides a means of authentication for dynamic DNS updates and for queries to a secured DNS Server. DNS Key uses shared secret keys as a cryptographically secure means of authenticating a DNS update/query.
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 are initiated if it fails while the zone transfer is taking place. The changed data is overwritten during the next zone transfer.
The secondary server receives a full zone transfer-in (AXFR) into a different zone database. After the complete zone data is received, the server replaces the old database with the new one, and tries 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 (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 identify the modified data, then sends the data to the requester. For more information on DNS IXFR, refer to RFC 1995.
A 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.
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 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.
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.
A Novell 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 Novell Cluster Services.
The Novell 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 Novell 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.
NOTE:The forwarding list syntax is different from the Bind 9.2 syntax for forwarders.
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:
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. You get the benefit of all zones being primary, as opposed to a single zone being primary.
DNS zone data is replicated through eDirectory replication, which eliminates the need for explicit DNS replication.
Decentralized Administration of DNS is possible without accessing the DNS Server console or file system.
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:
flushname name [view]
This section provides information about iManager and the Java Management Console.
iManager can be used to configure and manage eDirectory-based DNS objects and can run on any browser workstation. It does not require the Novell Client or any installed component as a prerequisite. It operates within the common iManager framework and is thus tightly integrated with OES 2 Linux.
For more information, see:
iManager manages one eDirectory tree at a time.
When iManager is started in the browser, the first screen you see is the login screen. You are prompted to provide your username, password, and the eDirectory tree whose objects you want to manage.
Administration authentication in iManager is based on the common authentication mechanism.
To manage objects in a different eDirectory tree, you must log in to the utility again, specifying the eDirectory tree you want to access. Your login identity is displayed at the top of the screen.
Figure 1-12 The DNS iManager Interface
The main screen has three parts: a taskbar at the top of the screen that displays icons for top-level management functions; a left panel that displays roles, tasks, and other administrative functions; and a main panel that allows you to manage role-based and administrative tasks.
For more information on the iManager management interface, see Novell iManager 2.7.4 Administration Guide.
The DNS services have been logically organized into roles and tasks in a way that is intuitive to network administrators. Each role consists of a set of tasks arranged in a manner that is hierarchical, top-down, and easy to administer.
To view the roles, click theicon on the taskbar.
The tasks under each of these roles are logically arranged in a top-down manner with the option to configure DNS scope settings at the head of each role. A role, depending on its current state, is preceded by a plus or a minus sign. An administrator can expand a role such as DNS to see the tasks it contains or collapse it for a more concise view.
The organization of roles and tasks follows the containership rules of object creation and manipulation in DNS. For example, if you expand the DNS role on the left pane, the logical tasks this role contains appear under it. At the top is the Scope Settings task. This is followed by DNS Server Management, which allows you to specify the location of the Locator object and the administrative scope for the session. At the next level is Zone Management, which manages zones handled by DNS servers. The Resource Record Management allows you to manage resource records contained within a zone. The DNS Key Management allows you to create, modify, and delete DNS Key objects. DNS Key provides a means of authentication for dynamic DNS updates and for queries to a secured DNS Server.
Each task is associated with a set of operations that appear in a drop-down menu on the main panel when you click the task.
For example, to create a new DNS zone, clickThis launches the Zone Management window in the main panel of the screen. Select from the drop-down menu and click to open the Create New Zone window, where you can proceed with the task of creating a new zone.
You can select one object, more than one object, or all objects for deletion with the multi-select delete feature.
IMPORTANT:For improved performance, configure the DNS scope settings before you start using iManager.
The Java Management Console can be used to configure and manage eDirectory-based DNS objects. It is supported on Windows XP and Windows Vista. It is an independent executable Java application. It can be launched through Windows by using the Programs menu. ClickIt can also be launched by double-clicking the shortcut icon created on the desktop.
When the Java Management Console is launched, it prompts you to select a tree as the target eDirectory context.
The administrator must log in to the desired eDirectory tree before launching the Java Management Console. 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-13 shows the main user interface window for DNS services.
Figure 1-13 DNS Java-based Management Console User Interface
For more information, see:
DNS objects can be accessed via thetab. 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 be 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
Objects that can be created
DNS Server, Zone
DNS Server, Zone
DNS Server, Zone, and Resource Record
DNS Server, Zone, and Resource Record
DNS Server, Zone, and Resource Record
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 thecheck box.
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-14 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
When Our Network, Subnet, Subnet Address Range, IP Address, DHCP Server, Shared Network, All Zones, Zone, DNS Server, RRSet, or Resource Record is the selected object
When Subnet, Subnet Address Range, Shared Network, Zone, RRSet, Resource Record, DHCP Server, or DNS Server is selected
When fields have been changed for updates or changes
Enabled for DHCP Service
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-15 shows the status bar and the DNS server icon. The status bar is at the bottom of the figure.
Figure 1-15 DNS Status Bar
Server icons are displayed in the lower portion of the Management Console.
Figure 1-16 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-16 DNS Server Icons
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 server, DNS zone, can be created in any context. After a new DNS object has been created, iManager grants the Read and Write rights to the Locator object. 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.
iManager 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 and iManager. However, during installation if these contexts are specified, then you can create the locator object.
Locator object can be created in the Top, treeroot, 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 and iManager.