Produktmerknader om API for domener

Dette er versjonsmerknadene for Domains API. Vi sørger for å holde deg oppdatert med alle kommende og nye funksjoner og nye tilbud.

April 2020

WHOIS personvernendringer

1. juli 2020 vil vi forbedre vårt personverntilbud for å gi deg mer kontroll over hvordan du administrerer personvern for domenene dine. Først vil du kunne aktivere eller deaktivere personvern uten å kansellere og kjøpe på nytt produktet. Når du først legger til personvern til et domene, vil proxy -kontaktinformasjon brukes til å erstatte din personlige kontaktinformasjon som svar på WHOIS -spørsmål. For å midlertidig avsløre din personlige kontaktinformasjon i WHOIS blir det introdusert et nytt exposeWhois -attributt, i tillegg til en ny avtalsnøkkel for å bekrefte samtykke til å eksponere personlige kontaktopplysninger:

PATCH /v1/domains/mydomain.com "Agreement": {"AgreementAt": "2020-03-30T10: 00: 00Z", "AgreementBy": "12.13.14.15", "AgreementKeys": ["EXPOSE_WHOIS"]} , "exposeWhois": "true"

Proxy -kontaktinformasjon kan gjenopprettes ved hjelp av følgende kommando, uten avtalsnøkkel nødvendig:

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

I tillegg, fra og med 1. juli 2020, tilbyr vi gratis grunnleggende personvernbeskyttelse på alle nye domener og eksisterende domener som ikke allerede har vår avanserte personvernbeskyttelse. Grunnleggende personvern vil maskere de fleste personlige kontaktopplysningene i whois -spørringer, og kun eksponere firmanavn, land og delstat. For domener med grunnleggende personvernbeskyttelse, kan personlig kontaktinformasjon eventuelt bli eksponert eller maskert i hvem som bruker de samme API -kommandoene beskrevet ovenfor.

Nå tilgjengelig: .APP, .DEV og .PAGE

Fra og med 28. april 2020 kan API -brukere registrere .APP-, .DEV- og .PAGE -domener med én spesiell innkvartering. .APP, .DEV og .PAGE er utpekt som sikre navnerom. Alle store nettlesere krever at domener i disse navnerommene har et SSL -sertifikat.

Registranter er ikke pålagt å kjøpe et SSL-sertifikat som en forutsetning for å kjøpe domenet sitt, men domenenavnleverandører er pålagt å varsle registrantene sine på registreringstidspunktet at de trenger et SSL-sertifikat for å kunne betjene domenet sitt i en nettleser .

Komplett informasjon om dette kravet er tilgjengelig via følgende API -metode:

GET/v1/domener/avtaler? Tlds = APP

Til støtte for disse spesielle toppdomenene blir det introdusert en ekstra avtalsnøkkel kalt HTTPS_NOTICE til samtykke -delen i brødteksten til kjøpsendepunktet, slik at brukerne kan bekrefte at de har gjennomgått dette kravet og ønsker å fortsette med registreringen. Inkludert denne nye nødvendige avtalsnøkkelen, vil samtykke -delen av en gyldig kjøpsforespørsel se slik ut:

POST/v1/domains/purchase "domain": "mydomain.app", "toestemming": {"AgreementAt": "2020-03-30T10: 00: 00Z", "AgreementBy": "12.13.14.15", "AgreementKeys ": [" DNRA "," HTTPS_NOTICE "]}, ...

TLD -er for ubestemt varemerke -påstander

13 ekstra toppdomener er nå tilgjengelig via API: et: .ACCOUNTANT, .CRICKET, .DATE, .DOWNLOAD, .FAITH, .LOAN, .MEN, .PARTY, .RACING, .REVIEW, .SCIENCE, .STORAGE, og .WIN. Disse TLD -ene er i en ubestemt periode for varemerkekrav. Foreløpig vil domener i disse 13 navnområdene som har varemerkekrav bli behandlet som utilgjengelige. Domener uten varemerkkrav kan kjøpes normalt.

Grenser for DNS -sonepost

For å sikre skalerbarheten av våre DNS -administrasjonsfunksjoner for alle klienter, implementerer vi grenser for antall poster som kan opprettes i en enkelt sone. Fra og med 28. april 2020 kan standard DNS -kunder opprette opptil 500 poster per sone, og premium DNS -kunder kan opprette opptil 1500 poster per sone. Denne endringen vil påvirke følgende endepunkter:

PUT/v1/domener/ {domain} /poster PUT/v1/domener/ {domain} /poster/ {type} PUT/v1/domener/ {domain} /poster/ {type} / {name} PATCH/v1/domains/ {domain}

Når noen av de ovennevnte endepunktene påkalles, vil vi evaluere om den forespurte oppdateringen av sonen vil føre til at sonen overskrider postgrensen. Hvis ikke, vil vi behandle forespørselen på vanlig måte. I så fall vil vi returnere et 422 -svar med følgende feilopplysninger:

kode: ZONE_LIMIT_EXCEEDED melding: Sonen kan ikke overskride 500 poster; ønsket operasjon vil overskride grensen.

For soner som for øyeblikket overskrider grensen, vil alle eksisterende oppføringer forbli intakte. Ingen nye poster kan imidlertid legges til før det totale sonepostantallet er ført innenfor postgrensen, noe som kan oppnås ved å bruke PUT -metoden.

Sidestørrelse for DNS -soneoppføring

Når du henter poster fra en sone, brukes grense -parameteren for å indikere antall poster som skal hentes. Den 28. april 2020 vil vi håndheve en maksimumsgrense på 500 poster for å sikre systemets skalerbarhet. Denne endringen vil påvirke følgende endepunkter:

GET/v1/domener/ {domain} /poster GET/v1/domener/ {domain} /records/ {type}

Når en forespørsel mottas med en grense som er større enn 500, returnerer vi et 422 -svar med følgende feilopplysninger:

code: VALUE_OVER -melding: Grensen må ha en verdi som ikke er større enn 500.

Brukerne vil fremdeles være i stand til å gjenta gjennom alle sonepostene sine i sidestørrelser opptil 500, ved hjelp av offset- og grense -parameterne.