Deprecated: Setting up a wildcard DNS entry

The DNS wildcard requirement is deprecated for versions 1.0.8 and higher. A DNS wildcard entry makes all Cloud Pak for Data services automatically reply to any FQDN prefix via the wildcard.

This document uses a sample to show you how to set up a wildcard DNS entry.

It is recommended that you create a DNS entry on the customer DNS server to handle all FQDN prefixes for all services. The wildcard entry is simply *.<FQDN>.

If you do not specify a wildcard entry, you must specify a DNS entry for each service that is deployed. Following is the list of the DNS entries that must be created:
  • icpd-zen.<FQDN>
  • icpd-system.<FQDN>
If you do not specify a wildcard entry, you must specify a DNS entry for each service that is deployed. If you do not have all of these records in your DNS server, you might be unable to access services that you deploy until the DNS records exist. For example, you might be unable to reach the web consoles.

About this task

The sample configuration was written on Red Hat Enterprise Linux 7.6. The bind and bind-utils packages are version 9.9.4. The guidelines should apply to any bind9-based distribution.

A DNS CNAME record is a type of resource record in the DNS that maps one domain name (an alias) to another (the canonical name).

The following example provides an overview of the CNAME and A record configuration for an IBM Cloud Pak for Data System that is installed in the domain. The application's FQDN is and its IP is The DNS server's FQDN is and its IP is

A wildcard DNS entry is a record that answers DNS requests for any undefined subdomain within a defined domain. You create a wildcard record by entering an asterisk (*) and a dot (.) before the defined domain in the A record of a zone file. In the following example, a wildcard record *.cp4ds is created, which resolves to the IP address specified in the CNAME entry for cp4ds. The FQDN for the application is completed by concatenating the CNAME with the $ORIGIN domain that is

The following is a sample of the /etc/named.conf file, which references the domain for which it is authoritative in  2 . The /etc/named.conf file is the default configuration file for the named server. For example:
options {
	directory 	"/var/named";  1  

zone "" IN {
	type master;
	file "testlab";  2  

zone "" IN {
	type master;
  file "";  3  

In this example, the directory option  1  points to the working directory for the name server /etc/named. All non-absolute path names in the named.conf file are expected to be relative to this directory (this includes the zone files that are described in the example). The zone definition  2  defines the zone for which the name server is responsible (its zone of authority).The zone definition  3  describes a reverse lookup (pointer) record for the zone.

Zone file:

The zone file has a standard header format. In the following sample:
  • The A and CNAME type records begin at  4 .
  • The example general record for the application is at  5 .
  • The example wildcard entry is at  6 .

The wildcard entry maps all addresses within the to the cp4ds IP address.

Note that a typical zone file has many more entries than the sample.

$TTL 86400	; 1 day
testlab			IN SOA (
				1906281151 ; serial as YYMMDDhhmm
				3600       ; refresh (1 hour)
				1800       ; retry (30 minutes)
				604800     ; expire (1 week)
				86400      ; minimum (1 day)
$TTL 3600	; 1 hour
gateway			A  4 
ns			A
cp4ds			A  5 
*.cp4ds			CNAME	cp4ds  6 

Using DHCP for the application (cp4ds) address is not supported.

PTR (Reverse-lookup) Zone File:

The pointer zone file has the ’reverse’ lookup information. So, following from the example, the address should resolve to This is shown below at  7 .
$TTL 3600	; 1 hour
11		PTR 7 

The header was left out of the sample, and there would typically be many records in the pointer zone file.

Since,, and all resolve to, there is no PTR record for them.