{"id":19697,"date":"2026-06-05T08:35:34","date_gmt":"2026-06-05T06:35:34","guid":{"rendered":"https:\/\/webhosting.de\/dns-ttl-strategie-hochverfuegbare-infrastruktur-redundanz\/"},"modified":"2026-06-05T08:35:34","modified_gmt":"2026-06-05T06:35:34","slug":"dns-ttl-strategy-highly-available-infrastructure-redundancy","status":"publish","type":"post","link":"https:\/\/webhosting.de\/en\/dns-ttl-strategie-hochverfuegbare-infrastruktur-redundanz\/","title":{"rendered":"DNS TTL strategies for highly available infrastructures"},"content":{"rendered":"<p>I show how <strong>DNS TTL<\/strong> strategies to control the switch between locations, providers and routing policies so that users can still reliably reach the right address in the event of failures. In doing so, I balance low TTL for fast switching and higher TTL for low latency and cache efficiency, tailored to record type, criticality and <strong>Failover<\/strong>-mechanics.<\/p>\n\n<h2>Key points<\/h2>\n\n<ul>\n  <li><strong>TTL balance<\/strong>short values for switching, longer values for cache and speed<\/li>\n  <li><strong>Record types<\/strong>A\/AAAA short, CNAME medium, MX\/TXT high<\/li>\n  <li><strong>Planned changes<\/strong>: Lower TTL in advance, then increase again<\/li>\n  <li><strong>Failover<\/strong>: Health checks plus customized TTL per front end<\/li>\n  <li><strong>Monitoring<\/strong>: Measure propagation, error, resolver behavior<\/li>\n<\/ul>\n\n<h2>Why DNS controls TTL High Availability<\/h2>\n\n<p>I set <strong>TTL values<\/strong> so that DNS caches become obsolete quickly or slowly - depending on the need for switching and performance. A short TTL speeds up the switch to new IPs, but costs additional queries to authoritative servers and can slow down the performance. <strong>Latency<\/strong> increase slightly. Longer TTLs save requests, accelerate repeated calls and reduce the load, but delay changes. For highly available infrastructures, I plan TTLs according to the role of the domain: Frontdoors short, backend and validation records longer. In this way, I use DNS as an active control instrument, not as a static entry.<\/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\/dns-strategien-rechenzentrum-7629.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>How caching and propagation work<\/h2>\n\n<p>Each resolver retains responses until the expiry of the <strong>TTL<\/strong> in the cache and only then asks the authoritative server again. This is why changes do not propagate globally immediately, but instead run with a time delay from the caches. I plan updates in such a way that I lower the TTL before a change until all important resolvers have cached the short value. I then apply changes worldwide with a delay of a few minutes instead of waiting many hours. This avoids mixed states in which users still see old IPs and new accesses are already active, which <strong>Accessibility<\/strong> noticeably influenced.<\/p>\n\n<h2>Record types and useful TTLs<\/h2>\n\n<p>A and AAAA records that serve web or API front-ends get short to medium <strong>TTL<\/strong> (60-600 s) because I prioritize switches there. I usually keep CNAME entries for CDN or routing layers in the midfield (300-3,600 s) to balance flexibility and cache hits. I rarely change MX and TXT records; here I choose longer TTLs (3,600-86,400 s) so that email and security checks run with little overhead. Static content or media domains receive long values, while internal routing hosts remain very short. This differentiation saves on queries and gives me a better overview of critical endpoints. <strong>Room for maneuver<\/strong>.<\/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_ttl_meeting_4823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Table: TTL recommendations by use case<\/h2>\n\n<p>I summarize the following overview as <strong>Guard rail<\/strong> which I fine-tune depending on the load, architecture and monitoring data. Short values are aimed at switching and failure response, medium values at user-related performance, long values at rarely changed entries. For each line, I take into account the purpose, the impact on caches and the operating costs on the name server side. In this way, I make conscious decisions instead of blanket standards. In practice, I temporarily adjust downwards before major changes and then increase back to the productive level. <strong>Level<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Record type<\/th>\n      <th>Typical purpose<\/th>\n      <th>TTL recommendation<\/th>\n      <th>Reason<\/th>\n      <th>Notes<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>A\/AAAA<\/td>\n      <td>Web\/API front ends<\/td>\n      <td>60-600 s<\/td>\n      <td>Fast failover and deployments<\/td>\n      <td>Short for critical, medium for constant phases<\/td>\n    <\/tr>\n    <tr>\n      <td>CNAME<\/td>\n      <td>CDN, routing layer<\/td>\n      <td>300-3.600 s<\/td>\n      <td>Balance of changes and cache quota<\/td>\n      <td>Dependent on external provider<\/td>\n    <\/tr>\n    <tr>\n      <td>MX<\/td>\n      <td>E-mail delivery<\/td>\n      <td>3.600-86.400 s<\/td>\n      <td>Rare changes, priority reliability<\/td>\n      <td>Long TTL reduces overhead<\/td>\n    <\/tr>\n    <tr>\n      <td>TXT<\/td>\n      <td>SPF, DKIM, DMARC, validation<\/td>\n      <td>3.600-86.400 s<\/td>\n      <td>Rarely changed, cache saves queries<\/td>\n      <td>Temporarily lower during conversion<\/td>\n    <\/tr>\n    <tr>\n      <td>A\/AAAA internal<\/td>\n      <td>Control\/routing zones<\/td>\n      <td>30\u2013120 s<\/td>\n      <td>Very fast response required<\/td>\n      <td>Note name server capacity<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Planning DNS changes without outages<\/h2>\n\n<p>Before a move, I set the <strong>TTL<\/strong> of the affected record 24-48 hours in advance to 300 seconds or less. This lead time ensures that almost all resolvers have adopted the short value before I change the IP or the destination. As soon as the change has been made, I measure the propagation and check logs and monitoring for error rates. If everything is running smoothly, I increase the TTL back to a productive value between 1,800 and 3,600 seconds so that caches take effect and load decreases. This reduces the risk phase from many hours to just a few minutes without having to deal permanently with <strong>Extreme values<\/strong> to work.<\/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-ttl-strategies-blog-4671.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Failover strategies: Active\/passive<\/h2>\n\n<p>For active\/passive, I prioritize short <strong>TTL<\/strong> for the frontend domains, usually 60-300 seconds, so that I can quickly point to the backup location in the event of an error. Health checks decide when the primary IP drops out and the alternative address takes over responses. Internal services or admin accesses can be slightly longer, around 300-900 seconds, to limit the number of queries. It remains important to have a consistent test plan that regularly verifies the impact of the TTL on switchover time and user experience. I outline more about the operational procedure under <a href=\"https:\/\/webhosting.de\/en\/dns-failover-hosting-implementation-server-redundancy-failover\/\">DNS failover implementation<\/a>, where I explain the steps from monitoring to panning back.<\/p>\n\n<h2>Failover strategies: Active\/Active and Geo-Routing<\/h2>\n\n<p>In active\/active scenarios, I distribute traffic across several locations and keep <strong>TTL<\/strong> often between 120 and 600 seconds. This allows geolocation or latency-based responses to work without having to fetch each response from the authoritative server. If a location fails according to the health check, I immediately remove the associated IP from the responses and allow caches to become obsolete promptly. A TTL that is too short can significantly increase the query load; I therefore regularly measure how many lookups are received per second. I use this feedback to find the sweet spot between response time and name server capacity. <strong>Find<\/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\/06\/DNSTTLStrategienBuero1234.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Limits through resolver caches and how I test<\/h2>\n\n<p>Not all resolvers respect very short <strong>TTL<\/strong> Some set internal minimum values or extend entries. I therefore always allow for a transition phase in which some users still call up old targets. I regularly test failover with global checkpoints and correlate the results with endpoint monitoring. I specifically clear local caches on clients, browsers and routers so that measurements remain reliable. From this experience, I derive adjustments to the TTL and health check intervals until the practical switchover time meets my requirements. <strong>Goals<\/strong> achieved.<\/p>\n\n<h2>Performance vs. load: the right balance<\/h2>\n\n<p>High cache hits reduce DNS lookups and save money <strong>round trips<\/strong>, which noticeably reduces loading times. At the same time, the TTL must not be so long that I make changes too late in an emergency. I like to start with 300-1,800 seconds for www, api and login, then monitor requests per second, latency and error rates. If authoritative servers reach critical utilization, I increase them moderately; if tests show sluggish switching, I lower them again. I show how values affect measurements in the compact <a href=\"https:\/\/webhosting.de\/en\/dns-ttl-performance-comparison-optimal-flux\/\">TTL performance comparison<\/a>, which makes typical trade-offs visible.<\/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_ttl_strategien_2948.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Practical profiles for typical domains<\/h2>\n\n<p>For <strong>www<\/strong> and api I set 300-900 seconds so that I can control changes with a few minutes delay. Static assets or image domains get 3,600-86,400 seconds because infrequent updates and high cache quotas count here. I like to keep login and payment endpoints in the 300-600 second range in order to flexibly handle load changes and maintenance. I keep internal routing zones for service discovery very short (30-120 seconds), coupled with strong name server capacity. These profiles form a resilient starting point, which I can test on the basis of real <strong>Metrics<\/strong> finely optimize.<\/p>\n\n<h2>Monitoring and alerting of name resolution<\/h2>\n\n<p>I monitor <strong>Resolution times<\/strong>, error rates, NXDOMAIN peaks and query volumes separately by zone. In addition, I regularly check the global propagation for changes in order to identify individual regions with lag. In the event of anomalies, I trigger alarms and investigate whether resolvers are caching for an unusually long time or whether health checks are triggering false positives. For quick root cause analysis, I document specifications, previously set TTLs and exact change times. This transparency helps me to recognize trends and <strong>Measures<\/strong> to prioritize cleanly.<\/p>\n\n<h2>Capacity and choice of provider<\/h2>\n\n<p>The shorter the <strong>TTL<\/strong>, the more load hits the authoritative name servers. I therefore plan for sufficient capacity, anycast locations and caching benefits and avoid overly aggressive values without cross-checking. A platform with fast response, good redundancy and reliable health checks makes failover much easier. For architecture comparisons and tuning, I use tips from the <a href=\"https:\/\/webhosting.de\/en\/dns-architecture-hosting-resolver-ttl-performance-cacheboost\/\">DNS architecture<\/a> and stick to repeatable test scenarios. This keeps response times low, while switchovers are possible despite short warning times. <strong>grab<\/strong>.<\/p>\n\n<h2>DNS details: SOA, negative caches and delegation<\/h2>\n\n<p>TTL does not only affect positive responses. Negative caches - i.e. NXDOMAIN and NODATA responses - are held with the negative cache value defined in the SOA record. I set this value moderately (usually 300-900 seconds) so that typing errors and short-lived subdomains do not remain \u201enon-existent\u201c forever, while I do not unnecessarily burden authoritative servers with brute-force-type incorrect queries. I also pay attention to the TTL of <strong>NS<\/strong>-records and glue entries: They are the foundation of the delegation and are therefore allowed to live much longer (hours to days) so that resolvers do not have to constantly rebuild the delegation chain. Important: Within an RRset, all entries must have the same TTL; I keep A\/AAAA multivalue responses consistent so as not to risk unpredictable cache states.<\/p>\n\n<h2>DNSSEC and TTL in practice<\/h2>\n\n<p>With DNSSEC, the perspective shifts slightly: in addition to TTL, I look at the validity of the signatures (RRSIG). I make sure that productive TTL values are not longer than the remaining signature validity so that caches do not hoard expiring signatures. For key rotations, I plan generous transition windows, lower the TTL of relevant RRsets and the DS\/DNSKEY records moderately in advance, carry out the change and then increase them again. Negative responses (NSEC\/NSEC3) are also signed and cached; a negative TTL value that is not too high pays off here so that new subdomains become visible promptly.<\/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\/rechenzentrum-dns-ttl-4829.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Split horizon, private DNS and geo-routing in detail<\/h2>\n\n<p>In split-horizon setups, I age internal and external zones separately. Internally, I often choose very short TTLs (30-120 s) for service discovery and smooth maintenance, while externally I opt for more stable values. For geo-routing, I take into account that some resolvers centralize requests and can thus distort geolocation. Short to medium TTL helps to correct suboptimal routes more quickly without flooding the authoritative layer with continuous queries. I keep the configuration simple: clear health check signals, unambiguous location mapping and no overly complex chains of CNAMEs and redirects.<\/p>\n\n<h2>Client and resolver behavior that I schedule<\/h2>\n\n<p>Operating systems, browsers and middleboxes often set minimum and maximum values for TTL. Even 0 seconds is not passed through everywhere; many resolvers are stuck at 30-60 seconds. Conversely, some environments do not respect very high TTLs and limit them internally. There is also \u201eserve-stale\u201c behavior: If the authoritative path fails, some resolvers will still serve expired records for a short time - good for resilience, but relevant for practical switchover time. I also take into account local DNS caches in corporate networks and mobile providers, which influence the observed latency and propagation.<\/p>\n\n<h2>Modern record types and their TTLs<\/h2>\n\n<p>In addition to A\/AAAA, CNAME, MX and TXT, I include SRV and HTTPS\/SVCB records in the planning. I use SRV for service-oriented endpoints (e.g. VoIP, LDAP) and generally keep their TTL in the middle (300-1,800 s) so that priorities and weights take effect promptly. HTTPS\/SVCB transport target and transport parameters for web services; here I select similar TTLs as for the corresponding A\/AAAA or CNAMEs in order to achieve coherent switching. Longer TTLs are usually sufficient for CAA and PTR (reverse), as changes are rare, but I lower them temporarily before major provider changes.<\/p>\n\n<h2>Change playbook: Example schedule for risk-minimized changeovers<\/h2>\n\n<ul>\n  <li>T-48 h: Identify affected RRsets, document productive TTL, check negative cache values.<\/li>\n  <li>T-36 to T-24 h: Reduce TTL to 300 s (critical) or 600-900 s (non-critical), verify health checks, preheat back ends.<\/li>\n  <li>T-2 h: Run smoke tests against the target system under test host name, observe logs and capacity.<\/li>\n  <li>T-0: Perform DNS change (A\/AAAA, CNAME or SRV), document rollout and rollback conditions.<\/li>\n  <li>T+5 to T+30 min: Measure propagation, check error rates and latency, have emergency panning back ready.<\/li>\n  <li>T+2 h: Stabilization phase, increase TTL stepwise to 1,800-3,600 s if metrics are inconspicuous.<\/li>\n  <li>T+24 h: Follow-up measurement, lessons learned, anchor productive values.<\/li>\n<\/ul>\n\n<h2>Capacity model and cost effect of short TTL<\/h2>\n\n<p>I work with simple approximations to estimate the name server load: The shorter the TTL, the more frequently a resolver has to query. An expected QPS band can be derived from traffic, active clients and the proportion of \u201ecold\u201c resolutions. I plan buffers for peaks, misconfigurations and distributed attack attempts. Decisive levers are load distribution via anycast, caching-friendliness of the responses (no overlong chains) and sensible TTL spans per service. When I reach load limits, I selectively increase the TTL for less critical subdomains instead of tightening the slider globally.<\/p>\n\n<h2>Safety and risk aspects around TTL<\/h2>\n\n<p>TTL has a security effect: too long a validity period extends the range of outdated or compromised responses in an emergency. At the same time, a TTL that is too short allows attackers to potentially take more frequent shots at cache poisoning - good validation and DNSSEC are therefore mandatory. In the event of hijacks or misconfigurations, I cannot flush caches centrally; I therefore reduce the damage window through well-considered TTL and fast, documented countermeasures. For delegation-critical records (NS, DS), I avoid hectic TTL jumps and work with conservative, well-tested change paths.<\/p>\n\n<h2>Observability and test methodology in everyday life<\/h2>\n\n<p>I measure TTL \u201eon the wire\u201c: repeated queries from distributed locations show whether resolvers are aging as expected. I compare positive and negative responses, observe additional CNAME hops and check whether responses arrive with reduced TTL after a resolver has cached them. For changes, I correlate the timing of authority responses, resolver behavior and application metrics (errors, latency). It is important to avoid \u201ecache snooping\u201c risks: I test specifically on my own behalf and respect the security guidelines of the remote sites.<\/p>\n\n<h2>Documentation, governance and auditability<\/h2>\n\n<p>I hold all <strong>TTL<\/strong>-The change window is defined in writing in terms of specifications, record layouts, target systems involved and health check rules. Each change window is given a plan with pre-sinks, switchover time, audit trails and reversal. These notes speed up audits, facilitate postmortems and reduce misconfigurations. I add checklists to playbooks so that nothing is missing even in moments of stress. Clear documentation makes the control of name resolution comprehensible and supports <strong>Teamwork<\/strong> across layers.<\/p>\n\n<h2>My quintessence for DNS TTL<\/h2>\n\n<p>I treat <strong>DNS<\/strong> not as a static directory, but as an active lever for availability and speed. Different record types receive coordinated TTLs, critical frontends rather short, rarely changed entries longer. Before changes, I lower values early, measure the propagation and then switch back to productive intervals. I test failovers regularly and adjust TTL, health checks and capacity to the measured practice. Maintaining this discipline shortens maintenance windows, minimizes the consequences of failures and provides users with reliable <strong>Experience<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Discover how an optimized DNS TTL strategy supports highly available infrastructures, accelerates failover domains and enables high availability DNS.<\/p>","protected":false},"author":1,"featured_media":19690,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[674],"tags":[],"class_list":["post-19697","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":"147","_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 TTL","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":"19690","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/19697","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=19697"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/posts\/19697\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media\/19690"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/media?parent=19697"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/categories?post=19697"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/en\/wp-json\/wp\/v2\/tags?post=19697"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}