{"id":18961,"date":"2026-04-12T11:49:58","date_gmt":"2026-04-12T09:49:58","guid":{"rendered":"https:\/\/webhosting.de\/dns-cache-poisoning-schutz-hosting-sicherheit-protocol\/"},"modified":"2026-04-12T11:49:58","modified_gmt":"2026-04-12T09:49:58","slug":"dns-cache-poisoning-protection-hosting-security-protocol","status":"publish","type":"post","link":"https:\/\/webhosting.de\/da\/dns-cache-poisoning-schutz-hosting-sicherheit-protocol\/","title":{"rendered":"DNS-cache poisoning: beskyttelsesforanstaltninger og sikkerhed i hosting"},"content":{"rendered":"<p><strong>DNS-cache<\/strong> Poisoning rammer hostingmilj\u00f8er direkte: Angribere l\u00e6gger falske DNS-svar ind i cachen og omdirigerer brugerne til falske phishing-sider. Jeg viser p\u00e5 en praktisk m\u00e5de, hvordan jeg bruger DNSSEC, DoH\/DoT, strenge resolver-regler og overv\u00e5gning til at beskytte hosting-kunder mod <strong>Afvigelser<\/strong> og dataudstr\u00f8mning forbliver beskyttet.<\/p>\n\n<h2>Centrale punkter<\/h2>\n\n<p>Jeg opsummerer f\u00f8lgende n\u00f8gleaspekter i en kompakt form, f\u00f8r jeg g\u00e5r mere i detaljer og forklarer specifikke beskyttelsestrin for <strong>Hosting<\/strong> og drift.<\/p>\n<ul>\n  <li><strong>DNSSEC<\/strong>Kryptografiske signaturer forhindrer manipulerede svar.<\/li>\n  <li><strong>DoH\/DoT<\/strong>Krypterede transporter stopper man-in-the-middle.<\/li>\n  <li><strong>Randomisering<\/strong>: Uforudsigelige porte og ID'er g\u00f8r det sv\u00e6rere at forfalske.<\/li>\n  <li><strong>H\u00e6rdning<\/strong>Strenge resolver-politikker, patches, cache-flush.<\/li>\n  <li><strong>Overv\u00e5gning<\/strong>Logfiler, uregelm\u00e6ssigheder, CASB, advarsler i realtid.<\/li>\n<\/ul>\n<p>Jeg prioriterer f\u00f8rst <strong>DNSSEC<\/strong>, fordi det stopper forfalskning ved kilden. Derefter sikrer jeg transporten med DoH\/DoT, s\u00e5 ingen kan opsnappe anmodninger. S\u00e5 strammer jeg op p\u00e5 resolver-konfigurationen og forhindrer laterale angrebsstier. Overv\u00e5gning og audits afrunder beskyttelseskonceptet og giver mig tidlige advarselssignaler. P\u00e5 denne m\u00e5de reducerer jeg gradvist <strong>Angrebsoverflade<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/dns-schutzmassnahmen-2023.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>S\u00e5dan fungerer DNS-cacheforgiftning<\/h2>\n\n<p>Angribere manipulerer med <strong>Cache<\/strong> af en DNS-resolver ved at levere falske svar hurtigere end den legitime server. Hvis timingen lykkes, gemmer resolveren falske IP-adresser, og hver efterf\u00f8lgende anmodning f\u00e5r adgang til de falske oplysninger. Yderligere poster i \u201cAdditional\u201d- eller \u201cAuthority\u201d-delen, som en s\u00e5rbar resolver ogs\u00e5 gemmer, er s\u00e6rligt f\u00f8lsomme. Et enkelt svar kompromitterer flere dom\u00e6ner eller navneservere. Jeg genkender s\u00e5danne m\u00f8nstre i logfiler, reagerer med det samme og forkorter <strong>TTL<\/strong> ber\u00f8rte zoner.<\/p>\n\n<h2>DNSSEC: Signaturer, der g\u00f8r forfalskninger ugyldige<\/h2>\n\n<p>Med <strong>DNSSEC<\/strong> Jeg signerer zoner kryptografisk og tillader validerende resolvere at tjekke svarene entydigt. Enhver manipulation bryder signaturen, resolveren kasserer svaret og forhindrer forgiftning. Det er vigtigt, at k\u00e6den fra rodn\u00f8glen til zonen er ren, ellers virker valideringen ikke. N\u00f8gleroller (KSK\/ZSK) og planl\u00e6gbare key rollovers er et must for mig. Hvis du vil have en struktureret tilgang til at komme i gang, kan du bruge min guide <a href=\"https:\/\/webhosting.de\/da\/dnssec-hosting-sikkerhedsimplementering-trustchain\/\">Implementer DNSSEC korrekt<\/a> som <strong>Udgangspunkt<\/strong>.<\/p>\n\n<h2>Sikker transport: DoH og DoT<\/h2>\n\n<p>DoH og DoT krypterer DNS-trafikken mellem klient og resolver, s\u00e5 at <strong>Aflytter<\/strong> kan ikke manipulere anmodninger. Selvom transportkryptering ikke forhindrer cache poisoning i m\u00e5lresolveren, blokerer det for man-in-the-middle-tricks undervejs. Jeg stoler p\u00e5 standardkompatible resolvere, sikre certifikater og klare retningslinjer for hvert netv\u00e6rkssegment. For administratorer er det v\u00e6rd at tage et kig p\u00e5 den kompakte <a href=\"https:\/\/webhosting.de\/da\/dns-over-https-hosting-tips-guide-proxy\/\">Guide til DNS over HTTPS<\/a> med specifikke tuningsinstruktioner. Det er s\u00e5dan, jeg styrker k\u00e6den mellem klienten og <strong>Opl\u00f8ser<\/strong> efter eget valg.<\/p>\n\n<h2>Randomisering, cache flush og DNS firewalls<\/h2>\n\n<p>Jeg aktiverer randomiseringen af <strong>Kildehavne<\/strong> og transaktions-ID'er for at forhindre angribere i at g\u00e6tte svar. Jeg indf\u00f8rer ogs\u00e5 disciplin i TTL-styring og t\u00f8mmer cacher umiddelbart efter h\u00e6ndelser. En DNS-firewall filtrerer i\u00f8jnefaldende m\u00f8nstre og blokerer dom\u00e6ner fra kendte kampagner. Jeg vedligeholder undtagelsesregler sparsomt og dokumenterer \u00e6ndringer tydeligt. Dette giver mig mulighed for at holde signal-st\u00f8j-forholdet i <strong>Anerkendelse<\/strong> h\u00f8j.<\/p>\n\n<h2>Strenge resolver-politikker og sikre zoneoverf\u00f8rsler<\/h2>\n\n<p>Jeg begr\u00e6nser rekursive foresp\u00f8rgsler til betroede netv\u00e6rk og forbyder \u00e5bne foresp\u00f8rgsler. <strong>Opl\u00f8ser<\/strong> strengt taget. Svar m\u00e5 kun indeholde data, der vedr\u00f8rer det \u00f8nskede dom\u00e6ne; jeg kasserer alt andet. Jeg tillader kun zoneoverf\u00f8rsler (AXFR\/IXFR) via ACL og TSIG mellem definerede servere. Jeg sletter gamle eller for\u00e6ldrel\u00f8se poster efter gennemgang; dangling hosts er s\u00e6rligt risikable. Hvis du driver navneservere uafh\u00e6ngigt, skal du f\u00f8lge min praktiske vejledning <a href=\"https:\/\/webhosting.de\/da\/opsaet-din-egen-navneserver-dns-zoner-domaene-lim-poster-guide-power\/\">S\u00e6t din egen navneserver op<\/a> til <strong>Lim<\/strong>, zoner og sikre opdateringer.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/DNSCacheSicherheit5678.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>H\u00e6rdning af DNS-software og patch management<\/h2>\n\n<p>Jeg holder konsekvent BIND, Knot, PowerDNS og Unbound opdateret. <strong>Stativ<\/strong> og tester opdateringer f\u00f8r udrulning. Jeg anvender sikkerhedsopdateringer med det samme og dokumenterer rettelser med change tickets. Jeg forhindrer konfigurationsdrift med Git-versionering og automatiserede kontroller. Jeg tager backup af n\u00f8gler og zoner offline og tjekker gendannelser regelm\u00e6ssigt. P\u00e5 den m\u00e5de minimerer jeg de vinduer, hvor angribere kan udnytte kendte <strong>Huller<\/strong> udnytte.<\/p>\n\n<h2>Overv\u00e5gning og revision, der g\u00f8r angreb synlige<\/h2>\n\n<p>Jeg indsamler DNS-logfiler centralt, normaliserer felter og tagger dem. <strong>Afvigelse<\/strong> s\u00e5som sj\u00e6ldne foresp\u00f8rgselstyper eller pludselige NXDOMAIN-spidser. Metrikker som RCODE-distribution, svarst\u00f8rrelser og ventetider advarer i tilf\u00e6lde af afvigelser. Threat Intel-feeds beriger data uden at forstyrre legitime tests. En CASB hj\u00e6lper mig med at korrelere mist\u00e6nkelige m\u00f8nstre i forbindelse med SaaS-m\u00e5lendepunkter. Dette observationslag giver mig de n\u00f8dvendige <strong>Gennemsigtighed<\/strong>, for at stoppe forgiftningsfors\u00f8g p\u00e5 et tidligt tidspunkt.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/dns-cache-poisoning-protection-4721.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>H\u00e6rdning af netv\u00e6rk: Tag BCP 38 alvorligt<\/h2>\n\n<p>BCP 38 filtrerer forfalskninger <strong>Kilde-adresser<\/strong> i udkanten af netv\u00e6rket og dermed forhindre spoofing. Jeg tjekker med netv\u00e6rksteamet, om upstream-udbydere filtrerer korrekt, og rapporterer overtr\u00e6delser. Interne retningslinjer h\u00e5ndh\u00e6ver anti-spoofing p\u00e5 alle adgangsporte. Sammen med hastighedsgr\u00e6nser p\u00e5 DNS-niveau reducerer jeg st\u00f8j og letter analyser. Denne disciplin beskytter DNS-resolvere mod <strong>Oversv\u00f8mmelser<\/strong> og syntetisk trafik.<\/p>\n\n<h2>Beskyttelse af slutbrugere: private resolvere og VPN<\/h2>\n\n<p>Brugerne reducerer deres risiko, hvis de <strong>privat<\/strong> Brug resolvere, der underst\u00f8tter DoH\/DoT, og som ikke stikker \u00e5bent ud p\u00e5 internettet. En VPN tunnellerer ogs\u00e5 DNS-foresp\u00f8rgsler og forhindrer, at nysgerrige mellemm\u00e6nd f\u00e5r adgang til dem. Jeg forklarer kunderne, hvordan de kan gemme resolvere permanent i operativsystemet. Mobile enheder f\u00e5r profiler med klare DNS-specifikationer. Det holder sessionerne konsekvente, og opl\u00f8sningen forbliver under din egen kontrol. <strong>Kontrol<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/dns_sicherheit_hosting_7392.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Undg\u00e5 fejlkilder: H\u00e6ngende DNS og glemte poster<\/h2>\n\n<p>Det bliver farligt, n\u00e5r underdom\u00e6ner henviser til slettede <strong>Tjenester<\/strong> der ikke l\u00e6ngere har en destination. Angribere g\u00f8r derefter krav p\u00e5 ressourcen og kaprer trafik via gyldige DNS-poster. Jeg opg\u00f8r regelm\u00e6ssigt zoner, matcher CNAME'er og A\/AAAA-poster med rigtige m\u00e5l. Automatiserede kontroller rapporterer straks om for\u00e6ldrel\u00f8se ressourcer. Jeg sletter alt, der ikke har nogen legitim ejer efter <strong>Udgivelse<\/strong> konsekvent.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/dns_cache_schutz_4567.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Oversigt over modforanstaltninger: Effekt og prioritering<\/h2>\n\n<p>F\u00f8lgende matrix hj\u00e6lper mig med at organisere beskyttelsestrin i henhold til risiko, indsats og prioritet. <strong>Planl\u00e6g<\/strong> og huller er synlige. Jeg gennemg\u00e5r denne tabel hvert kvartal, prioriterer og justerer k\u00f8replanerne.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Risiko<\/th>\n      <th>Angrebsteknik<\/th>\n      <th>kendetegn<\/th>\n      <th>modforanstaltning<\/th>\n      <th>Udgifter<\/th>\n      <th>Prioritet<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Forgiftning<\/td>\n      <td>Falske svar<\/td>\n      <td>Uventede IP'er<\/td>\n      <td>DNSSEC-validering<\/td>\n      <td>Medium<\/td>\n      <td>H\u00f8j<\/td>\n    <\/tr>\n    <tr>\n      <td>MITM<\/td>\n      <td>Aflyttede foresp\u00f8rgsler<\/td>\n      <td>Spring i ventetid<\/td>\n      <td>DoH\/DoT<\/td>\n      <td>Lav<\/td>\n      <td>H\u00f8j<\/td>\n    <\/tr>\n    <tr>\n      <td>Misbrug af resolver<\/td>\n      <td>\u00c5ben rekursion<\/td>\n      <td>Ukendte netv\u00e6rk<\/td>\n      <td>ACL'er, m\u00e6ngdebegr\u00e6nsninger<\/td>\n      <td>Lav<\/td>\n      <td>H\u00f8j<\/td>\n    <\/tr>\n    <tr>\n      <td>Cache-forfalskninger<\/td>\n      <td>TXID\/Port-Guessing<\/td>\n      <td>Mislykkede fors\u00f8g<\/td>\n      <td>Randomisering<\/td>\n      <td>Lav<\/td>\n      <td>Medium<\/td>\n    <\/tr>\n    <tr>\n      <td>Fejlkonfiguration<\/td>\n      <td>Dinglende DNA<\/td>\n      <td>NXDOMAIN-drift<\/td>\n      <td>Opg\u00f8relse, oprydning<\/td>\n      <td>Medium<\/td>\n      <td>Medium<\/td>\n    <\/tr>\n    <tr>\n      <td>DDoS<\/td>\n      <td>Forst\u00e6rkning<\/td>\n      <td>Svar p\u00e5 oversv\u00f8mmelser<\/td>\n      <td>BCP 38, Anycast<\/td>\n      <td>Medium<\/td>\n      <td>Medium<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<p>Jeg bruger tabellen til audits, tr\u00e6ningskurser og <strong>Prioritering<\/strong> af budgetans\u00f8gninger. Hvis du planl\u00e6gger p\u00e5 en struktureret m\u00e5de, kan du g\u00f8re hurtige fremskridt med lav risiko.<\/p>\n\n<h2>Implementeringstrin: 30\/60\/90-dages plan<\/h2>\n\n<p>Om 30 dage vil jeg aktivere <strong>Randomisering<\/strong>, lukker \u00e5ben rekursion, definerer ACL'er og ops\u00e6tter alarmer. P\u00e5 dag 60 udruller jeg DoH\/DoT, tilf\u00f8jer DNS-firewallregler og rydder op i l\u00f8se poster. P\u00e5 dag 90 signerer jeg zoner med DNSSEC og etablerer key rollovers inklusive dokumentation. Samtidig vedligeholder jeg patch-rytmer og recovery-tests. Denne k\u00f8replan giver hurtig succes og en klar <strong>K\u00f8replan<\/strong> for de kommende kvartaler.<\/p>\n\n<h2>QNAME-minimering, 0x20-casing, DNS-cookies og EDNS-tuning<\/h2>\n\n<p>Ud over de grundl\u00e6ggende foranstaltninger \u00f8ger jeg opl\u00f8sningens entropi og robusthed:<\/p>\n<ul>\n  <li><strong>Minimering af QNAME<\/strong>: Opl\u00f8seren sender kun den n\u00f8dvendige del af navnet til hver <em>Myndighed<\/em>-Hop. Det betyder, at mellemstationer ser mindre kontekst, og at angrebsfladen skrumper. Jeg aktiverer dette som standard og verificerer det med tests.<\/li>\n  <li><strong>0x20-hus<\/strong>: Ved tilf\u00e6ldigt at skrive etiketterne med store bogstaver \u00f8ger jeg antallet af uigennemskuelige tr\u00e6k i svarene, som en angriber skal spejle korrekt.<\/li>\n  <li><strong>DNS-cookies<\/strong>Jeg bruger cookies p\u00e5 server- og klientsiden til at afvise spoofing-pakker og binde anmodninger til rigtige slutpunkter.<\/li>\n  <li><strong>EDNS-bufferst\u00f8rrelse<\/strong>Jeg indstiller UDP-nyttelasten konservativt (f.eks. 1232 bytes) for at undg\u00e5 fragmentering og tillade <strong>TCP fallback<\/strong> for gode svar.<\/li>\n  <li><strong>Polstring<\/strong>EDNS-padding udj\u00e6vner svarst\u00f8rrelser mod trafikanalyse og reducerer informationsl\u00e6kager.<\/li>\n  <li><strong>Minimale svar<\/strong> og <strong>Afvis enhver form for<\/strong>: Opl\u00f8seren leverer kun <em>n\u00f8dvendigt<\/em> data og ignorerer brede ANY-anmodninger, der letter angreb.<\/li>\n<\/ul>\n\n<h2>Arkitektur: Anycast-resolver, forwarder-design og zoneadskillelse<\/h2>\n\n<p>Arkitektoniske beslutninger afg\u00f8r, hvor modstandsdygtig DNS er i drift. Jeg bruger rekursive resolvere i <strong>Anycast<\/strong>-klynger for at reducere ventetiden og isolere angreb lokalt. Jeg bruger kun forwarders bevidst: Enten stoler jeg p\u00e5 en begr\u00e6nset k\u00e6de af upstream-resolvere af h\u00f8j kvalitet, eller ogs\u00e5 l\u00f8ser jeg problemet med en lokal forwarder. <strong>fuldt rekursiv<\/strong> mig selv. Til interne dom\u00e6ner bruger jeg <strong>Delt horisont<\/strong> og skelne skarpt mellem interne og eksterne visninger. Hvert milj\u00f8 (prod\/stage\/test) har sine egne cacher og ACL'er for at forhindre, at fejlkonfigurationer spreder sig.<\/p>\n\n<h2>DNSSEC-drift i praksis: algoritmer, NSEC og automatisering<\/h2>\n\n<p>I produktive zoner v\u00e6lger jeg moderne algoritmer (f.eks. ECDSA-baserede) for at f\u00e5 mindre signaturer og mindre fragmentering. Hvor det giver mening, bruger jeg <strong>NSEC3<\/strong> med moderat iteration for at g\u00f8re zonevandring sv\u00e6rere. Jeg planl\u00e6gger <strong>N\u00f8gleoverf\u00f8rsler<\/strong> deterministisk, \u00f8ve failover med sikkerhedskopier (HSM\/offline-n\u00f8gler) og dokumentere hvert trin. Til delegerede zoner bruger jeg <strong>CDS\/CDNSKEY<\/strong>-automatisering, s\u00e5 tillidsankre spredes rent. Aggressiv NSEC-caching reducerer un\u00f8dvendige upstream-anmodninger om ikke-eksisterende navne og minimerer belastningsspidser under h\u00e6ndelser.<\/p>\n\n<h2>Begr\u00e6nsning af svarprocent og RPN-styring<\/h2>\n\n<p><strong>RRL<\/strong> begr\u00e6nser svarfloden og g\u00f8r det sv\u00e6rere at misbruge den som forst\u00e6rker. Jeg s\u00e6tter gr\u00e6nser pr. kilde\/m\u00e5lkriterium og tillader \u201eslip\u201c-responser, s\u00e5 legitime opl\u00f8sere ikke bliver bremset. Med <strong>RPZ<\/strong>Jeg foretager f\u00f8rst \u00e6ndringer i DNS-politikker (DNS-firewall) i \u201eShadow Mode\u201c, observerer virkningerne og skifter f\u00f8rst derefter til \u201eEnforce\u201c. Det forhindrer falske positiver, som ellers ville p\u00e5virke tjenesterne. Jeg dokumenterer undtagelser og revurderer dem regelm\u00e6ssigt.<\/p>\n\n<h2>H\u00e6ndelsesrespons for DNS: Runbooks, Serve-Stale og NTA'er<\/h2>\n\n<p>Hvis indikatorer peger p\u00e5 forgiftning, tyer jeg til klare <strong>L\u00f8beb\u00f8ger<\/strong>:\n1) Alarmering og isolering af ber\u00f8rte resolver-instanser.\n2) <strong>Cache-skylning<\/strong> selektivt pr. zone\/navn.\n3) Midlertidig aktivering af <strong>Serve-Stale<\/strong>, for at give brugerne kendte svar, n\u00e5r upstreams svigter.\n4) Hvis en zone er forkert signeret, s\u00e6tter jeg kortvarigt en <strong>Negativt tillidsanker<\/strong>, for at sikre tilg\u00e6ngelighed - samtidig med at jeg l\u00f8ser \u00e5rsagen til signaturen.\n5) Post-mortem med log-korrelation og justering af regler og metrikker.<\/p>\n\n<h2>Forhindre fragmenteringsangreb: UDP-st\u00f8rrelse, rekursion og TCP fallback<\/h2>\n\n<p>Flere varianter af cacheforgiftning udnytter IP-fragmentering. Jeg minimerer risikoen ved at reducere EDNS-st\u00f8rrelsen og foretr\u00e6kker overlange svar via <strong>TCP<\/strong> eller DoT\/DoH og er opm\u00e6rksom p\u00e5 ren PMTU-h\u00e5ndtering. Jeg optimerer store DNSSEC-k\u00e6der ved hj\u00e6lp af passende algoritmer\/n\u00f8glest\u00f8rrelser. Jeg overv\u00e5ger ogs\u00e5 andelen af \u201etrunkerede\u201c (TC bit) svar for hurtigt at kunne genkende forkerte stier.<\/p>\n\n<h2>Klienth\u00e5ndtering i virksomheder: Politikker, DHCP\/MDM og GPO<\/h2>\n\n<p>For at sikre, at beskyttelsesforanstaltninger tr\u00e6der i kraft p\u00e5 slutenheder, distribuerer jeg <strong>Retningslinjer<\/strong> Centraliseret: DHCP-indstillinger forankrer interne resolvere, MDM-profiler (mobil) og gruppepolitikker (desktop) definerer DoH\/DoT-slutpunkter. Jeg harmoniserer browserens egne DoH-indstillinger med netv\u00e6rksstandarderne, s\u00e5 der ikke er nogen \u201eresolver-zigzag\u201c. For roaming-enheder h\u00e5ndh\u00e6ver jeg VPN-tunnelering af DNS og kontrollerer split-DNS-scenarier n\u00f8je.<\/p>\n\n<h2>Multiklient-kapacitet og delegeringsprocesser<\/h2>\n\n<p>I hosting adskiller jeg <strong>Klienter<\/strong> Streng: separate visninger\/instanser, separate keystores og roller (princippet om dobbeltkontrol) for zone\u00e6ndringer. Jeg dokumenterer delegeringer med klare ejere og livscyklusser. Ved offboarding fjerner jeg automatisk delegeringer, host records og access tokens, s\u00e5 der ikke efterlades \u201eh\u00e6ngende\u201c poster. Jeg underskriver \u00e6ndringer p\u00e5 en sporbar m\u00e5de og ruller dem ud i etaper (canary, derefter fleet).<\/p>\n\n<h2>SLO'er, tests og kaos-teknik for DNS<\/h2>\n\n<p>Jeg definerer <strong>SLO'er<\/strong> for succesrate, latenstid og valideringsrate (DNSSEC) og m\u00e5ler dem l\u00f8bende. Syntetiske kontroller sp\u00f8rger efter kritiske v\u00e6rtsnavne fra forskellige netv\u00e6rk; afvigende IP-adresser eller RCODE-m\u00f8nstre udl\u00f8ser alarmer. I kontrollerede vinduer simulerer jeg fejl (f.eks. slukkede upstreams, \u00f8delagte signaturer) for at teste runbooks. Canary resolvers med en lille brugergruppe validerer konfigurations\u00e6ndringer, f\u00f8r jeg distribuerer dem bredt.<\/p>\n\n<h2>Compliance og databeskyttelse for DNS-logfiler<\/h2>\n\n<p>DNS-logfiler kan potentielt indeholde <strong>personlig<\/strong> Data. Jeg minimerer og pseudonymiserer, hvor det er muligt, fasts\u00e6tter klare opbevaringsperioder og giver kun adgang baseret p\u00e5 roller. Jeg bruger sampling og hashing til analyser uden at miste effektiviteten af opdagelser. Jeg informerer kunderne p\u00e5 en gennemsigtig m\u00e5de om omfanget af og form\u00e5let med analyserne, s\u00e5 <strong>Overensstemmelse<\/strong> og sikkerhed g\u00e5r h\u00e5nd i h\u00e5nd.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/04\/hosting-sicherheitsmassnahmen-3942.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kort opsummeret<\/h2>\n\n<p>Jeg sikrer DNS mod <strong>Forgiftning<\/strong>, ved at kombinere DNSSEC, DoH\/DoT og strenge resolver-politikker. Randomisering, cachedisciplin og patch management g\u00f8r timing og g\u00e6tteangreb meget sv\u00e6rere. Overv\u00e5gning, audits og CASB g\u00f8r afvigelser synlige, f\u00f8r der sker skade. Netv\u00e6rksfiltre som BCP 38 og klare operat\u00f8rregler reducerer misbrug yderligere. Dette g\u00f8r hosting modstandsdygtig, og brugerne ender ved rigtige m\u00e5l i stedet for i <strong>F\u00e6lder<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Find ud af, hvordan DNS-cacheforgiftning fungerer, og hvilke beskyttelsesforanstaltninger der beskytter din hostinginfrastruktur. DNSSEC, DoH og andre DNS-sikkerhedshostingl\u00f8sninger.<\/p>","protected":false},"author":1,"featured_media":18954,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"_crdt_document":"","inline_featured_image":false,"footnotes":""},"categories":[794],"tags":[],"class_list":["post-18961","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-sicherheit-computer_und_internet"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"521","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"DNS Cache Poisoning","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"18954","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/18961","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/comments?post=18961"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/posts\/18961\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media\/18954"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/media?parent=18961"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/categories?post=18961"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/da\/wp-json\/wp\/v2\/tags?post=18961"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}