How to Configure Access Zone DNS Dual Delegation

• Abstract:
• Unsupported Configurations
• Delegation
• FAQ Questions
• Does support include my DNS vendor?
• My DNS uses forwarding feature is this the same thing as Dual delegation?
• Should I delegate with IP address?
• Can two NS records be added to the delegation to use Primary and Secondary Subnet Service IP ahead of time to simplify failover and remove the DNS manual step post failover?
• Can dual delegation be used without Eyeglass?
• Will Dual Delegation support SMB and NFS failovers?
• How to setup the dual delegation?
• How does this work with DNS?
• DNS Return codes
• DNS Return Message
• DNS Response Code
• Function

Abstract:

This technical note covers Dual Delegation, answers key questions, how to set it up and how it works, with DNS.

Unsupported Configurations

1. DNS Forwarding is untested and not recommended.  Name server delegation is the recommended method to configure your DNS servers.  This is often used with Infoblox.
2. Do not disable recursive queries on your DNS server.  This is untested and not recommended.
3. Do not use CNAME's that point to Smartconnect names and do not create a loop that uses CNAME's within other resource records.
   1. Dell Isilon documentation states CNAME's should not be used https://www.delltechnologies.com/resources/en-us/asset/white-papers/products/storage/h16463-isilon-advanced-networking-fundamentals.pdf
      1. 8.10.2 SmartConnect zone aliases as opposed to CNAMEs
      2. SmartConnect zone aliases as opposed to CNAMEs A Canonical Name (CNAME) record is a DNS resource mapping one domain to another domain. CNAMEs are not recommended with OneFS, as it is not possible to discover which CNAME points to a given SmartConnect zone name. During a disaster recovery scenario, CNAMEs complicate and extend the failover process, as many CNAMEs must be updated. Further, Active Directory Kerberos does not function with CNAMEs. Zone aliases are the recommended alternative.  OneFS provides an option for creating SmartConnect zone aliases. As a best practice, a SmartConnect zone alias should be created in place of CNAMEs. To create a SmartConnect zone alias, use the following command: isi networks modify pool --add-zone-aliases= Once the SmartConnect zone alias is provisioned, a matching delegation record must be created in the site DNS, pointing to a SmartConnect Service IP (SSIP).
      3. The DNS RFC states  https://tools.ietf.org/html/rfc1912
         2.4 CNAME records
         
         
         A CNAME record is not allowed to coexist with any other data
         1. RFC 1912 Common DNS Errors February 1996
            Don't use CNAMEs in combination with RRs which point to other names
            like MX, CNAME, PTR and NS. (PTR is an exception if you want to
            implement classless in-addr delegation.) For example, this is
            strongly discouraged:
         2. podunk.xx. IN MX mailhost
            mailhost IN CNAME mary
            mary IN A 1.2.3.4
            
            

Delegation

Let's review Access Zone failover with Eyeglass at a high level before explaining how “Dual Delegation” works.   It involves SmartConnect zones applied to IP pools failing over.   This means creating an alias on the target PowerScale that existed on the source cluster IP pool.   Once this is completed,  DNS delegation records are based on NS or name server records that point at the Subnet Service IP servicing the IP pool involved in the failover.

The IP Pools are updated to forward SmartConnect zone lookups to the newly active clusters subnet Service ip with the newly created IP alias on the IP pool.

Skip the reading and watch the video 5M on how to setup Dual Delegation with Microsoft DNS (other DNS vendors work as well, the concept is the same).

Continue reading below for details and how it works.

Eyeglass automates this process during failover BUT the source cluster SmartConnect Zone is renamed (Preserved for failback operations), and leaves a simple breadcrumb zone that remains that is prefixed with igls-original-whatever-the-zone-name-was.  This rename operation has a second benefit, in that the source cluster Service IP will no longer answer any queries that are sent to the source cluster Subnet Service IP.

(see diagram below) DNS resolution BEFORE failover where typically on only a single NS record points at Primary cluster.

(see diagram below) DNS resolution AFTER manually updating the NS record to point at the Service IP of the secondary cluster.

FAQ Questions

Does support include my DNS vendor?

Support examples are provided as examples using Microsoft DNS, all other DNS vendor solutions should use the vendor documentation for creating Name server records.  Support contract does not include support for DNS itself and how to guides for procedures should come from the DNS vendor on how to create name server records.

