Configuring Secure64 Support
A note on Ports
ProVision uses port 22 to communicate with and configure Secure64 infrastructure - please ensure that this is addressed in any ACLs/firewalls
ProVision also uses port 53 to do zone checks if the DNS Module is enabled and in use. Please ensure that your Secure64 infrastructure is configured to accept DNS lookups from the ProVision server
The initial setup of the Secure64 Authoritative server is as follows:
Step 1: Create an nsd.conf file under the root directory / of your S64 Auth server
DO THIS
Make sure to add the line include: 6connect_nsd.conf to the nsd.conf file
[authdnsadmin@Secure64DNS]# cat nsd.conf server: ip-address: 50.198.192.141 axfr-logfile: /axfr_log/axfr.log axfr-logfile-flush-count: 1 axfr-logfile-max-size: 100000 axfr-logfile-max-size: 10 request-logfile: /request_log/request.log request-logfile-flush-count: 10 request-logfile-max-size: 1000000 request-logfile-max-files: 10 include: 6connect_nsd.conf
Step 2: Make a directory for 6connect ProVision to push zone files to on the Secure64 DNS Server
[authdnsadmin@Secure64DNS]# mkdir test12 [authdnsadmin@Secure64DNS]# ls /: 322 2013-08-19 06:07:42 nsd.conf <DIR> 1024 2013-08-16 17:30:12 test12
Step 3: Setup and Configure 6connect ProVision for your Secure64 DNS Server
To create a new server, start from the DNS Tab, select the DNS Servers sub menu. Then, click the "Add Server" button next to "DNS Server List".
This will open the "Server Settings" page.
Server Settings
1) Set Server Common Settings
In the "Common Settings" section of Server Settings, enter the new server's Display Name (the name that will appear on the ProVision interface), the FQDN / IP, server type, DNS service type, and desired parent Resource (may be left at the default Top Level Resource). For Secure64 servers, ensure that DNS Service is set to "Secure64 Authority", "Secure64 x86 Authority", "Secure64 KNOT Authority", or "Secure64 Cache".
2) Set Server Specific Settings
The next section is entering server service-type specific settings. The options visible in this section will depend on the "DNS Service" type chosen under "Common Settings".
Here, we see the fields for Secure64 server settings.
Enter the server Username, Password, Port, Remote Directory, Named Conf. Path, and whether to enabled SNMP.
For SSH Public Key Authentication and Dynamic Option updates, click on the ON / OFF toggle to select "ON" or "OFF" for each as needed.
After entering the server-specific settings in this section, you can click the "Test Connection" button at the bottom right of the page to test the server connection and authentication.
A window will pop up showing a success or failure response.
3) Set DNS Group Settings for Server
In the last section, select whether to enable support for exporting DNS Groups as Views (click to toggle ON / OFF), and select a default Group, if desired, to be associated with the server. Zones assigned to the selected Group will automatically be attached to the server.
4) Save Changes
Save your changes when done! Just click the "Save Changes" button at the bottom right of the page.
Step 4: Associate zones to your Secure64 DNS Server(s)
If a default Group was selected while setting up the S64 server, then any zones in that Group will automatically be associated with the server.
Zones may be manually added, moved, or imported into the Group - see Working with DNS Zones and Working with DNS Groups for details on associating zones with Groups.
If zones are to be imported, a DNS Group may be selected during the import process to associate with the zones.
Select the group specified as the default S64 server Group, then import the zones as described in the Import DNS Zones documentation.
OTHER Record Types
When working with DNS Zones and Records, additional record types may be manually added by selecting "Other" when adding a new record.
S64 DNS users can use record type "Other" to add "SYNTH" or "TYPE65464" type records similar to the format below:
$ORIGIN 30 IN TYPE65464 ${p4} PTR ${a4}.pool.example.com. $ORIGIN 600 IN TYPE65464 ${a4} A ${a4} $ORIGIN TYPE65464 ${p6} PTR user${a6}.my.example.com. $ORIGIN 5 IN SYNTH user${a6} AAAA ${a6} $ORIGIN IN SYNTH nptr-${u} NAPTR 10 20 "A" "" "" srv-${u} $ORIGIN IN SYNTH srv-${u} SRV 10 20 1234 srv-addr-${u}
However, arbitrary / other record types are unable to be validated, so use with care!
Step 5: Push Zones to Secure64 Server(s)
Navigate back to the DNS tab, and select the "DNS Servers" tab.
Locate the Secure64 server in the DNS Servers list, and then click the "Push" button under "Actions" at the end of the row.
Step 6: Verify DNS Zone push on Secure64 Server(s)
The result of the Push can be checked/verified by checking the Secure64 server as follows:
Verifying Zone pushes
Login using the designated login account and password
Enable cachednsadmin
ls
Now, verify that the "788 2013-08-21 12:35:04" 6connect_nsd.conf file now exists.
[authdnsadmin@eval138.secure64.com]# ls /: 6728 2013-08-13 00:15:30 nsd.conf 8416071 2013-08-21 12:35:07 nsd.db 788 2013-08-21 12:35:04 6connect_nsd.conf <DIR> 1024 2013-08-21 12:34:50 test12
You can verify the Push contents by doing a cat of the 6connect_nsd.conf
[authdnsadmin@Secure64DNS]# cat 6connect_nsd.conf
AutoGenerated by 6connect ProVision. Do not manually edit.
zone:
name: atestzone.com
zonefile: /test12/6connectGeneric/m/atestzone.com.zone
zone:
name: Testzone2.com
zonefile: /test12/6connectGeneric/m/Testzone2.com.zone
In the example above, two Zones have transferred.
To look at the contents of each zone you can cd to the proper directory /test12/6connectGeneric and find the zone files in an alphabetical directory structure as follows:
[authdnsadmin@Secure64DNS]# cd 6connectGeneric
[authdnsadmin@Secure64DNS]# cd test12
changed to test12
[authdnsadmin@Secure64DNS]# ls
/test12/:
﹤DIR﹥ 1024 2013-08-16 19:43:21 6connectGeneric
[authdnsadmin@Secure64DNS]# cd 6connectGeneric
changed to 6connectGeneric
[authdnsadmin@Secure64DNS]# ls
/test12/6connectGeneric/:
﹤DIR﹥ 1024 2013-08-16 17:30:13 e
﹤DIR﹥ 1024 2013-08-16 17:30:16 m
﹤DIR﹥ 1024 2013-08-16 18:49:21 d
﹤DIR﹥ 1024 2013-08-16 19:43:23 s
[authdnsadmin@Secure64DNS]# cd m
changed to m
[authdnsadmin@Secure64DNS]# ls
/test12/6connectGeneric/m/:
[authdnsadmin@eval138.secure64.com]# ls
5192 2013-08-21 15:35:01 atestzone.com.zone
6758 2013-08-21 15:35:02 Testzone2.com.zone
[authdnsadmin@Secure64DNS]#
Step 7: Validate Zone data in Your Infrastructure
Finally, do a dig of the zones to verify the DNS configuration has been successfully deployed.
Using dig to validate your Secure64 Server installation
; ﹤﹤﹥﹥ DiG SourceT 3.x ﹤﹤﹥﹥ @50.198.192.141 atestzone.com
;; Got answer:
;; ﹥﹥HEADER﹤﹤ opcode: QUERY, status: NOERROR, id: 59591
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;atestzone.com. IN A
;; AUTHORITY SECTION:
atestzone.com. 3600 IN SOA ns1.dns.6connect.net. hostmaster.6connect.net. (2013082102 10800 3600 604800 38400 )
[authdnsadmin@eval138.secure64.com]#
For any questions regarding the integration of Secure64 products into 6connect ProVision, please email 6connect at support@6connect.com, or Secure64 at support@secure64.com
Changing Secure64 Server IP addresses
When you setup ProVision to communicate via SSH to a Secure64 server, a ley/fingerprint is saved to the local hosts file. If you modify the IP address, but do not clear out the hosts file, then ProVision will think this is an attack and prevent communication with the Secure64 server.
To rectify this issue, you may need to reset the host file so that a new SSH host key can be added for the IP address. To do this manually, please follow the following steps:
1) The admin needs to login to the ProVision server via SSH/CLI
2) Open the file “known” in the /tmp folder in your preferred editor (vi, etc.)
3) Delete the line in the file with the server IP/fingerprint
4) Save the changes and exit the editor
To verify the functionality - attempt to connect to the DNS Server(s) using the “Test Server” button from the ProVision GUI
If you have any issues, please contact 6connect support per your Support Agreement/Plan.
Additional Information
For additional information on working in DNS, see the following sections: