|  Start
Hjälp

GoDaddy Hjälp

Boop pip bopp… beräknar… beräknar… initierar sekvens 42…
Det verkar som de tokiga robotarna ställer till det igen! De har tagit över och har översatt den här sidan till ditt språk. Robotarna menar väl i sina hjärtan av metall. De vill hjälpa dig! Berätta för oss hur robotarna sköter sig via knapparna längst ner på sidan. Gå till den engelskspråkiga versionen

Viktig information om API för domäner

Det här är versionerna för Domains API. Vi kommer att se till att hålla dig uppdaterad med eventuella nya och nya funktioner.

April 2020

WHOIS sekretessändringar

Den 1 juli 2020 kommer vi att förbättra vårt sekretesserbjudande för att ge dig mer kontroll över hur du hanterar sekretess för dina domäner. Först kommer du att kunna aktivera eller inaktivera sekretess utan att säga upp och köpa produkten på nytt. När du först lägger till sekretess för en domän kommer proxy-kontaktuppgifter att användas för att ersätta din personliga kontaktinformation som svar på WHOIS-frågor. För att tillfälligt exponera din personliga kontaktinformation i WHOIS införs ett nytt exposeWhois-attribut samt en ny nyckel för att verifiera samtycke till att exponera personlig kontaktinformation, enligt följande:

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

Proxy-kontaktinformation kan återställas med följande kommando, utan någon avtalsnyckel krävs:

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

Från och med den 1 juli 2020 erbjuder vi dessutom gratis grundläggande sekretesskydd på alla nya domäner och på befintliga domäner som inte redan har vårt avancerade sekretesskydd. Grundläggande sekretess maskerar de flesta personliga kontaktuppgifterna i whois-frågor och visar endast företagsnamn, land och delstat. För domäner med grundläggande sekretesskydd kan personlig kontaktinformation eventuellt exponeras eller maskeras i vem som använder samma API-kommandon som beskrivs ovan.

Nu tillgängligt: .APP, .DEV och .PAGE

Från och med 28 april 2020 kan API-användare registrera .APP-, .DEV- och .PAGE-domäner med ett särskilt boende. .APP, .DEV och .PAGE betecknas som säkra namnrymden. Alla stora webbläsare kräver att domäner i dessa namnutrymmen har ett SSL-certifikat.

Registrerare är inte skyldiga att köpa ett SSL-certifikat som en förutsättning för att köpa sin domän, men leverantörer av domännamn måste meddela sina registrerare vid tidpunkten för registreringen att de behöver ett SSL-certifikat för att kunna betjäna domänen i en webbläsare .

Komplett information om detta krav finns via följande API-metod:

GET / v1 / domäner / avtal? Tlds = APP

Till stöd för dessa speciella toppdomäner införs en ytterligare avtalningsnyckel som heter HTTPS_NOTICE i avsnittet om samtycke i delen för köpslutpunkten för att användare ska bekräfta att de har granskat detta krav och vill fortsätta med registreringen. Inkluderat den här nya nödvändiga avtalsnyckeln skulle avsnittet om samtycke i en giltig köpbegäran se ut så här:

POST / v1 / domäner / köp "domän": "mindomän.app", "samtycke": {"avtänktAt": "2020-03-30T10: 00: 00Z", "överenskommetBy": "12.13.14.15", "överenskommelseKeys ": [" DNRA "," HTTPS_NOTICE "]}, ...

TLD: er för obestämda varumärken

Ytterligare 13 toppdomäner är nu tillgängliga via API: et: .ACCOUNTANT, .CRICKET, .DATE, .DOWNLOAD, .FAITH, .LOAN, .MEN, .PARTY, .RACING, .REVIEW, .SCIENCE, .STORAGE och .WIN. Dessa toppdomäner har en obestämd varumärkesansökningsperiod. För närvarande behandlas domäner i dessa 13 namnområden som har varumärkesanspråk som otillgängliga. Domän utan varumärkesanspråk kan köpas normalt.

Gränser för DNS-zonpost

För att säkerställa skalbarheten för våra DNS-hanteringsfunktioner för alla klienter implementerar vi begränsningar för hur många poster som kan skapas i en enda zon. Från och med den 28 april 2020 kan standard-DNS-kunder skapa upp till 500 poster per zon och premium-DNS-kunder kan skapa upp till 1 500 poster per zon. Den här ändringen påverkar följande slutpunkter:

PUT / v1 / domäner / {domain} / poster PUT / v1 / domäner / {domain} / poster / {type} PUT / v1 / domäner / {domain} / poster / {type} / {name} PATCH / v1 / domäner / {domain}

När någon av ovanstående slutpunkter åberopas utvärderar vi om den begärda uppdateringen av zonen skulle medföra att zonen överskrider postgränsen. Om inte, kommer vi att behandla begäran som vanligt. I så fall returnerar vi ett 422-svar med följande felinformation:

kod: ZONE_LIMIT_EXCEEDED-meddelande: Zonen får inte överskrida 500 poster; den begärda åtgärden skulle överskrida gränsen.

För zoner som för närvarande överskrider gränsen förblir alla befintliga poster intakta. Emellertid får inga nya poster läggas till förrän det totala zonpostantalet ligger inom postgränsen, vilket kan åstadkommas med PUT-metoden.

Sidstorlek för DNS-zonpost

När poster hämtas från en zon används gränsparametern för att ange antalet poster som ska hämtas. För att säkerställa systemets skalbarhet upprätthåller vi en maximal gräns på 500 poster den 28 april 2020. Den här ändringen påverkar följande slutpunkter:

GET / v1 / domäner / {domain} / poster GET / v1 / domäner / {domain} / poster / {type}

När en begäran tas emot med en gräns som är högre än 500, skickar vi ett 422-svar med följande felinformation:

code: VALUE_OVER meddelande: Limit måste ha ett värde som inte är större än 500.

Användare kan fortfarande itera igenom alla sina zonposter i sidstorlekar upp till 500, med hjälp av offset- och limit-parametrarna.


Var den här artikeln till hjälp?
Tack för din feedback. Ring vårt supportnummer eller starta chattalternativet ovan om du vill prata med en medarbetare på kundtjänst.
Vi är glada att vi kunde hjälpa till! Finns det något mer vi kan göra för dig?
Det var tråkigt att höra. Berätta vad som var krångligt eller varför lösningen inte hjälpte dig med problemet.