NS1 status

Articles in this section

NS1 + OpenStack Designate Integration

  • Updated
Follow

Overview

OpenStack is a cloud platform that provides APIs to orchestrate bare metal, virtual machine (VM), and container resources on a single network. As widely used open-source software for building public and private clouds, OpenStack enables control of large pools of computing, storage, and networking resources--all managed and provisioned through APIs with common authentication mechanisms.

Designate is a project within OpenStack’s ecosystem of services for running clouds. It allows users and operators to manage DNS records, names, and zones via a REST API, and it can configure existing DNS name servers to contain those records.

The NS1 + OpenStack Designate integration allows you to manage your NS1 DNS resources via OpenStack Designate. The integration supports the default set of DNS records and commands enabled by Designate. Using Designate, you can utilize a common API to manage DNS on multiple DNS providers.

Prerequisites

  • You must have an NS1 Managed DNS account, Cloud-Managed DDI, or NS1 Enterprise DDI (on-premises) version 3.0 or later.

  • You must have installed OpenStack and Designate.

Note

The OpenStack Designate integration works only with NS1 as a secondary DNS provider.

Instructions

For the implementation process, you need to update OpenStack’s DNS server pools via the Designate Manage CLI. A YAML file defines the pool. Installing Designate creates a pools.yaml file (Default: etc/designate/pools.yaml) and sets the designate-mdns IP automatically.

Step 1: Configuring the integration with NS1.

Follow the instructions below to configure the integration.

  1. Edit the pools.yaml file to configure the integration with NS1. OpenStack’s site contains the following example of the NS1 configuration using the pools.yaml file:

    targets:
    - type: ns1
      description: NS1 DNS Server

      # List out the designate-mdns servers from which NS1 servers should
      # request zone transfers (AXFRs) from.
      masters:
        - host: 192.0.2.1
          port: 5354

      # NS1 Configuration options
      options:
        #NS1 XFR container ip and port
        host: 192.0.2.2
        port: 5302
        #NS1 API enpoint IP address or name (Core container). Enter only base address or name.
        #Plugin will generate full api address, e.g. https://192.0.2.2/v1/zones/<zone name>
        api_endpoint: 192.0.2.2
        #NS1 API key
        api_token: changeme
        # If a tsigkey is needed, uncomment the line below and insert the key name, algorithm and value
        # NOTE: TSIG key has to be set manually
        #tsigkey_name: testkey
        #tsigkey_hash: hmac-sha512
        #tsigkey_value: 4EJz00m4ZWe005HjLiXRedJbSnCUx5Dt+4wVYsBweG5HKAV6cqSVJ/oem/6mLgDNFAlLP3Jg0npbg1SkP7RMDg==

    When editing the file, refer to the table below for key differences and commonalities in configuring this integration for NS1 Managed DNS and Cloud-Managed DDI versus Enterprise DDI.

    Managed DNS

    Enterprise DDI

    masters

    host/port

    List out the designate-mdns servers from which NS1 servers should request zone transfers (AXFRs)

    options

    host

    192.135.223.10

    The IP address of your XFR container

    port

    53 (default)

    53 (default)

    API endpoint

    api.nsone.net

    IP address or hostname of the Core container

    API_token

    An API key from your NS1 account. The API key must have permission to create a secondary zone.

    TSIG options

    If TSIG is required, the parameters below are also required. See below for instructions on generating the tsig key.

    tsigkey_name

    The name of the TSIG key

    tsigkey_hash

    The hash algorithm used when generating the TSIG key

    tsigkey_value

    The value of the TSIG key

    Note

    Refer to Managing API keys for details.

  2. Update the pools in Designate.

    $ designate-manage pool update

    For further information on the designate-manage pool command, see here. For details on the YAML file syntax, see here.

Step 2: Configuring the TSIG key

A deployer may need to use TSIG keys to sign AXFR (zone transfer) requests in some situations. If TSIG is required, it needs to be configured on a per-zone basis upon creation, since NS1 does not support a per-host key setup.

The following example uses the OpenStack CLI. When using the OpenStack command-line client, follow these steps for TSIG key configuration:

  1. Generate a TSIG key using any of the available utilities (e.g., tsig-keygen):

    $ tsig-keygen -a hmac-sha512 testkey
key "testkey" {
algorithm hmac-sha512;
secret "vQbMI3u5QGUyRu6FWRm16eL0F0dfOOmVJjWKCTg4mIMNnba0g2PLrV+0G92WcTfJrgqZ20a4hv3RWDICKCcJhw==";
};

  2. Make a POST API call to /v2/tsigkeys, as referenced in the OpenStack API documentation. The resource_id will be the pool_id you configured for NS1 as part of your OpenStack installation.

    openstack tsigkey create --name testkey --algorithm hmac-sha512 --secret 4EJz00m4ZWe005HjLiXRedJbSnCUx5Dt+4wVYsBweG5HKAV6cqSVJ/oem/6mLgDNFAlLP3Jg0npbg1SkP7RMDg== --scope POOL --resource-id 794ccc2c-d751-44fe-b57f-8894c9f5c842

  3. Add the TSIG-related config lines to the pools.yaml file as described above.

Related articles