Skip to main content
Outside service Partner
Hitachi Vantara Knowledge

Configuring DNS for HCP


Domain name system (DNS) is a network service that translates, or resolves, domain names (for example, example.com) into IP addresses for client access. The service is provided by one or more servers, called name servers, that share responsibility for resolving client requests.

An HCP system can exist as multiple domains in the DNS — one for each front-end network defined in the system. Each of these domains must be a subdomain of a DNS domain to which you have administrative access, such as your corporate domain. All nodes that have IP addresses defined for a given front-end network belong to the HCP domain defined for that network.

NoteWebHelp.png

Note: If you enable the management network, you cannot access your front-end network through DNS unless you create secondary zones for the management network.

To enable access to HCP by domain name on any given network, you need to configure the HCP domain for that network in your DNS. To do this, you can use either secondary zones (also called slave zones) or stub zones.

This chapter contains:

A discussion of the advantages of using DNS

A description of zones, secondary zones, and stub zones

Windows and Unix instructions for configuring HCP domains in the DNS

Instructions for verifying the HCP domain definitions

DNS considerations for implementing HCP service by remote systems

For information on domains defined in HCP, see About domains. For information on HCP networks, see About virtual networking with HCP.

NoteWebHelp.png

Notes: 

HCP does not require DNS. For information on using HCP without DNS, see System Management Console URL.

When communicating with a DNS server, HCP may send packets that are larger than 512 bytes. You need to ensure that these packets can pass through your corporate firewall.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

DNS advantages


Using DNS provides several advantages over using IP addresses for access to the HCP system. For example:

When you use a domain name for namespace access, the HCP DNS manager, which runs on all storage nodes, is responsible for distributing client requests among those nodes. If you use IP addresses, you are responsible for ensuring that the processing load is balanced across the HCP nodes.

If an application uses a domain name for access to the HCP system and you change the IP addresses of the HCP nodes, you don’t need to change the application. If the application uses IP addresses and you change the node IP addresses, you need to update the application to specify the new IP addresses.

If both IPv4 and IPv6 addresses are defined for a front-end network, applications can use the domain name associated with that network to access the HCP system from client computers that have IPv4 addresses and from client computers that have IPv6 addresses. If an application uses IP addresses to access the HCP system over a front-end network with multiple IP addresses defined for each node, you need to configure the application to access the HCP system using only the IP addresses that are routable from the client computer on which the application is running.

If you use a domain name to identify the other system when you create a replication link and the IP addresses for that domain are changed on that system, replication continues without interruption. If you use IP addresses to identify the system and the IP addresses for the system change, replication stops until you change the IP addresses in the definition of the replication link.

If you use domain names to identify the systems in a replication topology and you enable DNS failover on those systems, client requests can be automatically redirected to other systems in the topology if the target system fails. If you use IP addresses to identify a system in a replication topology and that system fails, client requests that target that system cannot be automatically redirected to other systems.

For information on replication and DNS failover, see Replicating Tenants and Namespaces.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Zones


The domain names resolved by DNS are divided into zones, where each zone is defined by set of related hostnames. A corporate domain, for example, is associated with a zone.

Each domain you define in HCP is a subdomain of a higher-level domain. In the DNS, you need an HCP domain definition for each combination of network and domain you define in HCP. The IP addresses for each HCP domain in the DNS make up a zone within the zone for the applicable higher-level domain.

For example, suppose that you configure HCP to define two domains, hcp-ma.example.com and hcp-ca.example.com. Suppose also that you configure HCP to define three user-defined networks, net1, net2, and net3, and you configure these three networks to associate net1 and net2 with domain hcp-ma.example.com and associate net3 with domain hcp-ca.example.com. In this case, you need to add three zones to the DNS, one for each of these domain and network combinations:

Domain name: hcp-ma.example.com
Node IP addresses defined for network net1

Domain name: hcp-ma.example.com
Node IP addresses defined for network net2

Domain name: hcp-ca.example.com
Node IP addresses defined for nodes in network net3

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Secondary zones and stub zones


In the DNS, you configure each HCP domain as a secondary zone (also called a slave zone) or as a stub zone. A DNS server in which a given HCP domain is configured as a secondary zone maintains a full copy of the HCP DNS information for that domain and can, therefore, satisfy requests for resolution of the HCP domain name by itself. You might use secondary zones, for example, if the firewall that HCP sits behind is configured to allow client requests for DNS name resolution to go only to a corporate DNS server.

A DNS server in which a given HCP domain is configured as a stub zone gets only partial DNS information for that domain from HCP. Stub zones minimize zone replication and are less resource intensive for the DNS server.

If you enable hidden master or notify for a network, the HCP domain for that network must be configured as a secondary zone, not a stub zone, on each DNS server specified in the network configuration.

Secondary zone and stub zone definitions are basically the same. Each definition lists the IP addresses of master name servers for a domain but does not include individual records for those servers. Those records are stored on the master name servers themselves. The DNS servers get the individual name server records from the master name servers listed in the zone definition.

