{"id":19649,"date":"2026-06-03T15:03:10","date_gmt":"2026-06-03T13:03:10","guid":{"rendered":"https:\/\/webhosting.de\/dns-resolver-redundanz-hochverfuegbarkeit-hosting-failsafe\/"},"modified":"2026-06-03T15:03:10","modified_gmt":"2026-06-03T13:03:10","slug":"dns-resolver-redundancy-high-availability-hosting-failsafe","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/dns-resolver-redundanz-hochverfuegbarkeit-hosting-failsafe\/","title":{"rendered":"DNS resolver redundancy and high availability in hosting"},"content":{"rendered":"<p>DNS resolver redundancy keeps name resolution available in hosting even in the event of server or network errors; <strong>dns redundancy<\/strong> and high availability link several authoritative name servers and resolvers via separate networks, locations and automatic zone transfers. I ensure that websites, APIs and email services remain accessible even if individual components fail and other systems continue to work without errors.<\/p>\n\n<h2>Key points<\/h2>\n\n<ul>\n  <li><strong>Multiple name servers<\/strong> on separate networks and locations<\/li>\n  <li><strong>Clean delegation<\/strong> and secure zone transfers<\/li>\n  <li><strong>Resolver failover<\/strong> with short timeouts and consistent answers<\/li>\n  <li><strong>Geo-redundancy<\/strong> and anycast for low latency<\/li>\n  <li><strong>Monitoring<\/strong>, DNSSEC and clear documentation<\/li>\n<\/ul>\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\/dns_resolver_hosting_8723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Why DNS resolver redundancy in hosting is crucial<\/h2>\n\n<p>If the <strong>Name resolution<\/strong> websites and mail servers are immediately \u201eoffline\u201c, even though the machines themselves are running smoothly. That's why I plan DNS like a business-critical component and build resilience via several authoritative name servers and separate resolvers. This prevents a single error path from paralyzing the entire site and causing SLAs to be torn. Short response times, consistent zones and clever caching strategies measurably safeguard the user experience. I also take SEO influences into account, because repeated unavailability of the <strong>Domain<\/strong> triggers negative signals and loading times via the DNS path can increase.<\/p>\n\n<h2>Keep authoritative name servers and resolvers clearly separate<\/h2>\n\n<p>I make a strict distinction between <strong>authoritative<\/strong> name servers and recursive resolvers, as both layers require their own redundancy. Authoritative servers store zones and provide final answers, while resolvers resolve requests for clients and cache results. In practice, I set at least two, preferably three authoritative name servers per zone, distribute them to different IP networks and locations and secure zone transfers via TSIG. For clients, I store at least two resolvers with short timeouts so that the change is not noticeable in the event of a failure. This separation prevents incorrect assumptions and increases the <strong>Availability<\/strong> across both levels.<\/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_resolver_meeting_5273.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Delegation, glue and parameters in the parent zone<\/h2>\n<p>Redundancy starts with the delegation: I check that in the <em>Parent zone<\/em> correct NS records are stored and the necessary <strong>Glue-Records<\/strong> (A\/AAAA) exist for in-zone nameservers. Without a valid glue, a resolver may hang cyclically or rely on external sources. For dual stack setups I provide <strong>IPv4 and IPv6-Glue<\/strong> and pay attention to suitable TTLs in the parent zone, which do not always match the domain TTLs. When changing registrars or registries, I plan propagation times and verify delegation before switching productive loads. In this way, I avoid edge cases in which part of the Internet is still using old paths while others are already requesting new name servers.<\/p>\n\n<h2>Basic principles for highly available DNS setups<\/h2>\n\n<p>I anchor several <strong>Nameserver<\/strong> per domain, secure zone transfers, check delegation with the registrar and test regularly with tools such as dig. A primary server manages the zone, secondaries receive changes automatically via IXFR, triggered by the SOA serial. IP whitelists and TSIG secure transfers, while separate data centers reduce the location risk. In addition, I plan sensible TTL values in order to be able to switch faster during relocations without permanently increasing the load. These principles keep the responses consistent and the <strong>Accessibility<\/strong> high - even during maintenance or malfunctions.<\/p>\n\n<h2>Versioning and change discipline in zones<\/h2>\n<p>I use a clear <strong>SOA serial strategy<\/strong> (e.g. date format) and rolled out changes atomically: I change related records (A\/AAAA, MX, TXT, SPF) in one step. <strong>NOTIFY<\/strong> ensures that secondaries follow quickly with IXFR; where only AXFR is possible, I plan the transfer window and bandwidth. For risky changes, I lower TTLs in advance, set a <em>Freeze window<\/em> after the rollout and monitor the responses from all authoritative servers. I document dependencies (e.g. LB IPs, WAF IPs, CDN hostnames) so that there are no gaps when external components change.<\/p>\n\n<h2>Configure resolver failover correctly<\/h2>\n\n<p>By default, many clients first ask the first <strong>Resolver<\/strong> and only change after a timeout, so I set short, practical values. I make sure that stored resolvers provide consistent responses so that applications do not oscillate between different states. In the event of location or WAN problems, a second resolver in the other network prevents long waiting times and waves of calls to support. I measure response times, error rates and cache efficiency to detect bottlenecks early and proactively resolve them. This keeps the <strong>User Journey<\/strong> smoothly, even if a server fails or load peaks occur.<\/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-resolver-high-availability-7498.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Understanding client behavior and network provisioning<\/h2>\n<p>I take into account how <strong>Clients receive resolvers<\/strong>via DHCPv4 (option 6), DHCPv6 or RDNSS in IPv6 router advertisements. Different operating systems query resolvers differently; some use strictly sequential timeouts, others send parallel queries. I therefore keep timeouts short and ensure low latency to each resolver. With <strong>EDNS(0)<\/strong> I optimize packet sizes, plan a reliable TCP fallback and pay attention to MTU issues so that fragmentation does not swallow up responses. In corporate networks, I harmonize resolver lists between end devices, servers and network devices so that diagnostics and failover remain reproducible.<\/p>\n\n<h2>Making sensible use of geo-redundancy and anycast<\/h2>\n\n<p>For international users, I reduce latency via <strong>Anycast<\/strong>, so that requests automatically land at the nearest node. This distributes attacks and load across many locations and increases the chance that at least one node will respond at all times. For sensitive services, I combine Anycast with several providers in order to intercept provider failures. If you want to delve deeper, you can find technical background information on routing and latency in <a href=\"https:\/\/webhosting.de\/en\/dns-resolver-anycast-networks-hosting-low-latency-routing\/\">Anycast networks in hosting<\/a>. With this chain of geo-distribution, anycast and clean delegation, I increase the <strong>Resilience<\/strong> noticeable.<\/p>\n\n<h2>Anycast operation in detail<\/h2>\n<p>In productive Anycast operation, I link <strong>Health checks<\/strong> of the DNS software with the routing: If a node fails, it automatically withdraws its prefix. I use controlled <em>Prepending<\/em> or communities to drive traffic per region, and plan <em>Draining<\/em> before maintenance. Monitoring checks each instance separately and correlates BGP status with response quality. In the event of faults, I have playbooks ready that specifically switch nodes \u201edark\u201c without jeopardizing global availability. Anycast thus remains more than just a routing trick - it becomes a resilient operational discipline.<\/p>\n\n<h2>Typical architectures in comparison<\/h2>\n\n<p>I choose the architecture according to <strong>Requirements<\/strong>, budget and team know-how. Classic master-slave setups provide a good start and can be operated in a controlled manner. Multi-provider solutions provide additional protection against provider failures, but require clean synchronization. Anycast networks excel in terms of latency and DDoS distribution, but require careful planning and monitoring. The following table shows the core properties of the common variants and helps with the <strong>Classification<\/strong>:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Architecture<\/th>\n      <th>Availability<\/th>\n      <th>Latency<\/th>\n      <th>Operating expenses<\/th>\n      <th>Typical use<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Master-Slave<\/td>\n      <td>High for separate networks\/locations<\/td>\n      <td>Good, depending on locations<\/td>\n      <td>Low to medium<\/td>\n      <td>Small to medium-sized projects<\/td>\n    <\/tr>\n    <tr>\n      <td>Multi-provider DNS<\/td>\n      <td>Very high with good synchronization<\/td>\n      <td>Good to very good<\/td>\n      <td>Medium to high<\/td>\n      <td>Critical domains, provider independence<\/td>\n    <\/tr>\n    <tr>\n      <td>Anycast DNS<\/td>\n      <td>Very high due to node distribution<\/td>\n      <td>Very good (next node)<\/td>\n      <td>Funds (planning\/monitoring required)<\/td>\n      <td>Global traffic, e-commerce, SaaS<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\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_resolver_redundanz_7823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Split horizon and internal zones<\/h2>\n<p>Where internal and external responses differ, I use <strong>Split horizon<\/strong> (views) or conditional forwarding. Consistency is important: the external namespace must function independently, internal additional information must not leak any sensitive details to the outside. I document which resolvers have which view and regularly test from external vantage points to prevent accidental exposure. For hybrid cloud setups, I define clear responsibilities so that internal queries do not reach the public internet unintentionally.<\/p>\n\n<h2>TTL strategy, caching and consistency<\/h2>\n\n<p>I set <strong>TTL<\/strong>-I consciously choose moderate TTL values: TTLs that are too short increase the load, TTLs that are too long slow down changes. For critical entries such as load balancers or MX, I choose moderate values and lower them for a limited time before planned moves. I keep resolver caches consistent by rolling out changes cleanly with SOA serials and closely monitoring secondary servers. If you are looking for background information on TTL, resolver behavior and performance, you can find practical knowledge at <a href=\"https:\/\/webhosting.de\/en\/dns-architecture-hosting-resolver-ttl-performance-cacheboost\/\">Resolver, TTL and performance<\/a>. This discipline ensures that answers arrive quickly and that the <strong>User Experience<\/strong> does not suffer.<\/p>\n\n<h2>Stale serving, negative caching and prefetching<\/h2>\n<p>Redundancy becomes more robust when resolvers are used for short-term faults <strong>stal answers<\/strong> are allowed to deliver. I configure serve-stale carefully, limit the time window and correlate it with monitoring so that errors are not concealed. Negative caching (NXDOMAIN\/NODATA) is based on the SOA specification for the negative TTL - I set moderate values here so as not to unnecessarily reinforce misconfigurations. Popular records <strong>prefetche<\/strong> I before they fall out of the cache to keep hot-paths fast. All this only works if the data source (authoritative server) is stable and consistent.<\/p>\n\n<h2>Security: DNSSEC, zone transfers and hardening<\/h2>\n\n<p>I increase the integrity of the answers with <strong>DNSSEC<\/strong>, if the provider and domain setup support it. I limit zone transfers to known IPs and additionally secure them via TSIG to prevent unauthorized data tapping. I keep name server software up to date, reduce open resolver risks and monitor false patterns that indicate attacks. Rate limiting and response policies help to curb abusive patterns without severely impacting legitimate traffic. These measures dovetail with redundancy because failure paths through <strong>Security<\/strong>-events otherwise come as a surprise.<\/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\/dnsresolver_desk_6572.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Data protection, logging and compliance<\/h2>\n<p>I log DNS queries in such a way that <strong>Error analysis<\/strong> possible, but personal data is protected: limited storage, pseudonymization where appropriate, strict access rights. In sensitive environments, I use the following for Resolver <strong>DoT\/DoH<\/strong> at transport level, but taking into account operational aspects (certificates, pinning, monitoring). <em>QNAME minimization<\/em> and hard ACLs reduce unnecessary data exposure. My documentation records which logs are needed for what and when they are deleted - so compliance is not a brake pad, but part of reliable operation.<\/p>\n\n<h2>Monitoring, tests and SLAs without gaps<\/h2>\n\n<p>I monitor every <strong>Nameserver<\/strong> for availability, response times and error rates and link alarms to escalation chains. Synthetic checks from several regions show me early on if a location is weakening. I regularly perform load and failover tests to ensure that SLAs on availability and response times have substance. When changes are made, I check delegation, SOA serial, zone transfers and response routes to detect inconsistencies immediately. This is how I keep my <strong>Service quality<\/strong> measurable and can intercept problems before they affect users.<\/p>\n\n<h2>SLOs, latency profiles and error budgets<\/h2>\n<p>I define <strong>SLIs<\/strong> for success rate (e.g. NXDOMAIN excluded), p50\/p90\/p99 latencies and correlate them with load. <strong>SLOs<\/strong> result from user expectations and business risk; error budgets control how much maintenance leeway remains. <em>Burn rate<\/em>-Detect alerts when outages quickly consume the budget. Dashboards compare authoritative and recursive paths so that I can see whether problems lie with the resolver, the network route or the authoritative servers. This transparency is the basis for credible SLAs.<\/p>\n\n<h2>Integration into the hosting landscape<\/h2>\n\n<p>DNS only works if web servers, databases, network paths and firewalls are also set up to be fail-safe, so I think <strong>End-to-end<\/strong>. Load balancers, cluster replication and separate router paths reduce single points of failure and supplement DNS protection. I document all dependencies so that changes do not trigger chain reactions. I remain capable of acting under heavy load if resolvers and caches are appropriately dimensioned; information on capacity is provided by <a href=\"https:\/\/webhosting.de\/en\/dns-resolver-load-handling-high-last-cacheboost\/\">Load distribution on the resolver<\/a>. DNS thus reliably routes queries to services that are also <strong>highly available<\/strong> work.<\/p>\n\n<h2>Container and Kubernetes environments<\/h2>\n<p>In containers, DNS requirements often scale by leaps and bounds: service discovery, short TTLs and many pods generate query peaks. I use <strong>CoreDNS<\/strong> cleanly, use NodeLocal DNSCache, stubDomains and upstreams in a targeted manner and shield external resolvers from flooding. Readiness\/liveness probes of applications must not overload resolvers; caches at node level smooth out peaks. I check whether internal zones (e.g. cluster services) are clearly separated from external ones and simulate failover so that deployments do not fail due to DNS bottlenecks.<\/p>\n\n<h2>Checklist briefly explained<\/h2>\n\n<p>For productive <strong>Domains<\/strong> I store at least two, ideally three, authoritative name servers on separate networks and locations and check the delegation. I secure zone transfers, activate DNSSEC where possible and keep documentation and emergency plans up to date. Tests and monitoring run continuously, including alerts and regular test rollouts with shortened TTLs. For more resilience, I plan anycast or multi-provider setups, depending on risk and budget. This line provides me with a <strong>reliable<\/strong> Resolution that also works under stress.<\/p>\n\n<h2>SEO impact and user experience<\/h2>\n\n<p>Slow <strong>DNS<\/strong>-Responses lengthen the time to first byte and affect loading times, which is felt by users and crawlers alike. Recurring failures send bad signals and cost ranking opportunities, so availability is a priority. With clean resolver failover, short timeouts and geo-distribution, I ensure fast responses everywhere. Cache hits reduce latency, and consistent zones prevent misbehaving applications. A well thought out dns redundancy hosting strategy pays direct dividends on <strong>User satisfaction<\/strong> and visibility.<\/p>\n\n<h2>Email-specific aspects without surprises<\/h2>\n<p>E-mail is particularly sensitive: I operate <strong>MX-Failover<\/strong> via separate networks\/locations and set priorities so that the load is distributed sensibly. SPF records take all sending systems and providers into account; I test changes in advance with a lowered TTL. <strong>DKIM<\/strong>-I roll out the keys as planned, keep several selectors available and ensure that all authoritative nameservers keep the new keys synchronized. DMARC policy adjustments (<em>p=none\u2192quarantine\u2192reject<\/em>) with monitoring to ensure that legitimate mails do not go nowhere. This keeps deliverability high even in the event of failover.<\/p>\n\n<h2>My practice timetable<\/h2>\n\n<p>I start with a <strong>actual analysis<\/strong> delegation, check locations, IP networks and zone transfers and eliminate single points of failure. I then optimize TTLs, activate DNSSEC, set alerting profiles and plan failover tests in the calendar. For global traffic, I add anycast or a second provider and clearly document change paths. I then continuously measure response times, success rates and cache efficiency and scale resolvers when traffic increases. This keeps the <strong>Name resolution<\/strong> reliable, fast and highly available - exactly what modern hosting environments need.<\/p>\n\n<h2>Incident and chaos engineering for DNS<\/h2>\n<p>I'm practicing for an emergency: <strong>GameDays<\/strong> simulate resolver failures, left anycast nodes are specifically withdrawn, WAN latencies are artificially increased. I observe how quickly clients switch over, whether timeouts are appropriate and whether alarms fire correctly. Runbooks contain clear steps for delegation errors, defective signatures (DNSSEC) and failed transfers. Backups of zones and keys are tested, RTO\/RPO is defined. These exercises show where processes get stuck - and harden the entire chain from the client to the authoritative server.<\/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-serverraum-4816.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>","protected":false},"excerpt":{"rendered":"<p>Find out how DNS resolver redundancy works in hosting with multiple name servers and high-availability architecture and why this dns redundancy hosting strategy is so important for performance and SEO.<\/p>","protected":false},"author":1,"featured_media":19642,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[674],"tags":[],"class_list":["post-19649","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":"54","_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 redundancy","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":"19642","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/19649","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=19649"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/19649\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/19642"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=19649"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=19649"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=19649"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}