root@echelon:~# cat /var/log/cli-essentials/dns.md
// TUTORIAL

[*] cli-essentials #3 – DNS

23.05.2026 | autor: Kamil Górczyński czas czytania: 15 min

W kolejnym, trzecim już artykule z serii cli-essentials postaram się wyjaśnić jak działa DNS i dlaczego jest to ważne miejsce z perspektywy osoby zajmującej się cyberbezpieczeństwem.

DNS (Domain Name System) to rozproszony, hierarchiczny system tłumaczący nazwy domenowe (np. echelonwatch.pl) na adresy IP (104.21.10.42). Jest to fundament internetu, ponieważ bez DNS musiałbyś znać adres IP każdej strony, którą odwiedzasz.

Z perspektywy cyberbezpieczeństwa jest to pierwsze miejsce, gdzie widać atak. Każdy malware musi gdzieś zadzwonić, eksfiltracja danych musi mieć swój cel, a kampania phishingowa swoją domenę. W DNS możemy to wszystko zobaczyć.

HIERARCHIA DNS

System DNS zorganizowany jest jako odwrócone drzewo. Na samej górze znajduje się root (oznaczany pojedynczą kropką), poniżej TLD (Top-Level Domains – .com, .pl, .org), a jeszcze niżej domeny drugiego poziomu i subdomeny.

. root .com .pl .org .arpa TLD google.com echelonwatch.pl in-addr.arpa domain www.echelonwatch.pl subdomain

Kluczowe pojęcia

  • FQDN (Fully Qualified Domain Name) – pełna nazwa domeny z kropką na końcu: www.echelonwatch.pl.
  • Zone – strefa DNS, czyli fragment przestrzeni nazw zarządzanych przez konkretny authoritative server
  • Delegation – przekazanie odpowiedzialności za subdomenę innemu serwerowi (rekord NS)
  • Label – pojedynczy element nazwy oddzielony kropką (www, echelonwatch, pl). Max 63 znaki na label, max 255 znaków na całą nazwę.

Typy serwerów DNS

TYP
ROLA
Stub resolver
Mała biblioteka w systemie operacyjnym (np. systemd-resolved, getaddrinfo). Nie chodzi po hierarchii – pyta jeden recursive resolver wpisany w katalogu (/etc/resolv.conf).
Recursive resolver
Ten serwer przechodzi przez hierarchię root → TLD → authoritative. Np. 8.8.8.8, 1.1.1.1, resolver providera. Cachuje odpowiedzi.
Root server
Wskazuje, gdzie szukać TLD (.com, .pl, .org).
TLD server
Wskazuje authoritative NS dla domeny w danym TLD.
Authoritative server
Zna prawdziwą odpowiedź dla swojej strefy. To tu są trzymane rekordy. Ustawia flagę aa=1 w odpowiedzi.
Forwarder
Przekazuje zapytanie do innego resolvera.

JAK DZIAŁA ROZWIĄZYWANIE NAZW (REKURENCJA)

Krok po kroku postaram się przybliżyć, co się dzieje, gdy wpisujesz w przeglądarce np. echelonwatch.pl lub google.com.

  1. Przeglądarka pyta stub resolver w systemie operacyjnym
  2. Stub pyta recursive resolver (np. 8.8.8.8)
  3. Recursive sprawdza cache – jeżeli wpis widnieje, odpowiada od razu i operacja zakończona
  4. Jeżeli nie ma w cache:
    1. Pyta root server: "kto wie o .pl?"
    2. Root odpowiada: "spytaj .pl TLD serwer pod adresem X"
    3. Recursive pyta TLD: "kto wie o echelonwatch.pl?"
    4. TLD odpowiada: "spytaj authoritative NS pod adresem Y"
    5. Recursive pyta authoritative NS: "jakie A dla echelonwatch.pl?"
    6. Authoritative odpowiada 104.21.x.x z flagą aa=1
  5. Recursive cache'uje wynik na czas TTL i zwraca do stuba
CLIENT stub resolver RECURSIVE RESOLVER 8.8.8.8 / 1.1.1.1 / cache ROOT a-m.root-servers.net TLD (.pl) a-dns.pl ... j-dns.pl AUTHORITATIVE harvey.ns.cloudflare.com 1. query 8. answer 2. .pl? 3. ask TLD 4. echelonwatch.pl? 5. ask authoritative 6. A record? 7. 104.21.10.42 (aa=1) zapytanie (query) odpowiedź (answer) cache hit = pomijamy kroki 2-7

