En andra transitoperatör live i Chișinău — 20 Gbps blandad transitkapacitet. 20 Gbps blandad uppkoppling nu i drift Varför Republiken Moldavien

Drift Praktisk

Lagren ovanför din server: domän, CDN, transit

Din värd är ett lager av tre. Registret ovanför dig kan plocka bort ditt namn ur zonfilen genom ett enda domstolsbeslut, proxyn framför dig vidarebefordrar varje klagomål till din värd med din ursprungsadress bifogad, och ingen av dem befinner sig i din värds jurisdiktion.

16 min läsning Publicerad 28 augusti 2026 Kontrollerad idag

Att välja var servern står är ett beslut av tre, och det är sällan det som avgör utfallet. Ovanför servern sitter ett namn, som drivs av någon annan. Framför servern sitter, för de flesta webbplatser, en omvänd proxy som drivs av ännu någon annan. Ingen av dem är bunden av din värds policy, ingen av dem befinner sig i din värds jurisdiktion, och båda kan föreläggas att agera av en domstol som inte har någon räckvidd över din värd alls. Det här är den del av stacken som offshore-hosting inte täcker, och den är värd att känna till exakt var den slutar.

Tre lager, tre olika ägare

En webbplats som över huvud taget går att nå är beroende av minst tre separata företag, och de fallerar oberoende av varandra.

Namnet. En registrator sålde det till dig; ett register driver toppdomänen det ligger under. Två företag, oftast två länder, och det andra har aldrig hört talas om dig.

Fronten. Om något svarar för din räkning — en CDN, en omvänd proxy, en anycast-nod — avslutar den dina besökares anslutningar innan din server ser dem. Den känner därför till din ursprungsadress per konstruktion, och det är den som tar emot klagomålen.

Tråden och maskinen. Din värd, dess transitoperatörer, anläggningen, det adressintervall din server befinner sig inom. Det här är lagret folk handlar efter, och det är det enda av de tre som en hostingjurisdiktion faktiskt reglerar.

Vanan värd att bryta är att tänka på de här som ett enda köp. De är tre, och att lägga alla tre i en hand — eller i ett rättssystem — är hur ett enda beslut lägger ner allt på en gång.

Europeisk lagstiftning har redan ritat den här kartan, och det är en användbar en. Digital Services Act delar in mellanhänder i tre slag: ren vidarebefordran, cachning och värdtjänst. Skäl 29 namnger toppdomänsregister, registratorer, DNS-resolvrar och certifikatutfärdare som ren vidarebefordran, och CDN-tjänster och omvända proxyservrar som cachning. Alla tre slagen kan ta emot ett föreläggande enligt artikel 9 om att agera mot olagligt innehåll och ett föreläggande enligt artikel 10 om att lämna ut information. Att vara undantagen från ansvar är inte att vara undantagen från förelägganden.

Domänen: registratorn, och registret ovanför den

Din registrator är butiken. Registret är grossisten som driver toppdomänen, och det är lagret nästan ingen kontrollerar innan köpet.

Vad som får en registrator att agera

Sedan den 5 april 2024 har ackrediterade registratorer haft en avtalsenlig skyldighet att agera på det ICANN kallar DNS Abuse: när de sitter på handlingsbara bevis måste de skyndsamt vidta de begränsande åtgärder som rimligen krävs för att störa namnet. Den användbara halvan av den regeln är dess definition. DNS Abuse betyder skadlig kod, botnät, nätfiske, pharming och skräppost där skräppost är spridningsvägen för någon av de andra. Webbplatsinnehåll ligger utanför räckvidden, och upphovsrätt ligger utanför räckvidden — uttryckligen.

Läs det som en tröskel snarare än en tröst. Det talar om vilken form ett klagomål måste ha innan din registrator är skyldig att agera; det talar också om att allt som ligger utanför den listan måste komma som ett beslut från en domstol eller en myndighet, vilket är långsammare, kontrollerbart och möjligt att överklaga. Båda halvorna är värda att känna till innan du lämnar in det klagomål du är på väg att ta emot.

Vad registret kan göra, och var det befinner sig

