Hostnameverificatie

Bewijs met een DNS TXT-record of een HTTPS-bestand dat je een domein beheert, zodat je het mag opwarmen.

9 min leestijd

Voordat Cache Rocket ook maar één request naar een domein stuurt, moet je aantonen dat je het beheert. Deze pagina behandelt beide verificatiemethodes en wat je doet als er één mislukt.

Hostnames staan onder Account → Hostnames.

Waarom dit verplicht is

Een cache-warmer is een machine die heel snel veel requests naar een website stuurt. Dat is nuttig als hij op je eigen server gericht is, en vijandig als hij op die van iemand anders gericht is — het is dan feitelijk een DDoS-middel.

Verificatie is wat die twee scheidt. Het betekent dat elk request dat Cache Rocket namens jou stuurt naar infrastructuur gaat waarvan je aantoonbaar hebt bewezen dat je die beheert. Je kunt er niet van afzien, en geen enkel plan haalt deze eis weg.

Note

Dit beschermt jou ook. Niemand anders kan een warmer op jouw domein richten, want zij kunnen de verificatie niet doorstaan.

Een methode kiezen

DNS TXT-recordHTTPS-bestand of meta-tag
Je hebt toegang nodig totJe DNS-providerDe bestanden of templates van je site
Gebruikelijke wachttijdMinuten tot een uur, voor propagatieZo snel als je kunt deployen
Beste bijJe beheert DNS en wilt een wijziging die deploys overleeftJe deployt een app maar beheert geen DNS
Past goed bijTraditionele hosting, cPanel, eigen serversNext.js, Vercel, Netlify, statische hosts

Beide methodes leiden tot dezelfde geverifieerde status. Kies degene die jij het snelst kunt uitvoeren.

De juiste hostname kiezen

Dit is de meest voorkomende bron van verwarring, dus het is de moeite waard om precies te zijn. Een hostname is exact het domeingedeelte van je URL's. Dit zijn allemaal *verschillende* hostnames wat verificatie betreft:

text
example.com
www.example.com
shop.example.com
blog.example.com

Verifieer degene die in de entry-URL's staat die je wilt gebruiken. Verwijst je site example.com door naar www.example.com, dan moet je entry-URL de www-variant zijn, en dus ook de hostname die je verifieert.

Meerdere subdomeinen? Verifieer elk afzonderlijk. Er is geen wildcardverificatie.

Tip

Weet je niet welke vorm je site gebruikt? Open hem in een browser en kijk naar de adresbalk zodra hij klaar is met laden. Wat daar staat, na eventuele redirects, is de hostname die je verifieert.

Methode A — DNS TXT-record

  1. 1

    Voeg de hostname toe

    Typ op Account → Hostnames het domein en kies DNS TXT-record als verificatiemethode.

  2. 2

    Start de verificatie

    Klik op Verificatie starten. Cache Rocket genereert een unieke token en toont je de recordnaam en de exacte waarde die je moet publiceren.

  3. 3

    Maak het record aan bij je DNS-provider

    Log in waar je DNS beheerd wordt — Cloudflare, je registrar, het controlepaneel van je host — en voeg een nieuw TXT-record toe met de weergegeven naam en waarde. Kopieer en plak de waarde; typ die niet over.

  4. 4

    Wacht op propagatie

    DNS-wijzigingen zijn niet direct actief. Een paar minuten is gebruikelijk; tot een uur is normaal als je provider een lange TTL gebruikt.

  5. 5

    Klik op Verifiëren

    Klik in Cache Rocket op Verifiëren naast de hostname. Mislukt het, wacht dan langer en klik opnieuw — opnieuw proberen kost niets en zet niets terug.

Zelf het record controleren

Blijft verificatie mislukken, controleer dan eerst of het record echt zichtbaar is vanaf het publieke internet, voordat je aanneemt dat het aan Cache Rocket ligt:

macOS en Linux
bash
dig +short TXT _cacherocket.example.com
Windows
powershell
Resolve-DnsName -Type TXT _cacherocket.example.com

Vervang de recordnaam door die Cache Rocket je toonde. Geeft het commando niets terug, dan is het record nog niet doorgekomen of niet goed opgeslagen.

Veelgemaakte DNS-fouten

