Set Reverse DNS (PTR) for Your IPs: Portal and API

Method 1: In the portal

Open the IP Addresses page in the left-hand menu. It lists every address on your account, grouped under the server or cloud instance that holds it. The groups start collapsed: click a server name to open one, or use Expand all at the top right. The search box filters as you type, on IP, hostname or current rDNS, and the IPv4 / IPv6 pills narrow it further.

A listed address

1. Find the row and hover over the rDNS / PTR cell. A pencil icon appears; click it.
2. Type the hostname (for example mail.example.com) and press Enter or click the green tick. Esc backs out without saving.
3. A green rDNS updated confirmation pops up, and the row now shows the new value.

To clear a PTR, open the editor, empty the field and save. A new address may come with a default PTR such as ip4-203-0-113-10.rdns.netrouting.net. Swap it for your own whenever you like.

Any address in a delegated block

When a whole block is delegated to your server (anything from a /29 up to a /23, or an IPv6 /64), every address in it is yours, but only the ones somebody has already named show up as rows. The others aren't listed, and they don't have to be. You can name any of them directly.

1. Expand the server. Under Delegated blocks you'll find each block, with its CIDR and usable range.
2. On that block, click Set rDNS on an address….
3. Enter the address (any usable one from the range) plus the hostname, then save.
4. The address shows up as a row with its PTR. It's recorded on our side the first time you name it. The block's network, gateway and broadcast addresses are refused.

The same form handles reverse DNS for IPv6. A /64 is never enumerated, so you won't find its addresses in rows: you name them through the block form (or the API).

Each change lands on the Activity page as “Set reverse DNS for 203.0.113.10 to mail.example.com”, along with who made it and when.

Method 2: With the API

You need a key with the IPs scope (ips.write). Create one under Account → API Keys, tick IPs, then copy the key as soon as it appears, because it's only shown once. Full reference: api.amoni.app/v1/docs.

You can write a PTR two ways. By address is the one you'll usually want: it works for any address you own, listed yet or not, and it's the only way to name an address inside a large or IPv6 block. Writing by row id still works for addresses that are already listed.

1. List your addresses and blocks

curl -s https://api.amoni.app/v1/ips \
  -H "Authorization: Bearer nr_live_..."

Addresses come back grouped by the resource that holds them, and each server group also lists its delegated blocks under prefixes, usable range included:

{
  "success": true,
  "data": {
    "servers": [
      {
        "id": "srv-1042",
        "type": "server",
        "name": "web1.example.com",
        "location": "Amsterdam",
        "ips": [
          {
            "id": 4821,
            "address": "203.0.113.10",
            "ip_version": 4,
            "dns_name": "ip4-203-0-113-10.rdns.netrouting.net",
            "is_primary": true,
            "prefix_length": 29
          }
        ],
        "prefixes": [
          {
            "id": 524,
            "prefix": "203.0.113.8/29",
            "ip_version": 4,
            "usable_from": "203.0.113.10",
            "usable_to": "203.0.113.14",
            "usable": 5
          }
        ]
      }
    ],
    "total_ips": 1,
    "total_prefixes": 1,
    "total_servers": 1
  }
}

usable holds a count for IPv4 and null for IPv6, since those blocks are too large to count. The listed ips are only the addresses someone has already named. Any other address between usable_from and usable_to is yours to name.

2. Set the PTR by address

Send the address itself plus the hostname, with no id. It works the same for a listed address, an unlisted one inside one of your blocks, and IPv6.

curl -s -X PUT https://api.amoni.app/v1/ips/rdns \
  -H "Authorization: Bearer nr_live_..." \
  -H "Content-Type: application/json" \
  -d '{"address": "203.0.113.12", "dns_name": "mx.example.com"}'

{
  "success": true,
  "data": {
    "id": 11687,
    "address": "203.0.113.12",
    "dns_name": "mx.example.com",
    "created": false,
    "message": "Reverse DNS updated."
  }
}

The response carries the address's id, which you can then pass to PUT /v1/ips/{id}/rdns and GET /v1/ips/{id}. created comes back as true the first time you name an address that wasn't listed yet. To clear a PTR, send an empty string: {"address": "203.0.113.12", "dns_name": ""}.

3. Or set it by id

If the address is already listed under ips, writing by its id works too:

curl -s -X PUT https://api.amoni.app/v1/ips/4821/rdns \
  -H "Authorization: Bearer nr_live_..." \
  -H "Content-Type: application/json" \
  -d '{"dns_name": "mail.example.com"}'

GET /v1/ips/{id} returns just that address with its recorded dns_name. That's the value we hold, not a live lookup.

What the API will tell you

Have your code branch on the HTTP status and on code. The error text is meant for people and can be reworded. When a field fails basic validation, the answer comes in the framework's own shape, {"message": "…", "errors": {"field": ["…"]}}, without success or code, so for those, branch on the status alone.

Bulk example: name a whole delegation, no ids

Writing by address turns a whole delegation into a loop over its usable range. With a file ptrs.txt holding one address hostname pair per line:

#!/usr/bin/env bash
KEY="nr_live_..."
while read -r addr name; do
  curl -s -X PUT "https://api.amoni.app/v1/ips/rdns" \
    -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \
    -d "{\"address\": \"$addr\", \"dns_name\": \"$name\"}" \
    | jq -r --arg a "$addr" '"\($a): \(.data.message // .error)"'
done < ptrs.txt

To build ptrs.txt from the block itself, read prefixes[].usable_from and usable_to from GET /v1/ips and expand the range with your own tooling. Nothing needs to be listed beforehand; naming an address is what puts it on the list.