This recipe fits the case where several hostnames must be created for a new service, such as api, app, or status. The flow combines inventory, creation, and direct verification.

Prerequisites

• an API key with access to the DNS endpoints
• an existing zone managed through regfish DNS
• target values for the new hosts, such as IP addresses or CNAME targets
• a naming convention for technical and public hostnames

Step 1: Inspect the existing zone

Before creating new hosts, inspect the current zone so you can avoid collisions and detect early whether a hostname is already in use.

curl --request GET \
  --url 'https://api.regfish.com/dns/example.com/rr' \
  --header 'x-api-key: YOUR_API_KEY'

Step 2: Create the first host

For example, create an API host with a direct IPv4 target.

curl --request POST \
  --url 'https://api.regfish.com/dns/rr' \
  --header 'content-type: application/json' \
  --header 'x-api-key: YOUR_API_KEY' \
  --data '
{
  "type": "A",
  "name": "api.example.com.",
  "data": "203.0.113.20",
  "ttl": 300,
  "annotation": "bootstrap-api"
}
'

The response returns the new id, which should be stored for verification.

Step 3: Create another host as a CNAME

For web or routing entry points, a CNAME is often a good fit.

curl --request POST \
  --url 'https://api.regfish.com/dns/rr' \
  --header 'content-type: application/json' \
  --header 'x-api-key: YOUR_API_KEY' \
  --data '
{
  "type": "CNAME",
  "name": "app.example.com.",
  "data": "api.example.com.",
  "ttl": 300,
  "annotation": "bootstrap-app"
}
'

Step 4: Verify the created records directly

Once you have stored the RRIDs returned by the create calls, fetch the records individually.

curl --request GET \
  --url 'https://api.regfish.com/dns/rr/5001' \
  --header 'x-api-key: YOUR_API_KEY'

Check:

• that id matches the value returned by the create call
• that name, type, and data were stored correctly
• that ttl and annotations were written as intended

Practical notes for production workflows

• always inspect the zone before creating new records
• use consistent TTLs for newly bootstrapped service records
• store technical origin or service names in annotations
• keep the new RRIDs immediately so later updates remain explicit
• treat bootstrap and later desired-state synchronization as separate workflows

Result

This workflow lets you add new hosts to an existing zone quickly and in a controlled way. It is especially useful for new services, staging environments, or standardized platform provisioning.