For each network defined in HCP, HCP automatically generates name server records for all storage nodes that have IP addresses in that network. Each of those storage nodes stores a copy of these records, thereby making each storage node eligible to be a master name server for the applicable domain.

Before HCP can accept client requests that identify the system by a domain name, you need to register some or all of the eligible nodes as master name servers for the applicable HCP secondary zone or stub zone. You register a node by listing its IP addresses in the secondary zone or stub zone definition.

For any given HCP domain, all storage nodes with IP addresses defined for the applicable network can act as name servers for the HCP DNS manager, regardless of whether they’re registered as master name servers. However, for HCP to be accessible over that network, at least one registered node must be running. Therefore, you need to register a sufficient number of nodes for each network to minimize the risk that all registered nodes for a given network will fail at the same time.

TipWebHelp.png

Tip: If HCP has a small number of storage nodes, consider registering them all as master name servers. The more nodes you register, the more distributed the DNS queries will be.

When defining a secondary zone or stub zone for an HCP domain, you specify a fully qualified domain name for the HCP system. This is the name of the domain associated with the network that is defined in HCP.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Configuring an HCP secondary zone or stub zone in Windows


You can use either the GUI or a command line to configure a secondary zone or stub zone in Windows. The following sections present the GUI configuration procedure for Windows. For information on which Windows servers are supported, check the HCP release notes for the version of HCP that you have installed.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Configuring an HCP secondary zone in Windows


To configure an HCP domain as a secondary zone in Windows:

1.Open the DNS manager:

a.In the Windows Control Panel, double-click on Administrative Tools.

b.In the Administrative Tools window, double-click on DNS.

The DNS Manager window shows the hierarchy of zones currently defined in the DNS.

2.In the DNS Manager window, right-click on Forward Lookup Zones under the higher-level zone within which you want to configure the HCP secondary zone. On the dropdown menu, select New Zone.

The New Zone Wizard window opens.

3.In the New Zone Wizard window, click on Next.

4.On the Zone Type page, select Secondary zone. Then click on Next.

5.In the Zone name field on the Zone Name page, type the applicable fully qualified domain name for the HCP system. Then click on Next.

6.On the Master DNS Servers page, for each HCP storage node you want to register as a master name server, in the list box, type the IPv4 and IPv6 addresses assigned to the node for the applicable network. Then press Enter.

When you’re finished adding all the node IP addresses, click on Next.

7.Click on Finish.

The HCP new secondary zone appears in the zone hierarchy in the DNS manager window.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Configuring an HCP stub zone in Windows


To configure an HCP domain as a stub zone in Windows:

1.Open the DNS manager:

a.In the Windows Control Panel, double-click on Administrative Tools.

b.In the Administrative Tools window, double-click on DNS.

The DNS Manager window shows the hierarchy of zones currently defined in the DNS.

2.In the DNS Manager window, right-click on Forward Lookup Zones under higher-level zone within which you want to configure the HCP stub zone. On the dropdown menu, select New Zone.

The New Zone Wizard window opens.

3.In the New Zone Wizard window, click on Next.

4.On the Zone Type page, select Stub zone.

5.Take one of these actions:

oTo configure the stub zone with Windows Active Directory integration:

a.Select Store the zone in Active Directory.

b.On the Active Directory Zone Replication Scope page, select the option for the way in which you want DNS data to be replicated throughout your network.

Then click on Next.

NoteWebHelp.png

Note: You need to configure the stub zone with Windows Active Directory integration if you plan to enable HCP support for AD. For information on doing that, see Configuring Active Directory or Windows workgroup support.

oTo configure the stub zone without Windows Active Directory integration, click on Next.

6.In the Zone name field on the Zone Name page, type the applicable fully qualified domain name for the HCP system. Then click on Next.

7.On the Zone File page, select Create a new file with this file name and leave the default file name in the accompanying field. Then click on Next.

8.On the Master DNS Servers page, for each HCP storage node you want to register as a master name server, in the list box, type the IPv4 and IPv6 addresses assigned to the node for the applicable network. Then press Enter.

When you’re adding all the node IP addresses, click on Next.

9.Click on Finish.

The HCP new stub zone appears in the zone hierarchy in the DNS manager window.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Configuring an HCP secondary zone or stub zone in Unix


With BIND in Unix, zones are defined in the /etc/named.conf file on the DNS servers. In the definition of a secondary zone or stub zone for an HCP domain, you specify:

The applicable fully qualified domain name for the HCP system

The zone type (slave for a secondary zone or stub for a stub zone)

The name of the file you want the system to use to cache DNS query results for faster lookup

A list of the IP addresses of the master name servers for the secondary zone or stub zone (be sure to use all of the node IP addresses assigned to each node for the applicable network)

Here’s a sample zone statement that defines a secondary zone for an HCP domain with the domain name hcp-ma.example.com and four registered master name servers:

zone "hcp-ma.example.com" IN {
type slave;
file "/var/named/slave/hcp-ma.example.com";
masters {192.168.210.15;192.168.210.16;192.168.210.17;192.168.210.18;2001:0db8::101;
2001:0db8::102;2001:0db8::103;2001:0db8::104; };
};

