{"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-security-future","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/dns-over-https-dns-over-tls-im-hosting-sicherheit-future\/","title":{"rendered":"Using DNS over HTTPS and DNS over TLS securely in hosting"},"content":{"rendered":"<p>I'll show you how to <strong>dns over<\/strong> HTTPS (DoH) and DNS over TLS (DoT) in hosting securely without losing performance and transparency. The focus is on functionality, differences, architecture patterns and concrete steps so that your <strong>Resolver<\/strong> work reliably encrypted.<\/p>\n\n<h2>Key points<\/h2>\n\n<p>The following aspects provide you with a quick overview for a secure and high-performance integration of DoH and DoT.<\/p>\n<ul>\n  <li><strong>DoT<\/strong> encapsulates DNS directly in TLS via port 853; <strong>DoH<\/strong> uses HTTPS via port 443.<\/li>\n  <li><strong>Encryption<\/strong> protects requests from being recorded; <strong>Authentication<\/strong> saves the resolver identity.<\/li>\n  <li><strong>Hosting<\/strong>-Use: DoT is suitable for infrastructure paths; <strong>DoH<\/strong> plays in apps and browsers.<\/li>\n  <li><strong>Monitoring<\/strong> shifts to resolver logs; <strong>Policies<\/strong> prevent DNS leaks.<\/li>\n  <li><strong>Performance<\/strong> remains high with caching and reuse; <strong>Failover<\/strong> keeps services accessible.<\/li>\n<\/ul>\n\n<h2>DNS: Why encryption counts<\/h2>\n\n<p>DNS translates domains into IPs, but classic queries are often unencrypted and reveal a lot about the user. <strong>Usage behavior<\/strong>. Anyone sitting in the same network can read queries and manipulate responses, for example via spoofing or man-in-the-middle. I prevent such attacks by encrypting the transport path between the client and the resolver. DoH and DoT thus close an often overlooked gap between HTTPS web traffic and plain text DNS. This is how I strengthen <strong>Confidentiality<\/strong> and integrity without major modifications to the application.<\/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 encrypts DNS natively via TLS over port 853 and uses a TCP connection with <strong>Handshake<\/strong>. This allows me to recognize the DNS server via certificates and prevent third parties from seeing queries in plain text. DoT works very well for hosting routes between local resolvers, edge routers and upstream resolvers. I benefit from clear firewall rules because the dedicated port makes separation easier. At the same time I secure <strong>Integrity<\/strong> and ensure reproducible latencies with Connection Reuse.<\/p>\n\n<h2>DNS over HTTPS (DoH) in hosting<\/h2>\n\n<p>DoH transports DNS via HTTPS on port 443 and hides requests in the web tunnel via <strong>HTTP<\/strong>-requests. The traffic acts like normal web traffic, which makes deep packet inspection more difficult. Browsers and app stacks integrate DoH quickly because they use existing HTTPS mechanisms. In containers or microservices, I send requests directly from the application without disclosing separate DNS paths. This reduces attack surfaces and strengthens <strong>Data protection<\/strong> for sensitive workloads.<\/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>Similarities and key differences<\/h2>\n\n<p>Both DoH and DoT encrypt requests, protect against manipulation and enable <strong>Server identity<\/strong> via certificate. DoT remains easily recognizable and manageable as a pure DNS-in-TLS. DoH relies on HTTPS and integrates seamlessly into existing web stacks. In sensitive networks, DoT helps with clear policies, while DoH scores points in app-related scenarios. I combine both methods where they offer the greatest benefit. <strong>Effect<\/strong> unfold.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Feature<\/th>\n      <th>DNS over TLS (DoT)<\/th>\n      <th>DNS over HTTPS (DoH)<\/th>\n      <th>Hosting use<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Transportation<\/td>\n      <td>TLS via TCP, port <strong>853<\/strong><\/td>\n      <td>HTTPS via TLS, port <strong>443<\/strong><\/td>\n      <td>Infrastructure paths vs. app traffic<\/td>\n    <\/tr>\n    <tr>\n      <td>Recognizability<\/td>\n      <td>Easily distinguishable<\/td>\n      <td>Hard to separate from the web<\/td>\n      <td>Policy implementation vs. DPI circumvention<\/td>\n    <\/tr>\n    <tr>\n      <td>Integration<\/td>\n      <td>Resolver-, router-related<\/td>\n      <td>Browser-, app-oriented<\/td>\n      <td>Network control vs. app flexibility<\/td>\n    <\/tr>\n    <tr>\n      <td>Monitoring<\/td>\n      <td>Central <strong>Resolver<\/strong>, clear ports<\/td>\n      <td>HTTP metrics, app context<\/td>\n      <td>Network monitoring vs. app observability<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Protocol details: HTTP\/2, HTTP\/3 and DoQ at a glance<\/h2>\n\n<p>I take into account the choice of HTTP transport for DoH: HTTP\/2 allows multiplexing over a single TLS connection and thus reduces <strong>Head-of-Line<\/strong>-blocking compared to HTTP\/1.1. Where available, I also use HTTP\/3 (QUIC) to smooth latencies and better absorb packet losses. This is particularly worthwhile in edge segments with fluctuating quality. TCP remains established for DoT; I use DoQ (DNS over QUIC) experimentally where short setups without a TCP handshake help noticeably. I plan these paths optionally and keep fallbacks to DoT\/DoH ready so that I can maintain compatibility.<\/p>\n\n<h2>Architecture in hosting: sensible points of use<\/h2>\n\n<p>I define clear zones: internal resolvers speak DoT to trusted upstreams, while browsers or containers optionally use DoH. In this way, I keep internal paths controllable and give applications HTTPS-based <strong>DNS<\/strong>-channels. In multi-tenant setups, I use isolated resolvers to prevent clients from seeing other people's data. For edge locations, I use anycast resolvers to keep latencies short. Practical tips on tuning and proxy variants can be found in this <a href=\"https:\/\/webhosting.de\/en\/dns-over-https-hosting-tips-guide-proxy\/\">DoH hosting guide<\/a>, which I use as a supplement to my deployments and with <strong>Policies<\/strong> connect.<\/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>Set up a clean certificate and trust model<\/h2>\n\n<p>I make a strict distinction between opportunistic and strict encryption. Strict means: I verify the <strong>Hostnames<\/strong> of the upstream resolver against the certificate (including SAN) and document fingerprints. In internal networks, I rely on ACME-automated certificates or my own PKI, rotate keys regularly and check revocation statuses. For particularly sensitive paths, I consider mTLS between internal resolvers to authenticate not only the server but also the client. I pay attention to TLS 1.3, activate session resumption and use 0-RTT sparingly because repetitions are possible - DNS queries are idempotent, but I still exclude sensitive management requests from them.<\/p>\n\n<h2>DNSSEC and validation complement transport encryption<\/h2>\n\n<p>Encrypted transport prevents the data from being read - the <strong>Content integrity<\/strong> I also secure with DNSSEC. I activate validation on the recursive resolver, maintain the root trust anchor automatically (RFC 5011) and monitor the RRSIG error rates. If validation errors occur, I fall back on \u201eserve-stale\u201c to temporarily pass on known responses until upstreams are consistent again. This keeps services available without giving up the security line. For zones that I operate myself, I sign consistently, keep TTLs in line with rollovers and document key rotation processes cleanly.<\/p>\n\n<h2>Split horizon, policies and browser control<\/h2>\n\n<p>I avoid DNS leaks by blocking plain text ports and providing internal namespaces exclusively via internal resolvers. I configure browsers and apps specifically: I either refer to internal DoH endpoints or I prohibit non-system resolvers via policy. In this way, I ensure that split horizon zones (e.g. intern.example) are never unintentionally resolved via public DoH providers. For \u201ebreak-glass\u201c cases, I define a documented fallback that can only be activated in a controlled manner and for a limited time - including an alert so that I quickly notice any outliers.<\/p>\n\n<h2>Kubernetes and container practice deepened<\/h2>\n\n<p>In clusters, I keep the resolution predictable: CoreDNS remains the hub for service discovery, while I keep the <strong>upstream<\/strong> from CoreDNS to DoT\/DoH. Where latency matters, I use NodeLocal DNSCache to keep cache hits close to the pod. For workloads with strict constraints, I encapsulate DoH\/DoT in a sidecar resolver that accepts UDP\/TCP locally and forwards it encrypted. I document the DNSConfig of the pods (ndots, search suffixes) to avoid query explosions and simulate load peaks with synthetic queries before going into production.<\/p>\n\n<h2>Caching strategies and TTL design<\/h2>\n\n<p>I optimize <strong>Cache<\/strong>Efficiency with pre-fetching for popular records and activate \u201eserve-stale\u201c to provide responses from expired entries in the event of brief disruptions (time-limited). Negative caches prevent new resolutions for non-existent names (RFC 2308). I design TTLs in a differentiated way: shorter for dynamic services, longer for stable records. I use query minimization to avoid unnecessary information and deactivate EDNS Client Subnet if data protection has top priority. Where geo-routing is desired, I select ECS specifically and check whether the added value justifies the additional data outflows.<\/p>\n\n<h2>Resilience, DDoS protection and capacity<\/h2>\n\n<p>I scale Resolver horizontally and plan <strong>Anycast<\/strong>, so that failures of individual nodes are cushioned. Rate limits and per-tenant quotas prevent misuse in multi-tenant environments. Health checks on handshake times and error rates control automatic failover. I dimension connections (keep-alives, maximum simultaneous streams for HTTP\/2\/3) and buffers in such a way that even traffic bursts are absorbed in a stable manner. For maintenance, I rely on blue\/green deployment of resolvers, monitor the SLO metrics (availability, P95\/P99 latencies) and roll out changes in stages.<\/p>\n\n<h2>Troubleshooting: compact practical checklist<\/h2>\n\n<ul>\n  <li>TLS handshake error: Check certificate chain, synchronize host name\/SAN, ensure time\/time sync.<\/li>\n  <li>HTTP\/3 problems: Verify QUIC\/UDP shares on firewalls; fall back to HTTP\/2 in case of bottlenecks.<\/li>\n  <li>Intermittent timeouts: Harmonize keep-alive limits, max streams and idle timeouts between client\/server.<\/li>\n  <li>Performance drops: keep an eye on the cache hit rate, prefetch quotas, session resumption rate and TCP retransmits.<\/li>\n  <li>Leaks\/policy violations: Check router rules against plain text DNS, reinforce browser policies, audit app defaults.<\/li>\n  <li>DNSSEC error images: Check RRSIG expirations, clock skew and trust anchor updates; temporarily use \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>Operating DoH\/DoT resolvers: Roles and models<\/h2>\n\n<p>Having my own DoH\/DoT resolver gives me control over <strong>Logging<\/strong>, guidelines and certificates. I limit access, activate caching and set clear retention periods. For campus or enterprise environments, I validate certificates strictly and document fingerprints. Public resolvers offer an entry point, but it often pays off for hosting customers to have their own service. This is how I combine data protection, short paths and traceable <strong>Audits<\/strong>.<\/p>\n\n<h2>Security and data protection aspects<\/h2>\n\n<p>Encrypted DNS makes spoofing, cache poisoning and eavesdropping attacks more difficult because attackers no longer see requests in plain text. I reduce the risk of targeted redirects by securing transport and identity and adding DNSSEC for data integrity. At the same time, I pay attention to possible centralization effects with large public resolvers. This is where a transparent <strong>Data protection<\/strong>-policy including IP truncation and limited retention. For diagnostic purposes, I shift insights to resolver metrics and retain <strong>error patterns<\/strong> with synthetic checks in view.<\/p>\n\n<h2>Implementation scenarios in operation<\/h2>\n\n<p>For a DoT resolver, I set up port 853, store valid certificates and direct clients specifically to this endpoint. In doing so, I document fingerprints, define permitted cipher suites and plan <strong>Failover<\/strong>. If I want to use external resolvers, I set fixed allowlists and prevent DNS leaks with clear firewall rules. In Kubernetes or Docker, I encapsulate DoH\/DoT via sidecar or DaemonSet and keep internal name resolution consistent via classic DNS forwarding. This keeps paths clear, while the <strong>Transportation<\/strong>-layer is encrypted.<\/p>\n\n<h2>Performance and monitoring<\/h2>\n\n<p>TLS initialization takes time, but I reduce latency with connection reuse, session resumption and efficient caching. Persistent connections allow parallel queries and keep response times predictable. For monitoring, I record error rates, timeouts, handshake times and cache hit rates per <strong>Resolver<\/strong>. I separate logs in dashboards to quickly interpret trends and make bottlenecks visible. In addition, I simulate requests from different networks so that I can <strong>Malfunctions<\/strong> recognize early.<\/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>Configuration: Clients, routers and containers<\/h2>\n\n<p>On servers, I activate DoT\/DoH in the stub resolver and forward all requests to defined endpoints. In routers, I block plain text DNS so that no one avoids unencrypted DNS. For browsers, I set DoH policies and link them to internal endpoints. In containers, I use a local forwarder that terminates DoH\/DoT and resolves it internally in the classic way. In addition, I pull <a href=\"https:\/\/webhosting.de\/en\/dns-query-minimization-performance-resolver-cache-opti\/\">DNS Query Minimization<\/a> to reduce leakage data and to optimize the <strong>Cache<\/strong> more efficiently.<\/p>\n\n<h2>Policies, logging and data protection<\/h2>\n\n<p>I define clear rules: permitted resolvers, fallback behavior, certificate requirements and rotations. I minimize logs, shorten IPs and separate mandatory data from optional data. <strong>Diagnosis<\/strong>-entries. For support cases, I use temporary, granularly activatable debug logs. I inform customers about the storage locations, purposes and runtimes of the data. This is how I keep <strong>Compliance<\/strong> and create trust.<\/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>Industrial hygiene and cost control<\/h2>\n\n<p>I plan capacities consciously: I scale memory for caches, connection limits and CPU for validation with real usage profiles. I measure what is expensive (e.g. complex TLS handshakes, signature checks) and shift load by preheating caches and reuse to the flat phases of the day. I optimize costs and risks by defining clear SLOs, assigning budgets to metrics and establishing escalation paths for bottlenecks. This keeps the service stable, traceable and economical.<\/p>\n\n<h2>Best practices for hosting teams<\/h2>\n\n<p>I plan a resolver strategy with clear primary and secondary endpoints, separated into DoT and DoH. I renew certificates automatically and check cipher suites regularly. For operations and capacities, I continuously measure load, response times and error patterns. A clean <a href=\"https:\/\/webhosting.de\/en\/dns-architecture-hosting-resolver-ttl-performance-cacheboost\/\">DNS architecture in hosting<\/a> with coordinated TTLs and cache design keeps distances short. Documentation, troubleshooting guides and regular <strong>Tests<\/strong> secure everyday life.<\/p>\n\n<h2>Summary<\/h2>\n\n<p>DoH and DoT encrypt DNS, reduce attack surfaces and strengthen <strong>Privacy<\/strong>. In hosting, I use DoT for infrastructure paths and use DoH close to browsers and apps. I shift monitoring and diagnostics to resolver metrics and targeted tests. With caching, persistent connections and clear policies, I achieve short response times and resilient <strong>Processes<\/strong>. If you combine these components, DNS resolution is secure, traceable and efficient. I round off the picture with DNSSEC validation, clean certificate management and controlled browser management. Thanks to planned resilience, capacity management and a data protection-friendly logging strategy, the solution remains stable and compliant even under load.<\/p>","protected":false},"excerpt":{"rendered":"<p>Learn how DNS over HTTPS and DNS over TLS work in hosting, increase security and data protection and how to implement dns over https hosting step by step.<\/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\/en\/wp-json\/wp\/v2\/posts\/19609","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/comments?post=19609"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/19609\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/19602"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=19609"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=19609"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=19609"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}