Providers verschillen in of ze de volledige recordnaam verwachten of alleen het subdomeingedeelte — _cacherocket.example.com invoeren waar de provider je domein al toevoegt levert _cacherocket.example.com.example.com op. Let ook op automatisch toegevoegde aanhalingstekens en op witruimte aan het eind bij plakken.

Methode B — HTTPS-bestand of meta-tag

Kies HTTPS-bestand of meta-tag en klik op Verificatie starten. Cache Rocket toont dan drie dingen: de URL die gecontroleerd wordt, de exacte inhoud die die URL moet teruggeven, en een gelijkwaardige <meta>-tag. Je publiceert óf het bestand óf de meta-tag, niet beide.

Het bestand publiceren

Maak een bestand aan op het weergegeven pad, met exact de weergegeven inhoud en niets anders. In een Next.js-project betekent dat het in je map public/ zetten:

Next.js, Vite, Astro en de meeste statische hosts
text
public/
  └── .well-known/
        └── cacherocket-verification.txt

Deploy, en open daarna de verificatie-URL in een browser. Je hoort alleen de token te zien. Zie je je 404-pagina, opgemaakte HTML of een redirect, dan is het nog niet goed gepubliceerd.

Of via de meta-tag

Is bestanden toevoegen lastig, zet dan de meegeleverde <meta>-tag in de <head> van je homepage. In de Next.js App Router kan dat via de metadata-export:

app/layout.tsx
ts
export const metadata = {
  other: {
    'cacherocket-site-verification': 'JOUW_TOKEN_HIER',
  },
};

Deploy en klik daarna op Verifiëren.

Het bestand moet publiek bereikbaar zijn

Zit je site achter HTTP-basisauthenticatie, een IP-whitelist, een staging-wachtwoord of een “binnenkort online”-pagina, dan kan Cache Rocket het verificatiebestand niet lezen. Geef publieke toegang tot dat ene pad, of gebruik de DNS-methode.

Na de verificatie

De hostname toont Geverifieerd in je lijst en kan direct gebruikt worden in entry-URL's van zowel cache-warmers als API-warmers.

Je kunt het TXT-record of verificatiebestand daarna veilig verwijderen, maar laten staan is eenvoudiger — dan is opnieuw verifiëren direct klaar als dat ooit nodig is.

Een hostname verwijderen

Een hostname verwijderen breekt de bijbehorende warmers

Elke warmer met entry-URL's op die hostname gaat falen, omdat de URL's niet meer naar geverifieerde infrastructuur wijzen. Verplaats of verwijder die warmers eerst, of verifieer de hostname opnieuw om ze te herstellen.

Verificatie blijft mislukken

Ik heb het DNS-record toegevoegd maar verificatie mislukt nog steeds.
Bijna altijd propagatie. Controleer met het dig-commando hierboven of het record publiek zichtbaar is. Vindt dig het wel en Cache Rocket niet, kijk dan of het domein dubbel in de recordnaam staat, of er een tweede conflicterend TXT-record op dezelfde naam staat.
Het verificatiebestand opent goed in mijn browser, maar Cache Rocket kan het niet lezen.
Je browser is misschien ingelogd waar Cache Rocket dat niet is. Probeer de URL in een privévenster. Controleer ook of hij via https zonder redirect geserveerd wordt, en of de response platte tekst is en geen HTML-pagina met de token erin.
Welke hostname verifieer ik als mijn site doorverwijst?
De bestemming — de hostname die in de adresbalk staat nadat de redirect klaar is. Dat is degene die je entry-URL's moeten gebruiken.
Moet ik elk subdomein verifiëren?
Ja. Elke hostname wordt afzonderlijk geverifieerd, en er is geen wildcardoptie. shop.example.com heeft eigen verificatie nodig, ook als example.com al geverifieerd is.
Kan ik een domein verifiëren dat ik voor een klant beheer maar niet bezit?
Ja, mits je een DNS-record kunt toevoegen of een bestand kunt publiceren — dat is precies wat de verificatie test. Bureaus verifiëren doorgaans elke klant-hostname binnen de workspace van die klant. Zie Teams en rollen.
Kan ik een localhost of intern adres opwarmen?
Nee. Cache Rocket warmt op vanaf het publieke internet, dus de hostname moet publiek te resolven en bereikbaar zijn.