Here’s a sample zone statement that defines a stub zone for the same domain:

zone "hcp-ma.example.com" IN {
type stub;
file "/var/named/stub/hcp-ma.example.com";
masters {192.168.210.15;192.168.210.16;192.168.210.17;192.168.210.18;2001:0db8::101;
2001:0db8::102;2001:0db8::103;2001:0db8::104;};
};

TipWebHelp.png

Tip: From the Networks page in the HCP System Management Console, you can display the Unix zone definition for any network defined in HCP. For more information on this, see Viewing the DNS zone definition for a network domain.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

Verifying the configuration


You can verify that an HCP secondary zone or stub zone is working properly from either a Windows command-prompt window or a Unix shell. In both cases, you use either the dig or nslookup command, depending on which is available. The syntax for this is:

dig|nslookup (admin|nfs|cifs|www).hcp-domain-name

The response to this command should be a list of the IP addresses of all the HCP storage nodes that have IP addresses defined for the network for which the secondary zone or stub zone is defined.

Here’s an example of the output from the nslookup command when six out of the ten nodes in the network are registered as master name servers for the secondary zone or stub zone:

# nslookup www.hcp-ma.example.com
Server: adc1850.example.com
Addresses: 192.168.80.45
2001:0db8::201

Name: www.hcp-ma.example.com
Addresses: 192.168.210.11, 2001:0db8::101, 1192.168.210.12, 2001:0db8::102, 192.168.210.13, 2001:0db8::103, 192.168.210.14, 2001:0db8::104, 192.168.210.15, 2001:0db8::105, 192.168.210.16, 2001:0db8::106, 192.168.210.17, 2001:0db8::107, 192.168.210.18, 2001:0db8::108, 192.168.210.19, 2001:0db8::109, 192.168.210.20, 2001:0db8::10a

If you don’t see the expected node list, the secondary zone or stub zone is not defined correctly.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.

DNS considerations for service by remote systems


When you configure a secondary zone or stub zone for an HCP system, you specify a domain name and the IP addresses of the master name servers for the applicable HCP domain. This causes client requests that identify the system by that domain name to be forwarded to those master name servers.

Namespaces can be configured to accept client requests on HCP systems other than the system targeted by the request when that system is unavailable. To enable this redirection to occur automatically for a namespace:

DNS failover must have been enabled on the target system.

The applicable replication link must be failed over. The applicable replication link is the link between the target system and the system to which requests should be redirected.

The applicable secondary zone or stub zone for the target system must include the IP addresses of the applicable master name servers for the system to which requests should be redirected, where:

oThe applicable secondary zone or stub zone on the target system is the one defined for the data network for the tenant that owns the namespace

oThe applicable master name servers for the system to which requests should be redirected are the ones included in the secondary zone or stub zone for the network with the same name as the tenant data network on the target system

For example, suppose:

The data network for a tenant is the network named net1.

The system targeted by a client request has master name servers with IPv4 addresses 192.168.210.15, 16, 17, and 18 and with IPv6 addresses 2001:0db8::101, 102, 103, and 104 for net1.

The system to which requests should be redirected has master name servers with IPv4 addresses 192.168.24.72, 73, 74, and 75 and with IPv6 addresses 2001:0db8::201, 202, 203, and 204 for net1.

In this case, the secondary zone or stub zone for net1 on the target system would have these IP addresses:

192.168.210.15
2001:0db8::101
192.168.210.16
2001:0db8::102
192.168.210.17
2001:0db8::103
192.168.210.18
2001:0db8::104
192.168.24.72
2001:0db8::201
192.168.24.73
2001:0db8::202
192.168.24.74
2001:0db8::203
192.168.24.75
2001:0db8::204

The secondary zone or stub zone for net1 on the system to which requests should be redirected would have these IP addresses:

192.168.24.72
2001:0db8::201
192.168.24.73
2001:0db8::202
192.168.24.74
2001:0db8::203
192.168.24.75
2001:0db8::204

To enable redirection in both directions between two HCP systems that participate in an active/active replication link, the secondary zone or stub zone for each of the systems must include the IP addresses of the master name servers for the other system.

To enable client requests targeted to one system to be serviced by any of the other systems in a replication topology, the secondary zone or stub zone for that system must include the IP addresses of the master name servers for each of the other systems.

For example, suppose a replication topology includes systems A, B, C, and D. For systems B, C, and D to be able to service requests targeted to system A, the secondary zone or stub zone for system A must include the IP addresses of the master name servers for systems B, C, and D. For systems C, D, and A to be able to service requests targeted to system B, the secondary zone or stub zone for system B must include the IP addresses of the master name servers for systems C, D, and A.

For information on replication and DNS failover, see Replicating Tenants and Namespaces. For information on configuring namespaces to accept redirected requests, see Managing a Tenant and Its Namespaces or Managing the Default Tenant and Namespace.

NoteWebHelp.png

Note: If you are not enabling DNS failover on an HCP system, do not include IP addresses for the master name servers for other systems in the secondary zones or stub zones for that system.

© 2015, 2019 Hitachi Vantara Corporation. All rights reserved.