Нотатки до випуску API для доменів

Це примітки до випуску Domains API. Ми подбаємо про те, щоб ви постійно отримували інформацію про будь-які нові та нові пропозиції функцій.

Квітень 2020 р

Зміни конфіденційності WHOIS

1 липня 2020 р. Ми вдосконалюємо свою пропозицію щодо конфіденційності, щоб надати вам більше можливостей керувати конфіденційністю для своїх доменів. По-перше, ви зможете ввімкнути або вимкнути конфіденційність без скасування та повторного придбання продукту. Коли ви вперше додаєте конфіденційність домену, контактна інформація проксі-сервера використовується для заміни вашої особистої контактної інформації у відповідь на запити WHOIS. Щоб тимчасово розкрити вашу особисту контактну інформацію в WHOIS, запроваджується новий атрибут exposeWhois, а також новий ключ угоди для підтвердження згоди на розкриття особистих контактних даних, як показано нижче.

PATCH /v1/domains/mydomain.com "згода": {"згоденAt": "2020-03-30T10: 00: 00Z", "згіднийBy": "12.13.14.15", "94 , "exposeWhois": "true"

Контактну інформацію проксі-сервера можна відновити, використовуючи таку команду без ключа згоди:

PATCH /v1/domains/mydomain.com "exposeWhois": "false"

Крім того, з 1 липня 2020 р. Ми пропонуємо безкоштовний базовий захист конфіденційності для всіх нових доменів і наявних доменів, які ще не мають розширеного захисту конфіденційності. Базова конфіденційність маскує більшість особистих контактних даних у запитах Whois, викриваючи лише назву компанії, країну та штат. Для доменів з базовим захистом конфіденційності особиста контактна інформація може бути викрита або замаскована в Whois за допомогою тих самих команд API, які описані вище.

Тепер доступні: .APP, .DEV і .PAGE

Починаючи з 28 квітня 2020 р. Користувачі API можуть реєструвати домени .APP, .DEV та .PAGE з одним спеціальним приміщенням. .APP, .DEV і .PAGE позначені як безпечні простори імен. Усі основні браузери вимагають, щоб домени в цих просторах імен мали сертифікат SSL.

Реєстранти не повинні купувати сертифікат SSL як необхідну умову для придбання свого домену, але постачальники доменних імен повинні повідомляти своїх реєстрантів під час реєстрації, що їм буде потрібен сертифікат SSL, щоб обслуговувати свій домен у браузері. .

Повні відомості про цю вимогу можна отримати за допомогою наступного методу API:

GET / v1 / domains / accounts? Tlds = APP

На підтримку цих спеціальних доменів верхнього рівня в розділі згоди в тілі кінцевої точки придбання вводиться додатковий ключ угоди, який називається HTTPS_NOTICE, щоб користувачі могли підтвердити, що вони переглянули цю вимогу та бажають продовжити реєстрацію. Включаючи цей новий необхідний ключ угоди, розділ згоди у чинному запиті на придбання матиме такий вигляд:

POST / v1 / domains / придбання "domain": "mydomain.app", "згода": {"договоривсяAt": "2020-03-30T10: 00: 00Z", "згодивсяBy": "12.13.14.15", "sporazumKeys ": [" DNRA "," HTTPS_NOTICE "]}, ...

Домени найвищого рівня з невизначеною претензією на товарний знак

За допомогою API тепер доступно 13 додаткових доменів верхнього рівня .ACCOUNTANT, .CRICKET, .DATE, .DOWNLOAD, .FAITH, .LOAN, .MEN, .PARTY, .RACING, .REVIEW, .SCIENCE, .STORAGE і .WIN. Ці TLD перебувають у невизначеному періоді заявки на використання торговельної марки. Зараз домени в цих 13 просторах імен, на які заявлено права на використання торговельних марок, вважатимуться недоступними. Домен без претензій щодо торговельної марки можна придбати звичайно.

Межі записів зони DNS

Щоб забезпечити масштабованість наших функцій керування DNS для всіх клієнтів, ми запровадили обмеження на кількість записів, які можна створити в одній зоні. Починаючи з 28 квітня 2020 р. Стандартні клієнти DNS можуть створювати до 500 записів у кожній зоні, а преміум-клієнти DNS можуть створювати до 1500 записів у кожній зоні. Ця зміна вплине на такі кінцеві точки:

PUT / v1 / domains / {domain} / записи PUT / v1 / domains / {domain} / записи / {type} PUT / v1 / domains / {domain} / записи / {type} / {name} PATCH / v1 / domains / {domain} записи

Коли буде викликано будь-яку з наведених вище кінцевих точок, ми оцінимо, чи не може оновлення зони перевищити ліміт запису. Якщо ні, ми обробимо запит нормально. Якщо так, ми повернемо відповідь 422 із такими відомостями про помилку:

код: ZONE_LIMIT_EXCEEDED повідомлення: зона не може перевищувати 500 записів; запитана операція перевищує ліміт.

Для зон, які наразі перевищують ліміт, усі наявні записи залишаться недоторканими. Проте не можна додавати нові записи, доки загальна кількість записів зони не буде досягнуто за межі записів, які можна виконати за допомогою методу PUT.

Розмір сторінки запису зони DNS

Під час отримання записів із зони параметр limit використовується для позначення кількості записів, які потрібно отримати. Щоб забезпечити масштабованість системи, 28 квітня 2020 року ми введемо максимальний ліміт у 500 записів. Ця зміна вплине на такі кінцеві точки:

GET / v1 / domains / {domain} / записи GET / v1 / domains / {domain} / записи / {type}

Коли надходить запит із лімітом більше 500, ми повертаємо відповідь 422 із такими відомостями про помилку:

код: VALUE_OVER повідомлення: Значення Limit має бути не більше 500.

Користувачі все одно матимуть змогу переглядати всі свої записи зони розміром до 500 сторінок, використовуючи параметри зміщення та обмеження.