{"id":19649,"date":"2026-06-03T15:03:10","date_gmt":"2026-06-03T13:03:10","guid":{"rendered":"https:\/\/webhosting.de\/dns-resolver-redundanz-hochverfuegbarkeit-hosting-failsafe\/"},"modified":"2026-06-03T15:03:10","modified_gmt":"2026-06-03T13:03:10","slug":"dns-resolver-redundancja-wysoka-dostepnosc-hosting-failsafe","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pl\/dns-resolver-redundanz-hochverfuegbarkeit-hosting-failsafe\/","title":{"rendered":"Redundancja resolwera DNS i wysoka dost\u0119pno\u015b\u0107 w hostingu"},"content":{"rendered":"<p>Nadmiarowo\u015b\u0107 resolvera DNS zapewnia dost\u0119pno\u015b\u0107 rozpoznawania nazw w hostingu nawet w przypadku b\u0142\u0119d\u00f3w serwera lub sieci; <strong>redundancja dns<\/strong> i wysoka dost\u0119pno\u015b\u0107 \u0142\u0105cz\u0105 kilka autorytatywnych serwer\u00f3w nazw i resolver\u00f3w za po\u015brednictwem oddzielnych sieci, lokalizacji i automatycznych transfer\u00f3w stref. Zapewniam, \u017ce strony internetowe, interfejsy API i us\u0142ugi poczty e-mail pozostaj\u0105 dost\u0119pne nawet w przypadku awarii poszczeg\u00f3lnych komponent\u00f3w, a inne systemy nadal dzia\u0142aj\u0105 bez b\u0142\u0119d\u00f3w.<\/p>\n\n<h2>Punkty centralne<\/h2>\n\n<ul>\n  <li><strong>Wiele serwer\u00f3w nazw<\/strong> w oddzielnych sieciach i lokalizacjach<\/li>\n  <li><strong>Czysta delegacja<\/strong> i bezpieczne transfery stref<\/li>\n  <li><strong>Prze\u0142\u0105czanie awaryjne resolwera<\/strong> z kr\u00f3tkimi limitami czasu i sp\u00f3jnymi odpowiedziami<\/li>\n  <li><strong>Geo-redundancja<\/strong> i anycast dla niskich op\u00f3\u017anie\u0144<\/li>\n  <li><strong>Monitoring<\/strong>, DNSSEC i przejrzysta dokumentacja<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/dns_resolver_hosting_8723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Dlaczego redundancja resolver\u00f3w DNS w hostingu jest kluczowa?<\/h2>\n\n<p>Je\u015bli <strong>Rozdzielczo\u015b\u0107 nazwy<\/strong> Strony internetowe i serwery pocztowe s\u0105 natychmiast \u201eoffline\u201c, nawet je\u015bli same maszyny dzia\u0142aj\u0105 p\u0142ynnie. Dlatego planuj\u0119 DNS jak komponent krytyczny dla biznesu i buduj\u0119 odporno\u015b\u0107 za pomoc\u0105 kilku autorytatywnych serwer\u00f3w nazw i oddzielnych resolver\u00f3w. Zapobiega to sparali\u017cowaniu ca\u0142ej witryny przez pojedyncz\u0105 \u015bcie\u017ck\u0119 b\u0142\u0119du i naruszeniu um\u00f3w SLA. Kr\u00f3tkie czasy odpowiedzi, sp\u00f3jne strefy i inteligentne strategie buforowania w wymierny spos\u00f3b chroni\u0105 do\u015bwiadczenia u\u017cytkownik\u00f3w. Bior\u0119 r\u00f3wnie\u017c pod uwag\u0119 wp\u0142ywy SEO, poniewa\u017c powtarzaj\u0105ca si\u0119 niedost\u0119pno\u015b\u0107 strony <strong>Domena<\/strong> wyzwala negatywne sygna\u0142y i czasy \u0142adowania przez \u015bcie\u017ck\u0119 DNS mog\u0105 wzrosn\u0105\u0107.<\/p>\n\n<h2>Autorytatywne serwery nazw i resolwery powinny by\u0107 wyra\u017anie oddzielone.<\/h2>\n\n<p>Rzecznie rozr\u00f3\u017cniam mi\u0119dzy <strong>autorytatywny<\/strong> serwery nazw i rekurencyjne resolvery, poniewa\u017c obie warstwy wymagaj\u0105 w\u0142asnej redundancji. Autorytatywne serwery przechowuj\u0105 strefy i dostarczaj\u0105 ostateczne odpowiedzi, podczas gdy resolvery rozwi\u0105zuj\u0105 \u017c\u0105dania dla klient\u00f3w i buforuj\u0105 wyniki. W praktyce ustawiam co najmniej dwa, a najlepiej trzy autorytatywne serwery nazw na stref\u0119, dystrybuuj\u0119 je w r\u00f3\u017cnych sieciach IP i lokalizacjach oraz zabezpieczam transfery stref za po\u015brednictwem TSIG. Dla klient\u00f3w przechowuj\u0119 co najmniej dwa resolvery z kr\u00f3tkimi limitami czasu, aby zmiana nie by\u0142a zauwa\u017calna w przypadku awarii. Taka separacja zapobiega b\u0142\u0119dnym za\u0142o\u017ceniom i zwi\u0119ksza <strong>Dost\u0119pno\u015b\u0107<\/strong> na obu poziomach.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/dns_resolver_meeting_5273.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Delegacja, klej i parametry w strefie nadrz\u0119dnej<\/h2>\n<p>Redundancja zaczyna si\u0119 od delegacji: sprawdzam to w <em>Strefa nadrz\u0119dna<\/em> prawid\u0142owe zapisy NS s\u0105 przechowywane i niezb\u0119dne <strong>Glue-Records<\/strong> (A\/AAAA) istniej\u0105 dla serwer\u00f3w nazw w strefie. Bez prawid\u0142owego kleju, resolver mo\u017ce zawiesza\u0107 si\u0119 cyklicznie lub polega\u0107 na zewn\u0119trznych \u017ar\u00f3d\u0142ach. Dla konfiguracji z dwoma stosami zapewniam <strong>IPv4 i IPv6-Glue<\/strong> i zwracam uwag\u0119 na odpowiednie TTL w strefie nadrz\u0119dnej, kt\u00f3re nie zawsze pokrywaj\u0105 si\u0119 z TTL domeny. Zmieniaj\u0105c rejestrator\u00f3w lub rejestry, planuj\u0119 czasy propagacji i weryfikuj\u0119 delegacj\u0119 przed prze\u0142\u0105czeniem obci\u0105\u017ce\u0144 produkcyjnych. W ten spos\u00f3b unikam skrajnych przypadk\u00f3w, w kt\u00f3rych cz\u0119\u015b\u0107 Internetu nadal korzysta ze starych \u015bcie\u017cek, podczas gdy inne ju\u017c \u017c\u0105daj\u0105 nowych serwer\u00f3w nazw.<\/p>\n\n<h2>Podstawowe zasady konfiguracji DNS o wysokiej dost\u0119pno\u015bci<\/h2>\n\n<p>Zakotwiczam kilka <strong>Serwer nazw<\/strong> na domen\u0119, bezpieczne transfery stref, sprawdzanie delegacji u rejestratora i regularne testowanie za pomoc\u0105 narz\u0119dzi takich jak dig. Serwer g\u0142\u00f3wny zarz\u0105dza stref\u0105, a serwery podrz\u0119dne otrzymuj\u0105 zmiany automatycznie przez IXFR, wyzwalane przez serial SOA. Bia\u0142e listy IP i TSIG zabezpieczaj\u0105 transfery, a oddzielne centra danych zmniejszaj\u0105 ryzyko lokalizacji. Ponadto planuj\u0119 rozs\u0105dne warto\u015bci TTL, aby m\u00f3c szybciej prze\u0142\u0105cza\u0107 si\u0119 podczas ruch\u00f3w bez sta\u0142ego zwi\u0119kszania obci\u0105\u017cenia. Dzi\u0119ki tym zasadom odpowiedzi s\u0105 sp\u00f3jne, a <strong>Dost\u0119pno\u015b\u0107<\/strong> nawet podczas konserwacji lub awarii.<\/p>\n\n<h2>Wersjonowanie i dyscyplina zmian w strefach<\/h2>\n<p>U\u017cywam przezroczystego <strong>Strategia seryjna SOA<\/strong> (np. format daty) i wprowadzam zmiany atomowo: zmieniam powi\u0105zane rekordy (A\/AAA, MX, TXT, SPF) w jednym kroku. <strong>POWIADOMIENIE<\/strong> zapewnia, \u017ce urz\u0105dzenia podrz\u0119dne szybko pod\u0105\u017caj\u0105 za IXFR; tam, gdzie mo\u017cliwe jest tylko AXFR, planuj\u0119 okno transferu i przepustowo\u015b\u0107. W przypadku ryzykownych zmian, obni\u017cam TTL z wyprzedzeniem, ustawiam <em>Okno zamra\u017cania<\/em> po wdro\u017ceniu i monitorowa\u0107 odpowiedzi ze wszystkich autorytatywnych serwer\u00f3w. Dokumentuj\u0119 zale\u017cno\u015bci (np. adresy IP LB, adresy IP WAF, nazwy host\u00f3w CDN), aby nie by\u0142o luk w przypadku zmiany komponent\u00f3w zewn\u0119trznych.<\/p>\n\n<h2>Poprawna konfiguracja prze\u0142\u0105czania awaryjnego resolvera<\/h2>\n\n<p>Domy\u015blnie wielu klient\u00f3w najpierw zadaje pierwsze pytanie <strong>Resolver<\/strong> i zmieniaj\u0105 si\u0119 dopiero po up\u0142ywie limitu czasu, wi\u0119c ustawiam kr\u00f3tkie, praktyczne warto\u015bci. Upewniam si\u0119, \u017ce przechowywane resolvery zapewniaj\u0105 sp\u00f3jne odpowiedzi, aby aplikacje nie oscylowa\u0142y mi\u0119dzy r\u00f3\u017cnymi stanami. W przypadku problem\u00f3w z lokalizacj\u0105 lub sieci\u0105 WAN, drugi resolver w innej sieci zapobiega d\u0142ugim czasom oczekiwania i falom po\u0142\u0105cze\u0144 z pomoc\u0105 techniczn\u0105. Mierz\u0119 czasy odpowiedzi, wska\u017aniki b\u0142\u0119d\u00f3w i wydajno\u015b\u0107 pami\u0119ci podr\u0119cznej, aby wcze\u015bnie rozpoznawa\u0107 w\u0105skie gard\u0142a i proaktywnie je rozwi\u0105zywa\u0107. Pozwala to utrzyma\u0107 <strong>Podr\u00f3\u017c u\u017cytkownika<\/strong> p\u0142ynnie, nawet w przypadku awarii serwera lub wyst\u0105pienia szczyt\u00f3w obci\u0105\u017cenia.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/dns-resolver-high-availability-7498.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Zrozumienie zachowania klienta i udost\u0119pnianie sieci<\/h2>\n<p>Bior\u0119 pod uwag\u0119, jak <strong>Klienci otrzymuj\u0105 resolwery<\/strong>poprzez DHCPv4 (opcja 6), DHCPv6 lub RDNSS w og\u0142oszeniach router\u00f3w IPv6. R\u00f3\u017cne systemy operacyjne wysy\u0142aj\u0105 zapytania do resolver\u00f3w w r\u00f3\u017cny spos\u00f3b; niekt\u00f3re u\u017cywaj\u0105 \u015bci\u015ble sekwencyjnych timeout\u00f3w, inne wysy\u0142aj\u0105 r\u00f3wnoleg\u0142e zapytania. Dlatego utrzymuj\u0119 kr\u00f3tkie timeouty i zapewniam niskie op\u00f3\u017anienia do ka\u017cdego resolvera. Z <strong>EDNS(0)<\/strong> Optymalizuj\u0119 rozmiary pakiet\u00f3w, planuj\u0119 niezawodny mechanizm awaryjny TCP i zwracam uwag\u0119 na kwestie MTU, aby fragmentacja nie poch\u0142ania\u0142a \u017cadnych odpowiedzi. W sieciach korporacyjnych harmonizuj\u0119 listy resolver\u00f3w mi\u0119dzy urz\u0105dzeniami ko\u0144cowymi, serwerami i urz\u0105dzeniami sieciowymi, aby diagnostyka i prze\u0142\u0105czanie awaryjne by\u0142y powtarzalne.<\/p>\n\n<h2>Rozs\u0105dne wykorzystanie redundancji geograficznej i anycastu<\/h2>\n\n<p>Dla u\u017cytkownik\u00f3w mi\u0119dzynarodowych zmniejszam op\u00f3\u017anienia poprzez <strong>Anycast<\/strong>, aby \u017c\u0105dania automatycznie trafia\u0142y do najbli\u017cszego w\u0119z\u0142a. Rozk\u0142ada to ataki i obci\u0105\u017cenie na wiele lokalizacji i zwi\u0119ksza szans\u0119, \u017ce przynajmniej jeden w\u0119ze\u0142 odpowie przez ca\u0142y czas. W przypadku wra\u017cliwych us\u0142ug \u0142\u0105cz\u0119 Anycast z kilkoma dostawcami, aby r\u00f3wnie\u017c przechwytywa\u0107 awarie dostawc\u00f3w. Je\u015bli chcesz zag\u0142\u0119bi\u0107 si\u0119 w temat, mo\u017cesz znale\u017a\u0107 informacje techniczne na temat routingu i op\u00f3\u017anie\u0144 w nast\u0119puj\u0105cych artyku\u0142ach <a href=\"https:\/\/webhosting.de\/pl\/dns-resolver-anycast-networks-hosting-low-latency-routing\/\">Sieci anycast w hostingu<\/a>. Dzi\u0119ki temu \u0142a\u0144cuchowi geo-dystrybucji, anycast i czystej delegacji, zwi\u0119kszam <strong>Odporno\u015b\u0107<\/strong> zauwa\u017calne.<\/p>\n\n<h2>Szczeg\u00f3\u0142owy opis operacji Anycast<\/h2>\n<p>W produktywnej operacji Anycast \u0142\u0105cz\u0119 <strong>Kontrole stanu zdrowia<\/strong> oprogramowania DNS z routingiem: je\u015bli w\u0119ze\u0142 ulegnie awarii, automatycznie wycofa sw\u00f3j prefiks. U\u017cywam kontrolowanego <em>Poprzedzaj\u0105ce<\/em> lub spo\u0142eczno\u015bci, aby kontrolowa\u0107 ruch w regionie i planowa\u0107 <em>Ods\u0105czanie<\/em> przed konserwacj\u0105. Monitorowanie sprawdza ka\u017cd\u0105 instancj\u0119 osobno i koreluje status BGP z jako\u015bci\u0105 odpowiedzi. W przypadku awarii mam gotowe podr\u0119czniki, kt\u00f3re specjalnie prze\u0142\u0105czaj\u0105 w\u0119z\u0142y \u201ew ciemno\u201c bez nara\u017cania globalnej dost\u0119pno\u015bci. Anycast pozostaje wi\u0119c czym\u015b wi\u0119cej ni\u017c tylko sztuczk\u0105 routingu - staje si\u0119 odporn\u0105 dyscyplin\u0105 operacyjn\u0105.<\/p>\n\n<h2>Por\u00f3wnanie typowych architektur<\/h2>\n\n<p>Wybieram architektur\u0119 zgodnie z <strong>Wymagania<\/strong>, bud\u017cet i do\u015bwiadczenie zespo\u0142u. Klasyczne konfiguracje master-slave zapewniaj\u0105 dobry start i mog\u0105 by\u0107 obs\u0142ugiwane w kontrolowany spos\u00f3b. Rozwi\u0105zania z wieloma dostawcami zapewniaj\u0105 dodatkow\u0105 ochron\u0119 przed awariami dostawc\u00f3w, ale wymagaj\u0105 czystej synchronizacji. Sieci anycast wyr\u00f3\u017cniaj\u0105 si\u0119 pod wzgl\u0119dem op\u00f3\u017anie\u0144 i dystrybucji DDoS, ale wymagaj\u0105 starannego planowania i monitorowania. Poni\u017csza tabela przedstawia podstawowe w\u0142a\u015bciwo\u015bci popularnych wariant\u00f3w i pomaga w ich analizie. <strong>Klasyfikacja<\/strong>:<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th>Architektura<\/th>\n      <th>Dost\u0119pno\u015b\u0107<\/th>\n      <th>Op\u00f3\u017anienie<\/th>\n      <th>Koszty operacyjne<\/th>\n      <th>Typowe zastosowanie<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Master-Slave<\/td>\n      <td>Wysoki dla oddzielnych sieci\/lokalizacji<\/td>\n      <td>Dobry, w zale\u017cno\u015bci od lokalizacji<\/td>\n      <td>Niski do \u015bredniego<\/td>\n      <td>Ma\u0142e i \u015brednie projekty<\/td>\n    <\/tr>\n    <tr>\n      <td>DNS od wielu dostawc\u00f3w<\/td>\n      <td>Bardzo wysoki poziom z dobr\u0105 synchronizacj\u0105<\/td>\n      <td>Dobry do bardzo dobrego<\/td>\n      <td>\u015aredni do wysokiego<\/td>\n      <td>Krytyczne domeny, niezale\u017cno\u015b\u0107 dostawcy<\/td>\n    <\/tr>\n    <tr>\n      <td>Anycast DNS<\/td>\n      <td>Bardzo wysoka ze wzgl\u0119du na rozmieszczenie w\u0119z\u0142\u00f3w<\/td>\n      <td>Bardzo dobry (nast\u0119pny w\u0119ze\u0142)<\/td>\n      <td>Fundusze (wymagane planowanie\/monitorowanie)<\/td>\n      <td>Globalny ruch, handel elektroniczny, SaaS<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/dns_resolver_redundanz_7823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Podzielony horyzont i strefy wewn\u0119trzne<\/h2>\n<p>Tam, gdzie reakcje wewn\u0119trzne i zewn\u0119trzne r\u00f3\u017cni\u0105 si\u0119, u\u017cywam <strong>Podzielony horyzont<\/strong> (widoki) lub warunkowe przekazywanie. Sp\u00f3jno\u015b\u0107 jest wa\u017cna: zewn\u0119trzna przestrze\u0144 nazw musi funkcjonowa\u0107 niezale\u017cnie, a wewn\u0119trzne informacje dodatkowe nie mog\u0105 ujawnia\u0107 \u017cadnych poufnych szczeg\u00f3\u0142\u00f3w na zewn\u0105trz. Dokumentuj\u0119, kt\u00f3re resolvery maj\u0105 jaki widok i regularnie testuj\u0119 z zewn\u0119trznych punkt\u00f3w obserwacyjnych, aby zapobiec przypadkowej ekspozycji. W przypadku konfiguracji chmury hybrydowej definiuj\u0119 jasne obowi\u0105zki, aby wewn\u0119trzne zapytania nie dociera\u0142y przypadkowo do publicznego Internetu.<\/p>\n\n<h2>Strategia TTL, buforowanie i sp\u00f3jno\u015b\u0107<\/h2>\n\n<p>Ustawi\u0142em <strong>TTL<\/strong>-Jestem \u015bwiadomy warto\u015bci TTL: zbyt kr\u00f3tkie TTL zwi\u0119kszaj\u0105 obci\u0105\u017cenie, a zbyt d\u0142ugie spowalniaj\u0105 zmiany. W przypadku krytycznych wpis\u00f3w, takich jak load balancery lub MX, wybieram umiarkowane warto\u015bci i obni\u017cam je przez ograniczony czas przed planowanymi ruchami. Utrzymuj\u0119 sp\u00f3jno\u015b\u0107 pami\u0119ci podr\u0119cznych resolver\u00f3w poprzez czyste wprowadzanie zmian za pomoc\u0105 seriali SOA i \u015bcis\u0142e monitorowanie serwer\u00f3w pomocniczych. Je\u015bli szukasz podstawowych informacji na temat TTL, zachowania resolvera i wydajno\u015bci, mo\u017cesz znale\u017a\u0107 praktyczn\u0105 wiedz\u0119 na stronie <a href=\"https:\/\/webhosting.de\/pl\/architektura-dns-hosting-resolver-ttl-wydajnosc-cacheboost\/\">Resolver, TTL i wydajno\u015b\u0107<\/a>. Dyscyplina ta zapewnia, \u017ce odpowiedzi s\u0105 udzielane szybko i \u017ce <strong>Do\u015bwiadczenie u\u017cytkownika<\/strong> nie cierpi.<\/p>\n\n<h2>Nieaktualne serwowanie, buforowanie negatywne i pobieranie wst\u0119pne<\/h2>\n<p>Redundancja staje si\u0119 bardziej niezawodna, gdy resolwery s\u0105 u\u017cywane w przypadku kr\u00f3tkotrwa\u0142ych awarii. <strong>stal odpowiada<\/strong> mog\u0105 by\u0107 dostarczane. Ostro\u017cnie konfiguruj\u0119 serve-stale, ograniczam okno czasowe i koreluj\u0119 je z monitorowaniem, aby b\u0142\u0119dy nie by\u0142y ukrywane. Negatywne buforowanie (NXDOMAIN\/NODATA) opiera si\u0119 na specyfikacji SOA dla negatywnego TTL - ustawiam tutaj umiarkowane warto\u015bci, aby zapobiec niepotrzebnemu utrwalaniu b\u0142\u0119dnych konfiguracji. Ulubione rekordy <strong>prefetche<\/strong> Zanim wypadn\u0105 z pami\u0119ci podr\u0119cznej, aby utrzyma\u0107 szybkie \u015bcie\u017cki. Wszystko to dzia\u0142a tylko wtedy, gdy \u017ar\u00f3d\u0142o danych (serwer autorytatywny) jest stabilne i sp\u00f3jne.<\/p>\n\n<h2>Bezpiecze\u0144stwo: DNSSEC, transfery stref i wzmacnianie zabezpiecze\u0144<\/h2>\n\n<p>Zwi\u0119kszam integralno\u015b\u0107 odpowiedzi dzi\u0119ki <strong>DNSSEC<\/strong>, o ile dostawca i konfiguracja domeny to obs\u0142uguj\u0105. Ograniczam transfery stref do znanych adres\u00f3w IP, a tak\u017ce zabezpieczam je za pomoc\u0105 TSIG, aby zapobiec nieautoryzowanemu pods\u0142uchiwaniu danych. Aktualizuj\u0119 oprogramowanie serwer\u00f3w nazw, ograniczam ryzyko zwi\u0105zane z otwartymi resolwerami i monitoruj\u0119 fa\u0142szywe wzorce wskazuj\u0105ce na ataki. Zasady ograniczania szybko\u015bci i reagowania pomagaj\u0105 ograniczy\u0107 wzorce nadu\u017cy\u0107 bez powa\u017cnego wp\u0142ywu na legalny ruch. \u015arodki te wsp\u00f3\u0142graj\u0105 z redundancj\u0105, poniewa\u017c \u015bcie\u017cki awarii s\u0105 minimalizowane przez <strong>Bezpiecze\u0144stwo<\/strong>-W przeciwnym razie wydarzenia s\u0105 zaskoczeniem.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/dnsresolver_desk_6572.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ochrona danych, rejestrowanie i zgodno\u015b\u0107 z przepisami<\/h2>\n<p>Rejestruj\u0119 zapytania DNS w taki spos\u00f3b, \u017ce <strong>Analiza b\u0142\u0119d\u00f3w<\/strong> mo\u017cliwe, ale dane osobowe s\u0105 chronione: ograniczone przechowywanie, pseudonimizacja w stosownych przypadkach, \u015bcis\u0142e prawa dost\u0119pu. We wra\u017cliwych \u015brodowiskach u\u017cywam nast\u0119puj\u0105cych rozwi\u0105za\u0144 dla Resolver <strong>DoT\/DoH<\/strong> na poziomie transportu, ale z uwzgl\u0119dnieniem aspekt\u00f3w operacyjnych (certyfikaty, przypinanie, monitorowanie). <em>Minimalizacja QNAME<\/em> a twarde listy ACL ograniczaj\u0105 niepotrzebn\u0105 ekspozycj\u0119 danych. Moja dokumentacja rejestruje, kt\u00f3re dzienniki s\u0105 potrzebne do czego i kiedy s\u0105 usuwane - wi\u0119c zgodno\u015b\u0107 nie jest klockiem hamulcowym, ale cz\u0119\u015bci\u0105 niezawodnego dzia\u0142ania.<\/p>\n\n<h2>Monitorowanie, testy i umowy SLA bez luk<\/h2>\n\n<p>Monitoruj\u0119 ka\u017cdy <strong>Serwer nazw<\/strong> pod k\u0105tem dost\u0119pno\u015bci, czas\u00f3w reakcji i wska\u017anik\u00f3w b\u0142\u0119d\u00f3w oraz \u0142\u0105cz\u0105 alarmy z \u0142a\u0144cuchami eskalacji. Syntetyczne kontrole z kilku region\u00f3w pokazuj\u0105 mi wcze\u015bnie, czy dana lokalizacja s\u0142abnie. Regularnie przeprowadzam testy obci\u0105\u017cenia i prze\u0142\u0105czania awaryjnego, aby upewni\u0107 si\u0119, \u017ce umowy SLA dotycz\u0105ce dost\u0119pno\u015bci i czas\u00f3w reakcji s\u0105 istotne. Kiedy wprowadzane s\u0105 zmiany, sprawdzam delegacje, seryjne SOA, transfery stref i trasy odpowiedzi, aby natychmiast wykry\u0107 niesp\u00f3jno\u015bci. W ten spos\u00f3b utrzymuj\u0119 <strong>Jako\u015b\u0107 us\u0142ug<\/strong> Mierzalne i mog\u0105 przechwytywa\u0107 problemy, zanim wp\u0142yn\u0105 one na u\u017cytkownik\u00f3w.<\/p>\n\n<h2>SLO, profile op\u00f3\u017anie\u0144 i bud\u017cety b\u0142\u0119d\u00f3w<\/h2>\n<p>Definiuj\u0119 <strong>SLI<\/strong> dla wska\u017anika powodzenia (np. z wy\u0142\u0105czeniem NXDOMAIN), op\u00f3\u017anie\u0144 p50\/p90\/p99 i skorelowa\u0107 je z obci\u0105\u017ceniem. <strong>SLO<\/strong> wynikaj\u0105 z oczekiwa\u0144 u\u017cytkownik\u00f3w i ryzyka biznesowego; bud\u017cety b\u0142\u0119d\u00f3w kontroluj\u0105, ile pozostaje swobody w zakresie konserwacji. <em>Szybko\u015b\u0107 spalania<\/em>-Alerty rozpoznaj\u0105, kiedy awarie szybko poch\u0142aniaj\u0105 bud\u017cet. Pulpity nawigacyjne por\u00f3wnuj\u0105 \u015bcie\u017cki autorytatywne i rekurencyjne, dzi\u0119ki czemu mog\u0119 rozpozna\u0107, czy problemy dotycz\u0105 resolwera, trasy sieciowej czy serwer\u00f3w autorytatywnych. Ta przejrzysto\u015b\u0107 jest podstaw\u0105 wiarygodnych um\u00f3w SLA.<\/p>\n\n<h2>Integracja z \u015brodowiskiem hostingowym<\/h2>\n\n<p>DNS dzia\u0142a tylko wtedy, gdy serwery WWW, bazy danych, \u015bcie\u017cki sieciowe i zapory sieciowe s\u0105 r\u00f3wnie\u017c skonfigurowane tak, aby by\u0142y odporne na awarie, wi\u0119c my\u015bl\u0119, \u017ce <strong>End-to-end<\/strong>. R\u00f3wnowa\u017cenie obci\u0105\u017cenia, replikacja klastra i oddzielne \u015bcie\u017cki routera redukuj\u0105 pojedyncze punkty awarii i uzupe\u0142niaj\u0105 ochron\u0119 DNS. Dokumentuj\u0119 wszystkie zale\u017cno\u015bci, aby zmiany nie wywo\u0142ywa\u0142y reakcji \u0142a\u0144cuchowych. Jestem w stanie dzia\u0142a\u0107 pod du\u017cym obci\u0105\u017ceniem, je\u015bli resolwery i pami\u0119ci podr\u0119czne s\u0105 odpowiednio zwymiarowane; informacje na temat pojemno\u015bci s\u0105 dostarczane przez <a href=\"https:\/\/webhosting.de\/pl\/dns-resolver-load-handling-high-last-cacheboost\/\">Rozk\u0142ad obci\u0105\u017cenia na resolwerze<\/a>. W ten spos\u00f3b DNS niezawodnie przekazuje zapytania do us\u0142ug, kt\u00f3re s\u0105 r\u00f3wnie\u017c <strong>niezwykle dost\u0119pny<\/strong> praca.<\/p>\n\n<h2>\u015arodowiska kontenerowe i Kubernetes<\/h2>\n<p>W kontenerach wymagania DNS cz\u0119sto skaluj\u0105 si\u0119 skokowo: wykrywanie us\u0142ug, kr\u00f3tkie TTL i wiele pod\u00f3w generuj\u0105 szczyty zapyta\u0144. U\u017cywam <strong>CoreDNS<\/strong> czysto, u\u017cywaj NodeLocal DNSCache, stubDomains i upstreams w ukierunkowany spos\u00f3b i chro\u0144 zewn\u0119trzne resolvery przed zalaniem. Sondy gotowo\u015bci\/\u017cywotno\u015bci aplikacji nie mog\u0105 przeci\u0105\u017ca\u0107 resolver\u00f3w; pami\u0119ci podr\u0119czne na poziomie w\u0119z\u0142a wyg\u0142adzaj\u0105 szczyty. Sprawdzam, czy strefy wewn\u0119trzne (np. us\u0142ugi klastrowe) s\u0105 wyra\u017anie oddzielone od zewn\u0119trznych i symuluj\u0119 prze\u0142\u0105czanie awaryjne, aby wdro\u017cenia nie ko\u0144czy\u0142y si\u0119 niepowodzeniem z powodu w\u0105skich garde\u0142 DNS.<\/p>\n\n<h2>Kr\u00f3tkie wyja\u015bnienie listy kontrolnej<\/h2>\n\n<p>Dla produktywnych <strong>Domeny<\/strong> Przechowuj\u0119 co najmniej dwa, a najlepiej trzy autorytatywne serwery nazw w oddzielnych sieciach i lokalizacjach oraz sprawdzam delegacj\u0119. Zabezpieczam transfery stref, aktywuj\u0119 DNSSEC tam, gdzie to mo\u017cliwe oraz aktualizuj\u0119 dokumentacj\u0119 i plany awaryjne. Testy i monitorowanie dzia\u0142aj\u0105 w spos\u00f3b ci\u0105g\u0142y, w tym alerty i regularne wdro\u017cenia testowe ze skr\u00f3conymi TTL. Aby zwi\u0119kszy\u0107 odporno\u015b\u0107, planuj\u0119 konfiguracje anycast lub multi-provider, w zale\u017cno\u015bci od ryzyka i bud\u017cetu. Ta linia zapewnia mi <strong>niezawodny<\/strong> Rozdzielczo\u015b\u0107, kt\u00f3ra dzia\u0142a r\u00f3wnie\u017c pod wp\u0142ywem stresu.<\/p>\n\n<h2>Wp\u0142yw na SEO i wra\u017cenia u\u017cytkownika<\/h2>\n\n<p>Powolny <strong>DNS<\/strong>-Odpowiedzi wyd\u0142u\u017caj\u0105 czas do pierwszego bajtu i wp\u0142ywaj\u0105 na czas \u0142adowania, co odczuwaj\u0105 zar\u00f3wno u\u017cytkownicy, jak i roboty indeksuj\u0105ce. Powtarzaj\u0105ce si\u0119 awarie wysy\u0142aj\u0105 z\u0142e sygna\u0142y i kosztuj\u0105 mo\u017cliwo\u015bci rankingowe, wi\u0119c dost\u0119pno\u015b\u0107 jest priorytetem. Dzi\u0119ki czystemu prze\u0142\u0105czaniu awaryjnemu resolvera, kr\u00f3tkim limitom czasu i dystrybucji geograficznej zapewniam szybkie odpowiedzi w ka\u017cdym miejscu. Trafienia z pami\u0119ci podr\u0119cznej zmniejszaj\u0105 op\u00f3\u017anienia, a sp\u00f3jne strefy zapobiegaj\u0105 niew\u0142a\u015bciwym zachowaniom aplikacji. Dobrze przemy\u015blana strategia hostingu redundancji dns op\u0142aca si\u0119 bezpo\u015brednio na <strong>Zadowolenie u\u017cytkownika<\/strong> i widoczno\u015b\u0107.<\/p>\n\n<h2>Aspekty specyficzne dla poczty e-mail bez niespodzianek<\/h2>\n<p>E-mail jest szczeg\u00f3lnie wra\u017cliwy: dzia\u0142am <strong>Prze\u0142\u0105czanie awaryjne MX<\/strong> za po\u015brednictwem oddzielnych sieci\/lokalizacji i ustawi\u0107 priorytety tak, aby obci\u0105\u017cenie by\u0142o rozs\u0105dnie roz\u0142o\u017cone. Rekordy SPF uwzgl\u0119dniaj\u0105 wszystkie systemy wysy\u0142aj\u0105ce i dostawc\u00f3w; testuj\u0119 zmiany z wyprzedzeniem z obni\u017conym TTL. <strong>DKIM<\/strong>-Wdra\u017cam klucze zgodnie z planem, udost\u0119pniam kilka selektor\u00f3w i upewniam si\u0119, \u017ce wszystkie autorytatywne serwery nazw synchronizuj\u0105 nowe klucze. Dostosowanie polityki DMARC (<em>p=brak\u2192kwarantanna\u2192odrzu\u0107<\/em>) towarzyszy monitorowanie w celu zapewnienia, \u017ce legalne wiadomo\u015bci nie zostan\u0105 zniszczone. Oznacza to, \u017ce dostarczalno\u015b\u0107 pozostaje wysoka nawet w przypadku awarii.<\/p>\n\n<h2>M\u00f3j harmonogram \u0107wicze\u0144<\/h2>\n\n<p>Zaczynam od <strong>Analiza aktualnej sytuacji<\/strong> delegacji, sprawdzam lokalizacje, sieci IP i transfery stref oraz eliminuj\u0119 pojedyncze punkty awarii. Nast\u0119pnie optymalizuj\u0119 TTL, aktywuj\u0119 DNSSEC, ustawiam profile alert\u00f3w i planuj\u0119 testy prze\u0142\u0105czania awaryjnego w kalendarzu. W przypadku ruchu globalnego dodaj\u0119 anycast lub drugiego dostawc\u0119 i jasno dokumentuj\u0119 \u015bcie\u017cki zmian. Nast\u0119pnie stale mierz\u0119 czasy odpowiedzi, wska\u017aniki powodzenia i wydajno\u015b\u0107 pami\u0119ci podr\u0119cznej oraz skaluj\u0119 resolwery, gdy ruch wzrasta. Pozwala to utrzyma\u0107 <strong>Rozdzielczo\u015b\u0107 nazwy<\/strong> niezawodne, szybkie i wysoce dost\u0119pne - dok\u0142adnie to, czego potrzebuj\u0105 nowoczesne \u015brodowiska hostingowe.<\/p>\n\n<h2>In\u017cynieria incydent\u00f3w i chaosu dla DNS<\/h2>\n<p>\u0106wicz\u0119 na wypadek sytuacji awaryjnych: <strong>GameDays<\/strong> Symuluj\u0119 awarie resolvera, pozostawione w\u0119z\u0142y anycast s\u0105 specjalnie wycofywane, a op\u00f3\u017anienia WAN s\u0105 sztucznie zwi\u0119kszane. Obserwuj\u0119, jak szybko klienci prze\u0142\u0105czaj\u0105 si\u0119, czy timeouty s\u0105 odpowiednie i czy alarmy uruchamiaj\u0105 si\u0119 prawid\u0142owo. Runbooki zawieraj\u0105 jasne kroki dla b\u0142\u0119d\u00f3w delegacji, wadliwych podpis\u00f3w (DNSSEC) i nieudanych transfer\u00f3w. Testowane s\u0105 kopie zapasowe stref i kluczy, definiowane s\u0105 RTO\/RPO. \u0106wiczenia te pokazuj\u0105, gdzie procesy utkn\u0119\u0142y - i wzmacniaj\u0105 ca\u0142y \u0142a\u0144cuch od klienta do serwera autorytatywnego.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/06\/dns-hosting-serverraum-4816.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>","protected":false},"excerpt":{"rendered":"<p>Dowiedz si\u0119, jak dzia\u0142a redundancja resolvera DNS w hostingu z wieloma serwerami nazw i wysoce dost\u0119pn\u0105 architektur\u0105 oraz dlaczego ta strategia hostingu redundancji DNS jest tak wa\u017cna dla wydajno\u015bci i SEO.<\/p>","protected":false},"author":1,"featured_media":19642,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[674],"tags":[],"class_list":["post-19649","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-web_hosting"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"54","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"dns redundancy","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"19642","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/19649","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=19649"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/posts\/19649\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media\/19642"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/media?parent=19649"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/categories?post=19649"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pl\/wp-json\/wp\/v2\/tags?post=19649"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}