Ett register har en enda, absolut spak: det kan sätta en status på ditt namn som tar bort det ur zonen. Namnet slutar då att slå upp för alla, överallt, oavsett vad din registrator tycker och oavsett var din server befinner sig. Ingenting i hostinglagret mildrar detta, eftersom ingenting i hostinglagret är inblandat.

Det är inte teoretiskt. I juni 2026 utfärdade en distriktsdomstol i Texas ett beslut om kvarstad som ålade Verisign, som driver .com, att sätta motherless.com i registerspärr. Operatören var ett luxemburgskt bolag som hade ignorerat en texansk dom enligt delstatens lag om åldersverifiering; beslutet satte en borgen på 9,14 miljoner dollar som villkor för att få tillbaka namnet. Webbplatsen var inte hostad i Texas och bolaget fanns inte i Texas. Namnet låg under .com, och .com drivs av ett amerikanskt bolag under amerikansk jurisdiktion. Det räckte.

Den generaliserbara lärdomen handlar inte om det fallet. Den är att toppdomänen du väljer är ett jurisdiktionsval, precis som landet din server står i, och de flesta gör det valet av gammal vana. Fråga vem som driver toppdomänen, under vilken lag, och om det rättssystemet har för vana att beordra register att agera. Bestäm sedan om du vill ha ditt enda namn där.

Sekretess kring namnet handlar om publicering, inte om vetskap

Redigering i WHOIS och RDAP stoppar massskraparen och den tillfälliga uppslagningen. Det gör inte din registrator okunnig: ackrediteringen förpliktar den att spara registreringsuppgifter, och den lämnar ut de uppgifterna under laga process precis som vem som helst. En sekretesstjänst framför posten är en publiceringsinställning, inte ett skydd — och en registrator som aldrig bad dig om någonting kan inte lämna ut det den inte har, vilket är en helt annan egenskap och den enda värd att betala för.

Domänen är den enda delen av stacken som ett enda beslut kan stänga av överallt på en gång. Servrar byts ut, adresser roteras, proxyservrar byts på en eftermiddag. Ett namn som hålls hos registret slutar helt enkelt att slå upp, och varenda länk någon någonsin publicerat till dig går sönder i samma sekund.

Proxyn framför: vad den tar bort, vad den vidarebefordrar

En CDN är en cachande mellanhand. Den lagrar inte din webbplats varaktigt, så ”ta bort filen” är i regel inget den kan göra. Vad den kan göra är att sluta proxya dig — vilket, för en webbplats som är beroende av proxyn för att förbli nåbar och för att hålla sitt ursprung tyst, är en nedtagning och ett avslöjande i en och samma rörelse.

Det mer intressanta beteendet är vardagsbeteendet, och den största leverantören publicerar det öppet. När den tar emot en missbruksanmälan om en webbplats den bara proxyar kommer den att vidarebefordra ditt klagomål till webbplatsoperatören och hostingleverantören, och den kommer att ge hostingleverantören ursprungets IP-adress för det aktuella innehållet. Båda de raderna är citerade ur dess egen policy för missbruk, och de är motsatsen till vad köpare antar att de betalar för.

Proxyn är alltså ingen buffert mellan dig och din värds abuse-avdelning. Den är ett bud. Den bär klagomålet till din värd, och den talar om för din värd exakt vilken maskin den ska titta på. Om du valde din värd för hur den hanterar klagomål är det bra — klagomålet kommer dit du ville att det skulle komma. Om du valde en proxy i hopp om att klagomålet skulle stanna där, gör det inte det.

Samma leverantörs dokumentation ålägger också dig en skyldighet: håll en abuse-adress som aktivt hanteras och övervakas, och besvara varje meddelande om en missbruksanmälan inom tjugofyra timmar. Att inte svara i tid kan leda till att det anmälda innehållet tas bort eller blockeras, och till att kontot stängs av eller avslutas. Mellanhanden som inte kan ta bort ditt innehåll har ändå skrivit sig en borttagningsklausul — och en klocka.

