Balabit - DNS records (site 1)
Balabit SCB Solution · Config document · referenced from Hardware, cabling and networks and IPMI out-of-band management
dc1-s-xblm001 for management, dc1-s-xblb001 for operation, abhs, xbla, ablm). Chapters 7 and 8 of the same document and the L3 sheet use the newer names, in which dc1-s-xblb001 is the management address 10.11.16.81. Do not take these records as the final state.The A and AAAA records that my design document asked for in the Infoblox DNS of site 1, so that the appliances, their IPMI modules and the cluster addresses can be reached by name. A PTR record was to be created for every A and AAAA record.
| Item | Value |
|---|---|
| Source | My design document, version 0.5 of 2017-12-01 (draft), chapter 4.6, "DNS and NTP services – Infoblox" |
| DNS servers | Infoblox dc1-a-adnsvip001 (10.11.16.145) and dc1-b-adnsvip001 (10.11.18.145) |
| Zones | adm.example.net, mgmt.example.net, example.net |
| Not in it | A zone export or a query that shows what was really created; the PTR records (one sentence only) |
The listing
output 15 lines
### DNS Address records | DNS name | Value | Description | | dc1-a-ablm001.mgmt.example.net | 10.11.15.29 | Balabit SCB - oob-management | | dc1-b-ablm001.mgmt.example.net | 10.11.23.29 | Balabit SCB - oob-management | | dc1-a-abhs001.adm.example.net | 10.11.18.209 | Balabit SCB - ha-secondary | | dc1-b-abhs001.adm.example.net | 10.11.18.210 | Balabit SCB - ha-secondary | | dc1-s-xblm001.adm.example.net | 10.11.16.81 | Balabit SCB – management (VIP) | | dc1-s-xblb001.adm.example.net | 10.11.16.65 | Balabit SCB – operation (VIP) | | scb.example.net | 10.11.16.65 | Balabit SCB – operation (VIP) | | dc1-s-xbla001.adm.example.net | 10.11.18.225 | Balabit SCB – archive (VIP) | ### DNS IPv6 Address records | DNS name | Value | Description | | dc1-s-xblb001.adm.example.net | 2001:db8:a1:c0e::f:1 | Balabit SCB – operation (VIP) | | scb.example.net | 2001:db8:a1:c0e::f:1 | Balabit SCB – operation (VIP) |
The same addresses under the two naming schemes:
| Address | Name in these records | Name in the L3 sheet and chapters 7 and 8 |
|---|---|---|
10.11.15.29, 10.11.23.29 | dc1-a-ablm001.mgmt.example.net, dc1-b-ablm001.mgmt.example.net | dc1-a-ablb001m.mgmt.example.net, dc1-b-ablb001m.mgmt.example.net |
10.11.18.209, 10.11.18.210 | dc1-a-abhs001, dc1-b-abhs001 | dc1-a-ablb001cl02, dc1-b-ablb001cl2 |
10.11.16.81 | dc1-s-xblm001 | dc1-s-xblb001 |
10.11.16.65, 2001:db8:a1:c0e::f:1 | dc1-s-xblb001, scb.example.net | dc1-s-xblb001pro, scb.example.net |
10.11.18.225 | dc1-s-xbla001 | dc1-s-xblb001bck |
1.2.4.1, 1.2.4.2 | none | dc1-a-ablb001cl01, dc1-b-ablb001cl01, marked "not in the INFOBLOX" |
The rename turned dc1-s-xblb001 from the operation name into the management name. The web interface URL in chapter 8 is https://dc1-s-xblb001.adm.example.net/ at 10.11.16.81, and the certificates still carry dc1-s-xblm001. The hosts file lines of my operation how-to map dc1-s-xblb001, dc1-s-xblm001 and even scb.example.net to 10.11.16.81, see the workstation hosts file; that a hosts file was needed at all suggests that the records were not, or not yet, in the Infoblox when the how-to was written. The IPv6 records name only the production address; the management side is IPv4 only.
Checked against One Identity Safeguard for Privileged Sessions 9.0
| As built | Today |
|---|---|
| AAAA records only for the production (user) address | Still consistent with SPS 9.0: IPv6 is for monitored connections, and local services, including the web login, require IPv4 |