FORMAT ZAPYTAŃ DNS

Standardowy port używany przez DNS to UDP 53. TCP port 53 jako fallback, gdy:

  • Serwer zmieni flagę na TC (truncated) w odpowiedzi UDP – znak, że odpowiedź się nie zmieściła. Klient ponawia wtedy w TCP
  • Zone transfer (AXFR, IXFR)
  • DoT (DNS over TLS) – TCP port 853

Limit rozmiaru

  • RFC 1035 (1987): max 512B na odpowiedź UDP
  • EDNS0 (RFC 6891): klient i serwer mogą negocjować większy bufor, typowo do 4096B
  • DNS Flag Day 2020: rekomendacja 1232B, aby uniknąć fragmentacji IP, która powoduje gubienie pakietów

W praktyce oznacza to, że po UDP zwykle przechodzi <1232B, a więcej to fallback do TCP.

Struktura pakietu DNS

HEADER ID | flagi: QR OPCODE AA TC RD RA AD CD | liczniki sekcji QUESTION nazwa | typ | klasa ANSWER rekord odpowiedzi (A, AAAA, MX, TXT, ...) AUTHORITY authoritative NS dla strefy ADDITIONAL dodatkowe info (glue records, OPT pseudo-record EDNS)

TYPY REKORDÓW DNS

TYP
CEL
PRZYKŁAD
A
Mapowanie nazwa → IPv4
echelonwatch.pl. 300 IN A 104.21.10.20
AAAA
Mapowanie nazwa → IPv6
echelonwatch.pl. 300 IN AAAA 2606:4700::1
CNAME
Alias jednej nazwy na drugą
www.echelonwatch.pl. IN CNAME echelonwatch.pl.
MX
Serwer pocztowy domeny
echelonwatch.pl. IN MX 10 mx1.webh.email.
NS
Authoritative nameserver
echelonwatch.pl. IN NS hattie.ns.cloudflare.com.
SOA
Start of authority – metadane strefy
(patrz niżej)
TXT
Dowolny tekst – SPF, DKIM, DMARC
v=spf1 include:_spf.google.com ~all
HTTPS / SVCB
Service binding (RFC 9460) – metadane usługi: porty, ALPN, ECH
example.com. HTTPS 1 . alpn="h2,h3" ipv4hint=...

Nie są to wszystkie rekordy, ale wg mnie najważniejsze, z czego warto zwrócić w szczególności uwagę na HTTPS/SVCB. Jest to nowy typ (od 2023r.) używany przez Apple, Cloudflare i Chrome. Zawiera info o ALPN (h2/h3), portach, IP, a także Encrypted Client Hello (ECH) – mechanizm szyfrowania SNI.

Rekord SOA – wyjaśnienie

SOA jest unikalny – zawsze jeden na strefę i zawiera metadane:

echelonwatch.pl. 1800 IN SOA harvey.ns.cloudflare.com. dns.cloudflare.com. 2405020032 10000 2400 604800 1800

Rozbity na elementy z komentarzami:

echelonwatch.pl. 3600 IN SOA ns1.cloudflare.com. dns.cloudflare.com. ( 2405020032 ; serial (zwykle YYYYMMDDNN) 10000 ; refresh – co ile slave odświeża 2400 ; retry – co ile próbuje przy błędzie 604800 ; expire – po jakim czasie slave porzuca strefę 1800 ; minimum TTL (negative caching) )

TTL – Time To Live

Każdy rekord ma TTL w sekundach. Niski TTL (np. 60s) = częste odświeżanie. W kontekście cyber bardzo niski TTL (< 300s) na świeżo zarejestrowanej domenie może świadczyć o fast-flux DNS lub C2.

CLI – NARZĘDZIE DIG

Przejdźmy do praktyki i zacznijmy korzystać z jednego ze standardowych narzędzi do pracy z DNS z poziomu CLI – dig (Domain Information Groper).

Składnia podstawowa

dig [@resolver] [name] [type] [options]

Najważniejsze przykłady i odpowiedzi

dig echelonwatch.pl

Odpowiedź:

; <<>> DiG 9.20.15-1-Debian <<>> echelonwatch.pl ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 64141 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;echelonwatch.pl. IN A ;; ANSWER SECTION: echelonwatch.pl. 300 IN A 104.21.10.42 echelonwatch.pl. 300 IN A 172.67.189.234 ;; Query time: 28 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP) ;; WHEN: Sat May 23 21:32:28 CEST 2026 ;; MSG SIZE rcvd: 76

Konkretny typ rekordu:

dig echelonwatch.pl MX dig echelonwatch.pl TXT dig echelonwatch.pl NS

Odpowiedź dla MX:

; <<>> DiG 9.20.15-1-Debian <<>> echelonwatch.pl MX ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55019 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;echelonwatch.pl. IN MX ;; ANSWER SECTION: echelonwatch.pl. 300 IN MX 20 mx2.webh.email. echelonwatch.pl. 300 IN MX 30 mx3.webh.email. echelonwatch.pl. 300 IN MX 10 mx1.webh.email. ;; Query time: 24 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP) ;; WHEN: Sat May 23 21:34:00 CEST 2026 ;; MSG SIZE rcvd: 114

Użycie konkretnego resolvera:

dig @8.8.8.8 echelonwatch.pl dig @1.1.1.1 echelonwatch.pl

Odpowiedzi bez nagłówków:

dig +short echelonwatch.pl

Odpowiedź:

172.67.189.234 104.21.10.42

Cała odpowiedź, ale w bardziej przystępny sposób:

dig +noall +answer echelonwatch.pl

Odpowiedź:

echelonwatch.pl. 300 IN A 104.21.10.42 echelonwatch.pl. 300 IN A 172.67.189.234

Cała ścieżka delegacji od root:

dig +trace echelonwatch.pl

Odpowiedź:

; <<>> DiG 9.20.15-1-Debian <<>> +trace echelonwatch.pl ;; global options: +cmd . 87203 IN NS b.root-servers.net. . 87203 IN NS a.root-servers.net. . 87203 IN NS h.root-servers.net. . 87203 IN NS i.root-servers.net. . 87203 IN NS f.root-servers.net. . 87203 IN NS d.root-servers.net. . 87203 IN NS e.root-servers.net. . 87203 IN NS k.root-servers.net. . 87203 IN NS g.root-servers.net. . 87203 IN NS c.root-servers.net. . 87203 IN NS m.root-servers.net. . 87203 IN NS j.root-servers.net. . 87203 IN NS l.root-servers.net. . 87203 IN RRSIG NS 8 0 518400 20260605170000 20260523160000 54393 . gbF8btWR9blSMj4RByd+knNYwo6eWhnlcKG16aotfA3Xvwukju2Mggw6 Diq3tV4KSMp11piNw2xFqKAquFAq+Rtd5YG0a4nmYrY26BW71/fk2cBI jgEPA06LK8AMHhCxrcP7OV+TaKpA86PQWcZ9TNjgp6Rs2FrQBLK45Pt1 fjq/ya5elaWr9K3D9A44K29RhFEp8cUpnivSa+X1k9tZmM0DM4cTc91T jOSEwOQQXPCp/MjFsLLAJDD2fDn6Cdes2hLiHk/DV8RtrmJMwNzpJwXq 4gD6y2I4r2rYw0PZ7i1f0ZzI8K3wVCyrXPyZyejCdh2vmLbWXP0B7fh/ Zr9dFw== ;; Received 525 bytes from 8.8.8.8#53(8.8.8.8) in 20 ms pl. 172800 IN NS a-dns.pl. pl. 172800 IN NS b-dns.pl. pl. 172800 IN NS d-dns.pl. pl. 172800 IN NS f-dns.pl. pl. 172800 IN NS h-dns.pl. pl. 172800 IN NS j-dns.pl. pl. 86400 IN DS 2782 8 2 C1FE7378DEB55944721A1A329F789FA7BA03180CEF530AD440E7D03A 777B5116 pl. 86400 IN RRSIG DS 8 1 86400 20260605170000 20260523160000 54393 . RU7RcHG/fs7RasiOUxpX4SnaKxhxoUjfWCX/iqfvHgIjtnvAAmeJ9FTu jp6nREbeEOZLfsqA7E1p4CdxqridkH4EwZ2xyKPGpTbkArMptRw6w8Tm k8pKDwAP5gsktx8H9DlHrWMfq5wAkACEHhfp30GWbVYTMQVBgTtm92zo +NYh1Zv0ghtdX8AN3QNEPjL8/XZyh60OiNMtMavwnbVSIGWfOVuY1khc l+ODlZtTM2EZnYjzR9lxTmzJ8eS0PbSpI/vusR2e54i/c5v5UCeQq5xv 19or1g2RJa12t3Gxf93ozZEBWbWlUoYaesOyqTokvJ0hlFOABOAqSo79 mPkYBA== ;; Received 763 bytes from 192.203.230.10#53(e.root-servers.net) in 24 ms echelonwatch.pl. 86400 IN NS hattie.ns.cloudflare.com. echelonwatch.pl. 86400 IN NS harvey.ns.cloudflare.com. HEC4DTFKFRCH7PTMK61VG096VN0PBHC3.pl. 3600 IN NSEC3 1 1 0 134BB5DDB8EA4BDB HEC51V5HEEVSUMDB1TGKHK9MDIDOBL59 NS SOA TXT RRSIG DNSKEY NSEC3PARAM HEC4DTFKFRCH7PTMK61VG096VN0PBHC3.pl. 3600 IN RRSIG NSEC3 8 2 3600 20260616120000 20260517120000 15186 pl. aKP0I34acZd49XjTdoksi4kJoaUZeAUgQRTKgZUChtc9nV3uQDoozYef b/ciPPnCH77U6wWaBlJmhfPdBjsgSs33XCBvTv4d6Gb8B+0o5ox6ykw6 m5hnXhfH9iqT9eNgcRU+PFUjmkDanW+Lx2cnc72Ti0icTXwW7aHRnHQR FS23cZC/EBaP0w39ZcfCCDrIjrILxaIPv1X89b1uACbpSObRjV7FAyNj oyvpsJMAyMh10i8HyQ8BNpIORfSEhB36vNRpjFz7A1k4CZ4reJOm8ZmI Ks4ZHjE9aNlicX9ZQrDrkIyYDOOCNtG7GmYpvVrvrlHRFYXjMUNv4p5G mJTD/A== R2L9NC212K487FD1SM7M0HHV6CTDJCJS.pl. 3600 IN NSEC3 1 1 0 134BB5DDB8EA4BDB R2LI2VDC2ED7E0ENJ0GQOO5ND25TMTHV NS DS RRSIG R2L9NC212K487FD1SM7M0HHV6CTDJCJS.pl. 3600 IN RRSIG NSEC3 8 2 3600 20260616120000 20260517120000 15186 pl. Gq5H9IOdb1NjsJZXrfDDtITPSXM1l2luK4mmpfdhJKeSLdiXh2PtJgRE VHAmUDHMyK+L31VzIdO5nTLlOuVfkqrjdJyo9+vNF+CA6wsv5Chll51y ReyIhOHSJSjUfPDvxZyUdmSt971TuQciYZqY1f36yy+Mau10JIRidVHa rLCcfyyIiI/UjQPnxec2pONmzt7W/tulT5xBQKQ79InRB5dU3ZgkhLy3 4LCyZz6GonO/MckJjz5aeD9QrJTk3pJn6Pg9zkfT9kNDi0jWI+QRCbyj G++x7A0q10IbFx5H9OLcI4WYvho6lTtskCSTL1/to8MblmtjIZSVoxih Kv6pKg== ;; Received 886 bytes from 204.61.217.4#53(j-dns.pl) in 36 ms echelonwatch.pl. 300 IN A 104.21.10.42 echelonwatch.pl. 300 IN A 172.67.189.234 echelonwatch.pl. 300 IN RRSIG A 13 2 300 20260524203740 20260522183740 34505 echelonwatch.pl. Kpyb2A/yi5UmuABddTuVEa8r4SN1FECx6Tk/V1mmU8TAoCdRdaQufZRB 06WvCAyX2bZpwRlpH9sBWtuRaZx2tQ== ;; Received 187 bytes from 162.159.44.152#53(harvey.ns.cloudflare.com) in 36 ms

Nad tym przykładem możemy się zatrzymać, aby omówić go szczegółowo.

Krok 1: Pytanie root server o .pl

. 87203 IN NS c.root-servers.net. . 87203 IN NS l.root-servers.net. ... (13 root serverów: a-m.root-servers.net) . 87203 IN RRSIG NS 8 0 518400 ... ;; Received 525 bytes from 8.8.8.8#53(8.8.8.8) in 24 ms
  • dig zapytał lokalny resolver (8.8.8.8) o listę root serverów – punkt startowy każdej rekurencji
  • Dostał 13 wpisów NS
  • 87203 to TTL – ile sekund ten wpis żyje w cache
  • 525 bytes – odpowiedź zmieściła się w UDP (pamiętamy limit UDP do 1232B)