Ett undantag spelar roll. Där samma bolag också hostar — sin objektlagring, sin serverlösa plattform, sina produkter för media och sidor — är det en hostingleverantör för det innehållet, det säger det självt, och det tar bort innehåll enligt ett notice-and-takedown-förfarande med motanmälan, i den form amerikansk lag föreskriver. Två produkter från en leverantör, två helt olika svar. Vet vilken av dem du faktiskt använder.

En proxy framför en offshore-värd gör inte arrangemanget mer offshore. Den lägger till ett bolag i ett annat land, under ett annat rättssystem, som avtalsenligt är förpliktat att vidarebefordra det den tar emot till din värd — med din ursprungsadress bifogad.

Vad en CDN inte döljer, och hur ursprung hittas

Många sätter en proxy framför en server av en enda anledning: att hålla ursprungsadressen borta från det öppna internet. Det är värt att veta hur väl det fungerar i praktiken, och det ärliga svaret är att det fungerar tills ett av fem vanliga misstag river ner det. Inget av dem är exotiskt; leverantörerna av proxytjänster dokumenterar dem själva.

Posterna du publicerade innan du flyttade. DNS är offentligt och det arkiveras. Nästan varje webbplats som flyttade bakom en proxy har sin adress från före flytten liggande i någons historiska dataset, permanent. Leverantörens egen rekommendation är att rotera ursprungsadressen efter påkopplingen — gjorde du inte det var flytten kosmetisk.

Posterna du lämnade oproxyade. En enda subdomän som pekar rakt mot maskinen räcker: mail, ftp, cpanel, dev, staging, vpn, övervakningsvärden du satte upp en gång. Granska varenda post i zonen, inte bara de du minns att du skapade.

Post som lämnar maskinen. Om ursprungsservern skickar e-post reser dess adress med i huvudena. Skicka ett meddelande till en adress som inte finns, och studsmeddelandet kommer tillbaka med adressen i släptåg. Post hör hemma på en annan maskin än den du försöker hålla tyst.

Certifikatstransparens. Varje offentligt betrott certifikat loggas med de namn det omfattar. Loggarna lämnar inte ut en adress, men de lämnar ut den fullständiga listan över subdomäner att pröva, inklusive de du trodde var privata.

Storskalig skanning. Hela adressrymden skannas kontinuerligt och indexeras efter vad den svarar. En särpräglad sida som serveras från en bar adress är en databasslagning, inte en utredning.

Åtgärderna är väl kända, och de är värda att göra i styrkeordning snarare än i bekvämlighetsordning.

  1. En enbart utgående tunnel. Ursprungsservern öppnar en anslutning till kanten och lyssnar på ingenting. Det finns ingen port att hitta, så adressen slutar vara intressant även om den läcker. Det här är det enda alternativet på listan som inte beror på att få en regel rätt.
  2. Ömsesidig TLS från kanten. Ursprungsservern svarar bara en klient som visar upp proxyns certifikat. Adressen kan läcka; den kommer inte att svara. Starkt, och det överlever att adressen blir offentlig.
  3. Brandvägg mot proxyns publicerade adressintervall. Bättre än ingenting och lätt att sätta upp, men intervallen ändras, och leverantörens egen jämförelse pekar ut den här metoden som sårbar för förfalskning. Behandla den som ett golv, inte en lösning.
  4. Städning. Rotera ursprungsadressen så snart du är bakom kanten, flytta posten från maskinen, och granska oproxyade poster efter varje ändring. De flesta exponeringar är en av dessa tre, inte en smart attack.

En proxy döljer ursprunget för en främling med en webbläsare. Den döljer inte ursprunget för proxyn själv — som känner till det per definition, och som, vid mottagandet av ett klagomål, är förpliktad att tala om för din hostingleverantör vad det är.

Under maskinen: transit, prefix, anläggning

Under din server finns ännu en uppsättning parter, och det är de en värd oftast är minst angelägen att diskutera.

