PDNS API Documentation
The documentation will be recorded in bash using the curl command, with some examples in python v3.8+.
The API is REST and communicates solely via HTTPS with TLSv1.2 as a minimum, although future versions will only allow negotiation from TLSv1.3 due to the security gap with earlier versions and the RTT possibility offered by v1.3.
PDNS-API Versions
There are very few endpoints in version 2.0, and they are intended to dynamically intervene in the configuration of resolvers and authoritative servers.
It is only from version 2.1 onwards that more endpoints are provided, allowing you to build a CRM or an application without needing to use the web interface at all.
Authentication and Methods
Authentication is geared towards Resellers within multi-tenancy. Two headers must be specified to allow authorization:
Reseller |
Authorization |
In the Reseller header goes the crm-id or short-name (not the full long name) of the Reseller.
In the Authorization header goes the APIKEY assigned to the Reseller.
According to the security policy and the orchestration capacity of the organization implementing the API, you can frequently rollover your APIKEYs.
It is recommended to store both data in environment variables, whether for an application (e.g., in a .env) or global to a container or server, e.g., in ~/.bashrc
For example, bash environment variables:
export PDNS_APIURI="https://api-server.cirion.live"
export PDNS_RESELLER="reseller01"
export PDNS_APIKEY="api-key-QueeSihuak2aegai"
Warning
In a future version, APIKEYs will be incorporated at the Company level below a Reseller, e.g., to allow a company the autonomy to implement a failover scheme (e.g., monitoring a mirrored site, and changing the IP to the mirror if the main site goes down) without resorting to their provider.
The allowed methods are
GET |
POST |
PUT |
DELETE |
The GET method is for retrieving information.
The POST method is for introducing a new element or modifying it.
The PUT method is for modifying existing elements.
The DELETE method is for deleting elements.
Note
The examples are mostly shown in a hypothetical bash environment with the described environment variables.
Endpoints v2.0
Below are the v2.0 methods intended to interact with the bind9 configuration, and also to generally retrieve information about the data entered in the web interface.
Retrieving permitted blocks for resolvers (GET)
In the case of resolvers, the blocks they are allowed to access are declared in the web interface. You can retrieve them via the API:
curl -X GET ${PDNS_APIURI}/api/v1/api_trusted_blocks -H "Authorization: ${PDNS_APIKEY}" -H "Reseller: ${PDNS_RESELLER}
This returns a JSON with the blocks declared in the web interface:
[
{
"cidr_block": "184.103.220.0/24"
},
{
"cidr_block": "181.122.241.0/24"
},
{
"cidr_block": "200.187.43.157"
}
]
In python3, the same result could be generated with the following code:
import requests
import sys
import os
reseller=os.environ['PDNS_RESELLER']
apikey=os.environ['PDNS_APIKEY']
apiuri=os.environ['PDNS_APIURI']
try:
response = requests.get( f"{apiuri}/api/v1/api_trusted_blocks",
headers={
'Accept':'application/json',
'Content-type': 'application/json',
"Authorization":f"{apikey}",
"Reseller":f"{reseller}"
}
)
except Exception as e:
print( f"ERROR: al enviar el request {str(e)}" )
sys.exit(-1)
print(response.json())
Retrieving activated RPZ zones (GET, v2.0)
Para los resellers con licencia de Feed RPZ , este endpoint permite obtener las Response Policy Zones activadas.
curl -X GET ${PDNS_APIURI}/api/v1/api_rpz_zones -H "Authorization: ${PDNS_APIKEY}" -H "Reseller: ${PDNS_RESELLER}
Below is the format of a hypothetical result:
[
{
"zone_name": "planisys.phishing"
},
{
"zone_name": "planisys.spam"
},
{
"zone_name": "planisys.malware"
},
{
"zone_name": "coinblocker.srv"
},
{
"zone_name": "porn.host.srv"
},
{
"zone_name": "torblock.srv"
},
{
"zone_name": "drop.ip.dtq"
},
{
"zone_name": "urlhaus.zone"
}
]
Retrieving domain list (GET, v2.0)
The complete list of domains for a reseller is obtained as follows:
Warning
Depending on whether you authenticate with HTTP_RESELLER or HTTP_COMPANY, each with its respective APIKEY, this endpoint returns the list of domains for the Reseller or the Company.
curl -X GET ${PDNS_APIURI}/api/v1/domain_list -H "Authorization: ${PDNS_APIKEY}" -H "Reseller: ${PDNS_RESELLER}"
Warning
This endpoint only returns active domains, meaning domains that have not been suspended. The suspension of companies and domains was introduced in version 2.1.
And here is an example JSON result, with two domains:
[
{
"domain": "assetcrypt.com",
"type": "master",
"master1": "",
"master2": "",
"soa_serial": 2024032003,
"allow_axfr": false,
"tsig": "",
"dnssec": true,
"deploy_dnssec": false,
"acl": "none",
"company": "1-planisys"
},
{
"domain": "psys.ar",
"type": "master",
"master1": "",
"master2": "",
"soa_serial": 2024021305,
"allow_axfr": false,
"tsig": "",
"dnssec": true,
"deploy_dnssec": false,
"acl": "none",
"company": "1-planisys"
}
]
The data received in the JSON for each domain are:
Key |
Explanation |
|---|---|
domain |
domain name |
type |
type is master or slave |
master1 |
if it is a slave, the first master |
master2 |
if it is a slave, the second master |
soa_serial |
the serial of the SOA record |
allow_axfr |
this can be true or false. If true, there must be an ACL specifying who is allowed to copy the domain via AXFR |
tsig |
this is a tsig key to further protect domains that allow zone-transfer or AXFR to other servers |
dnssec |
indicates if DNSSEC is enabled, meaning if there are signed records and rollover is enabled |
deploy_dnssec |
indicates if DNSSEC should be activated for this domain |
acl |
here goes the name of the Access Control List declared to allow zone-transfer of this domain to other servers |
company |
this is the company, within the Reseller, to which this domain belongs |
Retrieving the SOA of a domain (GET, v2.0)
This GET call includes the domain name in the URI, from which you want to retrieve a JSON with the SOA data of the domain assetcrypt.com:
curl -X GET ${PDNS_APIURI}/api/v1/get_soa/assetcrypt.com -H "Authorization: ${PDNS_APIKEY}" -H "Reseller: ${PDNS_RESELLER}"
The result is a JSON with the SOA (Start of Authority) record data
[
{
"mname": "globaldns1.planisys.net.",
"rname": "hostmaster.planisys.com",
"expire_ttl": 604800,
"minimum_ttl": 3600,
"retry_ttl": 3600,
"refresh_ttl": 10800,
"serial": 2024032003
}
]
The SOA information is very important for the domain.
Key |
Explanation |
|---|---|
mname |
Primary Master Name Server |
rname |
Responsible Person’s Email Address |
expire_ttl |
this is the maximum time a secondary can go without refreshing the zone from the primary. Once the maximum time has passed, it stops responding for the zone. |
minimum_ttl |
Specifies the minimum TTL for each record in the zone, for when the TTL is not specified in the record. It is the caching time of the resolvers for each RR (Resource Record) |
retry_ttl |
It is the backoff time a secondary must wait before retrying to transfer the zone from a master, in case of a failed transfer. |
refresh_ttl |
It is the frequency with which the secondary will ask the primary if there is a new version of the zone. |
serial |
Responsible Person’s Email Address |
Note
In PDNS, the refresh_ttl is often overridden by the NOTIFY message, as PDNS generates the zone list with a directive to notify the secondary IPs whenever there is a change.
Warning
The serial is generally in calendar mode, being YYYYMMDDHH (four digits for the year, two for the month, two for the day, two for the hour, or alternatively two digits from 00 to 99). However, the PDNS interface allows you to specify for each domain whether it is in calendar mode or in pure serial mode, which is an incrementing number.
Retrieve Resource Records of a domain (GET)
Example: retrieve a JSON with the Resource Records (records), except the SOA which is retrieved separately, for the domain assetcrypt.com.
curl -X GET ${PDNS_APIURI}/api/v1/domain_rr_list/assetcrypt.com -H "Authorization: ${PDNS_APIKEY}" -H "Reseller: ${PDNS_RESELLER}"|jq
The result is a JSON representing a list of RRs:
[
{
"rr_id": 43214,
"rr_ttl": 3600,
"rr_name": "*.subdom",
"rr_type": "CNAME",
"rr_prio": "0",
"rr_value": "www.planisys.net."
},
{
"rr_id": 37245,
"rr_ttl": 3600,
"rr_name": "@",
"rr_type": "A",
"rr_prio": "0",
"rr_value": "38.83.73.10"
},
{
"rr_id": 112,
"rr_ttl": 3600,
"rr_name": "@",
"rr_type": "AAAA",
"rr_prio": "0",
"rr_value": "2803:bc00::98"
},
{
"rr_id": 917,
"rr_ttl": 3600,
"rr_name": "@",
"rr_type": "NS",
"rr_prio": "0",
"rr_value": "globaldns1.planisys.net"
},
{
"rr_id": 875,
"rr_ttl": 3600,
"rr_name": "@",
"rr_type": "NS",
"rr_prio": "0",
"rr_value": "globaldns2.planisys.net"
},
{
"rr_id": 34103,
"rr_ttl": 3600,
"rr_name": "@",
"rr_type": "MX",
"rr_prio": "10",
"rr_value": "avas-mx-corpmail7-1.planisys.net."
},
{
"rr_id": 229,
"rr_ttl": 3600,
"rr_name": "tipo1conpunto",
"rr_type": "CNAME",
"rr_prio": "0",
"rr_value": "www.assetcrypt.com."
},
{
"rr_id": 136,
"rr_ttl": 3600,
"rr_name": "tipo1sinpunto",
"rr_type": "CNAME",
"rr_prio": "0",
"rr_value": "www"
},
{
"rr_id": 154,
"rr_ttl": 3600,
"rr_name": "www",
"rr_type": "CNAME",
"rr_prio": "0",
"rr_value": "www.planisys.net."
}
]
Note
The value of rr_prio is numeric, but it is returned as a string to facilitate the creation of zones in authoritative servers. It is only necessary for certain records like MX.
Note
The value of rr_id is unique, and it allows you to modify or delete a record.
Delete a Resource Record by ID (DELETE)
You can delete a resource by ID
curl -X DELETE ${PDNS_APIURI}/api/v1/domain_rr/assetcrypt.com -H "Authorization: ${PDNS_APIKEY}" -H "Reseller: ${PDNS_RESELLER}" -d '{ "rr_id": 176 }'
If it doesn’t exist or is not part of the domain specified in the URI, it returns a 400 error
Note
the SOA serial of the zone is automatically incremented by 1 (one)
Create a Resource Record (POST)
Creating an RR within a zone returns its ID.
In this case, we create a record within the assetcrypt.com zone
curl -X POST ${PDNS_APIURI}/api/v1/domain_rr/assetcrypt.com -H "Authorization: ${PDNS_APIKEY}" -H "Reseller: ${PDNS_RESELLER}" -d '{ "rr_ttl": 360, "rr_name": "www", "rr_type": "A", "rr_prio": 0, "rr_value": "123.223.111.222" }'
Warning
The restrictions explained in the PDNS manual for CNAMEs apply, such as the prohibition of overlapping CNAMEs with other records and therefore the prohibition of CNAME in the APEX of the zone, since the SOA record is already present there.
Note
the SOA serial of the zone is automatically incremented by 1 (one)
Note
A reverse zone only accepts NS and PTR records, apart from the SOA which is created along with the zone.
Modify a Resource Record by ID (PUT)
Once you have the ID of an RR, you can modify its TTL, value, or type:
curl -X PUT ${PDNS_APIURI}/api/v1/domain_rr/assetcrypt.com -H "Authorization: ${PDNS_APIKEY}" -H "Reseller: ${PDNS_RESELLER}" -d '{ "rr_id": 176, "rr_ttl": 3600 }'
Note
Once you have the ID, it’s only necessary to send the fields to be modified. In other words, it’s not necessary to repeat everything.
Note
the SOA serial of the zone is automatically incremented by 1 (one)
Retrieve ACLs of a Reseller (GET)
ACLs or Access Control Lists allow transfer permissions to be set for domains that are allowed to be transferred to other servers. In other words, domains whose full content can be copied.
Whenever a domain is allowed to be transferred, IPv4 or IPv6 must be specified individually or in blocks, or a TSIG cryptographic key must be provided, allowing whoever holds it to take a copy of the domain regardless of the source IP.
An ACL has a name and is a list of possible blocks or individual IPs (i.e., /32) IPv4 and/or IPv6, and possibly a TSIG key.
For example, a call to the list of ACLs of a reseller:
curl -X GET ${PDNS_APIURI}/api/v1/get_acls -H "Authorization: ${PDNS_APIKEY}" -H "Reseller: ${PDNS_RESELLER}"|jq
An example of what this endpoint might return: two ACLs, one called ACL1 and the other 1-planisys_globaldns-pdns
[
{
"acl_name": "1-planisys_globaldns-pdns",
"items": [
{
"component": "131.108.40.71",
"comment": "powerdns web interface",
"type": "ipv4addr"
},
{
"component": "143.42.183.85",
"comment": "nj-dns",
"type": "ipv4addr"
},
{
"component": "64.64.107.50",
"comment": "lw-dns",
"type": "ipv4addr"
},
{
"component": "63.251.107.116",
"comment": "inap-dns",
"type": "ipv4addr"
},
{
"component": "2600:3c03::f03c:93ff:fe99:49bd",
"comment": "nj-dns",
"type": "ipv6addr"
},
{
"component": "185.180.8.10",
"comment": "planisys-miami",
"type": "ipv4addr"
},
{
"component": "179.63.248.233",
"comment": "planisys-miami",
"type": "ipv4addr"
},
{
"component": "179.63.248.234",
"comment": "planisys-miami",
"type": "ipv4addr"
},
{
"component": "179.63.249.133",
"comment": "planisys-miami",
"type": "ipv4addr"
},
{
"component": "179.63.249.134",
"comment": "planisys-miami",
"type": "ipv4addr"
}
]
},
{
"acl_name": "ACL1",
"items": [
{
"component": "131.108.40.71",
"comment": "dns1",
"type": "ipv4addr"
}
]
},
]
Endpoints v2.1
These are the endpoints available in version 2.1 as of February 2024.
Retrieve list of Companies (GET)
curl -X GET ${PDNS_APIURI}/api/v1/companies -H "Authorization: ${PDNS_APIKEY}" -H "Reseller: ${PDNS_RESELLER}"
[
{
"crm_id": "vlans",
"name": "Vlans",
"apikey": "ru34wbSYPb",
"suspended": false
},
{
"crm_id": "munibelleville",
"name": "Municipalidad",
"apikey": "8789y3kv0D",
"suspended": false
}
]
Retrieve Company data (GET)
This GET call must include a parameter in the input JSON to retrieve data for a company named “vlans”.
curl -X GET ${PDNS_APIURI}/api/v1/company/vlans -H "Authorization: ${PDNS_APIKEY}" -H "Reseller: ${PDNS_RESELLER}"
The result is a JSON with operational data for that particular company, such as its API key and whether it is suspended or not.
{
"crm_id": "vlans",
"name": "Vlans",
"apikey": "ru34wbSYPb",
"suspended": false
}
Note
If you want to obtain a list of companies managed by the Reseller, you should use the companies method call.
Warning
If the crm_id sent in the URL does not correspond to any Company, the call returns an HTTP 400 along with a JSON: {“msg”:”crmid01 does not exist”}
Modification of Company data (PUT)
You must send a crm_id of the company to be modified in the URL, and the fields you want to modify, including the crm_id itself (only the values listed in the JSON are modified), e.g.
curl -X PUT ${PDNS_APIURI}/api/v1/company/vlans -H "Authorization: ${PDNS_APIKEY}" -H "Reseller: ${PDNS_RESELLER}" -d '{"apikey": "newapikey001", "suspended": true}'
Warning
If the value of suspended is modified, the changes will be effective for all domains of the Company.
Note
If a domain is in a suspended state, it means that the Reseller’s authoritative servers will not announce/publish it.
Warning
If the crm_id is changed, it will be verified to be valid (alphanumeric, with only ‘-‘ and ‘_’ as allowed special characters, and it will all be converted to lowercase as it is a search key).
Warning
If apikey is changed, all spaces, ‘,’ and ‘;’ will be removed, as they are not allowed as part of an API key.
Creation of a Company (POST)
A crm_id must be sent with the previously defined restrictions, a name, and an apikey. The initial state of suspended is False, meaning the company is active so that all domains associated with it are active by default as they are created.
The endpoint checks that the crm_id does not already exist, and that name and apikey are provided as mandatory parameters.
curl -X POST ${PDNS_APIURI}/api/v1/company/nuevaempresa1 -H "Authorization: ${PDNS_APIKEY}" -H "Reseller: ${PDNS_RESELLER}" -d '{ "name":"Nueva Empresa1", "apikey": "newapikey001" }'
If the crm_id already exists, the API returns a 400 error and a message {“msg”:”Company nuevaempresa1 already exists”}
Deletion of a Company (DELETE)
A crm_id must be sent with the previously defined restrictions, and the company’s apikey for security, to confirm the request.
The endpoint checks that the crm_id exists; otherwise, it returns a 400 error with a message {“msg”:”Company empresaxyz does not exist”}.
Warning
This endpoint deletes all domains belonging to the company.
curl -X DELETE ${PDNS_APIURI}/api/v1/company/empresaxyz -H "Authorization: ${PDNS_APIKEY}" -H "Reseller: ${PDNS_RESELLER}" -d '{ "apikey": "company_apikey001" }'
Creation of a master zone (POST)
To create a master zone, you must specify to which company it belongs (crm_id), and a fqdn or Fully Qualified Domain Name (the latter in the URI). The name does not need to be recognized on the Internet, as it may be a new zone or an internal zone. In addition, data for the SOA record must be provided.
The SOA serial type can be numeric or calendar (in the latter case it is YYYYMMDDSS, with SS being a value from 0 to 99). In the case of calendar, the number of changes is limited to 100 per day.
Example:
curl -X POST ${PDNS_APIURI}/api/v1/domain' -H 'Authorization: ${PDNS_APIKEY}' -H 'Reseller: ${PDNS_RESELLER}' -H 'Content-Type: application/json' -d '{"domain": "test2.com", "crm_id": "empresa2", "mname": "globaldns1.planisys.net", "rname": "hostmaster.planisys.com", "expire_ttl": 604800, "minimum_ttl": 3600, "retry_ttl": 3600, "refresh_ttl": 10800, "serial": 2024096000, "serial_type": "calendar"}'
If any data is missing, the endpoint returns a 400 error stating that a field is missing. It also performs consistency checks, e.g., regarding the mname or Master DNS Name, which is automatically set as an NS record when creating the zone, and also creates the SOA record with the provided data.
If the zone already exists within the Reseller, it will return a 400 error with a Duplicate zone message.
The zone is created with the suspended parameter set to False, meaning the zone is activated immediately.
Change of SOA or company of a zone (PUT)
This is a case of changing a zone’s metadata, you just need to provide new values, either for the SOA or the company, or even change the serial_type. It is also used to artificially increment the SOA of a zone:
curl -X PUT ${PDNS_APIURI}/api/v1/zone/dom1.com -H "Authorization: ${PDNS_APIKEY}" -H "Reseller: ${PDNS_RESELLER}" -d '{ "crm_id":"empresa2", "mname": "globaldns1.planisys.net", "rname": "hostmaster.planisys.com", "expire_ttl": 604800, "minimum_ttl": 3600, "retry_ttl": 3600, "refresh_ttl": 10800, "serial": 2200000001, "serial_type": "numeric" }'
Note
It is only necessary to provide the values to be modified
Reverse master zone
Regarding the creation of zones, the following notes apply:
Warning
if the zone ends in in-addr.arpa or ip6.arpa, the zone will be considered reverse instead of forward. This metadata cannot be changed.
Note
Unlike the web interface, where direct notation of a /24 is used, e.g., 123.221.24.0/24 to denote the creation of a reverse zone, in the API we use 24.221.123.in-addr.arpa directly as the zone name. Currently, PDNS only supports /24 zones for PTR records.
Note
For example, an IPv6 zone 0.0.0.0.0.0.c.b.3.0.8.2.ip6.arpa represents a /40, with values such as 2803:bc00::9A, the extended value is 2803:bc00:0000:0000:0000:0000:0000:009a. If you want to represent the 2803:bc00:0000::/64 zone, the zone name is longer 0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.c.b.3.0.8.2.ip6.arpa
Creation of a slave zone (POST)
To create a slave zone, you must specify to which company it belongs (crm_id), a fqdn or Fully Qualified Domain Name, and the master-ips. The name does not need to be recognized on the Internet, as it may be a new zone or an internal zone. The master-ips can be one or two, and they are IP addresses from which the Reseller’s authoritative server will attempt to transfer the zone.
Warning
this version does not support TSIG keys, see secure_slave_zone to create a slave zone protected with a TSIG key
Example:
curl -X POST ${PDNS_APIURI}/api/v1/slave_zone/dom1.com -H "Authorization: ${PDNS_APIKEY}" -H "Reseller: ${PDNS_RESELLER}" -d '{ "masterip1": "192.168.33.44", "masterip2": "192.168.44.55" }'
If any data is missing, the endpoint returns a 400 error stating that a field is missing.
Note
Only masterip1 is mandatory
If the zone already exists within the Reseller, it will return a 400 error with a Duplicate zone message.
The zone is created with the suspended parameter set to False, meaning the zone is activated immediately.
Warning
if the zone ends in in-addr.arpa or ip6.arpa, the zone will be considered reverse instead of forward. This metadata cannot be changed.
Suspension and Resumption of a zone (PUT)
A zone can be resumed and suspended successively using PUT calls to the following endpoints, e.g.:
curl -X PUT ${PDNS_APIURI}/api/v1/suspend_zone/dom1.com -H "Authorization: ${PDNS_APIKEY}" -H "Reseller: ${PDNS_RESELLER}"
curl -X PUT ${PDNS_APIURI}/api/v1/resume_zone/dom1.com -H "Authorization: ${PDNS_APIKEY}" -H "Reseller: ${PDNS_RESELLER}"
Note
Suspending a zone means that it is not published in the authoritative DNSs corresponding to the Reseller, where the Company to which the zone belongs is located. However, modifications can be made via Web or API to the zone’s records, as they are still available.
Deletion of a zone (DELETE)
To delete a zone, you simply use the DELETE method, which will also delete all its Resource Records including the SOA. The zone will no longer be published and its records will no longer be available.
Example:
curl -X DELETE ${PDNS_APIURI}/api/v1/domain -H "Authorization: ${PDNS_APIKEY}" -H "Reseller: ${PDNS_RESELLER}" -d '{"domain": "test.com", "crm_id": "test1"}'
Warning
Once the zone is deleted, there is no trace of it left.
Endpoints v2.2
These are the endpoints available in version 2.2 scheduled for August 2024.
Creation of a TSIG slave (POST)
Example of a key in bind9 format, generated with /usr/sbin/tsig-keygen hola1
key "hola1" {
algorithm hmac-sha256;
secret "LvzAji80xCrq7eoD5YODSDjD0LLJLiX2nWPGSA11q1w=";
};
The endpoint to create a TSIG key and publish it in bind9 requires a name and an algorithm. The algorithm must be one of the following:
hmac-md5 |
hmac-sha1 |
hmac-sha224 |
hmac-sha256 |
hmac-sha384 |
hmac-sha512 |
This example creates a key named keyname with the hmac-256 algorithm.
curl -X POST ${PDNS_APIURI}/api/v1/createkey/newkey -H "Authorization: ${PDNS_APIKEY}" -H "Reseller: ${PDNS_RESELLER}" -d '{ "algorithm": "hmac-sha512" }'
The call returns the key in base 64
{
"algorithm": "hmac-sha512",
"keyname": "newkey",
"secret": "STe13VSVnkXdCXoe/ibjpSxzviqnGqb20VJhkDEc54cmNP3z3/s+qURW1feeYylwWa6L0hdTyHMBxivK2x2zOQ=="
}
Deletion of a TSIG slave (DELETE)
Deletion is only possible as long as there are no slave zones that require it.
curl -X DELETE ${PDNS_APIURI}/api/v1/createkey/newkey -H "Authorization: ${PDNS_APIKEY}" -H "Reseller: ${PDNS_RESELLER}"
Creation of a secure slave zone (POST)
Unlike the slave_zone endpoint, this secure_slave_zone endpointallows you to declare a list of master IPs (not limited to two, as in thecase of slave_zone) and with an additional TSIG key.
Additionally, a TSIG or cryptographic key can be added if it is requiredby the server providing the zone, specifying the key name.
curl -X POST ${PDNS_APIURI}/api/v1/secure_slave_zone/dom1.com -H "Authorization: ${PDNS_APIKEY}" -H "Reseller: ${PDNS_RESELLER}" -d '{ "masters": [ "192.168.33.44", "192.168.44.55", "192.168.55.66"], "keyname": "newkey1" }'
In this way, if the administrator of a zone exposes that zone through several IPsand a TSIG key, we must first create the key with createkey, and then add its**name** in this call to secure_slave_zone in order to associate the key withthe master IPs (from which, chosen at random, the zone will be attempted to bebrought to our corresponding Reseller primary).