{"id":1479,"date":"2026-05-05T07:32:31","date_gmt":"2026-05-05T07:32:31","guid":{"rendered":"https:\/\/sudoit.pl\/?p=1479"},"modified":"2026-05-05T07:32:33","modified_gmt":"2026-05-05T07:32:33","slug":"diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce","status":"publish","type":"post","link":"https:\/\/sudoit.pl\/index.php\/2026\/05\/05\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\/","title":{"rendered":"Diagnostyka sieci i DNS w Linuxie \u2013 nslookup, dig i tcpdump w praktyce"},"content":{"rendered":"\n

Konfiguracja us\u0142ug sieciowych<\/strong> w Linuxie to dopiero po\u0142owa pracy. Sama wiedza o tym, jak ustawi\u0107 adres IP, routing czy serwer DNS, nie wystarczy, je\u015bli w pewnym momencie co\u015b przestanie dzia\u0142a\u0107 i nie b\u0119dziesz wiedzia\u0142, gdzie le\u017cy problem. A w praktyce takie sytuacje pojawiaj\u0105 si\u0119 bardzo cz\u0119sto. Klient nie rozwi\u0105zuje nazwy hosta, serwer DNS odpowiada tylko lokalnie, pakiety dochodz\u0105 do routera, ale nie wracaj\u0105 z drugiej strony, a nowy rekord istnieje na masterze, ale wci\u0105\u017c nie pojawia si\u0119 na slave.<\/p>\n\n\n\n

W takich momentach nie wystarczy ju\u017c samo ping<\/strong> i szybkie spojrzenie w plik konfiguracyjny. Trzeba umie\u0107 sprawdzi\u0107, czy klient naprawd\u0119 wys\u0142a\u0142 zapytanie<\/strong>, czy serwer DNS je odebra\u0142<\/strong>, jak\u0105 odpowied\u017a zwr\u00f3ci\u0142<\/strong> i czy pakiet w og\u00f3le przeszed\u0142 przez sie\u0107<\/strong>. Do tego s\u0142u\u017c\u0105 w\u0142a\u015bnie narz\u0119dzia diagnostyczne. W Linuxie i Windowsie bardzo cz\u0119sto wykorzystuje si\u0119 do tego nslookup<\/strong>, dig<\/strong> oraz tcpdump<\/strong>. Ka\u017cde z nich dzia\u0142a troch\u0119 inaczej, ka\u017cde pokazuje inny poziom problemu i ka\u017cde przydaje si\u0119 w troch\u0119 innym momencie.<\/p>\n\n\n\n

W tym artykule poka\u017c\u0119 Ci, jak diagnozowa\u0107 problemy z DNS i sieci\u0105 w Linuxie<\/strong>, wykorzystuj\u0105c dok\u0142adnie to samo \u015brodowisko, kt\u00f3re budowali\u015bmy wcze\u015bniej.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Przejdziemy przez podstawowe zastosowania nslookup<\/strong>, dig<\/strong> i tcpdump<\/strong>, om\u00f3wimy najwa\u017cniejsze r\u00f3\u017cnice mi\u0119dzy nimi, a potem wykonamy seri\u0119 praktycznych test\u00f3w i awarii: od prostych problem\u00f3w z rekordami DNS, przez brak odpowiedzi z serwera slave, a\u017c po problemy z forwardingiem i zapor\u0105 sieciow\u0105. Zademonstruj\u0119 Ci problemy na jakie natrafi\u0142em w poprzednim artykule i narz\u0119dzia, kt\u00f3re pomog\u0142y mi je rozwi\u0105za\u0107.<\/p>\n\n\n\n

<\/div>\n\n\n\n

Dlaczego samo ping nie wystarcza?<\/h2>\n\n\n\n
\n\n\n\n

Zacznijmy od prostej sytuacji, kt\u00f3ra bardzo dobrze pokazuje, dlaczego samo ping<\/strong> nie wystarcza. Na Windowsie CL1<\/strong> wykonujemy dwa testy:<\/p>\n\n\n\n

ping 172.16.10.1  \nping 172.16.20.11<\/code><\/pre>\n\n\n
\n
\"\"<\/figure>\n<\/div>\n\n\n
Pierwszy ping do Debiana<\/strong> dzia\u0142a. Drugi, skierowany do Ubuntu<\/strong>, ju\u017c nie. Na pierwszy rzut oka wygl\u0105da to jak zwyk\u0142y problem z sieci\u0105, ale tak naprawd\u0119 ten objaw mo\u017ce oznacza\u0107 kilka r\u00f3\u017cnych rzeczy naraz:<\/p>\n\n\n\n
    \n
  • brak poprawnej trasy,<\/li>\n\n\n\n
  • brak forwardingu na routerze,<\/li>\n\n\n\n
  • zablokowany ruch ICMP po drodze,<\/li>\n\n\n\n
  • problem z odpowiedzi\u0105 hosta docelowego,<\/li>\n\n\n\n
  • albo lokaln\u0105 zapor\u0119 na kt\u00f3rym\u015b z system\u00f3w.<\/li>\n<\/ul>\n\n\n\n
    I w\u0142a\u015bnie tutaj zaczyna si\u0119 r\u00f3\u017cnica mi\u0119dzy \u201esprawdzaniem czy dzia\u0142a\u201d a prawdziw\u0105 diagnostyk\u0105. Je\u015bli co\u015b nie dzia\u0142a, ping<\/strong> nie powie Ci jeszcze, na kt\u00f3rym etapie wszystko si\u0119 zatrzyma\u0142o<\/strong>. W\u0142a\u015bnie dlatego przy diagnostyce warto rozdzieli\u0107 problem na warstwy i u\u017cywa\u0107 narz\u0119dzi, kt\u00f3re pokazuj\u0105 konkretny fragment ca\u0142ego procesu.<\/p>\n\n\n\n
    <\/div>\n\n\n\n
    nslookup \u2013 szybki test dzia\u0142ania DNS<\/h2>\n\n\n\n
    \n\n\n\n
    To bardzo dobre narz\u0119dzie do pierwszego kontaktu z problemem. Nie daje tak szczeg\u00f3\u0142owego obrazu jak dig, ale pozwala w kilka sekund sprawdzi\u0107, czy serwer DNS odpowiada i czy zna konkretny rekord. To cz\u0119sto wystarcza, \u017ceby ustali\u0107, czy problem jest og\u00f3lny, czy dotyczy tylko jednego hosta albo jednego typu rekordu.<\/p>\n\n\n\n
    <\/div>\n\n\n\n
    Podstawowe u\u017cycie nslookup<\/h3>\n\n\n\n
    Najprostszy przyk\u0142ad wygl\u0105da tak:<\/p>\n\n\n\n
    nslookup dns1.firma.local 172.16.10.1<\/code><\/pre>\n\n\n\n
    W tym przypadku pytasz konkretnie serwer DNS Debian<\/strong> o rekord dns1.firma.local<\/strong>.<\/p>\n\n\n\n
    Mo\u017cesz wykona\u0107 to samo pytanie do serwera slave na Ubuntu:<\/p>\n\n\n\n
    nslookup dns1.firma.local 172.16.20.11<\/code><\/pre>\n\n\n\n
    To bardzo wygodny spos\u00f3b na szybkie por\u00f3wnanie odpowiedzi z:<\/p>\n\n\n\n
      \n
    • serwera master<\/strong><\/li>\n\n\n\n
    • oraz serwera slave<\/strong><\/li>\n<\/ul>\n\n\n
      \n
      \"\"<\/figure>\n<\/div>\n\n\n
      Je\u015bli oba zwracaj\u0105 ten sam rekord, to znaczy, \u017ce synchronizacja strefy dzia\u0142a poprawnie. Je\u015bli jeden odpowiada, a drugi nie, to od razu wiadomo, w kt\u00f3r\u0105 stron\u0119 i\u015b\u0107 z diagnostyk\u0105. <\/p>\n\n\n\n
      W tym przypadku widzimy, \u017ce serwer master odpowiada, a serwer slave nie odpowiada. I tu zaczynaj\u0105 si\u0119 schodki bo po drodze do serwera Ubuntu jest kilka urz\u0105dze\u0144 i na pierwszy rzut oka nie wiadomo gdzie le\u017cy wina. Poka\u017ce jak podej\u015b\u0107 do tego tematu w momencie gdy przedstawi\u0119 wszystkie narz\u0119dzia.<\/p>\n\n\n\n
      <\/div>\n\n\n\n
      nslookup dla reverse DNS<\/h3>\n\n\n\n
      To samo narz\u0119dzie mo\u017cna wykorzysta\u0107 do sprawdzenia rekord\u00f3w PTR, czyli reverse DNS.<\/p>\n\n\n\n
      nslookup 172.16.10.10 172.16.10.1<\/code><\/pre>\n\n\n\n
      Je\u015bli strefa odwrotna jest skonfigurowana poprawnie, powiniene\u015b otrzyma\u0107 nazw\u0119 hosta przypisan\u0105 do tego adresu, w tym przypadku cl1.firma.local<\/strong>.<\/p>\n\n\n\n
      \"\"<\/figure>\n\n\n\n
      To bardzo dobry test do sprawdzenia, czy dzia\u0142a nie tylko zwyk\u0142e mapowanie nazwy na IP, ale te\u017c odwrotne mapowanie adresu na nazw\u0119.<\/p>\n\n\n\n
      <\/div>\n\n\n\n
      Interaktywny tryb nslookup<\/h3>\n\n\n\n
      nslookup mo\u017ce dzia\u0142a\u0107 tak\u017ce w trybie interaktywnym. To przydatne, gdy chcesz zadawa\u0107 kilka pyta\u0144 do jednego serwera bez wpisywania jego adresu za ka\u017cdym razem. To bardzo wygodne przy szybkich testach po stronie klienta.<\/p>\n\n\n\n
      nslookup  \nserver 172.16.20.11  \nset type=mx  \nfirma.locaL<\/code><\/pre>\n\n\n\n
      W ten spos\u00f3b mo\u017cesz zapyta\u0107 o:<\/p>\n\n\n\n
        \n
      • rekordy MX<\/strong>,<\/li>\n\n\n\n
      • rekordy SRV<\/strong>,<\/li>\n\n\n\n
      • rekordy PTR<\/strong>,<\/li>\n\n\n\n
      • albo po prostu prze\u0142\u0105cza\u0107 si\u0119 mi\u0119dzy r\u00f3\u017cnymi serwerami DNS.<\/li>\n<\/ul>\n\n\n
        \n
        \"\"<\/figure>\n<\/div>\n\n\n
        <\/div>\n\n\n\n
        dig \u2013 dok\u0142adna analiza odpowiedzi DNS<\/h2>\n\n\n\n
        \n\n\n\n
        Je\u015bli nslookup jest dobry na szybki test, to dig<\/strong> jest narz\u0119dziem do dok\u0142adnego zrozumienia odpowiedzi DNS. W praktyce bardzo cz\u0119sto dopiero dig pokazuje, czy rekord rzeczywi\u015bcie istnieje, z kt\u00f3rej strefy pochodzi odpowied\u017a, jaki jest numer seryjny strefy i czy serwer zwraca wynik poprawnie.<\/p>\n\n\n\n
        <\/div>\n\n\n\n
        Podstawowe zapytanie dig<\/h3>\n\n\n\n
        Poni\u017cej prezentuje przyk\u0142adowe zapytanie do serwera master.<\/p>\n\n\n\n
        dig @172.16.10.1 dns1.firma.local<\/code><\/pre>\n\n\n\n
        Najpierw wskazujemy adres IP serwera DNS, z kt\u00f3rego ma przyj\u015b\u0107 odpowied\u017a a nast\u0119pnie pytamy o rekord. Jak wida\u0107 na poni\u017cszym screenie w wyniku zapytania otrzymali\u015bmy adres IP rekordu dns1.firma.local<\/strong>.<\/p>\n\n\n\n
        Wynik dig<\/strong> jest du\u017co bogatszy ni\u017c wynik nslookup. Warto zwr\u00f3ci\u0107 uwag\u0119 przede wszystkim na:<\/p>\n\n\n\n
          \n
        • status<\/li>\n\n\n\n
        • ANSWER SECTION<\/li>\n\n\n\n
        • Query time<\/li>\n\n\n\n
        • SERVER<\/li>\n<\/ul>\n\n\n\n
          \"\"<\/figure>\n\n\n\n
          Spr\u00f3bujmy odpyta\u0107 serwer slave w ten spos\u00f3b. Niestety w tym przypadku dostajemy komunikat “host unreachable”. Z niewiadomego powodu na ten moment nie jest dost\u0119pny. W dalszej cz\u0119\u015bci artyku\u0142u poka\u017ce jak naprawi\u0107 ten problem.<\/p>\n\n\n\n
          \"\"<\/figure>\n\n\n\n
          <\/div>\n\n\n\n
          Co oznaczaj\u0105 najcz\u0119stsze statusy?<\/h3>\n\n\n\n
          W odpowiedzi dig<\/strong> bardzo du\u017co m\u00f3wi sam status<\/strong> zwr\u00f3cony przez serwer DNS. To w\u0142a\u015bnie on cz\u0119sto jako pierwszy podpowiada, z jakim typem problemu masz do czynienia.<\/p>\n\n\n\n
          NOERROR<\/strong> oznacza, \u017ce serwer obs\u0142u\u017cy\u0142 zapytanie poprawnie. Nie zawsze musi to od razu znaczy\u0107, \u017ce rekord zosta\u0142 znaleziony, ale pokazuje, \u017ce samo zapytanie nie zako\u0144czy\u0142o si\u0119 b\u0142\u0119dem.<\/p>\n\n\n\n
          NXDOMAIN<\/strong> oznacza, \u017ce taka nazwa nie istnieje w danej strefie. Najcz\u0119\u015bciej wskazuje to na liter\u00f3wk\u0119, brak rekordu albo pytanie skierowane do niew\u0142a\u015bciwej strefy DNS.<\/p>\n\n\n\n
          SERVFAIL<\/strong> oznacza, \u017ce serwer pr\u00f3bowa\u0142 odpowiedzie\u0107, ale co\u015b posz\u0142o nie tak po drodze. W praktyce bardzo cz\u0119sto sugeruje problem z forwardingiem, odpowiedzi\u0105 z innego serwera DNS, walidacj\u0105 DNSSEC albo og\u00f3lnym b\u0142\u0119dem po stronie samej us\u0142ugi DNS.<\/p>\n\n\n\n
          REFUSED<\/strong> oznacza, \u017ce serwer \u015bwiadomie odmawia odpowiedzi. Taki status zwykle pojawia si\u0119 wtedy, gdy rekursja jest wy\u0142\u0105czona, obowi\u0105zuj\u0105 ograniczenia allow-query<\/code> albo serwer zosta\u0142 skonfigurowany tak, by nie odpowiada\u0107 na zapytania z danego \u017ar\u00f3d\u0142a.<\/p>\n\n\n\n
          <\/div>\n\n\n\n
          dig dla r\u00f3\u017cnych typ\u00f3w rekord\u00f3w<\/h3>\n\n\n\n
          To samo narz\u0119dzie mo\u017cesz wykorzysta\u0107 do sprawdzania r\u00f3\u017cnych typ\u00f3w rekord\u00f3w.<\/p>\n\n\n\n
            \n
          • Rekordy A<\/strong> – dig @172.16.10.1 sklep.firma.local<\/li>\n\n\n\n
          • Rekordy MX<\/strong> – dig @172.16.10.1 firma.local MX<\/li>\n\n\n\n
          • Rekordy SRV<\/strong> – dig @172.16.10.1 _sip._udp.firma.local SRV<\/li>\n\n\n\n
          • Reverse DNS<\/strong> – dig @172.16.10.1 -x 172.16.10.10<\/li>\n<\/ul>\n\n\n\n
            \"\"<\/figure>\n\n\n\n
            To bardzo wygodne, bo jednym narz\u0119dziem mo\u017cesz sprawdzi\u0107 praktycznie ca\u0142y przekr\u00f3j informacji DNS.<\/p>\n\n\n\n
            <\/div>\n\n\n\n
            dig i numer seryjny SOA<\/h3>\n\n\n\n
            Jedno z najlepszych zastosowa\u0144 dig<\/strong> w \u015brodowisku z master\/slave to sprawdzanie numeru seryjnego strefy:<\/p>\n\n\n\n
            dig @172.16.10.1 firma.local SOA  \ndig @172.16.20.11 firma.local SOA<\/code><\/pre>\n\n\n\n
            To pozwala bardzo szybko ustali\u0107:<\/p>\n\n\n\n
              \n
            • czy slave pobra\u0142 ju\u017c now\u0105 wersj\u0119 strefy,<\/li>\n\n\n\n
            • czy nadal trzyma starsz\u0105 kopi\u0119,<\/li>\n\n\n\n
            • czy problemem jest brak zwi\u0119kszenia numeru seryjnego.<\/li>\n<\/ul>\n\n\n\n
              <\/div>\n\n\n\n
              Przydatne opcje dig<\/h3>\n\n\n\n
              +short<\/strong> – Pokazuje tylko sam wynik bez ca\u0142ej reszty:<\/p>\n\n\n\n
              dig @172.16.20.11 sklep.firma.local +short<\/code><\/pre>\n\n\n\n
              +tcp<\/strong> – Wymusza u\u017cycie TCP zamiast UDP:<\/p>\n\n\n\n
              dig @172.16.20.11 dns1.firma.local +tcp<\/code><\/pre>\n\n\n\n
              To bardzo przydatne, gdy podejrzewasz problem z odpowiedziami po UDP.<\/p>\n\n\n\n
              <\/div>\n\n\n\n
              tcpdump \u2013 podgl\u0105d rzeczywistego ruchu<\/h2>\n\n\n\n
              \n\n\n\n
              To narz\u0119dzie pokazuje, co naprawd\u0119 idzie po sieci. Jest bezcenne wtedy, gdy chcesz sprawdzi\u0107, czy klient na pewno wys\u0142a\u0142 zapytanie, czy serwer je odebra\u0142 i czy odpowied\u017a wr\u00f3ci\u0142a. Podgl\u0105d obserwujesz na bie\u017c\u0105co, informacje wyskakuj\u0105 na ekranie.<\/p>\n\n\n\n
              \"\"<\/figure>\n\n\n\n
              <\/div>\n\n\n\n
              Podgl\u0105d ruchu DNS<\/h3>\n\n\n\n
              Na Debianie mo\u017cesz podejrze\u0107 ca\u0142y ruch DNS tak:<\/p>\n\n\n\n
              tcpdump -ni any port 53<\/code><\/pre>\n\n\n\n
              Je\u017celi chcesz zaw\u0119zi\u0107 widok tylko do konkretnego klienta, na przyk\u0142ad CL2<\/strong>, mo\u017cesz u\u017cy\u0107:<\/p>\n\n\n\n
              sudo tcpdump -ni any host 172.16.20.10 and port 53<\/code><\/pre>\n\n\n\n
              To pozwala bardzo szybko sprawdzi\u0107:<\/p>\n\n\n\n
                \n
              • czy klient naprawd\u0119 wysy\u0142a pytania,<\/li>\n\n\n\n
              • czy serwer je dostaje,<\/li>\n\n\n\n
              • i czy pojawia si\u0119 odpowied\u017a.<\/li>\n<\/ul>\n\n\n\n
                <\/div>\n\n\n\n
                Podgl\u0105d ICMP<\/h3>\n\n\n\n
                Do diagnostyki ping\u00f3w i routingu \u015bwietnie nadaje si\u0119:<\/p>\n\n\n\n
                sudo tcpdump -ni any icmp<\/code><\/pre>\n\n\n\n
                <\/div>\n\n\n\n
                Dlaczego tcpdump jest tak przydatny<\/h3>\n\n\n\n
                To narz\u0119dzie pozwala rozstrzygn\u0105\u0107 rzeczy, kt\u00f3rych nie poka\u017ce sam ping<\/strong> ani dig<\/strong>. Na przyk\u0142ad:<\/p>\n\n\n\n
                  \n
                • klient m\u00f3wi, \u017ce DNS timeoutuje,<\/li>\n\n\n\n
                • ale tcpdump<\/strong> pokazuje, \u017ce pytanie w og\u00f3le nie wysz\u0142o,<\/li>\n\n\n\n
                • albo pytanie dochodzi do serwera, ale odpowied\u017a jest blokowana przez nftables<\/strong>,<\/li>\n\n\n\n
                • albo routing dzia\u0142a tylko w jedn\u0105 stron\u0119.<\/li>\n<\/ul>\n\n\n\n
                  I w\u0142a\u015bnie dlatego tcpdump tak dobrze uzupe\u0142nia nslookup<\/strong> i dig<\/strong>.<\/p>\n\n\n\n
                  <\/div>\n\n\n\n
                  Troubleshooting krok po kroku \u2013 przyk\u0142ady wykorzystania narz\u0119dzi<\/h2>\n\n\n\n
                  \n\n\n\n
                  Najlepszy spos\u00f3b nauki diagnostyki to nie tylko patrzenie na dzia\u0142aj\u0105ce \u015brodowisko, ale te\u017c przej\u015bcie przez kilka prawdziwych awarii. W moim przypadku punkt wyj\u015bcia by\u0142 prosty: z CL1 mo\u017cna by\u0142o pingowa\u0107 Debiana, ale Ubuntu ju\u017c nie odpowiada\u0142o<\/strong>. Taki objaw wygl\u0105da niewinnie, ale po roz\u0142o\u017ceniu go na etapy okaza\u0142o si\u0119, \u017ce po drodze kry\u0142y si\u0119 r\u00f3\u017cne problemy.<\/p>\n\n\n\n
                  <\/div>\n\n\n\n
                  Problem 1 \u2013 sprawdzamy, czy Debian w og\u00f3le forwarduje ruch<\/h3>\n\n\n\n
                  Skoro CL1<\/strong> widzi Debiana<\/strong>, ale nie widzi Ubuntu<\/strong>, pierwszym podejrzanym staje si\u0119 router po drodze. W naszym labie rol\u0119 hosta po\u015brednicz\u0105cego pe\u0142ni\u0142 w\u0142a\u015bnie Debian<\/strong>, wi\u0119c naturalnym krokiem by\u0142o sprawdzenie, czy pakiet w og\u00f3le do niego dochodzi i czy jest przekazywany dalej.<\/p>\n\n\n\n
                  Na Debianie uruchomi\u0142em:<\/strong><\/p>\n\n\n\n
                  tcpdump -ni any icmp and \\(host 172.16.10.10 or host 172.16.20.11\\)<\/code><\/pre>\n\n\n\n
                  Nast\u0119pnie z CL1<\/strong> ponowi\u0142em:<\/p>\n\n\n\n
                  ping 172.16.20.11<\/code><\/pre>\n\n\n\n
                  \"\"<\/figure>\n\n\n\n
                  Wynik by\u0142 bardzo czytelny: pakiet od 172.16.10.10<\/strong> dochodzi\u0142 do Debiana, ale nie pojawia\u0142 si\u0119 po stronie interfejsu prowadz\u0105cego dalej do CentOS-a i Ubuntu. To oznacza\u0142o, \u017ce problem nie le\u017ca\u0142 jeszcze w Ubuntu, tylko wcze\u015bniej – Debian nie forwardowa\u0142<\/strong> ruchu.<\/p>\n\n\n\n
                  <\/div>\n\n\n\n
                  Co by\u0142o popsute i jak to naprawi\u0142em?<\/h4>\n\n\n\n
                  \"\"<\/figure>\n\n\n\n
                  Na Debianie problemem by\u0142 wy\u0142\u0105czony IP forwarding<\/strong> albo b\u0142\u0119dna polityka przekazywania pakiet\u00f3w pomi\u0119dzy interfejsami. Za pomoc\u0105 polecenia sysctl -p<\/strong> sprawdzi\u0142em czy routing jest w\u0142\u0105czony. Jako, \u017ce nie by\u0142, to w\u0142\u0105czy\u0142em go na sta\u0142e poleceniem:<\/p>\n\n\n\n
                  sysctl -w net.ipv4.ip_forward=1<\/code><\/pre>\n\n\n\n
                  <\/div>\n\n\n\n
                  Problem 2 \u2013 przechodzimy do DNS i okazuje si\u0119, \u017ce Ubuntu odpowiada tylko lokalnie<\/h3>\n\n\n\n
                  Skoro sie\u0107 zacz\u0119\u0142a dzia\u0142a\u0107 poprawnie po IP, mo\u017cna by\u0142o przej\u015b\u0107 do diagnostyki samego DNS. I tu pojawi\u0142 si\u0119 kolejny problem: CL1<\/strong> nie potrafi\u0142 rozwi\u0105zywa\u0107 nazw z Ubuntu slave<\/strong>, mimo \u017ce Ubuntu by\u0142o osi\u0105galne ju\u017c po IP.<\/p>\n\n\n\n
                  Na kliencie wykona\u0142em poni\u017csze polecenie i dosta\u0142em timeout.:<\/p>\n\n\n\n
                  nslookup dns1.firma.local 172.16.20.11<\/code><\/pre>\n\n\n
                  \n
                  \"\"<\/figure>\n<\/div>\n\n\n
                  Na pierwszy rzut oka wygl\u0105da\u0142o to jak problem z samym serwerem DNS. Ale to w\u0142a\u015bnie tutaj dobrze wida\u0107 r\u00f3\u017cnic\u0119 mi\u0119dzy nslookup<\/code>, dig<\/code> i tcpdump<\/code><\/strong>.<\/p>\n\n\n\n
                  <\/div>\n\n\n\n
                  Co pokaza\u0142 dig?<\/h4>\n\n\n\n
                  Na samym Ubuntu wykona\u0142em:<\/p>\n\n\n\n
                  dig @172.16.20.11 dns1.firma.local<\/code><\/pre>\n\n\n\n
                  i dosta\u0142em poprawn\u0105 odpowied\u017a. To oznacza\u0142o, \u017ce:<\/p>\n\n\n\n
                    \n
                  • strefa jest za\u0142adowana,<\/li>\n\n\n\n
                  • rekord istnieje,<\/li>\n\n\n\n
                  • named dzia\u0142a lokalnie.<\/li>\n<\/ul>\n\n\n\n
                    Czyli problem nie le\u017ca\u0142 w samym rekordzie ani w konfiguracji strefy.<\/p>\n\n\n\n
                    \"\"<\/figure>\n\n\n\n
                    <\/div>\n\n\n\n
                    Co pokaza\u0142 tcpdump?<\/h4>\n\n\n\n
                    Na Ubuntu uruchomi\u0142em:<\/p>\n\n\n\n
                    sudo tcpdump -ni any host 172.16.20.10 and port 53<\/code><\/pre>\n\n\n\n
                    Nast\u0119pnie ponowi\u0142em nslookup z CL1<\/strong>. Wynik by\u0142 bardzo ciekawy. W tcpdump<\/strong> by\u0142o wida\u0107, \u017ce zapytania od klienta dochodz\u0105 do Ubuntu, ale odpowiedzi nie wracaj\u0105 do sieci. To oznacza\u0142o, \u017ce serwer dostaje pytania<\/strong>, ale co\u015b blokuje odpowied\u017a.<\/p>\n\n\n\n
                    \"\"<\/figure>\n\n\n\n
                    <\/div>\n\n\n\n
                    Co by\u0142o popsute i jak to naprawi\u0142em?<\/h4>\n\n\n\n
                    Winne okaza\u0142o si\u0119 aktywne nftables<\/strong> na Ubuntu. To by\u0142 dok\u0142adnie ten typ problemu, kt\u00f3rego nie wida\u0107 od razu po samym ping<\/strong> ani po samym dig<\/strong>. Lokalnie wszystko wygl\u0105da\u0142o dobrze, ale ruch wychodz\u0105cy by\u0142 filtrowany.<\/p>\n\n\n\n
                    Na Ubuntu wykona\u0142em:<\/p>\n\n\n\n
                    sudo nft flush ruleset<\/code><\/pre>\n\n\n\n
                    Po tej operacji serwer slave od razu zacz\u0105\u0142 odpowiada\u0107 klientom w sieci, a nslookup<\/code> z CL2 zacz\u0105\u0142 dzia\u0142a\u0107 poprawnie.<\/p>\n\n\n\n
                    \"\"<\/figure>\n\n\n\n
                    <\/div>\n\n\n\n
                    Problem 3 \u2013 nowy rekord istnieje na masterze, ale nie ma go na slave<\/h3>\n\n\n\n
                    To jeden z tych problem\u00f3w, kt\u00f3re na pocz\u0105tku wygl\u0105daj\u0105 gro\u017anie, a w praktyce bardzo cz\u0119sto wynikaj\u0105 z jednego drobnego przeoczenia. W naszym labie sytuacja wygl\u0105da\u0142a tak: na Debianie<\/strong> jako serwerze master<\/strong> doda\u0142em nowy rekord do strefy firma.local<\/code>, ale na Ubuntu<\/strong> jako serwerze slave<\/strong> rekord wci\u0105\u017c nie by\u0142 widoczny. Na pierwszy rzut oka mo\u017cna by\u0142o pomy\u015ble\u0107, \u017ce co\u015b zepsu\u0142o si\u0119 w samym transferze strefy. W rzeczywisto\u015bci problem by\u0142 du\u017co prostszy \u2014 po edycji pliku strefy nie zosta\u0142 zwi\u0119kszony numer seryjny w rekordzie SOA<\/strong>.<\/p>\n\n\n\n
                    To bardzo wa\u017cny szczeg\u00f3\u0142, bo w\u0142a\u015bnie numer seryjny m\u00f3wi serwerowi podrz\u0119dnemu, czy na masterze pojawi\u0142a si\u0119 nowa wersja strefy. Je\u015bli serial si\u0119 nie zmienia, to z punktu widzenia slave\u2019a nic nowego si\u0119 nie wydarzy\u0142o. Nawet je\u015bli w pliku na Debianie rzeczywi\u015bcie pojawi\u0142 si\u0119 nowy rekord, Ubuntu nadal b\u0119dzie uwa\u017ca\u0142o, \u017ce ma aktualn\u0105 kopi\u0119 danych i nie b\u0119dzie mia\u0142o powodu, \u017ceby pobiera\u0107 stref\u0119 jeszcze raz.<\/p>\n\n\n\n
                    <\/div>\n\n\n\n
                    Co celowo zepsu\u0142em?<\/h4>\n\n\n\n
                    Na Debianie doda\u0142em nowy rekord do pliku strefy, na przyk\u0142ad:<\/p>\n\n\n\n
                    blog     IN      A       172.16.10.1<\/code><\/pre>\n\n\n\n
                    ale zostawi\u0142em stary numer seryjny w rekordzie SOA<\/strong>. Nast\u0119pnie zrestartowa\u0142em us\u0142ug\u0119 DNS na masterze i sprawdzi\u0142em rekord na obu serwerach.<\/p>\n\n\n\n
                    <\/div>\n\n\n\n
                    Jak wygl\u0105da\u0142 objaw?<\/h4>\n\n\n\n
                    Na masterze rekord ju\u017c dzia\u0142a\u0142:<\/p>\n\n\n\n
                    dig @172.16.10.1 www.firma.local<\/code><\/pre>\n\n\n\n
                    ale na slave nadal go nie by\u0142o:<\/p>\n\n\n\n
                    dig @172.16.20.11 www.firma.local<\/code><\/pre>\n\n\n\n
                    W praktyce bardzo cz\u0119sto taki test na Ubuntu ko\u0144czy si\u0119 odpowiedzi\u0105 NXDOMAIN<\/strong>, czyli informacj\u0105, \u017ce taka nazwa nie istnieje. I w\u0142a\u015bnie to jest moment, w kt\u00f3rym \u0142atwo b\u0142\u0119dnie za\u0142o\u017cy\u0107, \u017ce zepsu\u0142 si\u0119 transfer strefy.<\/p>\n\n\n\n
                    <\/div>\n\n\n\n
                    Jak to sprawdzi\u0107 poprawnie?<\/h4>\n\n\n\n
                    W takiej sytuacji dig<\/code> jest idealnym narz\u0119dziem diagnostycznym. Zamiast od razu szuka\u0107 problemu w logach albo restartowa\u0107 us\u0142ugi, najlepiej por\u00f3wna\u0107 rekord SOA<\/strong> na obu serwerach:<\/p>\n\n\n\n
                    dig @172.16.10.1 firma.local SOA  \ndig @172.16.20.11 firma.local SOA<\/code><\/pre>\n\n\n\n
                    Najwa\u017cniejsz\u0105 rzecz\u0105 w wyniku jest numer seryjny strefy<\/strong>. Je\u015bli Ubuntu pokazuje starszy numer ni\u017c Debian to znaczy, \u017ce serwer slave nie pobra\u0142 nowej wersji strefy<\/strong>.<\/p>\n\n\n\n
                    To bardzo wa\u017cny moment diagnostyczny, bo pokazuje, \u017ce problem nie musi le\u017ce\u0107 w samym mechanizmie transferu strefy. Czasem slave dzia\u0142a poprawnie, tylko po prostu nie dosta\u0142 sygna\u0142u, \u017ce ma pobra\u0107 nowsz\u0105 wersj\u0119 danych.<\/p>\n\n\n\n
                    <\/div>\n\n\n\n
                    Jak naprawi\u0142em problem?<\/h4>\n\n\n\n
                    Naprawa polega\u0142a na zwi\u0119kszeniu numeru seryjnego w rekordzie SOA<\/strong> na Debianie. Po zapisaniu pliku i restarcie us\u0142ugi DNS master m\u00f3g\u0142 ju\u017c poinformowa\u0107 slave\u2019a, \u017ce strefa zosta\u0142a zmieniona.<\/p>\n\n\n\n
                    Dopiero po tej zmianie Ubuntu mog\u0142o pobra\u0107 now\u0105 wersj\u0119 danych i zacz\u0105\u0107 odpowiada\u0107 z uwzgl\u0119dnieniem nowego rekordu.<\/p>\n\n\n\n
                    <\/div>\n\n\n\n
                    Jak \u0142\u0105czy\u0107 nslookup, dig i tcpdump w praktyce<\/h2>\n\n\n\n
                    \n\n\n\n
                    Po przej\u015bciu przez te trzy problemy bardzo dobrze wida\u0107, \u017ce ka\u017cde z tych narz\u0119dzi ma troch\u0119 inn\u0105 rol\u0119.<\/p>\n\n\n\n
                    nslookup<\/strong> najlepiej sprawdza si\u0119 wtedy, gdy chcesz szybko zobaczy\u0107 sytuacj\u0119 z punktu widzenia klienta. To dobre narz\u0119dzie na start, bo od razu pokazuje, czy serwer odpowiada i czy klient co\u015b dostaje.<\/p>\n\n\n\n
                    dig<\/strong> przydaje si\u0119 wtedy, gdy chcesz zrozumie\u0107 odpowied\u017a dok\u0142adniej. Dzi\u0119ki niemu mo\u017cesz ustali\u0107, czy rekord istnieje, czy odpowied\u017a pochodzi z w\u0142a\u015bciwej strefy, jaki jest status zapytania i czy slave ma ju\u017c aktualn\u0105 wersj\u0119 danych.<\/p>\n\n\n\n
                    tcpdump<\/strong> jest niezast\u0105piony wtedy, gdy trzeba rozstrzygn\u0105\u0107, czy pakiet w og\u00f3le przeszed\u0142 przez sie\u0107. To w\u0142a\u015bnie dzi\u0119ki niemu da si\u0119 stwierdzi\u0107:<\/p>\n\n\n\n
                      \n
                    • czy klient naprawd\u0119 wys\u0142a\u0142 pytanie,<\/li>\n\n\n\n
                    • czy router przekaza\u0142 ruch dalej,<\/li>\n\n\n\n
                    • czy serwer dosta\u0142 zapytanie,<\/li>\n\n\n\n
                    • i czy odpowied\u017a zosta\u0142a wys\u0142ana z powrotem.<\/li>\n<\/ul>\n\n\n\n
                      W praktyce najlepszy efekt daje w\u0142a\u015bnie po\u0142\u0105czenie tych trzech narz\u0119dzi<\/strong>. Jedno pokazuje objaw, drugie dok\u0142adnie opisuje odpowied\u017a, a trzecie udowadnia, co faktycznie wydarzy\u0142o si\u0119 na poziomie ruchu sieciowego.<\/p>\n","protected":false},"excerpt":{"rendered":"
                      Konfiguracja us\u0142ug sieciowych w Linuxie to dopiero po\u0142owa pracy. Sama wiedza o tym, jak ustawi\u0107 adres IP, routing czy serwer DNS,…<\/p>\n","protected":false},"author":3,"featured_media":1480,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_lmt_disableupdate":"","_lmt_disable":"","footnotes":""},"categories":[26],"tags":[32,34],"class_list":["post-1479","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-linux","tag-linux","tag-sieci"],"yoast_head":"\nDiagnostyka sieci i DNS w Linuxie \u2013 nslookup, dig i tcpdump w praktyce - SudoIT<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/sudoit.pl\/index.php\/2026\/05\/05\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\/\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"Diagnostyka sieci i DNS w Linuxie \u2013 nslookup, dig i tcpdump w praktyce - SudoIT\" \/>\n<meta property=\"og:description\" content=\"Konfiguracja us\u0142ug sieciowych w Linuxie to dopiero po\u0142owa pracy. Sama wiedza o tym, jak ustawi\u0107 adres IP, routing czy serwer DNS,…\" \/>\n<meta property=\"og:url\" content=\"https:\/\/sudoit.pl\/index.php\/2026\/05\/05\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\/\" \/>\n<meta property=\"og:site_name\" content=\"SudoIT\" \/>\n<meta property=\"article:published_time\" content=\"2026-05-05T07:32:31+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2026-05-05T07:32:33+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/sudoit.pl\/wp-content\/uploads\/2026\/05\/Diagnostyka_sieci_DNS-1024x683.png\" \/>\n\t<meta property=\"og:image:width\" content=\"1024\" \/>\n\t<meta property=\"og:image:height\" content=\"683\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"Patryk\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"Patryk\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"13 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/sudoit.pl\\\/index.php\\\/2026\\\/05\\\/05\\\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/sudoit.pl\\\/index.php\\\/2026\\\/05\\\/05\\\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\\\/\"},\"author\":{\"name\":\"Patryk\",\"@id\":\"https:\\\/\\\/sudoit.pl\\\/#\\\/schema\\\/person\\\/62b95033a7a8937fbb692e81d5e0b8bd\"},\"headline\":\"Diagnostyka sieci i DNS w Linuxie \u2013 nslookup, dig i tcpdump w praktyce\",\"datePublished\":\"2026-05-05T07:32:31+00:00\",\"dateModified\":\"2026-05-05T07:32:33+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/sudoit.pl\\\/index.php\\\/2026\\\/05\\\/05\\\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\\\/\"},\"wordCount\":2538,\"commentCount\":0,\"image\":{\"@id\":\"https:\\\/\\\/sudoit.pl\\\/index.php\\\/2026\\\/05\\\/05\\\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/sudoit.pl\\\/wp-content\\\/uploads\\\/2026\\\/05\\\/Diagnostyka_sieci_DNS.png\",\"keywords\":[\"linux\",\"sieci\"],\"articleSection\":[\"Linux\"],\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"CommentAction\",\"name\":\"Comment\",\"target\":[\"https:\\\/\\\/sudoit.pl\\\/index.php\\\/2026\\\/05\\\/05\\\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\\\/#respond\"]}]},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/sudoit.pl\\\/index.php\\\/2026\\\/05\\\/05\\\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\\\/\",\"url\":\"https:\\\/\\\/sudoit.pl\\\/index.php\\\/2026\\\/05\\\/05\\\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\\\/\",\"name\":\"Diagnostyka sieci i DNS w Linuxie \u2013 nslookup, dig i tcpdump w praktyce - SudoIT\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/sudoit.pl\\\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\\\/\\\/sudoit.pl\\\/index.php\\\/2026\\\/05\\\/05\\\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\\\/#primaryimage\"},\"image\":{\"@id\":\"https:\\\/\\\/sudoit.pl\\\/index.php\\\/2026\\\/05\\\/05\\\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\\\/#primaryimage\"},\"thumbnailUrl\":\"https:\\\/\\\/sudoit.pl\\\/wp-content\\\/uploads\\\/2026\\\/05\\\/Diagnostyka_sieci_DNS.png\",\"datePublished\":\"2026-05-05T07:32:31+00:00\",\"dateModified\":\"2026-05-05T07:32:33+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/sudoit.pl\\\/#\\\/schema\\\/person\\\/62b95033a7a8937fbb692e81d5e0b8bd\"},\"breadcrumb\":{\"@id\":\"https:\\\/\\\/sudoit.pl\\\/index.php\\\/2026\\\/05\\\/05\\\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\\\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/sudoit.pl\\\/index.php\\\/2026\\\/05\\\/05\\\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\\\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/sudoit.pl\\\/index.php\\\/2026\\\/05\\\/05\\\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\\\/#primaryimage\",\"url\":\"https:\\\/\\\/sudoit.pl\\\/wp-content\\\/uploads\\\/2026\\\/05\\\/Diagnostyka_sieci_DNS.png\",\"contentUrl\":\"https:\\\/\\\/sudoit.pl\\\/wp-content\\\/uploads\\\/2026\\\/05\\\/Diagnostyka_sieci_DNS.png\",\"width\":1536,\"height\":1024},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/sudoit.pl\\\/index.php\\\/2026\\\/05\\\/05\\\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Home\",\"item\":\"https:\\\/\\\/sudoit.pl\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Diagnostyka sieci i DNS w Linuxie \u2013 nslookup, dig i tcpdump w praktyce\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/sudoit.pl\\\/#website\",\"url\":\"https:\\\/\\\/sudoit.pl\\\/\",\"name\":\"SudoIT\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/sudoit.pl\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/sudoit.pl\\\/#\\\/schema\\\/person\\\/62b95033a7a8937fbb692e81d5e0b8bd\",\"name\":\"Patryk\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/d933a3eef1e4f0026a85747cca61f1ae9043bf2753554c0427f1a2dc8ca46096?s=96&d=mm&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/d933a3eef1e4f0026a85747cca61f1ae9043bf2753554c0427f1a2dc8ca46096?s=96&d=mm&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/d933a3eef1e4f0026a85747cca61f1ae9043bf2753554c0427f1a2dc8ca46096?s=96&d=mm&r=g\",\"caption\":\"Patryk\"},\"url\":\"https:\\\/\\\/sudoit.pl\\\/index.php\\\/author\\\/patryk\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"Diagnostyka sieci i DNS w Linuxie \u2013 nslookup, dig i tcpdump w praktyce - SudoIT","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/sudoit.pl\/index.php\/2026\/05\/05\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\/","og_locale":"en_US","og_type":"article","og_title":"Diagnostyka sieci i DNS w Linuxie \u2013 nslookup, dig i tcpdump w praktyce - SudoIT","og_description":"Konfiguracja us\u0142ug sieciowych w Linuxie to dopiero po\u0142owa pracy. Sama wiedza o tym, jak ustawi\u0107 adres IP, routing czy serwer DNS,…","og_url":"https:\/\/sudoit.pl\/index.php\/2026\/05\/05\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\/","og_site_name":"SudoIT","article_published_time":"2026-05-05T07:32:31+00:00","article_modified_time":"2026-05-05T07:32:33+00:00","og_image":[{"width":1024,"height":683,"url":"https:\/\/sudoit.pl\/wp-content\/uploads\/2026\/05\/Diagnostyka_sieci_DNS-1024x683.png","type":"image\/png"}],"author":"Patryk","twitter_card":"summary_large_image","twitter_misc":{"Written by":"Patryk","Est. reading time":"13 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/sudoit.pl\/index.php\/2026\/05\/05\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\/#article","isPartOf":{"@id":"https:\/\/sudoit.pl\/index.php\/2026\/05\/05\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\/"},"author":{"name":"Patryk","@id":"https:\/\/sudoit.pl\/#\/schema\/person\/62b95033a7a8937fbb692e81d5e0b8bd"},"headline":"Diagnostyka sieci i DNS w Linuxie \u2013 nslookup, dig i tcpdump w praktyce","datePublished":"2026-05-05T07:32:31+00:00","dateModified":"2026-05-05T07:32:33+00:00","mainEntityOfPage":{"@id":"https:\/\/sudoit.pl\/index.php\/2026\/05\/05\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\/"},"wordCount":2538,"commentCount":0,"image":{"@id":"https:\/\/sudoit.pl\/index.php\/2026\/05\/05\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\/#primaryimage"},"thumbnailUrl":"https:\/\/sudoit.pl\/wp-content\/uploads\/2026\/05\/Diagnostyka_sieci_DNS.png","keywords":["linux","sieci"],"articleSection":["Linux"],"inLanguage":"en-US","potentialAction":[{"@type":"CommentAction","name":"Comment","target":["https:\/\/sudoit.pl\/index.php\/2026\/05\/05\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\/#respond"]}]},{"@type":"WebPage","@id":"https:\/\/sudoit.pl\/index.php\/2026\/05\/05\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\/","url":"https:\/\/sudoit.pl\/index.php\/2026\/05\/05\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\/","name":"Diagnostyka sieci i DNS w Linuxie \u2013 nslookup, dig i tcpdump w praktyce - SudoIT","isPartOf":{"@id":"https:\/\/sudoit.pl\/#website"},"primaryImageOfPage":{"@id":"https:\/\/sudoit.pl\/index.php\/2026\/05\/05\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\/#primaryimage"},"image":{"@id":"https:\/\/sudoit.pl\/index.php\/2026\/05\/05\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\/#primaryimage"},"thumbnailUrl":"https:\/\/sudoit.pl\/wp-content\/uploads\/2026\/05\/Diagnostyka_sieci_DNS.png","datePublished":"2026-05-05T07:32:31+00:00","dateModified":"2026-05-05T07:32:33+00:00","author":{"@id":"https:\/\/sudoit.pl\/#\/schema\/person\/62b95033a7a8937fbb692e81d5e0b8bd"},"breadcrumb":{"@id":"https:\/\/sudoit.pl\/index.php\/2026\/05\/05\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/sudoit.pl\/index.php\/2026\/05\/05\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/sudoit.pl\/index.php\/2026\/05\/05\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\/#primaryimage","url":"https:\/\/sudoit.pl\/wp-content\/uploads\/2026\/05\/Diagnostyka_sieci_DNS.png","contentUrl":"https:\/\/sudoit.pl\/wp-content\/uploads\/2026\/05\/Diagnostyka_sieci_DNS.png","width":1536,"height":1024},{"@type":"BreadcrumbList","@id":"https:\/\/sudoit.pl\/index.php\/2026\/05\/05\/diagnostyka-sieci-i-dns-w-linuxie-nslookup-dig-i-tcpdump-w-praktyce\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https:\/\/sudoit.pl\/"},{"@type":"ListItem","position":2,"name":"Diagnostyka sieci i DNS w Linuxie \u2013 nslookup, dig i tcpdump w praktyce"}]},{"@type":"WebSite","@id":"https:\/\/sudoit.pl\/#website","url":"https:\/\/sudoit.pl\/","name":"SudoIT","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/sudoit.pl\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Person","@id":"https:\/\/sudoit.pl\/#\/schema\/person\/62b95033a7a8937fbb692e81d5e0b8bd","name":"Patryk","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/secure.gravatar.com\/avatar\/d933a3eef1e4f0026a85747cca61f1ae9043bf2753554c0427f1a2dc8ca46096?s=96&d=mm&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/d933a3eef1e4f0026a85747cca61f1ae9043bf2753554c0427f1a2dc8ca46096?s=96&d=mm&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/d933a3eef1e4f0026a85747cca61f1ae9043bf2753554c0427f1a2dc8ca46096?s=96&d=mm&r=g","caption":"Patryk"},"url":"https:\/\/sudoit.pl\/index.php\/author\/patryk\/"}]}},"_links":{"self":[{"href":"https:\/\/sudoit.pl\/index.php\/wp-json\/wp\/v2\/posts\/1479","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/sudoit.pl\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/sudoit.pl\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/sudoit.pl\/index.php\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/sudoit.pl\/index.php\/wp-json\/wp\/v2\/comments?post=1479"}],"version-history":[{"count":1,"href":"https:\/\/sudoit.pl\/index.php\/wp-json\/wp\/v2\/posts\/1479\/revisions"}],"predecessor-version":[{"id":1495,"href":"https:\/\/sudoit.pl\/index.php\/wp-json\/wp\/v2\/posts\/1479\/revisions\/1495"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/sudoit.pl\/index.php\/wp-json\/wp\/v2\/media\/1480"}],"wp:attachment":[{"href":"https:\/\/sudoit.pl\/index.php\/wp-json\/wp\/v2\/media?parent=1479"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/sudoit.pl\/index.php\/wp-json\/wp\/v2\/categories?post=1479"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/sudoit.pl\/index.php\/wp-json\/wp\/v2\/tags?post=1479"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}