{"id":19609,"date":"2026-06-02T11:48:44","date_gmt":"2026-06-02T09:48:44","guid":{"rendered":"https:\/\/webhosting.de\/dns-over-https-dns-over-tls-im-hosting-sicherheit-future\/"},"modified":"2026-06-02T11:48:44","modified_gmt":"2026-06-02T09:48:44","slug":"dns-over-https-dns-over-tls-in-hosting-beveiliging-toekomst","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/dns-over-https-dns-over-tls-im-hosting-sicherheit-future\/","title":{"rendered":"Veilig gebruik van DNS over HTTPS en DNS over TLS in hosting"},"content":{"rendered":"<p>Ik zal je laten zien hoe je <strong>dns over<\/strong> HTTPS (DoH) en DNS over TLS (DoT) in veilige hosting zonder verlies van prestaties en transparantie. De focus ligt op functionaliteit, verschillen, architectuurpatronen en concrete stappen zodat uw <strong>Oplosser<\/strong> betrouwbaar versleuteld werken.<\/p>\n\n<h2>Centrale punten<\/h2>\n\n<p>De volgende aspecten geven je een snel overzicht voor een veilige en krachtige integratie van DoH en DoT.<\/p>\n<ul>\n  <li><strong>DoT<\/strong> kapselt DNS direct in TLS in via poort 853; <strong>DoH<\/strong> gebruikt HTTPS via poort 443.<\/li>\n  <li><strong>Encryptie<\/strong> beschermt verzoeken tegen opnemen; <strong>Authenticatie<\/strong> slaat de resolver-identiteit op.<\/li>\n  <li><strong>Hosting<\/strong>-Gebruik: DoT is geschikt voor infrastructuurpaden; <strong>DoH<\/strong> speelt in apps en browsers.<\/li>\n  <li><strong>Controle<\/strong> verschuift naar resolverlogs; <strong>Beleid<\/strong> DNS-lekken voorkomen.<\/li>\n  <li><strong>Prestaties<\/strong> blijft hoog met caching en hergebruik; <strong>Failover<\/strong> houdt diensten toegankelijk.<\/li>\n<\/ul>\n\n<h2>DNS: Waarom encryptie telt<\/h2>\n\n<p>DNS vertaalt domeinen naar IP's, maar klassieke zoekopdrachten zijn vaak onversleuteld en onthullen veel over de gebruiker. <strong>Gebruiksgedrag<\/strong>. Iedereen op hetzelfde netwerk kan query's lezen en antwoorden manipuleren, bijvoorbeeld via spoofing of man-in-the-middle. Ik voorkom zulke aanvallen door het transportpad tussen de client en de resolver te versleutelen. DoH en DoT dichten zo een vaak over het hoofd gezien gat tussen HTTPS-webverkeer en DNS met platte tekst. Zo versterk ik <strong>Vertrouwelijkheid<\/strong> en integriteit zonder grote wijzigingen aan de applicatie.<\/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\/06\/sichere-hosting-dns-verbindungen-2846.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>DNS over TLS (DoT) in hosting<\/h2>\n\n<p>DoT versleutelt DNS van nature via TLS over poort 853 en gebruikt een TCP-verbinding met <strong>Handdruk<\/strong>. Hierdoor kan ik de DNS-server herkennen via certificaten en voorkomen dat derden queries in platte tekst zien. DoT werkt erg goed voor het hosten van routes tussen lokale resolvers, edge routers en upstream resolvers. Ik profiteer van duidelijke firewallregels omdat de speciale poort scheiding eenvoudiger maakt. Tegelijkertijd beveilig ik <strong>Integriteit<\/strong> en reproduceerbare latenties garanderen met hergebruik van verbindingen.<\/p>\n\n<h2>DNS over HTTPS (DoH) in hosting<\/h2>\n\n<p>DoH transporteert DNS via HTTPS op poort 443 en verbergt verzoeken in de webtunnel via <strong>HTTP<\/strong>-verzoeken. Het verkeer gedraagt zich als normaal webverkeer, wat deep packet inspection moeilijker maakt. Browsers en app-stacks integreren DoH snel omdat ze gebruik maken van bestaande HTTPS-mechanismen. In containers of microservices stuur ik verzoeken rechtstreeks vanuit de applicatie zonder aparte DNS-paden vrij te geven. Dit verkleint het aanvalsoppervlak en versterkt <strong>Gegevensbescherming<\/strong> voor gevoelige werklasten.<\/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\/06\/dnssecuritymeeting8732.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Overeenkomsten en belangrijke verschillen<\/h2>\n\n<p>Zowel DoH als DoT versleutelen verzoeken, beschermen tegen manipulatie en maken <strong>Server-identiteit<\/strong> via een certificaat. DoT blijft gemakkelijk herkenbaar en beheersbaar als een pure DNS-in-TLS. DoH vertrouwt op HTTPS en integreert naadloos in bestaande webstacks. In gevoelige netwerken helpt DoT met een duidelijk beleid, terwijl DoH hoog scoort in app-gerelateerde scenario's. Ik combineer beide methoden waar ze het grootste voordeel bieden. <strong>Effect<\/strong> ontvouwen.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Functie<\/th>\n      <th>DNS over TLS (DoT)<\/th>\n      <th>DNS via HTTPS (DoH)<\/th>\n      <th>Hosting inzet<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Transport<\/td>\n      <td>TLS via TCP, poort <strong>853<\/strong><\/td>\n      <td>HTTPS via TLS, poort <strong>443<\/strong><\/td>\n      <td>Infrastructuurpaden vs. app-verkeer<\/td>\n    <\/tr>\n    <tr>\n      <td>Herkenbaarheid<\/td>\n      <td>Gemakkelijk te onderscheiden<\/td>\n      <td>Moeilijk te scheiden van het web<\/td>\n      <td>Beleidsimplementatie vs. DPI-omzeiling<\/td>\n    <\/tr>\n    <tr>\n      <td>Integratie<\/td>\n      <td>Resolver-, router-nabij<\/td>\n      <td>Browser- en app-geori\u00ebnteerd<\/td>\n      <td>Netwerkcontrole vs. app-flexibiliteit<\/td>\n    <\/tr>\n    <tr>\n      <td>Controle<\/td>\n      <td>Centraal <strong>Oplosser<\/strong>, poorten vrijmaken<\/td>\n      <td>HTTP-gegevens, app-context<\/td>\n      <td>Netwerkbewaking vs. app-observeerbaarheid<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Protocolgegevens: HTTP\/2, HTTP\/3 en DoQ in \u00e9\u00e9n oogopslag<\/h2>\n\n<p>Ik houd rekening met de keuze van HTTP-transport voor DoH: HTTP\/2 staat multiplexing over een enkele TLS-verbinding toe en vermindert dus <strong>Hoofd van de lijn<\/strong>-blokkering vergeleken met HTTP\/1.1. Waar beschikbaar gebruik ik ook HTTP\/3 (QUIC) om latenties af te vlakken en pakketverliezen beter op te vangen. Dit is vooral de moeite waard in randsegmenten met fluctuerende kwaliteit. TCP blijft ingesteld voor DoT; ik gebruik DoQ (DNS over QUIC) experimenteel waar korte setups zonder TCP handdruk merkbaar helpen. Ik plan deze paden optioneel en houd fallbacks naar DoT\/DoH klaar zodat ik compatibiliteit kan behouden.<\/p>\n\n<h2>Architectuur in hosting: zinvolle gebruikspunten<\/h2>\n\n<p>Ik definieer duidelijke zones: interne resolvers spreken DoT naar vertrouwde upstreams, terwijl browsers of containers optioneel DoH gebruiken. Op deze manier houd ik interne paden controleerbaar en geef ik applicaties HTTPS-gebaseerde <strong>DNS<\/strong>-kanalen. In multi-tenant opstellingen zorg ik ervoor dat resolvers ge\u00efsoleerd zijn zodat clients de gegevens van anderen niet kunnen zien. Voor locaties aan de rand gebruik ik anycast resolvers om latencies kort te houden. Praktische tips over tuning en proxy-varianten zijn te vinden in deze <a href=\"https:\/\/webhosting.de\/nl\/dns-over-https-hosting-tips-gids-proxy\/\">DoH Hosting Gids<\/a>, die ik gebruik als aanvulling op mijn uitzendingen en met <strong>Beleid<\/strong> aansluiten.<\/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\/06\/dns-sicherheit-hosting-7421.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Een schoon certificaat en vertrouwensmodel instellen<\/h2>\n\n<p>Ik maak een strikt onderscheid tussen opportunistische en strikte versleuteling. Streng betekent: ik verifieer de <strong>Hostnamen<\/strong> van de upstream resolver tegen het certificaat (inclusief SAN) en document fingerprints. In interne netwerken vertrouw ik op ACME-geautomatiseerde certificaten of mijn eigen PKI, roteer ik sleutels regelmatig en controleer ik de revocatiestatus. Voor bijzonder gevoelige paden overweeg ik mTLS tussen interne resolvers om niet alleen de server maar ook de client te authenticeren. Ik besteed aandacht aan TLS 1.3, activeer sessiehervatting en gebruik 0-RTT spaarzaam omdat herhalingen mogelijk zijn - DNS query's zijn idempotent, maar ik sluit er toch gevoelige beheerverzoeken van uit.<\/p>\n\n<h2>DNSSEC en validatie vullen transportcodering aan<\/h2>\n\n<p>Gecodeerd transport voorkomt lezen door onbevoegden - de <strong>Integriteit van inhoud<\/strong> Ik beveilig ook met DNSSEC. Ik activeer validatie op de recursieve resolver, onderhoud het root trust anchor automatisch (RFC 5011) en controleer de RRSIG-foutenpercentages. Als er validatiefouten optreden, val ik terug op \u201eserve-stale\u201c om tijdelijk bekende antwoorden door te geven totdat de upstreams weer consistent zijn. Hierdoor blijven services beschikbaar zonder de beveiligingslijn op te geven. Voor zones die ik zelf beheer, onderteken ik consistent, houd ik TTL's in lijn met rollovers en documenteer ik sleutelrotatieprocessen netjes.<\/p>\n\n<h2>Gesplitste horizon, beleidsregels en browsercontrole<\/h2>\n\n<p>Ik voorkom DNS-lekken door platte tekstpoorten te blokkeren en interne naamruimten uitsluitend via interne resolvers aan te bieden. Ik configureer browsers en apps specifiek: Ik verwijs naar interne DoH-eindpunten of ik verbied niet-systeemomzettingen via beleid. Op deze manier zorg ik ervoor dat gesplitste horizonzones (bijv. intern.example) nooit onbedoeld worden omgezet via openbare DoH-providers. Voor \u201ebreak-glass\u201c gevallen definieer ik een gedocumenteerde fallback die alleen kan worden geactiveerd op een gecontroleerde manier en voor een beperkte tijd - inclusief een waarschuwing zodat ik eventuele uitschieters snel opmerk.<\/p>\n\n<h2>Kubernetes en container praktijk verdiept<\/h2>\n\n<p>In clusters houd ik de resolutie voorspelbaar: CoreDNS blijft de hub voor service discovery, terwijl ik de <strong>Upstream<\/strong> van CoreDNS naar DoT\/DoH. Waar latency van belang is, gebruik ik NodeLocal DNSCache om cache-hits dicht bij de pod te houden. Voor werklasten met strikte beperkingen, verpak ik DoH\/DoT in een zijwaartse resolver die lokaal UDP\/TCP accepteert en versleuteld doorstuurt. Ik documenteer de DNSConfig van de pods (ndots, zoeksuffixen) om query-explosies te voorkomen en belastingspieken te simuleren met synthetische query's voordat ze in productie gaan.<\/p>\n\n<h2>Cachingstrategie\u00ebn en TTL-ontwerp<\/h2>\n\n<p>Ik optimaliseer <strong>Cache<\/strong>Verhoog de effici\u00ebntie met pre-fetchen voor populaire records en activeer \u201eserve-stale\u201c om antwoorden te geven van verlopen entries in het geval van korte onderbrekingen (tijdsbeperkt). Negatieve caches voorkomen nieuwe resoluties voor niet-bestaande namen (RFC 2308). Ik ontwerp TTL's op een gedifferentieerde manier: korter voor dynamische services, langer voor stabiele records. Ik gebruik query-minimalisatie om onnodige informatie te vermijden en schakel EDNS Client Subnet uit als gegevensbescherming de hoogste prioriteit heeft. Waar geo-routing nodig is, selecteer ik ECS specifiek en controleer ik of de toegevoegde waarde de extra gegevensuitstroom rechtvaardigt.<\/p>\n\n<h2>Veerkracht, DDoS-bescherming en capaciteit<\/h2>\n\n<p>Ik schaal Resolver horizontaal en plan <strong>Anycast<\/strong>, zodat storingen van individuele nodes worden opgevangen. Snelheidslimieten en quota's per huurder voorkomen misbruik in omgevingen met meerdere huurders. Gezondheidscontroles op handshake tijden en foutpercentages controleren automatische failover. Ik dimensioneer verbindingen (keep-alives, maximale gelijktijdige streams voor HTTP\/2\/3) en buffers zodanig dat zelfs verkeersuitbarstingen op een stabiele manier worden opgevangen. Voor onderhoud vertrouw ik op blauw\/groene inzet van resolvers, monitor ik de SLO metrieken (beschikbaarheid, P95\/P99 latencies) en rol ik veranderingen gefaseerd uit.<\/p>\n\n<h2>Problemen oplossen: compacte praktische checklist<\/h2>\n\n<ul>\n  <li>Fout bij TLS-handshake: controleer certificaatketen, synchroniseer hostnaam\/SAN, zorg voor tijd\/tijdsynchronisatie.<\/li>\n  <li>HTTP\/3-problemen: QUIC\/UDP-aandelen op firewalls controleren; terugvallen op HTTP\/2 in geval van knelpunten.<\/li>\n  <li>Onderbroken timeouts: Harmoniseer keep-alive limieten, maximale streams en idle timeouts tussen client\/server.<\/li>\n  <li>Prestatiedalingen: houd de cache hit rate, prefetch quota, sessie hervattingspercentage en TCP retransmits in de gaten.<\/li>\n  <li>Lekken\/beleidsovertredingen: Controleer routerregels tegen platte DNS-tekst, versterk het browserbeleid, controleer app-standaardinstellingen.<\/li>\n  <li>DNSSEC-foutafbeeldingen: Controleer RRSIG-vervaldatums, klokvertraging en updates van vertrouwensankers; gebruik tijdelijk \u201eserve-stale\u201c.<\/li>\n<\/ul>\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\/06\/hosting_sicher_dns_tls_7063.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Operationele DoH\/DoT resolvers: Rollen en modellen<\/h2>\n\n<p>Met mijn eigen DoH\/DoT resolver heb ik controle over <strong>Loggen<\/strong>, richtlijnen en certificaten. Ik beperk de toegang, activeer caching en stel duidelijke bewaarperioden in. Voor campus- of bedrijfsomgevingen valideer ik certificaten strikt en documenteer ik fingerprints. Publieke resolvers bieden een ingang, maar voor hostingklanten loont het vaak om een eigen service te hebben. Zo combineer ik gegevensbescherming, korte paden en traceerbaarheid <strong>Audits<\/strong>.<\/p>\n\n<h2>Beveiliging en gegevensbescherming<\/h2>\n\n<p>Versleutelde DNS maakt spoofing, cache poisoning en afluisteraanvallen moeilijker omdat aanvallers niet langer verzoeken in platte tekst zien. Ik verlaag het risico op gerichte omleidingen door transport en identiteit te beveiligen en DNSSEC toe te voegen voor gegevensintegriteit. Tegelijkertijd let ik op mogelijke centralisatie-effecten met grote publieke resolvers. Dit is waar een transparante <strong>Gegevensbescherming<\/strong>-beleid inclusief IP truncation en beperkte retentie. Voor diagnostische doeleinden verschuif ik inzichten naar resolver-metriek en behoud <strong>Foutbeelden<\/strong> met synthetische controles in het vooruitzicht.<\/p>\n\n<h2>Uitvoeringsscenario's in bedrijf<\/h2>\n\n<p>Voor een DoT resolver stel ik poort 853 in, sla geldige certificaten op en stuur cli\u00ebnten specifiek naar dit eindpunt. Daarbij documenteer ik fingerprints, definieer ik toegestane cipher suites en plan ik <strong>Failover<\/strong>. Als ik externe resolvers wil gebruiken, stel ik vaste allowlists in en voorkom ik DNS-lekken met duidelijke firewallregels. In Kubernetes of Docker kapsel ik DoH\/DoT in via sidecar of DaemonSet en houd ik de interne naamresolutie consistent via klassieke DNS forwarding. Dit houdt paden vrij, terwijl de <strong>Transport<\/strong>-laag is gecodeerd.<\/p>\n\n<h2>Prestaties en monitoring<\/h2>\n\n<p>TLS initialisatie kost tijd, maar ik verminder latentie met hergebruik van verbindingen, sessiehervatting en effici\u00ebnte caching. Persistente verbindingen maken parallelle queries mogelijk en houden de responstijden voorspelbaar. Voor monitoring registreer ik foutpercentages, timeouts, handshake tijden en cache hit rates per verbinding. <strong>Oplosser<\/strong>. Ik scheid logs in dashboards om snel trends te interpreteren en knelpunten te visualiseren. Ik simuleer ook aanvragen van verschillende netwerken zodat ik <strong>Storingen<\/strong> vroeg herkennen.<\/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\/06\/entwickler_schreibtisch_1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Configuratie: clients, routers en containers<\/h2>\n\n<p>Op servers activeer ik DoT\/DoH in de stub resolver en stuur ik alle verzoeken door naar gedefinieerde eindpunten. Op routers blokkeer ik DNS met platte tekst zodat niemand ongecodeerde DNS vermijdt. Ik stel DoH-beleid in voor browsers en koppel ze aan interne eindpunten. In containers gebruik ik een lokale forwarder die DoH\/DoT afsluit en intern op de klassieke manier omzet. Daarnaast trek ik <a href=\"https:\/\/webhosting.de\/nl\/dns-query-minimalisatie-prestaties-resolver-cache-opti\/\">DNS-query minimalisatie<\/a> om lekkende gegevens te verminderen en de <strong>Cache<\/strong> effici\u00ebnter.<\/p>\n\n<h2>Beleid, logboekregistratie en gegevensbescherming<\/h2>\n\n<p>Ik definieer duidelijke regels: toegestane resolvers, fallback-gedrag, certificaatvereisten en rotaties. Ik minimaliseer logs, verkort IP's en scheid verplichte gegevens van optionele gegevens. <strong>Diagnose<\/strong>-items. Voor ondersteuningsgevallen gebruik ik tijdelijke, granulair activeerbare debug-logs. Ik informeer klanten over de opslaglocaties, doeleinden en looptijden van de gegevens. Zo houd ik <strong>Naleving<\/strong> en vertrouwen cre\u00ebren.<\/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\/06\/dns-hosting-sicher-5831.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Industri\u00eble hygi\u00ebne en kostenbeheersing<\/h2>\n\n<p>Ik plan capaciteiten bewust: ik schaal geheugen voor caches, verbindingslimieten en CPU voor validatie met echte gebruiksprofielen. Ik meet wat duur is (bijv. complexe TLS-handshakes, handtekeningcontroles) en verschuif belasting door caches voor te verwarmen en te hergebruiken naar de vlakke fasen van de dag. Ik optimaliseer kosten en risico's door duidelijke SLO's te defini\u00ebren, budgetten toe te wijzen aan statistieken en escalatiepaden voor knelpunten vast te stellen. Dit houdt de service stabiel, traceerbaar en economisch.<\/p>\n\n<h2>Beste werkwijzen voor hostingteams<\/h2>\n\n<p>Ik plan een resolverstrategie met duidelijke primaire en secundaire eindpunten, gescheiden in DoT en DoH. Ik vernieuw automatisch certificaten en controleer regelmatig cipher suites. Voor operaties en capaciteiten meet ik continu de belasting, responstijden en foutpatronen. Een schone <a href=\"https:\/\/webhosting.de\/nl\/dns-architectuur-hosting-resolver-ttl-prestaties-cacheboost\/\">DNS-architectuur in hosting<\/a> met geharmoniseerde TTL's en cacheontwerp houdt de afstanden kort. Documentatie, probleemoplossingsgidsen en regelmatige <strong>Tests<\/strong> veilig dagelijks leven.<\/p>\n\n<h2>Samenvatting<\/h2>\n\n<p>DoH en DoT versleutelen DNS, verminderen aanvalsoppervlakken en versterken <strong>Privacy<\/strong>. Bij hosting gebruik ik DoT voor infrastructuurpaden en gebruik ik DoH dicht bij browsers en apps. Ik verschuif monitoring en diagnostiek naar resolver-metriek en gerichte tests. Met caching, persistente verbindingen en duidelijke beleidsregels bereik ik korte responstijden en veerkrachtige <strong>Processen<\/strong>. Als je deze componenten combineert, is DNS-resolutie veilig, traceerbaar en effici\u00ebnt. Ik rond het plaatje af met DNSSEC-validatie, schoon certificaatbeheer en gecontroleerd browserbeheer. Dankzij geplande veerkracht, capaciteitsbeheer en een gegevensbeschermingsvriendelijke logstrategie blijft de oplossing zelfs onder belasting stabiel en compliant.<\/p>","protected":false},"excerpt":{"rendered":"<p>Leer hoe DNS over HTTPS en DNS over TLS werken bij hosting, verhoog de beveiliging en gegevensbescherming en hoe u dns over https-hosting stap voor stap kunt implementeren.<\/p>","protected":false},"author":1,"featured_media":19602,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[674],"tags":[],"class_list":["post-19609","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-web_hosting"],"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":"73","_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 over","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":"19602","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/19609","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/comments?post=19609"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/19609\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/19602"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=19609"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=19609"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=19609"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}