1. My DNS uses forwarding feature is this the same thing as Dual delegation?

2. 1. No DNS forwarding is not the same thing and is not based on DNS standards and is implemented differently by DNS vendors.  You can use DNS forwarding but this guide will no longer be of any value and no DNS debug tools like nslookup or DIG will work to validate DNS forwarding configurations.  Eyeglass Dual DNS validation will need to be disabled if you choose to use DNS forwarding and support will not be able to assist to validate your configuration.  All DNS vendors can use Name Server records.  This is our recommendation for the above reasons.

3. Should I delegate with IP address?

4. 1. The examples show IP address for simplicity but A records should be used in the name server delegation records to follow DNS best practices.

5. Can two NS records be added to the delegation to use Primary and Secondary Subnet Service IP ahead of time to simplify failover and remove the DNS manual step post failover?

1. Answer:  Yes, this is possible and removes yet another step in the failover when using Access Zone Failover

6. Can dual delegation be used without Eyeglass?

1. Answer: no without Eyeglass, this configuration can not be used.  This is because the Primary cluster SmartConnect Zone needs to be manually removed or renamed, Eyeglass turns this into an Atomic automated process during failover when the Secondary cluster file system is made writeable (the only time you need this functionality)

4. Will Dual Delegation support SMB and NFS failovers?

1. Answer: Yes, both protocols benefit from this feature with SMB handling this better since retrying failed mounts requires clicking on the drive letter or accessing the UNC again to look up the name to ip address.    NFS clients will require unmount and remount since they mount an ip address after name resolution has completed, even if used in the /etc/fstab file with an FQDN.  Script Engine can now be focused  entirely on host side automation without needing and DNS updates

How to setup the dual delegation?

Simple, delegate the SmartConnect Zone with two NS records #1 to primary cluster and #2 the Secondary cluster SSIP that answers DNS queries for the IP pool.

Let's review how this works.  The following two diagrams show the DNS setup before and after failover with Eyeglass.

How does this work with DNS?

Answer:  

1. The DNS server can issue queries for SmartConnect Zone userdata.ad1.test to either Name server record.
2. If a query is sent to the Secondary Cluster before failover the PowerScale answers the query code 5 or Refused.  

NOTE: apply igls-original-<production cluster smartconnect name>, dual delegation requires a SmartConnect name to exist on the target IP pool.  We recommend the syntax above.   Also NOTE detection of the igls-original prefix on an Access Zone pool will update the DR dashboard with FAILEDOVER state.  

7. This tells the DNS server to re-issue to the second name server record to satisfy the query.
8. Since the Primary cluster is configured for this SmartConnect Zone, it will answer the query from one of IP addresses in the IP pool as expected.
9. The DNS server returns the IP address provided to the client that issued the query.
10. done.

Failover Steps

1. Same as above except Eyeglass has disabled the Primary cluster SmartConnect Zone name with prefix igls-original-xxxx, and the Primary cluster will respond with DNS return code 5 Refused
2. DNS server re-issues the query to the Secondary cluster SSIP to get the query answered.
3. The above all assumes a TTL of 0 on NS records to avoid caching name to ip addresses which works with the exception of Linux mount commands.  
4. If a real-DR event occurs versus a controlled failover where both clusters are reachable, the last step would be to ensure the Primary cluster is not ip reachable (if partial disaster), and prevent this cluster from coming up again post DR Event, so that it does not answer DNS queries again or simple remove the entry from DNS..  This is standard practice but mentioned for completeness.  

  Let's review the wireshark traces below of a failover from a DNS view of a Linux Client.

1. Linux Client 172.31.1.101 issues query to userdata.ad1.test

2. DNS server source sends query to Primary cluster SSIP (no longer the active cluster)

3. Primary Cluster (ip 172.31.1.200) with igl-original renamed Smartconnect Zone answers the query from DNS server (172.16.80.6)

5. DNS Server re-issues query to 2nd NS record in this case the Secondary cluster SSIP

6. Secondary cluster responds with new IP address from the target failover over IP pool mapped by Eyeglass for failover

7. Client mount can now succeed using new ip address on the Secondary cluster IP pool to mount shares or exports
8. Done.

DNS Return codes