Transitoperatörer. Din värd köper anslutning av någon. De operatörerna har sina egna abuse-avdelningar, avtal och risktoleranser, och en operatör som bestämmer att du är ett problem kan fatta beslutet åt din värd. Fråga hur många operatörer det finns — en enda är en enda policypunkt lika mycket som en enda felpunkt — och ställ den skarpare frågan: accepterar din värd, tyst, blockeringslistor från operatörssidan på din trafik?

Prefixet du delar. Ryktessystem arbetar på adressintervall, inte på kunder. Du ärver dina grannar, och du ärver dem utan att få veta vilka de är. Det här är den konkreta kostnaden för en leverantör som marknadsför sig som en tillflyktsort för vad som helst: blockeringslistorna når intervallet, och din post och dina API-anrop finns inuti det.

Anläggningen och hårdvaran. Hyrda rackskåp betyder en hyresvärd med en egen abuse-policy som sitter ovanför din värd, osynligt, och varje lager ovanför din värd är ännu en part som kan avsluta dig av skäl du aldrig kommer att få se.

Eftersom poängen med den här guiden är att göra varje lager svarsskyldigt, här är vårt eget i samma termer. Två transitoperatörer, BGP-balanserade, tjugo gigabit blandat, in i Chișinău. Filtrering på lager 3 och lager 4 uppströms om varje port, för alla, utan något att köpa till. Blockeringslistor från operatörssidan accepteras inte på kundtrafik: om något måste blockeras säger en domstol det, och vi talar om det för dig. Hårdvaran ägs snarare än hyrs, i ett enda land, av bolaget du köper av — detaljerna finns på nätverkssidan och anläggningssidan.

Och luckan, sagd rakt ut: vi säljer inte domäner, och vi driver inte proxyn du sätter framför din server. De två lagren är dina. Allt ovan om register och om vidarebefordrade klagomål gäller dig exakt som skrivet, och ingen hostingjurisdiktion — vår inräknad — ändrar ett ord av det.

Att lägga de tre lagren i tre olika händer

Hela guiden reduceras till en handfull beslut, och inget av dem kostar något.

  1. Tre lager, tre leverantörer, tre rättsfamiljer. Namn, kant och server i ett enda bolags händer är ett enda beslut från ingenting. I tre händer lämnar ett beslut mot vilken som helst av dem de andra två i drift och ger dig tid.
  2. Ställ samma tre frågor till varje lager. Vad kan du tvingas vidarebefordra, vad kan du tvingas ta bort, och vad kan du tvingas lämna ut? De fallerar oberoende av varandra, och en leverantör som besvarar alla tre i en enda mening har inte förstått frågan.
  3. Konfigurera som om proxyn vidarebefordrar, för det gör den. Anta att varje klagomål når din värd med din ursprungsadress bifogad. Om det utfallet är ett problem sitter lösningen i hostinglagret eller i det du publicerar — inte i att lägga till ännu en mellanhand.
  4. Stäng ursprunget ordentligt. Enbart utgående tunnel eller ömsesidig TLS; post på en annan maskin; rotera adressen efter påkopplingen; granska oproxyade poster. Fyra punkter, alla tråkiga, och de täcker nästan varje verklig exponering.
  5. Behandla namnet som din enda felpunkt, och planera för det. Vet vilket register som driver din toppdomän och under vilken lag. Håll ett andra namn, i en annan toppdomän, hos en annan registrator, och vet i förväg hur du skulle be folk använda det.

Inget av det här talar mot att sätta en proxy framför din server, och inget av det talar mot offshore-hosting — vi vore en märklig källa till något av de argumenten. Det argumenterar för att de tre lagren är tre separata köp med tre separata felmoder, och att det lager de flesta granskar hårdast inte är det som mest sannolikt gör slut på dem. Om du vill att lagret vi faktiskt driver ska hållas till samma måttstock finns kvartalssiffrorna och sidan för brottsbekämpning att kontrollera det på.

Skrivet av de ingenjörer som driver plattformen, och omläst idag. Om något här är fel eller har blivit inaktuellt, säg till via panelen – det är därifrån ungefär hälften av dessa kommer.

Språk

Läs den här webbplatsen på ditt språk

Tillgängligt på 28 språk idag. Resten håller på att översättas.