Krok 2: Próby IPv6

;; UDP setup with 2001:500:9f::42#53(2001:500:9f::42) for echelonwatch.pl failed: network unreachable. ;; no servers could be reached

Nie jest to błąd, dig próbował połączyć się z root serverem przez IPv6, a obecnie korzystam z IPv4.

Krok 3: Pytanie o konkretny root server .pl

pl. 172800 IN NS d-dns.pl. pl. 172800 IN NS f-dns.pl. pl. 172800 IN NS a-dns.pl. pl. 172800 IN NS j-dns.pl. pl. 172800 IN NS h-dns.pl. pl. 172800 IN NS b-dns.pl. pl. 86400 IN DS 2782 8 2 C1FE7378... pl. 86400 IN RRSIG DS 8 1 86400 ... ;; Received 791 bytes from 192.33.4.12#53(c.root-servers.net) in 28 ms
  • dig wybrał sobie jeden z root serverów (c.root-servers.net = 192.33.4.12) i go zapytał: "kto wie o .pl?"
  • Root odpowiedział: NASK (Polish TLD) trzyma rekordy .pl na serwerach a-dns.pl, b-dns.pl, d-dns.pl, f-dns.pl, h-dns.pl, j-dns.pl

Krok 4: Pytanie .pl o echelonwatch.pl

echelonwatch.pl. 86400 IN NS harvey.ns.cloudflare.com. echelonwatch.pl. 86400 IN NS hattie.ns.cloudflare.com. hec4dtfkfrch7ptmk61vg096vn0pbhc3.pl. 3600 IN NSEC3 1 1 0 134BB5DDB8EA4BDB ... r2l9nc212k487fd1sm7m0hhv6ctdjcjs.pl. 3600 IN NSEC3 1 1 0 134BB5DDB8EA4BDB ... ;; Received 858 bytes from 185.159.198.48#53(h-dns.pl) in 32 ms
  • dig zapytał h-dns.pl (jeden z TLD serverów): "kto jest authoritative dla echelonwatch.pl?"
  • Odpowiedź: harvey.ns.cloudflare.com i hattie.ns.cloudflare.com

Krok 5: Pytanie authoritative NS o A record

echelonwatch.pl. 300 IN A 104.21.10.42 echelonwatch.pl. 300 IN A 172.67.189.234 echelonwatch.pl. 300 IN RRSIG A 13 2 300 20260524190208 20260522170208 34505 echelonwatch.pl. ni1j7ZyoGbNqSP331EEbYYeMOmezv76nfyXO3DAwMcohw4dPDGv7NRUu pSauMAImdACFUA34ncY6BXrrnZqcaQ== ;; Received 187 bytes from 162.159.44.152#53(harvey.ns.cloudflare.com) in 32 ms
  • dig zapytał harvey.ns.cloudflare.com (Twój authoritative NS): "jakie A dla echelonwatch.pl?"
  • Odpowiedź: dwa IP Cloudflare – 104.21.10.42 i 172.67.189.234. Cloudflare zawsze daje dwa IP dla redundancy (jeden z 104.21.0.0/16, drugi z 172.67.0.0/16)

Podsumowując:

  • Rozwiązywanie nazw jest szybkie (24ms → 28ms → 32ms → 32ms = ~116ms total)
  • Cloudflare zwraca dwa IP dla redundancy
  • TTL 300s = krótkie odświeżanie, ale to standard Cloudflare

Kolejne zapytanie – wszystkie typowe rekordy:

dig echelonwatch.pl ANY

Sekcje output dig

  • ;; ->>HEADER<<- – flagi i status (status: NOERROR, flags: qr rd ra ad)
  • ;; QUESTION SECTION – co pytasz
  • ;; ANSWER SECTION – co dostałeś
  • ;; AUTHORITY SECTION – kto jest authoritative
  • ;; ADDITIONAL SECTION – dodatkowe rekordy (np. glue, OPT EDNS)
  • ;; Query time – ile zajęło
  • ;; SERVER – kogo pytałeś

CHEATSHEET DIG

Prosty zestaw komend, który warto mieć pod ręką.

Czy serwer jest authoritative dla domeny?

