Configuring DNS

Last published : Jun 12, 2026
Optionally, using DNS custom resource you can configure a DNS resource that updates the DNS server entries in the event of a failover or migration. The DNS CR must to be separately applied on all DR clusters. When configured, the DNS CR monitors the resource records for the hostname and IP address mappings on the DNS servers. When the Disaster Recovery Plan is configured, the DNS pointer can be provided in the Disaster Recovery Plan CR. Whenever, the DR plan is activated on any primary cluster, the configured DNS is also activated with the provided hostname and IP addresses. When the disaster recovery plan is migrated, the DNS entries from the primary site are removed and the DNS entries on the secondary site are updated.
DNS resource states can be as follows:
State Description
INIT Default state, not active.
OFFLINE Corresponding DNS resource is offline. State on non-active cluster.
ONLINE DNS entries are configured and DNS resource is online. State on the active primary cluster.
FAULTED Underlying DNS resource is faulted
Applicable only to Secure Linux DNS
  1. Following steps are the prerequisites for SampleDNS.yaml. DNS private keyandDNS key must be added to infoscale-dns-secret.
    • Run the following command on the master node:
cat dns.private | base64
Copy and remove all unnecessary spaces from the \<dns private key\> that is displayed.
  • Run the following command on the master node:
cat dns.key | base64
Copy and remove all unnecessary spaces from the \<dns key\> that is displayed.
  • Run the following command on the bastion node to generate the keys:
kubectl get secret -n infoscale-vtas |grep infoscale-sds-dns-secret
Use the output in the following command.
  • Run the following command on the master node and add the keys:
kubectl edit secret <output for infoscale-sds-dns-secret> -n infoscale-vtas
apiVersion: v1
data:
    dns.private: <dns private key>
    dns.key: <dns key>
kind: Secret
Note: You can add thedata:section if it is not present in the file.
  • Save and close the file.
  • Run the following command to verify whether addition of keys is successful:
kubectl get secret infoscale-dns-secret -n infoscale-vtas -o json
Review the output as under:
{
    "apiVersion": "v1",
    "data": {
        "dns.key": "\<dns key\>",
        "dns.private": "\<dns private key\>"
    },
    "kind": "Secret",
.
.
  • The private key files are created in /etc/vx/dns-certs/. You can run the following command on any of the InfoScale pods.
ls -l /etc/vx/dns-certs/dns.*
Review the output as under:
lrwxrwxrwx. 1 root root 18 Oct 18 05:10 /etc/vx/dns-certs/dns.key
                                                -> ..data/dns.key
lrwxrwxrwx. 1 root root 18 Oct 18 05:10 /etc/vx/dns-certs/dns.private
                                              -> ..data/dns.private
  1. Edit /infoscale-yamls-v9.1.2/DR/SampleDNS.yaml as under:
    Note: Ensure that this resource is applied in the same namespace as that of data replication configuration resource.
    apiVersion: infoscale.veritas.com/v1
    kind: DNS
    metadata:
      name: \<Name of DNS\>
      \#namespace: \<Enter the namespace\>
    spec:
      \# Domain name for the DNS
      domain: "\<Add example.com here\>"

      \# (optional) Path for the file containing private TSIG key,
      \# required for secure DNS updates.
      \# Configure only for UNIX based DNS server
      \#tsigKeyFile: "/etc/vx/dns-certs/dns.private"

      \# (optional) The list of primary master name servers in the domain.
      \#stealthMasters: ["1.2.3.4"]

      \# (optional) An association of DNS resource record value
      \# Specify the key values in map format
      \#resRecord:
            \#"HostName_1" : "100.200.30.41"
            \#"HostName_2" : "100.200.30.42"
            \#"HostName_3" : "100.200.30.43"
            \#"www" : "HostName_1"
            \#"abc" : "HostName_2"
            \#"xyz" : "HostName_3"

      \# (optional) Time to Live value,
      \# in seconds for DNS entries in the zone
      \# default value is 86400
      \#ttl: 86400

      \# (optional) Time in seconds after which DNS agent
      \# attempts to refresh resrecords on DNS server
      \#refreshInterval: 0

      \# (optional)  Set to "true" if the DNS server that
      \# you have configured is a Windows DNS server and
      \# only if it accepts secure dynamic updates
      \# default is false
      \#useGSSAPI: false

      \# (optional) Set to "true" if you want to clean up all
      \# the existing DNS records for the configured keys
      \# before adding new records default is false
      \#cleanRRKeys: false

      \# (optional) Set to "true" if DNS online should create PTR records
      \# for each RR of type A or AAAA
      \# default is false
      \#createPTR: false

      \# (optional) Set to "true" if if DNS offline should remove all records
      \# defined by ResRecord
      \# default is false
      \#offDelRR: false
    Note: name,namespace, anddomainare mandatory here. UpdatetsigKeyFilefor secure DNS only.
    1. Run the following command on the master node:
    kubectl apply -f /infoscale-yamls-v9.1.2/DR/SampleDNS.yaml
    1. To verify whether DNS resource is created successfully, run the following command on the master node:
    kubectl -n infoscale-vtas get dns.infoscale.veritas.com/Name of DNS
    1. Review output similar to the following:
    NAME        DOMAIN        STATE
    Name of DNS example.com   INIT
Note: You must create a DNS resource with its attributes on each member cluster as DNS CR is not synchronized across peer clusters.
Related information