PUT /v1/compute/servers/{serverId}/reverse-dns

Kimlik Doğrulama

Bearer token olarak bir API anahtarı gönderin. Anahtar sites.restart iznine sahip olmalıdır; bu izne sahip olmayan bir anahtar 404 ile değil, 403 ile reddedilir.

Bu uç nokta hiçbir organizasyon kimliği almaz. Anahtarınız zaten ait olduğu organizasyonu tanımlar ve yanıt bu organizasyonla sınırlandırılır.

Dene

Köşeli parantez içindeki her şeyi kendi değerlerinizle ve anahtar yer tutucusunu panonuzdan bir anahtarla değiştirin.

curl -X PUT https://api.zinndigital.com/v1/compute/servers/{serverId}/reverse-dns \
  -H "Authorization: Bearer zdk_live_…" \
  -H "Content-Type: application/json" \
  -d '{ "ip": <string> }'

Oturum açtınız mı? Panonuzdaki API konsolu, gerçek organizasyon kimliğinizi ve kendi anahtarınızı otomatik olarak doldurur ve isteği canlı API üzerinde çalıştırarak gerçek yanıtı görmenizi sağlar. Bu uç noktayı API konsolunda açın

Ayrıntılar

⛔ `ip` is required and is never inferred from the machine: a machine has an IPv4 and an IPv6 address with **different** default states, so "set the PTR of this server" is not a well-formed request. An empty `hostname` resets that address to the provider's own default, which is a real thing to want and is not the same as leaving it alone. ⛔⛔ **The hostname must resolve forward to this address, and that is checked before anything is written.** Receiving mail servers check forward-confirmed reverse DNS, so a PTR whose name does not point back is *worse* than the supplier's default: it looks configured on the screen and still fails delivery. A name that does not resolve at all is refused too — "we could not look it up" is not evidence the record exists. An `ip` the machine does not hold is `422`, and that refusal is the tenancy boundary: the provider would happily set a PTR for any address on the account, including another customer's. Requires `sites.restart`.

Parametreler

İstek gövdesi

Yanıt

Bu uç noktanın dönderebileceği hatalar

401 · 403 · 404 · 422 · 429 · 503