{"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":"strategia-dns-ttl-wysoce-dostepna-redundancja-infrastruktury","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pl\/dns-ttl-strategie-hochverfuegbare-infrastruktur-redundanz\/","title":{"rendered":"Strategie DNS TTL dla infrastruktur o wysokiej dost\u0119pno\u015bci"},"content":{"rendered":"<p>Pokazuj\u0119, jak <strong>DNS TTL<\/strong> strategie kontrolowania prze\u0142\u0105czania mi\u0119dzy lokalizacjami, dostawcami i zasadami routingu, aby u\u017cytkownicy mogli nadal niezawodnie dociera\u0107 do w\u0142a\u015bciwego adresu w przypadku awarii. W ten spos\u00f3b r\u00f3wnowa\u017c\u0119 niski TTL dla szybkiego prze\u0142\u0105czania i wy\u017cszy TTL dla niskiego op\u00f3\u017anienia i wydajno\u015bci pami\u0119ci podr\u0119cznej, dostosowany do typu rekordu, krytyczno\u015bci i wydajno\u015bci. <strong>Prze\u0142\u0105czanie awaryjne<\/strong>-Mechanika.<\/p>\n\n<h2>Punkty centralne<\/h2>\n\n<ul>\n  <li><strong>Balans TTL<\/strong>Kr\u00f3tkie warto\u015bci dla prze\u0142\u0105czania, d\u0142u\u017csze warto\u015bci dla pami\u0119ci podr\u0119cznej i pr\u0119dko\u015bci<\/li>\n  <li><strong>Typy rekord\u00f3w<\/strong>A\/AAA kr\u00f3tkie, CNAME \u015brednie, MX\/TXT wysokie<\/li>\n  <li><strong>Planowane zmiany<\/strong>Obni\u017cenie TTL z wyprzedzeniem, a nast\u0119pnie ponowne zwi\u0119kszenie<\/li>\n  <li><strong>Prze\u0142\u0105czanie awaryjne<\/strong>Kontrole stanu oraz niestandardowy TTL na front-end<\/li>\n  <li><strong>Monitoring<\/strong>Pomiar propagacji, b\u0142\u0105d, zachowanie resolwera<\/li>\n<\/ul>\n\n<h2>Dlaczego DNS kontroluje wysok\u0105 dost\u0119pno\u015b\u0107 TTL<\/h2>\n\n<p>Ustawi\u0142em <strong>Warto\u015bci TTL<\/strong> dzi\u0119ki czemu pami\u0119ci podr\u0119czne DNS staj\u0105 si\u0119 przestarza\u0142e szybko lub powoli - w zale\u017cno\u015bci od wymaga\u0144 dotycz\u0105cych prze\u0142\u0105czania i wydajno\u015bci. Kr\u00f3tki TTL przyspiesza prze\u0142\u0105czanie na nowe adresy IP, ale wi\u0105\u017ce si\u0119 z dodatkowymi zapytaniami do serwer\u00f3w autorytatywnych i mo\u017ce spowolni\u0107 dzia\u0142anie systemu. <strong>Op\u00f3\u017anienie<\/strong> nieznacznie wzrosn\u0105\u0107. D\u0142u\u017csze TTL oszcz\u0119dzaj\u0105 \u017c\u0105dania, przyspieszaj\u0105 powtarzaj\u0105ce si\u0119 wywo\u0142ania i zmniejszaj\u0105 obci\u0105\u017cenie, ale op\u00f3\u017aniaj\u0105 zmiany. W przypadku wysoce dost\u0119pnych infrastruktur planuj\u0119 TTL w zale\u017cno\u015bci od roli domeny: Frontdoor kr\u00f3tkie, backend i rekordy walidacji d\u0142u\u017csze. W ten spos\u00f3b u\u017cywam DNS jako aktywnego instrumentu kontroli, a nie jako statycznego wpisu.<\/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>Jak dzia\u0142a buforowanie i propagacja<\/h2>\n\n<p>Ka\u017cdy resolver przechowuje odpowiedzi do momentu wyga\u015bni\u0119cia limitu <strong>TTL<\/strong> w pami\u0119ci podr\u0119cznej, a dopiero potem ponownie wysy\u0142a zapytanie do serwera autorytatywnego. To dlatego zmiany nie s\u0105 propagowane globalnie natychmiast, ale zamiast tego s\u0105 uruchamiane z op\u00f3\u017anieniem czasowym z pami\u0119ci podr\u0119cznej. Planuj\u0119 aktualizacje w taki spos\u00f3b, \u017ce obni\u017cam TTL przed zmian\u0105, dop\u00f3ki wszystkie wa\u017cne resolvery nie zbuforuj\u0105 kr\u00f3tkiej warto\u015bci. Nast\u0119pnie stosuj\u0119 zmiany na ca\u0142ym \u015bwiecie z kilkuminutowym op\u00f3\u017anieniem zamiast czeka\u0107 wiele godzin. Pozwala to unikn\u0105\u0107 mieszanych stan\u00f3w, w kt\u00f3rych u\u017cytkownicy nadal widz\u0105 stare adresy IP, a nowe dost\u0119py s\u0105 ju\u017c aktywne. <strong>Dost\u0119pno\u015b\u0107<\/strong> zauwa\u017calny wp\u0142yw.<\/p>\n\n<h2>Typy rekord\u00f3w i przydatne warto\u015bci TTL<\/h2>\n\n<p>Rekordy A i AAAA, kt\u00f3re obs\u0142uguj\u0105 interfejsy sieciowe lub API, maj\u0105 kr\u00f3tkie lub \u015brednie warto\u015bci. <strong>TTL<\/strong> (60-600 s), poniewa\u017c tam nadaj\u0119 priorytet prze\u0142\u0105cznikom. Zwykle utrzymuj\u0119 wpisy CNAME dla CDN lub warstw routingu w \u015brednim zakresie (300-3 600 s), aby zharmonizowa\u0107 elastyczno\u015b\u0107 i trafienia w pami\u0119ci podr\u0119cznej. Rzadko zmieniam rekordy MX i TXT; tutaj wybieram d\u0142u\u017csze TTL (3 600-86 400 s), aby poczta e-mail i kontrole bezpiecze\u0144stwa dzia\u0142a\u0142y z niewielkim narzutem. Statyczne domeny tre\u015bci lub medi\u00f3w otrzymuj\u0105 d\u0142ugie warto\u015bci, podczas gdy wewn\u0119trzne hosty routingu pozostaj\u0105 bardzo kr\u00f3tkie. Takie rozr\u00f3\u017cnienie pozwala zaoszcz\u0119dzi\u0107 na zapytaniach i daje mi lepszy przegl\u0105d krytycznych punkt\u00f3w ko\u0144cowych. <strong>Pole manewru<\/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>Tabela: Zalecenia dotycz\u0105ce TTL w zale\u017cno\u015bci od przypadku u\u017cycia<\/h2>\n\n<p>Poni\u017cszy przegl\u0105d podsumowuj\u0119 nast\u0119puj\u0105co <strong>Szyna ochronna<\/strong> kt\u00f3re dostrajam w zale\u017cno\u015bci od obci\u0105\u017cenia, architektury i danych z monitoringu. Kr\u00f3tkie warto\u015bci s\u0105 ukierunkowane na prze\u0142\u0105czanie i reakcj\u0119 na awarie, \u015brednie warto\u015bci na wydajno\u015b\u0107 zwi\u0105zan\u0105 z u\u017cytkownikami, d\u0142ugie warto\u015bci na rzadko zmieniane wpisy. Dla ka\u017cdej linii bior\u0119 pod uwag\u0119 cel, wp\u0142yw na cache i koszty operacyjne po stronie serwera nazw. W ten spos\u00f3b podejmuj\u0119 \u015bwiadome decyzje zamiast uog\u00f3lnionych standard\u00f3w. W praktyce, przed wi\u0119kszymi zmianami, tymczasowo obni\u017cam warto\u015bci, a nast\u0119pnie zwi\u0119kszam je z powrotem do poziomu produkcyjnego. <strong>Poziom<\/strong>.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Typ rekordu<\/th>\n      <th>Typowy cel<\/th>\n      <th>Zalecenie TTL<\/th>\n      <th>Pow\u00f3d<\/th>\n      <th>Uwagi<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>A\/AAAA<\/td>\n      <td>Interfejsy WWW\/API<\/td>\n      <td>60-600 s<\/td>\n      <td>Szybkie prze\u0142\u0105czanie awaryjne i wdro\u017cenia<\/td>\n      <td>Kr\u00f3tki dla faz krytycznych, \u015bredni dla faz sta\u0142ych<\/td>\n    <\/tr>\n    <tr>\n      <td>CNAME<\/td>\n      <td>CDN, warstwa routingu<\/td>\n      <td>300-3.600 s<\/td>\n      <td>Bilans zmian i limit pami\u0119ci podr\u0119cznej<\/td>\n      <td>Zale\u017cy od zewn\u0119trznego dostawcy<\/td>\n    <\/tr>\n    <tr>\n      <td>MX<\/td>\n      <td>Dostarczanie wiadomo\u015bci e-mail<\/td>\n      <td>3.600-86.400 s<\/td>\n      <td>Rzadkie zmiany, priorytetowa niezawodno\u015b\u0107<\/td>\n      <td>D\u0142ugi TTL zmniejsza koszty og\u00f3lne<\/td>\n    <\/tr>\n    <tr>\n      <td>TXT<\/td>\n      <td>SPF, DKIM, DMARC, walidacja<\/td>\n      <td>3.600-86.400 s<\/td>\n      <td>Rzadko zmieniane, pami\u0119\u0107 podr\u0119czna zapisuje zapytania<\/td>\n      <td>Tymczasowo ni\u017csze podczas przebudowy<\/td>\n    <\/tr>\n    <tr>\n      <td>A\/AAA wewn\u0119trzne<\/td>\n      <td>Strefy kontroli\/routingu<\/td>\n      <td>30\u2013120 s<\/td>\n      <td>Wymagana bardzo szybka reakcja<\/td>\n      <td>Uwaga: pojemno\u015b\u0107 serwera nazw<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n<h2>Planowanie zmian DNS bez awarii<\/h2>\n\n<p>Przed przeprowadzk\u0105 ustawiam <strong>TTL<\/strong> dotkni\u0119tego rekordu 24-48 godzin wcze\u015bniej do 300 sekund lub mniej. Ten czas realizacji zapewnia, \u017ce prawie wszystkie resolvery przyj\u0119\u0142y kr\u00f3tk\u0105 warto\u015b\u0107, zanim zmieni\u0119 adres IP lub miejsce docelowe. Jak tylko zmiana zostanie wprowadzona, mierz\u0119 propagacj\u0119 i sprawdzam dzienniki oraz monitoruj\u0119 wska\u017aniki b\u0142\u0119d\u00f3w. Je\u015bli wszystko dzia\u0142a p\u0142ynnie, zwi\u0119kszam TTL z powrotem do warto\u015bci produktywnej mi\u0119dzy 1800 a 3600 sekund, aby pami\u0119\u0107 podr\u0119czna zacz\u0119\u0142a dzia\u0142a\u0107, a obci\u0105\u017cenie spad\u0142o. Zmniejsza to faz\u0119 ryzyka z wielu godzin do zaledwie kilku minut bez konieczno\u015bci ci\u0105g\u0142ego radzenia sobie z <strong>Warto\u015bci ekstremalne<\/strong> do pracy.<\/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>Strategie prze\u0142\u0105czania awaryjnego: Aktywna\/pasywna<\/h2>\n\n<p>Dla aktywnego\/pasywnego priorytetem jest kr\u00f3tki <strong>TTL<\/strong> dla domen frontendowych, zwykle 60-300 sekund, dzi\u0119ki czemu mog\u0119 szybko wskaza\u0107 lokalizacj\u0119 zapasow\u0105 w przypadku b\u0142\u0119du. Kontrole kondycji decyduj\u0105, kiedy podstawowy adres IP przestaje dzia\u0142a\u0107, a alternatywny adres przejmuje odpowiedzi. Us\u0142ugi wewn\u0119trzne lub dost\u0119p administratora mog\u0105 by\u0107 nieco d\u0142u\u017csze, oko\u0142o 300-900 sekund, aby ograniczy\u0107 liczb\u0119 zapyta\u0144. Wa\u017cne jest, aby mie\u0107 sp\u00f3jny plan test\u00f3w, kt\u00f3ry regularnie weryfikuje wp\u0142yw TTL na czas prze\u0142\u0105czania i wra\u017cenia u\u017cytkownika. Wi\u0119cej informacji na temat procedury operacyjnej mo\u017cna znale\u017a\u0107 pod adresem <a href=\"https:\/\/webhosting.de\/pl\/dns-failover-wdrozenie-hostingu-redundancja-serwera-failover\/\">Implementacja prze\u0142\u0105czania awaryjnego DNS<\/a>, gdzie wyja\u015bniam kroki od monitorowania do cofania.<\/p>\n\n<h2>Strategie prze\u0142\u0105czania awaryjnego: Active\/Active i Geo-Routing<\/h2>\n\n<p>W scenariuszach aktywny\/aktywny rozk\u0142adam ruch na kilka lokalizacji i utrzymuj\u0119 <strong>TTL<\/strong> cz\u0119sto od 120 do 600 sekund. Pozwala to na dzia\u0142anie geolokalizacji lub odpowiedzi opartych na op\u00f3\u017anieniach bez konieczno\u015bci pobierania ka\u017cdej odpowiedzi z serwera autorytatywnego. Je\u015bli lokalizacja nie powiedzie si\u0119 zgodnie z testem kondycji, natychmiast usuwam powi\u0105zany adres IP z odpowiedzi i pozwalam, aby pami\u0119ci podr\u0119czne szybko si\u0119 dezaktualizowa\u0142y. Zbyt kr\u00f3tki TTL mo\u017ce znacznie zwi\u0119kszy\u0107 obci\u0105\u017cenie zapytaniami; dlatego regularnie mierz\u0119 liczb\u0119 wyszukiwa\u0144 otrzymywanych na sekund\u0119. U\u017cywam tej informacji zwrotnej, aby znale\u017a\u0107 najlepsze miejsce mi\u0119dzy czasem odpowiedzi a wydajno\u015bci\u0105 serwera nazw. <strong>Znajd\u017a<\/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>Limity przez pami\u0119\u0107 podr\u0119czn\u0105 resolvera i spos\u00f3b testowania<\/h2>\n\n<p>Nie wszystkie resolvery respektuj\u0105 bardzo kr\u00f3tkie czasy <strong>TTL<\/strong> Niekt\u00f3rzy ustawiaj\u0105 wewn\u0119trzne warto\u015bci minimalne lub rozszerzaj\u0105 wpisy. Dlatego zawsze dopuszczam faz\u0119 przej\u015bciow\u0105, w kt\u00f3rej niekt\u00f3rzy u\u017cytkownicy nadal wywo\u0142uj\u0105 stare cele. Regularnie testuj\u0119 prze\u0142\u0105czanie awaryjne za pomoc\u0105 globalnych punkt\u00f3w kontrolnych i koreluj\u0119 wyniki z monitorowaniem punkt\u00f3w ko\u0144cowych. Specjalnie czyszcz\u0119 lokalne pami\u0119ci podr\u0119czne na klientach, przegl\u0105darkach i routerach, aby pomiary pozosta\u0142y wiarygodne. Na podstawie tych do\u015bwiadcze\u0144 dostosowuj\u0119 TTL i interwa\u0142y sprawdzania kondycji, a\u017c praktyczny czas prze\u0142\u0105czania spe\u0142ni moje wymagania. <strong>Cele<\/strong> osi\u0105gni\u0119to.<\/p>\n\n<h2>Wydajno\u015b\u0107 a obci\u0105\u017cenie: w\u0142a\u015bciwa r\u00f3wnowaga<\/h2>\n\n<p>Wysoka liczba trafie\u0144 w pami\u0119ci podr\u0119cznej zmniejsza liczb\u0119 wyszukiwa\u0144 DNS i pozwala zaoszcz\u0119dzi\u0107 pieni\u0105dze. <strong>Podr\u00f3\u017ce w obie strony<\/strong>, co znacznie skraca czas \u0142adowania. Jednocze\u015bnie TTL nie mo\u017ce by\u0107 tak d\u0142ugi, \u017ce wprowadzam zmiany zbyt p\u00f3\u017ano w sytuacji awaryjnej. Lubi\u0119 zaczyna\u0107 od 300 do 1800 sekund dla www, api i logowania, a nast\u0119pnie monitorowa\u0107 \u017c\u0105dania na sekund\u0119, op\u00f3\u017anienia i wska\u017aniki b\u0142\u0119d\u00f3w. Je\u015bli serwery autorytatywne osi\u0105gn\u0105 krytyczne wykorzystanie, zwi\u0119kszam je umiarkowanie; je\u015bli testy wykazuj\u0105 powolne prze\u0142\u0105czanie, ponownie je obni\u017cam. Pokazuj\u0119, jak warto\u015bci wp\u0142ywaj\u0105 na pomiary w kompaktowym <a href=\"https:\/\/webhosting.de\/pl\/porownanie-wydajnosci-dns-ttl-optymalny-strumien\/\">Por\u00f3wnanie wydajno\u015bci TTL<\/a>, co uwidacznia typowe kompromisy.<\/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>Praktyczne profile dla typowych domen<\/h2>\n\n<p>Dla <strong>www<\/strong> i api ustawiam 300-900 sekund, dzi\u0119ki czemu mog\u0119 kontrolowa\u0107 zmiany z kilkuminutowym op\u00f3\u017anieniem. Statyczne zasoby lub domeny graficzne otrzymuj\u0105 3,600-86,400 sekund, poniewa\u017c licz\u0105 si\u0119 tutaj rzadkie aktualizacje i wysokie limity pami\u0119ci podr\u0119cznej. Lubi\u0119 utrzymywa\u0107 punkty ko\u0144cowe logowania i p\u0142atno\u015bci w zakresie 300-600 sekund, aby elastycznie obs\u0142ugiwa\u0107 zmiany obci\u0105\u017cenia i konserwacj\u0119. Uruchamiam wewn\u0119trzne strefy routingu do wykrywania us\u0142ug przez bardzo kr\u00f3tki czas (30-120 sekund), w po\u0142\u0105czeniu z du\u017c\u0105 pojemno\u015bci\u0105 serwera nazw. Profile te stanowi\u0105 odporny punkt wyj\u015bcia, kt\u00f3ry mog\u0119 przetestowa\u0107 na podstawie rzeczywistych obci\u0105\u017ce\u0144. <strong>Metryki<\/strong> precyzyjna optymalizacja.<\/p>\n\n<h2>Monitorowanie i powiadamianie o rozwi\u0105zywaniu nazw<\/h2>\n\n<p>I monitor <strong>Czasy rozdzielczo\u015bci<\/strong>, stopy b\u0142\u0119d\u00f3w, szczyty NXDOMAIN i wolumeny zapyta\u0144 oddzielnie dla ka\u017cdej strefy. Regularnie sprawdzam r\u00f3wnie\u017c globaln\u0105 propagacj\u0119 pod k\u0105tem zmian w celu rozpoznania poszczeg\u00f3lnych region\u00f3w z op\u00f3\u017anieniami. W przypadku anomalii uruchamiam alarmy i badam, czy resolvery buforuj\u0105 przez niezwykle d\u0142ugi czas lub czy kontrole kondycji wyzwalaj\u0105 fa\u0142szywe alarmy. W celu szybkiej analizy przyczyn \u017ar\u00f3d\u0142owych dokumentuj\u0119 specyfikacje, wcze\u015bniej ustawione warto\u015bci TTL i dok\u0142adne czasy zmian. Ta przejrzysto\u015b\u0107 pomaga mi rozpozna\u0107 trendy i <strong>\u015arodki<\/strong> czysto ustala\u0107 priorytety.<\/p>\n\n<h2>Mo\u017cliwo\u015bci i wyb\u00f3r dostawcy<\/h2>\n\n<p>Im kr\u00f3tszy <strong>TTL<\/strong>, im wi\u0119ksze obci\u0105\u017cenie trafia na autorytatywne serwery nazw. Dlatego planuj\u0119 wystarczaj\u0105c\u0105 pojemno\u015b\u0107, lokalizacje anycast i korzy\u015bci z buforowania i unikam zbyt agresywnych warto\u015bci bez sprawdzania krzy\u017cowego. Platforma z szybk\u0105 reakcj\u0105, dobr\u0105 redundancj\u0105 i niezawodnymi kontrolami stanu znacznie u\u0142atwia prze\u0142\u0105czanie awaryjne. Do por\u00f3wnywania i dostrajania architektury u\u017cywam wskaz\u00f3wek z artyku\u0142u <a href=\"https:\/\/webhosting.de\/pl\/architektura-dns-hosting-resolver-ttl-wydajnosc-cacheboost\/\">Architektura DNS<\/a> i trzyma\u0107 si\u0119 powtarzalnych scenariuszy testowych. Dzi\u0119ki temu czasy reakcji s\u0105 niskie, a prze\u0142\u0105czenia s\u0105 nadal mo\u017cliwe pomimo kr\u00f3tkich czas\u00f3w ostrzegania. <strong>chwyt<\/strong>.<\/p>\n\n<h2>Szczeg\u00f3\u0142y DNS: SOA, negatywne cache i delegowanie<\/h2>\n\n<p>TTL wp\u0142ywa nie tylko na pozytywne odpowiedzi. Negatywne pami\u0119ci podr\u0119czne - tj. odpowiedzi NXDOMAIN i NODATA - s\u0105 przechowywane z ujemn\u0105 warto\u015bci\u0105 pami\u0119ci podr\u0119cznej zdefiniowan\u0105 w rekordzie SOA. Ustawiam t\u0119 warto\u015b\u0107 umiarkowanie (zwykle 300-900 sekund), aby b\u0142\u0119dy literowe i kr\u00f3tkotrwa\u0142e subdomeny nie pozosta\u0142y \u201enieistniej\u0105ce\u201c na zawsze, a jednocze\u015bnie nie obci\u0105\u017cam niepotrzebnie serwer\u00f3w autorytatywnych niepoprawnymi zapytaniami typu brute-force. Zwracam r\u00f3wnie\u017c uwag\u0119 na TTL <strong>NS<\/strong>-rekordy i wpisy kleju: S\u0105 one podstaw\u0105 delegacji i dlatego mog\u0105 \u017cy\u0107 znacznie d\u0142u\u017cej (od godzin do dni), aby resolvery nie musia\u0142y stale odbudowywa\u0107 \u0142a\u0144cucha delegacji. Wa\u017cne: W ramach RRset wszystkie wpisy musz\u0105 mie\u0107 ten sam TTL; utrzymuj\u0119 sp\u00f3jne odpowiedzi wielowarto\u015bciowe A\/AAA, aby nie ryzykowa\u0107 nieprzewidywalnych stan\u00f3w pami\u0119ci podr\u0119cznej.<\/p>\n\n<h2>DNSSEC i TTL w praktyce<\/h2>\n\n<p>W przypadku DNSSEC perspektywa nieco si\u0119 zmienia: opr\u00f3cz TTL, patrz\u0119 na wa\u017cno\u015b\u0107 podpis\u00f3w (RRSIG). Upewniam si\u0119, \u017ce produktywne warto\u015bci TTL nie s\u0105 d\u0142u\u017csze ni\u017c pozosta\u0142y okres wa\u017cno\u015bci podpisu, aby pami\u0119ci podr\u0119czne nie gromadzi\u0142y wygasaj\u0105cych podpis\u00f3w. W przypadku rotacji kluczy planuj\u0119 du\u017ce okna przej\u015bciowe, obni\u017cam TTL odpowiednich zestaw\u00f3w RR i rekord\u00f3w DS\/DNSKEY z umiarkowanym wyprzedzeniem, przeprowadzam zmian\u0119, a nast\u0119pnie ponownie je zwi\u0119kszam. Negatywne odpowiedzi (NSEC\/NSEC3) s\u0105 r\u00f3wnie\u017c podpisywane i buforowane; ujemna warto\u015b\u0107 TTL, kt\u00f3ra nie jest zbyt wysoka, op\u0142aca si\u0119 tutaj, aby nowe subdomeny sta\u0142y si\u0119 szybko widoczne.<\/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, prywatny DNS i geo-routing w szczeg\u00f3\u0142ach<\/h2>\n\n<p>W konfiguracjach z podzielonym horyzontem starzej\u0119 strefy wewn\u0119trzne i zewn\u0119trzne oddzielnie. Wewn\u0119trznie cz\u0119sto wybieram bardzo kr\u00f3tkie TTL (30-120 s) w celu wykrycia us\u0142ugi i p\u0142ynnego utrzymania, podczas gdy zewn\u0119trznie wybieram bardziej stabilne warto\u015bci. W przypadku geolokalizacji bior\u0119 pod uwag\u0119, \u017ce niekt\u00f3re resolwery centralizuj\u0105 \u017c\u0105dania, co mo\u017ce zniekszta\u0142ca\u0107 geolokalizacj\u0119. Kr\u00f3tki lub \u015bredni TTL pomaga szybciej korygowa\u0107 nieoptymalne trasy bez zalewania warstwy autorytatywnej ci\u0105g\u0142ymi zapytaniami. Utrzymuj\u0119 prost\u0105 konfiguracj\u0119: wyra\u017ane sygna\u0142y kontroli kondycji, jednoznaczne mapowanie lokalizacji i brak zbyt skomplikowanych \u0142a\u0144cuch\u00f3w CNAME i przekierowa\u0144.<\/p>\n\n<h2>Zachowanie klienta i resolvera, kt\u00f3re planuj\u0119<\/h2>\n\n<p>Systemy operacyjne, przegl\u0105darki i middleboxy cz\u0119sto ustawiaj\u0105 minimalne i maksymalne warto\u015bci TTL. Nawet 0 sekund nie jest przepuszczane wsz\u0119dzie; wiele resolver\u00f3w utkn\u0119\u0142o na 30-60 sekundach. I odwrotnie, niekt\u00f3re \u015brodowiska nie respektuj\u0105 bardzo wysokich warto\u015bci TTL i ograniczaj\u0105 je wewn\u0119trznie. Istnieje r\u00f3wnie\u017c zachowanie \u201eserve-stale\u201c: Je\u015bli \u015bcie\u017cka autorytatywna zawiedzie, niekt\u00f3re resolvery b\u0119d\u0105 nadal obs\u0142ugiwa\u0107 wygas\u0142e rekordy przez kr\u00f3tki czas - dobre dla odporno\u015bci, ale istotne dla praktycznego czasu prze\u0142\u0105czania. Uwzgl\u0119dniam r\u00f3wnie\u017c lokalne pami\u0119ci podr\u0119czne DNS w sieciach firmowych i u operator\u00f3w kom\u00f3rkowych, kt\u00f3re charakteryzuj\u0105 obserwowane op\u00f3\u017anienia i propagacj\u0119.<\/p>\n\n<h2>Nowoczesne typy rekord\u00f3w i ich TTL<\/h2>\n\n<p>Opr\u00f3cz A\/AAAA, CNAME, MX i TXT, w planowaniu uwzgl\u0119dniam rekordy SRV i HTTPS\/SVCB. U\u017cywam SRV dla punkt\u00f3w ko\u0144cowych zorientowanych na us\u0142ugi (np. VoIP, LDAP) i generalnie utrzymuj\u0119 ich TTL po\u015brodku (300-1,800 s), aby priorytety i wagi szybko zacz\u0119\u0142y obowi\u0105zywa\u0107. Cel transportowy HTTPS\/SVCB i parametry transportowe dla us\u0142ug internetowych; tutaj wybieram podobne TTL jak dla odpowiednich A\/AAA lub CNAME, aby uzyska\u0107 sp\u00f3jne prze\u0142\u0105czanie. D\u0142u\u017csze TTL s\u0105 zwykle wystarczaj\u0105ce dla CAA i PTR (reverse), poniewa\u017c zmiany s\u0105 rzadkie, ale obni\u017cam je tymczasowo przed powa\u017cnymi zmianami dostawcy.<\/p>\n\n<h2>Podr\u0119cznik zmian: Przyk\u0142adowy harmonogram przezbrajania z minimalizacj\u0105 ryzyka<\/h2>\n\n<ul>\n  <li>T-48 h: Zidentyfikowanie dotkni\u0119tych zestaw\u00f3w RR, udokumentowanie produktywnego TTL, sprawdzenie ujemnych warto\u015bci pami\u0119ci podr\u0119cznej.<\/li>\n  <li>T-36 do T-24 h: Zmniejszenie TTL do 300 s (krytyczne) lub 600-900 s (niekrytyczne), sprawdzenie kondycji, wst\u0119pne podgrzanie tylnych cz\u0119\u015bci.<\/li>\n  <li>T-2 h: Uruchom testy dymu w systemie docelowym pod nazw\u0105 hosta testowego, obserwuj dzienniki i wydajno\u015b\u0107.<\/li>\n  <li>T-0: Przeprowadzenie zmiany DNS (A\/AAA, CNAME lub SRV), udokumentowanie warunk\u00f3w rollout i rollback.<\/li>\n  <li>T+5 do T+30 min: Pomiar propagacji, sprawdzenie poziomu b\u0142\u0119d\u00f3w i op\u00f3\u017anienia, przygotowanie awaryjnego cofania.<\/li>\n  <li>T+2 h: Faza stabilizacji, stopniowe zwi\u0119kszanie TTL do 1,800-3,600 s, je\u015bli wska\u017aniki nie odbiegaj\u0105 od normy.<\/li>\n  <li>T+24 h: Pomiar kontrolny, wyci\u0105gni\u0119te wnioski, zakotwiczenie warto\u015bci produkcyjnych.<\/li>\n<\/ul>\n\n<h2>Model przepustowo\u015bci i wp\u0142yw kr\u00f3tkiego TTL na koszty<\/h2>\n\n<p>Pracuj\u0119 z prostymi przybli\u017ceniami, aby oszacowa\u0107 obci\u0105\u017cenie serwera nazw: Im kr\u00f3tszy TTL, tym cz\u0119\u015bciej resolver musi odpytywa\u0107. Oczekiwane pasmo QPS mo\u017cna wyprowadzi\u0107 z ruchu, aktywnych klient\u00f3w i proporcji \u201ezimnych\u201c rozdzielczo\u015bci. Planuj\u0119 bufory na szczyty, b\u0142\u0119dne konfiguracje i rozproszone pr\u00f3by atak\u00f3w. Decyduj\u0105cymi d\u017awigniami s\u0105 dystrybucja obci\u0105\u017cenia poprzez anycast, przyjazno\u015b\u0107 dla buforowania odpowiedzi (brak zbyt d\u0142ugich \u0142a\u0144cuch\u00f3w) i rozs\u0105dne zakresy TTL dla ka\u017cdej us\u0142ugi. Kiedy osi\u0105gam limity obci\u0105\u017cenia, selektywnie zwi\u0119kszam TTL dla mniej krytycznych subdomen, zamiast globalnie zaostrza\u0107 suwak.<\/p>\n\n<h2>Aspekty bezpiecze\u0144stwa i ryzyka zwi\u0105zane z TTL<\/h2>\n\n<p>TTL ma wp\u0142yw na bezpiecze\u0144stwo: zbyt d\u0142ugi okres wa\u017cno\u015bci rozszerza zakres nieaktualnych lub zagro\u017conych odpowiedzi w sytuacjach awaryjnych. Jednocze\u015bnie zbyt kr\u00f3tki TTL pozwala atakuj\u0105cym na potencjalnie cz\u0119stsze pr\u00f3by zatrucia pami\u0119ci podr\u0119cznej - dobra walidacja i DNSSEC s\u0105 zatem obowi\u0105zkowe. W przypadku przej\u0119cia lub b\u0142\u0119dnej konfiguracji nie mog\u0119 centralnie opr\u00f3\u017cni\u0107 pami\u0119ci podr\u0119cznej; dlatego zmniejszam okno szk\u00f3d poprzez dobrze przemy\u015blany TTL i szybkie, udokumentowane \u015brodki zaradcze. W przypadku rekord\u00f3w krytycznych dla delegacji (NS, DS) unikam gor\u0105czkowych skok\u00f3w TTL i pracuj\u0119 z konserwatywnymi, dobrze przetestowanymi \u015bcie\u017ckami zmian.<\/p>\n\n<h2>Obserwowalno\u015b\u0107 i metodologia test\u00f3w w \u017cyciu codziennym<\/h2>\n\n<p>Mierz\u0119 TTL \u201epo kablu\u201c: powtarzaj\u0105ce si\u0119 zapytania z rozproszonych lokalizacji pokazuj\u0105, czy resolvery starzej\u0105 si\u0119 zgodnie z oczekiwaniami. Por\u00f3wnuj\u0119 pozytywne i negatywne odpowiedzi, obserwuj\u0119 dodatkowe przeskoki CNAME i sprawdzam, czy odpowiedzi przychodz\u0105 z obni\u017conym TTL po tym, jak resolver je zbuforowa\u0142. W przypadku zmian koreluj\u0119 czas odpowiedzi urz\u0119du, zachowanie resolvera i metryki aplikacji (b\u0142\u0119dy, op\u00f3\u017anienia). Wa\u017cne jest, aby unika\u0107 ryzyka \u201ecache snooping\u201c: Testuj\u0119 specjalnie we w\u0142asnym imieniu i przestrzegam wytycznych bezpiecze\u0144stwa zdalnych witryn.<\/p>\n\n<h2>Dokumentacja, zarz\u0105dzanie i audytowalno\u015b\u0107<\/h2>\n\n<p>Trzymam wszystko <strong>TTL<\/strong>-Okno zmian jest definiowane na pi\u015bmie pod wzgl\u0119dem specyfikacji, uk\u0142ad\u00f3w rekord\u00f3w, system\u00f3w docelowych i zasad kontroli kondycji. Ka\u017cde okno zmian ma plan z wst\u0119pnymi zlewami, czasem prze\u0142\u0105czania, \u015bcie\u017ckami audytu i odwr\u00f3ceniem. Te notatki przyspieszaj\u0105 audyty, u\u0142atwiaj\u0105 postmortem i zmniejszaj\u0105 liczb\u0119 b\u0142\u0119dnych konfiguracji. Dodaj\u0119 listy kontrolne do playbook\u00f3w, aby niczego nie brakowa\u0142o nawet w chwilach stresu. Przejrzysta dokumentacja sprawia, \u017ce kontrola rozdzielczo\u015bci nazw jest zrozumia\u0142a i wspiera <strong>Praca zespo\u0142owa<\/strong> mi\u0119dzy warstwami.<\/p>\n\n<h2>Moja kwintesencja DNS TTL<\/h2>\n\n<p>Traktuj\u0119 <strong>DNS<\/strong> nie jako statyczny katalog, ale jako aktywna d\u017awignia dost\u0119pno\u015bci i szybko\u015bci. R\u00f3\u017cne typy rekord\u00f3w otrzymuj\u0105 zharmonizowane TTL, krytyczne frontendy raczej kr\u00f3tkie, rzadko zmieniane wpisy d\u0142u\u017csze. Przed zmianami obni\u017cam warto\u015bci na wczesnym etapie, mierz\u0119 propagacj\u0119, a nast\u0119pnie wracam do produktywnych interwa\u0142\u00f3w. Regularnie testuj\u0119 prze\u0142\u0105czanie awaryjne i dostosowuj\u0119 TTL, kontrole kondycji i przepustowo\u015b\u0107 do zmierzonej praktyki. Utrzymanie tej dyscypliny skraca okna konserwacyjne, minimalizuje konsekwencje awarii i zapewnia u\u017cytkownikom niezawodno\u015b\u0107. <strong>Do\u015bwiadczenie<\/strong>.<\/p>","protected":false},"excerpt":{"rendered":"<p>Dowiedz si\u0119, w jaki spos\u00f3b zoptymalizowana strategia DNS TTL obs\u0142uguje wysoce dost\u0119pne infrastruktury, przyspiesza prze\u0142\u0105czanie awaryjne domen i zapewnia wysok\u0105 dost\u0119pno\u015b\u0107 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":"142","_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\/pl\/wp-json\/wp\/v2\/posts\/19697","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/comments?post=19697"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/19697\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media\/19690"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media?parent=19697"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/categories?post=19697"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/tags?post=19697"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}