{"id":16610,"date":"2026-01-06T15:06:53","date_gmt":"2026-01-06T14:06:53","guid":{"rendered":"https:\/\/webhosting.de\/dns-ttl-falsch-performance-kostet-propagate\/"},"modified":"2026-01-06T15:06:53","modified_gmt":"2026-01-06T14:06:53","slug":"dns-ttl-onjuist-prestaties-kosten-propageren","status":"publish","type":"post","link":"https:\/\/webhosting.de\/nl\/dns-ttl-falsch-performance-kostet-propagate\/","title":{"rendered":"Waarom een verkeerde keuze van DNS TTL ten koste gaat van de algemene prestaties"},"content":{"rendered":"<p><strong>DNS TTL<\/strong> beslist hoe lang gebruikers wereldwijd oude IP's in de cache bewaren en bepaalt daarmee in aanzienlijke mate de <strong>Prestaties<\/strong> Uw website. Verkeerd ingestelde waarden veroorzaken trage propagatie, onnodige piekbelastingen en inconsistente bereikbaarheid over continenten heen.<\/p>\n\n<h2>Centrale punten<\/h2>\n\n<ul>\n  <li><strong>TTL-basisprincipes<\/strong>: De cacheduur bepaalt de updatesnelheid en de serverbelasting.<\/li>\n  <li><strong>Propagatie<\/strong>: Verschillende caches veroorzaken globale inconsistenties.<\/li>\n  <li><strong>Afwegingen<\/strong>: Een korte TTL zorgt voor flexibiliteit, een lange TTL bespaart queries.<\/li>\n  <li><strong>Hosting DNS<\/strong>: Anycast en snelle autoriteiten versnellen reacties.<\/li>\n  <li><strong>Beste praktijken<\/strong>: Voor het aanbrengen van wijzigingen verlagen, daarna weer verhogen.<\/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\/01\/dns-performanceverlust-1843.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hoe DNS TTL werkt \u2013 kort uitgelegd<\/h2>\n\n<p>Ik zie de TTL als <strong>Caching-hendel<\/strong>, die bepaalt hoe lang resolvers antwoorden bewaren voordat ze opnieuw een vraag stellen aan de gezaghebbende server. Een korte instelling versnelt wijzigingen, maar genereert meer <strong>Query's<\/strong> en daarmee de belasting op naamservers. Een lange instelling vermindert het aantal verzoeken, maar vertraagt elke wijziging van A-, AAAA- of MX-records aanzienlijk. Als ik een IP migreer en de TTL 24 uur is, blijft het oude adres tot een dag actief in de cache van veel netwerken. Dit is precies de reden waarom de beruchte propagatieverschillen optreden, waarbij gebruikers in het ene land al het nieuwe IP-adres zien, terwijl andere regio's nog steeds het oude antwoord leveren.<\/p>\n\n<h2>Caching-niveaus en TTL in de praktijk<\/h2>\n\n<p>Ik onderscheid verschillende caching-niveaus die samen de gebruikerservaring bepalen:<\/p>\n<ul>\n  <li><strong>Client-\/OS-cache<\/strong>: Besturingssystemen en browsers slaan DNS-antwoorden zelfstandig op in de cache. Deze laag respecteert meestal de TTL, maar kan lokaal aanzienlijk korter of langer werken als software eigen limieten heeft.<\/li>\n  <li><strong>Recursieve resolver (ISP\/bedrijf)<\/strong>: Hier bevindt zich de hoofdcache. Deze bepaalt hoe vaak er daadwerkelijk vragen worden gesteld aan gezaghebbende naamservers. Sommige resolvers <em>klemmen<\/em> TTL's (minimale of maximale waarden instellen) of gebruiken <em>serve-stale<\/em>, om bij upstream-problemen tijdelijk verlopen antwoorden te leveren.<\/li>\n  <li><strong>Autoritaire naamservers<\/strong>: Zij leveren de waarheid aan de zone. Hun responstijden en geografische nabijheid bepalen hoe pijnloos korte TTL's tijdens piekbelastingen functioneren.<\/li>\n<\/ul>\n<p>Ook belangrijk is <strong>negatieve caching<\/strong>: Antwoorden zoals NXDOMAIN worden opgeslagen in de resolver volgens de SOA-parameter (negatieve TTL). Dit is goed tegen overbodige queries, maar kan bij verkeerde configuraties (bijv. per ongeluk verwijderde records) de fout onnodig lang in stand houden. Ik stel negatieve TTL's praktisch in, zodat fouten snel kunnen worden gecorrigeerd.<\/p>\n\n<h2>De werkelijke kosten van een verkeerde TTL<\/h2>\n\n<p>Bij te korte TTL's reken ik altijd met een aanzienlijke toename van <strong>Serverbelasting<\/strong>, wat bij pieken in het verkeer tot vertraging en zelfs uitval kan leiden. Te lange TTL's zorgen weliswaar voor rust in de query-stroom, maar ze vertragen belangrijke wijzigingen zoals failover, certificaatwijzigingen of migratiestappen. Voor een goed onderbouwde beoordeling van de opties is het de moeite waard om een <a href=\"https:\/\/webhosting.de\/nl\/dns-ttl-prestatievergelijking-optimale-flux\/\">Vergelijking van TTL-prestaties<\/a>, die laat zien hoe sterk het aantal zoekopdrachten en de latentie vari\u00ebren, afhankelijk van de waarde. Vanuit SEO-oogpunt brengen verouderde vermeldingen een snelle time-to-first-byte in gevaar en leiden ze tot meer bouncepercentages. Elke extra seconde vertraging kost conversie, wat bij winkels direct leidt tot omzetverlies in euro's.<\/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\/01\/dns_ttl_meeting_4583.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Afwegingen: korte versus lange TTL<\/h2>\n\n<p>Ik gebruik korte TTL's als ik snelle <strong>Veranderingen<\/strong> plan en verhoog deze wanneer de infrastructuur stabiel draait en de latentie uit de cache moet komen. Dit geldt met name voor dynamische webapps, waarbij IP's of routing vaak veranderen. Langere TTL's bewaar ik voor statische sites of landingspagina's waarvan de doeladressen zelden veranderen. Een praktisch compromis ligt vaak bij 3.600 seconden, omdat hier flexibiliteit en queryvolume redelijk in balans blijven. Wie load balancing of DNS-gebaseerde failover gebruikt, kiest eerder voor korte waarden, accepteert daarvoor echter extra queries en let op de capaciteit van de autoritatieve servers.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>TTL-waarde<\/th>\n      <th>Voordelen<\/th>\n      <th>Nadelen<\/th>\n      <th>Typisch gebruik<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>300 s (5 min.)<\/td>\n      <td>Snelle updates, <strong>Failover<\/strong><\/td>\n      <td>Meer queries, hogere belasting<\/td>\n      <td>Dynamische apps, load balancing<\/td>\n    <\/tr>\n    <tr>\n      <td>3.600 s (1 uur)<\/td>\n      <td>Goed <strong>Compromis<\/strong>, matige belasting<\/td>\n      <td>Gemiddelde vertraging bij wijzigingen<\/td>\n      <td>Webapps, API's<\/td>\n    <\/tr>\n    <tr>\n      <td>86.400 s (24 uur)<\/td>\n      <td>Weinig queries, snelle cache-hit<\/td>\n      <td>Trage propagatie, trage failover<\/td>\n      <td>Statische sites, zeldzame updates<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Recordtypes in TTL-context \u2013 waar ik op let<\/h2>\n\n<p>Ik maak onderscheid tussen TTL's op basis van het type record, omdat er kettingreacties kunnen ontstaan:<\/p>\n<ul>\n  <li><strong>CNAME<\/strong>: De effectieve cache-duur wordt bepaald door de <em>kortste<\/em> TTL langs de keten (CNAME zelf plus doelrecord). Wie veel CNAME-hops heeft (bijv. CDN-setups), moet te korte waarden vermijden, anders stijgt de querybelasting onevenredig.<\/li>\n  <li><strong>ALIAS\/NAAM<\/strong> bij Apex: ze worden door de provider aan de serverzijde opgelost. Ik kies voor het zichtbare Apex-record een TTL die past bij het wijzigingsritme van de upstream en controleer hoe vaak de provider intern ververst.<\/li>\n  <li><strong>NS\/Lijm<\/strong>: Delegatie- en Glue-TTL's bevinden zich in de bovenliggende zone. Lange waarden stabiliseren de bereikbaarheid, maar vertragen de verandering van naamserver. Ik plan hier ruime doorlooptijden.<\/li>\n  <li><strong>TXT\/SRV<\/strong>: Voor SPF, DKIM, DMARC en Service Discovery stel ik gemiddelde tot langere TTL's in (bijv. 3.600\u201343.200 s), omdat deze vermeldingen minder vaak veranderen, maar bij een verkeerde configuratie verstrekkende gevolgen hebben.<\/li>\n<\/ul>\n\n<h2>Propagatieproblemen begrijpen<\/h2>\n\n<p>Ik houd er rekening mee dat ISP's en lokale resolvers TTL's gedeeltelijk <strong>negeren<\/strong> of verlengen, waardoor updates regionaal verschillend zichtbaar zijn. Hierdoor ontstaan er fasen waarin Europa de nieuwe IP gebruikt, terwijl Azi\u00eb nog steeds oude caches gebruikt. Bovendien verlengen hoge TTL's op TLD- of rootniveau het totale effect, wat zelfs goed geplande overgangen vertraagt. Voorbeeld migratie: wie de TTL niet vooraf verlaagt, riskeert uren- tot dagenlange bereikonderbrekingen en meldingen over schijnbare storingen. Ik voorkom dit door de TTL 24-48 uur voor de wijziging te verlagen, zodat de latere omschakeling gecontroleerd en betrouwbaar verloopt.<\/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\/01\/dns-ttl-performanceverlust-9274.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Hosting-DNS: invloed van de provider<\/h2>\n\n<p>Bij de keuze van een provider let ik op Anycast-netwerken, <strong>laag latent<\/strong> Betrouwbare en betrouwbare update-pijplijnen. Goede hosting DNS-platforms leveren snel wereldwijd en reageren soepel op pieken in het aantal zoekopdrachten. Zwakke platforms versterken propagatieproblemen, omdat overbelaste nameservers langzamer reageren en time-outs zich opstapelen. Wie geo-routing of failover plant, profiteert bovendien van een wereldwijd netwerk met knooppunten dicht bij de doelgroep. Een vergelijking zoals <a href=\"https:\/\/webhosting.de\/nl\/anycast-vs-geodns-smart-dns-routing-vergelijking-2025\/\">Anycast versus GeoDNS<\/a> helpt mij bij het bepalen van de juiste strategie voor bereik en veerkracht.<\/p>\n\n<h2>DNSSEC en veiligheid in combinatie met TTL<\/h2>\n\n<p>Ik gebruik DNSSEC waar mogelijk om cache poisoning en man-in-the-middle-risico's te verminderen. TTL's fungeren daarbij als <strong>Replay-barri\u00e8re<\/strong>: Kortere waarden beperken de tijd dat een ondertekend antwoord geldig mag blijven in de cache. Tegelijkertijd moeten <em>RRSIG<\/em>-handtekeningen binnen hun geldigheidsperiode vallen. Ik vermijd situaties waarin de TTL langer is dan de resterende geldigheidsduur van de handtekening \u2013 anders serveren resolvers in geval van twijfel eerder opnieuw of geven ze fouten. Voor zones met frequente wijzigingen houd ik de geldigheidsduur van handtekeningen gematigd en stem ik deze af op de gekozen TTL's.<\/p>\n\n<h2>Praktische instellingsregels voor verschillende scenario's<\/h2>\n\n<p>Ik zet meestal A- en AAAA-records <strong>korte<\/strong> tussen 300 en 1.800 seconden, als IP's af en toe veranderen of als ik met DNS-failover werk. MX-records houd ik aanzienlijk langer, ongeveer 43.200 tot 86.400 seconden, omdat mailrouting stabiel moet blijven. Voor statische websites pas ik vergelijkbare waarden toe, zodat lookups vaker uit de cache komen. Voor zeer dynamische API's of feature flags blijf ik bij 300 tot 3.600 seconden om flexibel te kunnen sturen. Na grotere projecten verhoog ik de TTL weer zodra logs en monitoring stabiele toestanden laten zien.<\/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\/01\/dns_ttl_performance_9247.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Capaciteitsplanning: queries versus TTL \u2013 een eenvoudige vuistregel<\/h2>\n\n<p>Ik plan de autoritaire capaciteit op basis van het verwachte aantal resolvers en de TTL. Grofweg geldt: hoe korter de TTL, hoe vaker er wordt gevraagd. <em>iedereen<\/em> Resolver. Een sterk vereenvoudigde berekening helpt om een idee te krijgen van de ordes van grootte:<\/p>\n<p>Stel dat 20.000 verschillende recursieve resolvers wereldwijd een populair domein opvragen. Bij <strong>TTL 300 s<\/strong> produceert dat gemiddeld ongeveer <strong>\u2248 20.000 \/ 300 \u2248 67 QPS<\/strong> per recordnaam (bijvoorbeeld de apex). Bij <strong>TTL 3.600 s<\/strong> daalt dezelfde waarde tot <strong>\u2248 5\u20136 QPS<\/strong>. In complexe opstellingen met CNAME-ketens, meerdere records en DNS-gebaseerde load balancing wordt de belasting dienovereenkomstig geschaald. Ik dimensionneer nameservers daarom niet alleen op basis van het totale verkeer, maar expliciet op basis van <em>kritisch<\/em> Namen met korte TTL.<\/p>\n\n<h2>Plan voor geplande wijzigingen en migraties<\/h2>\n\n<p>Ik bereid veranderingen voor met een duidelijk <strong>Procedure<\/strong> vooraf: 24-48 uur voor de omschakeling verlaag ik de TTL tot ongeveer 300 seconden. Na de wijziging controleer ik het nieuwe antwoord met dig en certificeer ik dat de gezaghebbende servers de gewenste vermeldingen weergeven. Daarna controleer ik openbaar toegankelijke resolvers op meerdere locaties totdat het nieuwe IP-adres overal verschijnt. Als alles stabiel is, verhoog ik de TTL weer naar de normale waarde en voer ik lokaal een cache-flush uit. Wie hier onzeker over is, vindt praktische tips op <a href=\"https:\/\/webhosting.de\/nl\/dns-caching-client-laadtijd-optimaliseren-cacheflow\/\">DNS-caching optimaliseren<\/a>, zoals ipconfig \/flushdns of killall -HUP mDNSResponder de clientcache leegmaakt.<\/p>\n\n<h2>Foutmeldingen en troubleshooting-pad<\/h2>\n\n<p>Als updates niet zichtbaar worden, werk ik gestructureerd:<\/p>\n<ul>\n  <li><strong>Autoritatief controleren<\/strong>: Is het nieuwe record identiek op alle gezaghebbende naamservers? Klopt de TTL daar?<\/li>\n  <li><strong>Resolvers vergelijken<\/strong>: Raadpleeg meerdere openbare resolvers (verschillende regio's) en bekijk de gerapporteerde resterende TTL. Grote verschillen duiden op oude caches of TTL-clamping.<\/li>\n  <li><strong>Kettingen analyseren<\/strong>: Controleer bij CNAMEs elke stap. De kortste TTL bepaalt de totale duur totdat alles up-to-date is.<\/li>\n  <li><strong>Negatieve caches<\/strong>: NXDOMAIN\/NOERROR NODATA gevallen identificeren. Een eerder ontbrekend record kan nog steeds \u201enegatief\u201c in de cache staan.<\/li>\n  <li><strong>Delegatie\/Glue<\/strong>: Bij het wijzigen van de nameserver moet u ervoor zorgen dat de updates van de parentzone zijn doorgevoerd en dat de nieuwe NS ook reageren.<\/li>\n<\/ul>\n<p>Tegelijkertijd kijk ik in de logbestanden of het aantal SERVFAIL\/time-outs toeneemt. Dit duidt vaak op overbelaste autoritatieve servers die geen korte TTL's meer ondersteunen.<\/p>\n\n<h2>Optimaliseer wereldwijde prestaties met georouting en CDN<\/h2>\n\n<p>Ik combineer gemiddelde TTL's van 1.800 tot 3.600 seconden met <strong>Geo-routing<\/strong> en CDN's, zodat gebruikers dicht bij de edge-locatie terechtkomen. Deze combinatie vermindert roundtrips, verdeelt de belasting en houdt failover snel genoeg. Bij DNS-gebaseerde load balancing werk ik met kortere TTL's, maar accepteer ik frequentere antwoorden van de autoritatieve server. In CDN-opstellingen voorkom ik bovendien hotspots, omdat meer verzoeken naar regionale knooppunten gaan en DNS vervolgens vanuit caches wordt bediend. Zo verlaag ik de wereldwijde latentie zonder dagen te verliezen bij elke routingupdate.<\/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\/01\/dns-performance-ttl-4352.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Enterprise-specificaties: Split-Horizon, VPN, DoH\/DoT<\/h2>\n\n<p>In bedrijfsnetwerken houd ik rekening met <strong>Split-horizon DNS<\/strong>, waarbij interne en externe antwoorden verschillen. Hier moeten TTL's en wijzigingsplannen aan beide kanten consistent zijn, anders ontstaan er tegenstrijdige situaties. VPN-clients hebben vaak hun eigen resolvers; hun caches volgen soms andere regels. Bovendien gebruiken veel gebruikers tegenwoordig <em>DNS via HTTPS\/TLS<\/em>. Hierdoor verschuift de cache-soevereiniteit naar globale resolvers en kunnen propagatiepatronen veranderen. Ik meet daarom bewust via meerdere resolvertypes om het werkelijke bereik te controleren in plaats van alleen het ISP-specifieke bereik.<\/p>\n\n<h2>Risico's van permanent lage of hoge TTL<\/h2>\n\n<p>Ik vermijd permanent zeer korte TTL's, omdat ze tot 50-70 procent meer <strong>Belasting<\/strong> en reserves opgebruiken. Dat brengt kosten met zich mee en verslechtert de responstijden tijdens piekuren. Aan de andere kant vind ik constant zeer lange TTL's riskant als ik met \u00e9\u00e9n druk op de knop failover nodig heb. Ook DDoS-invloeden kunnen gedeeltelijk worden verzacht met zinvolle lange TTL's, omdat meer antwoorden rechtstreeks uit caches komen. De kunst ligt in het vinden van een evenwicht tussen de updatesnelheid en het aantal zoekopdrachten.<\/p>\n\n<h2>DNS- en HTTP-caching netjes scheiden<\/h2>\n\n<p>Ik maak een duidelijk onderscheid: <strong>DNS-TTL<\/strong> bepaalt hoe snel gebruikers het juiste doeladres krijgen; <strong>HTTP-\/CDN-caches<\/strong> bepalen hoe lang inhoud achter dit adres wordt opgeslagen. Een korte DNS-TTL versnelt weliswaar routeringswijzigingen, maar lost geen verouderde inhoud aan de rand op. Omgekeerd kan een lange DNS-TTL met zeer korte HTTP-TTL's zinvol zijn als alleen inhoud vaak wordt gewijzigd. Ik stem beide op elkaar af, zodat er geen onnodige DNS-belasting ontstaat en clients geen oude assets krijgen geleverd.<\/p>\n\n<h2>Metrics en monitoring: zo houd ik TTL onder controle<\/h2>\n\n<p>Ik meet de query-snelheid, <strong>Latency<\/strong>, cache-hitratio en NXDOMAIN-quotum om het effect van mijn TTL te begrijpen. Als het aantal query's na een verlaging stijgt, pas ik de waarden aan en controleer ik de limieten van de gezaghebbende servers. Als logboeken een hoog foutenpercentage laten zien, onderzoek ik of clients oude caches gebruiken of dat ISP's afwijkende TTL's toepassen. Daarnaast optimaliseer ik het SOA-record, met name de negatieve cachewaarde, zodat resolvers onjuiste niet-bestaande antwoorden niet te lang bewaren. Regelmatige tests met tools zoals dig en globale lookup-checks zorgen ervoor dat wijzigingen overal zichtbaar worden.<\/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\/01\/dns-performance-ttl-9247.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Kort samengevat<\/h2>\n\n<p>Verkeerd ingestelde TTL's kosten wereldwijd <strong>Snelheid<\/strong> en veroorzaken updates die pas uren later zichtbaar worden. Ik zet voor wijzigingen in op korte waarden, controleer het effect en verhoog daarna weer naar een redelijk niveau. Voor statische inhoud kies ik langere TTL's, voor dynamische diensten eerder korte tot gemiddelde. Goede hosting-DNS-platforms met Anycast en nabije PoP's maken elke instelling robuuster en versnellen de reacties. Wie deze principes ter harte neemt, vermindert de latentie, versterkt de beschikbaarheid en krijgt een meetbaar betere gebruikerservaring.<\/p>","protected":false},"excerpt":{"rendered":"<p>Waarom een verkeerde keuze van DNS TTL ten koste gaat van de algemene prestaties: propagatieproblemen, hosting-DNS-tips en best practices uitgelegd.<\/p>","protected":false},"author":1,"featured_media":16603,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[674],"tags":[],"class_list":["post-16610","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":"1234","_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":null,"_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":"16603","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/16610","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=16610"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/posts\/16610\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media\/16603"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/media?parent=16610"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/categories?post=16610"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/nl\/wp-json\/wp\/v2\/tags?post=16610"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}