dig @harvey.ns.cloudflare.com echelonwatch.pl SOA +short

Sprawdzenie SPF:

dig +short TXT echelonwatch.pl | grep spf1

Wszystkie A rekordy dla domeny od kilku resolverów (porównanie):

for r in 8.8.8.8 1.1.1.1 9.9.9.9; do echo "=== $r ==="; dig @$r +short echelonwatch.pl; done

DNS W ATAKACH

DNS Tunneling

Jak działa: atakujący koduje dane w polach DNS, np. za pomocą Base64 (głównie w rekordach TXT) i eksfiltruje poprzez DNS, ponieważ port 53 praktycznie zawsze przechodzi przez firewall.

Przykład takiej eksfiltracji:

dGhpcy1pcy1leGZpbHRyYXRlZC1kYXRh.attacker.com ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Base64 ze skradzionych danych jako subdomena

Każde zapytanie do *.attacker.com trafia do authoritative NS atakującego, który dekoduje subdomeny i składa dane.

INFECTED HOST malware + skradzione dane FIREWALL port 53 = ALLOW RECURSIVE DNS 8.8.8.8 / 1.1.1.1 ATTACKER NS attacker.com QUERY: dGhpcy1pcy1leGZpbHRyYXRlZC1kYXRh.attacker.com ↑ Base64-encoded data (subdomain) → attacker dekoduje subdomenę i odzyskuje skradzione dane

Jak można to wykryć?

  • Długie subdomeny (> 50 znaków, często blisko 63)
  • Wysoka entropia w nazwach (Base64/hex look-alike)
  • Dużo zapytań TXT z jednego hosta
  • Wiele różnych unikalnych subdomen pod tą samą domeną z jednego klienta

DGA – Domain Generation Algorithm

Polega na generowaniu setek/tysięcy domen dziennie poprzez wykorzystanie algorytmu (najczęściej seed = data + sekret). Atakujący rejestruje jedną z nich – malware ją "znajdzie" próbując rozwiązać kolejne.

Przykładowe DGA:

xj4n9p2k7q3r5t6y.com b8h2d6f9k3m7n1p4.com qrstuvwxyzabcdefg.net
  • Wysoka entropia (losowe ciągi liter/cyfr)
  • Brak czytelnych słów
  • Zwykle krótkie TLD-y (.xyz, .top, .icu, .biz) – tanie do rejestracji
  • Duża liczba NXDOMAIN – większość wygenerowanych domen nie istnieje
  • Krótki czas życia (zwykle 24-48h)

Fast-Flux DNS

Technika polegająca na bardzo szybkiej zmianie A rekordów dla domeny C2. Czyli ten sam FQDN dziś wskazuje inny IP niż godzinę temu + bardzo niski TTL (60–300s).

  • Single-flux – zmienia się tylko IP authoritative
  • Double-flux – zmieniają się też NS
  • Detection: TTL < 300s + częsta zmiana A rekordów + IP z różnych ASN/krajów
c2.malicious.xyz TTL: 60s 12:00 → 5.45.x.x (RU) 12:01 → 91.218.x.x (CN) 12:02 → 185.62.x.x (NL) 12:03 → 103.91.x.x (BR) DETECTION SIGNALS: ▸ TTL < 300s ▸ częsta zmiana A rekordów ▸ IP z różnych ASN/krajów ▸ świeżo zarejestrowana domena ▸ podejrzany TLD (.xyz, .top)

DNS Hijacking / Cache Poisoning

Cache poisoning – wstrzyknięcie fałszywych odpowiedzi do cache resolvera (atak Kaminsky'ego z 2008). DNSSEC powstał właśnie po to.

DNS hijacking – przejęcie domeny u rejestratora albo przekierowanie ruchu (np. przez modyfikację rekordów na NS). Spektakularne przypadki: Sea Turtle, DNSpionage.

Na tym zakończę dzisiejszy artykuł. Mam nadzieję, że udało mi się przybliżyć, jak działa DNS i na jakie ataki jest narażony.

DNS dig CLI Blue Team SOC cli-essentials
« POWRÓT DO LISTY ARTYKUŁÓW
▲

system@echelon:~# cat /etc/privacy_notice.txt

Ta strona używa Google Analytics do zbierania anonimowych informacji o ruchu na stronie. Kontynuując korzystanie z tej strony, wyrażasz zgodę na używanie plików cookie zgodnie z naszą Polityką Prywatności.