DNS w sieci lokalnej: split horizon, rekordy i ochrona przed spoofingiem

Rola DNS w sieci lokalnej i typowe scenariusze użycia

DNS jako „książka telefoniczna” sieci LAN

DNS w sieci lokalnej pełni tę samą funkcję, co w Internecie: tłumaczy nazwy na adresy IP. Różnica polega na tym, że w LAN chodzi o hosty wewnętrzne: serwery plików, drukarki, kontrolery domeny, systemy ERP, kamery IP, a nie tylko strony WWW.

Bez sprawnego DNS użytkownicy wpisują adresy IP ręcznie, skrypty się sypią, a usługi „znikają”. W środowisku firmowym każdy błąd w DNS szybko przekłada się na realny przestój – logowanie do domeny trwa wieczność, Outlook nie widzi serwera, VPN łączy się „raz na jakiś czas”.

W sieci lokalnej DNS jest też kręgosłupem wielu mechanizmów bezpieczeństwa i automatyzacji: logowanie do domeny AD, Kerberos, integracja z systemami monitoringu, reverse DNS w syslogach, weryfikacja certyfikatów TLS dla usług wewnętrznych. Brak spójnego planu oznacza później kosztowne „łatanie” i ręczne wpisy w hosts na dziesiątkach stacji.

Typowe scenariusze: małe biuro, średnia firma, sieć domowa z usługami

Przy projektowaniu DNS w sieci LAN podejście powinno zależeć od skali, ale pewne zasady się powtarzają.

Małe biuro (kilkanaście–kilkadziesiąt urządzeń): najczęściej cały DNS i DHCP rezyduje na routerze dostawcy lub prostym routerze SOHO. Zwykle jest to konfiguracja typu „wszystko z pudełka” – brak strefy lokalnej, nazwy hostów powstają automatycznie z DHCP, nie ma reverse DNS, urządzenia sieciowe i drukarki mają IP wpisane ręcznie. Działa – dopóki nie pojawi się serwer plików, VPN, VoIP lub lokalny serwer aplikacji z certyfikatem SSL. Wtedy zaczyna się konieczność świadomego zarządzania DNS.

Średnia firma: pojawiają się serwery, VLAN-y, oddziały, domena Active Directory, czasem DMZ. DNS jest zwykle obsługiwany przez Windows Server DNS skojarzony z AD lub przez BIND/Unbound na Linuxie. Dochodzi potrzeba podziału na strefy, split-horizon DNS dla tej samej domeny publicznej, integracja z DHCP, kontrola nad tym, kto może aktualizować DNS. Tu błędy projektowe wychodzą najszybciej: konflikty nazw, niespójne rekordy wewnątrz/zewnątrz, problemy z certyfikatami TLS.

Sieć domowa / HomeLab: coraz częściej w domach pojawia się NAS, serwer mediów, Home Assistant, mały lab testowy z maszynami wirtualnymi, a do tego VPN i zdalny dostęp. Wpisywanie IP w przeglądarce jest niewygodne, a jednocześnie nie ma potrzeby wystawiania wszystkiego do Internetu. Lokalne DNS z prostą strefą typu lan lub home rozwiązuje większość problemów i pozwala testować rozwiązania podobnie jak w małej firmie.

Integracja DNS z DHCP i usługami katalogowymi

W sieci lokalnej DNS rzadko działa w izolacji. Najczęściej łączy się go z DHCP i (w firmach) z usługą katalogową typu Active Directory lub LDAP.

Typowy schemat:

• DHCP przydziela adres IP hostowi w LAN,
• DHCP rejestruje (dynamicznie) rekord DNS typu A/AAAA i ewentualnie PTR,
• Active Directory wymaga poprawnych rekordów DNS (SRV, A, reverse) do logowania i replikacji.

Brak integracji powoduje chaos: klienci mają adresy, których nie ma w DNS, logi z firewalli i serwerów pokazują tylko IP, a narzędzia monitorujące nie mogą mapować adresów na nazwy. W AD każdy problem z DNS często objawia się jako „problemy z domeną”, mimo że sama usługa katalogowa jest poprawna.

Konsekwencje źle zaprojektowanego DNS w LAN

Najczęstsze skutki niedopracowanego DNS w sieci lokalnej:

• opóźnienia: aplikacje długo „myślą”, bo czekają na timeout zapytań DNS,
• błędy certyfikatów TLS: nazwa w adresie nie zgadza się z CN/SAN w certyfikacie, bo wewnątrz używana jest inna nazwa niż na zewnątrz,
• problemy z logowaniem do domeny: kontroler domeny nie rozwiązuje się poprawnie, klienci trafiają do złych DC,
• błędne logi i raporty: brak reverse DNS, analityka oparta na samych adresach IP, trudniejsze śledzenie incydentów,
• dziwne błędy aplikacji: skrypty i integracje odwołują się do nazw, które rozwiązują się różnie w różnych segmentach sieci.

W małych środowiskach użytkownicy przyzwyczajają się do wpisywania IP. W momencie rozbudowy lub migracji usług staje się to barierą. W większych – fatalny DNS powoduje lawinę zgłoszeń do helpdesku.

Przykład: wszystko na routerze ISP vs własny serwer DNS

Realistyczny scenariusz: małe biuro, router od ISP pełni rolę bramy, firewall, DHCP i DNS (zazwyczaj jako prosty forwarder do DNS operatora). Do tego serwer plików na NAS, aplikacja CRM na serwerze Windows, kilka drukarek sieciowych, kilka zdalnych pracowników łączących się VPN-em.

Bez własnego DNS:

• drukarki mają adresy statyczne, ale nie mają stabilnych nazw,
• NAS widoczny jest jako dziwna nazwa hosta z DHCP,
• serwer CRM działa pod IP, które trzeba znać lub mieć zapisane,
• VPN przydziela inne adresy, które nie pojawiają się w DNS,
• certyfikaty TLS dla CRM wystawiane są na IP albo na nazwę typu crm.local, która nie istnieje w żadnej sensownej strefie.

Po wdrożeniu własnego serwera DNS (np. BIND, Unbound, Windows Server DNS, lub nawet rozsądnie skonfigurowany router z obsługą lokalnych stref):

• powstaje strefa firma.lan lub corp.firma.pl,
• główne serwery i drukarki dostają stabilne nazwy i rezerwacje DHCP,
• VPN korzysta z tego samego DNS, więc użytkownik w domu wpisuje taką samą nazwę jak w biurze,
• pojawia się reverse DNS dla kluczowych hostów, logi stają się czytelne,
• łatwiej wdrożyć certyfikaty TLS – nazwy są spójne wewnątrz i na zewnątrz (np. przez split-horizon).

Podstawy techniczne DNS potrzebne do pracy w sieci lokalnej

Najważniejsze typy rekordów w sieci LAN

Do sensownej pracy z DNS w sieci lokalnej wystarczy dobrze opanować kilka typów rekordów. Te same typy używane są w publicznym DNS, ale w LAN nabierają specyficznego znaczenia.

• A – mapuje nazwę hosta na adres IPv4. Przykład: filesrv1.corp.lan IN A 192.168.10.20.
• AAAA – to samo dla IPv6. W sieciach z IPv6 umożliwia natywne adresowanie hostów zamiast NAT.
• CNAME – alias nazwy hosta. Przykład: files.corp.lan CNAME filesrv1.corp.lan. Umożliwia odseparowanie nazwy usługi od nazwy fizycznego serwera.
• MX – definiuje serwery pocztowe dla domeny, również wewnętrznej, jeśli istnieje lokalna poczta.
• TXT – pole tekstowe, elastyczne. Lokalnie sprawdza się do przechowywania metadanych (np. informacje dla systemów CMDB, identyfikatory usług, klucze dla wewnętrznych systemów).
• PTR – rekord odwrotny (reverse DNS), mapuje adres IP na nazwę hosta. Istotny przy logowaniu, monitoringu, niektórych protokołach bezpieczeństwa.

W sieci lokalnej szczególnie ważna jest konsekwencja: jeśli host ma rekord A, powinien mieć też PTR w odpowiedniej strefie reverse. Ułatwia to diagnostykę, a część narzędzi (np. syslog, SIEM-y) używa reverse DNS do wyświetlania nazw zamiast IP.

Strefy forward i reverse – para, która powinna iść razem

Każda sensowna konfiguracja DNS w LAN powinna obejmować strefę forward (np. corp.lan) i odpowiadające jej strefy reverse (np. 10.168.192.in-addr.arpa dla podsieci 192.168.10.0/24).

Strefy forward odpowiadają na pytania „jakie IP ma nazwa X”. Z kolei strefy reverse służą do pytań „jaką nazwę ma adres IP X”. Ta druga funkcja bywa lekceważona w małych sieciach, a później brak reverse DNS utrudnia analizę logów, korelację zdarzeń i niektóre mechanizmy bezpieczeństwa.

Przy projektowaniu stref reverse warto dopasować je do podziału adresacji w LAN. Dla klasycznego /24 tworzy się jedną strefę reverse. Przy bardziej podzielonej przestrzeni (np. kilka podsieci /26) można robić osobne strefy dla każdego fragmentu, o ile adresacja jest uporządkowana.

Autorytatywny DNS, resolver rekursywny i cache-only

Serwer DNS w sieci lokalnej może pełnić różne role – warto rozróżniać je w projekcie:

• Autorytatywny serwer DNS – zna „prawdę” o konkretnej strefie (np. corp.lan, 10.168.192.in-addr.arpa). Odpowiada na pytania o te nazwy bez odpytywania innych serwerów. W LAN jest to zazwyczaj serwer, na którym definiujesz swoje rekordy.
• Resolver rekursywny – przyjmuje zapytania od klientów i odpyta inne serwery DNS (np. publiczne) w ich imieniu, aż uzyska odpowiedź. W LAN to najczęściej rola pełniona przez ten sam serwer co autorytatywny lub przez oddzielny resolver (np. Unbound, dnsmasq, Windows Server DNS).
• Cache-only – nie jest autorytatywny dla żadnej strefy, tylko przechowuje w cache odpowiedzi uzyskane od innych serwerów. Czasem używany jako lokalny DNS blisko klientów dla odciążenia głównego resolvera i zwiększenia wydajności.

Rozumienie tych ról ma znaczenie przy split-horizon: serwer może być autorytatywny dla strefy firma.pl dla zapytań z LAN, ale jednocześnie forwardować lub delegować zapytania o tę samą domenę na zewnątrz dla części klientów.

TTL i cache – wpływ na zmiany w LAN

TTL (Time To Live) w rekordach DNS określa, jak długo odpowiedź może być przechowywana w cache resolverów. W sieci lokalnej TTL wpływa bezpośrednio na:

• szybkość propagacji zmian (np. kiedy przenosisz usługę na nowy serwer),
• obciążenie serwera DNS (krótkie TTL = częstsze zapytania),
• łatwość debugowania (za długi TTL utrudnia szybkie odwrócenie pomyłki).

Praktycznie w LAN można stosować krótsze TTL niż w publicznym DNS, bo odległość do resolvera jest mniejsza, a opóźnienia nie są krytyczne. Dla usług krytycznych i często zmieniających się (np. load balancer, adresy maszyn wirtualnych) często używa się TTL rzędu 60–300 sekund. Dla stabilnych hostów infrastrukturalnych (np. drukarki, NAS) można spokojnie stosować 1–4 godziny, a czasem nawet dłużej.

Ważne, aby przed większą migracją obniżyć TTL wybranych rekordów z wyprzedzeniem, tak aby cache w sieci opróżnił się szybciej, a zmiana adresu usługi przeszła płynnie.

Jak czytać odpowiedzi DNS – flags, RCODE i sekcje

Do diagnostyki DNS w LAN używa się zazwyczaj dig, nslookup lub GUI systemu DNS. Warto rozumieć podstawowe elementy odpowiedzi:

• Flags – m.in.:
  • qr – odpowiedź (a nie zapytanie),
  • aa – authoritative answer, serwer jest autorytatywny dla tej odpowiedzi,
  • ra – recursion available, serwer może wykonywać rekursję,
  • rd – recursion desired, klient prosi o rekursję.
• RCODE – kod odpowiedzi:
  • NOERROR – zapytanie obsłużone poprawnie,
  • NXDOMAIN – nazwa nie istnieje w danej strefie,
  • REFUSED – serwer odmawia odpowiedzi (np. z powodu ACL),
  • SERVFAIL – błąd po stronie serwera (często problemy z połączeniem do serwerów nadrzędnych lub błędy konfiguracji).
• Sekcje odpowiedzi:
  • Answer – właściwe rekordy odpowiadające na pytanie,
  • Authority – informacje o serwerach autorytatywnych (NS) dla danej strefy,
  • Additional – dodatkowe pomocnicze rekordy (np. A dla serwerów NS).

Przy split-horizon odpowiedzi dla tego samego zapytania z różnych sieci mogą się różnić. Odczytanie, czy odpowiedź jest autorytatywna i skąd pochodzi, pozwala szybko złapać błędy w konfiguracji widoków czy ACL.

Split-horizon DNS – idea, zastosowania i ryzyka

Na czym polega split-horizon DNS w praktyce

Split-horizon (split-view, split-brain) oznacza, że ten sam serwer DNS zwraca inne odpowiedzi w zależności od źródła zapytania. Użytkownik z LAN widzi jedną wersję strefy, użytkownik z Internetu – inną.

Klasyczny przykład: domena firma.pl hostuje publiczną stronę WWW w chmurze, ale ten sam adres vpn.firma.pl z LAN ma wskazywać na prywatny adres IP urządzenia VPN, a z Internetu – na jego adres publiczny.

• Klient w LAN: vpn.firma.pl IN A 10.0.0.10.
• Klient w Internecie: vpn.firma.pl IN A 83.12.34.56.

To dalej ta sama nazwa, ale inne dane w zależności od perspektywy. Mechanizm realizuje się przez „widoki” (views) w BIND, ACL-e w Unbound, strefy warunkowe (conditional forwarders) i „split-brain DNS” w Windows Server.

Typowe zastosowania split-horizon w sieci lokalnej

Split-horizon rozwiązuje kilka praktycznych problemów, które wychodzą przy styku LAN–Internet.

• Spójne nazwy dla użytkowników wewnętrznych i zewnętrznych
  Ten sam adres URL działa w biurze i poza nim. Przykładowo crm.firma.pl:
  • z LAN wskazuje na 10.0.10.20 (serwer aplikacyjny za firewallem),
  • spoza LAN wskazuje na publiczny IP reverse proxy lub WAF.
• Omijanie hairpin NAT
  Użytkownicy w LAN nie muszą łączyć się do własnej infrastruktury przez publiczny adres routera. Widzą wewnętrzne IP i łączą się bezpośrednio, z mniejszym opóźnieniem i prostszą ścieżką routingu.
• Ukrywanie wewnętrznej topologii
  Publiczny DNS pokazuje tylko to, co trzeba (np. publiczny front-end). Wewnętrzne nazwy hostów, rekordy SRV, szczegóły podsieci zostają w prywatnej wersji strefy.
• Łatwiejsze certyfikaty TLS
  Jedna publiczna nazwa w certyfikacie (np. portal.firma.pl), a split-horizon zapewnia odpowiednie IP dla danego klienta. Nie trzeba osobnych adresów typu portal.internal.
• Specyficzne serwery dla VPN
  Użytkownik po VPN może dostawać inne odpowiedzi niż użytkownik z fizycznego LAN lub Internetu (osobny widok dla adresacji VPN).

Warianty split-horizon: pełny i częściowy

Nie zawsze trzeba rozdzielać całą strefę. W praktyce pojawiają się trzy podstawowe warianty:

• Pełny split-horizon dla całej domeny
  Dla tej samej strefy (np. firma.pl) istnieją dwie różne bazy rekordów – wewnętrzna i zewnętrzna. Użyteczne, gdy większość hostów jest prywatna, a publicznych jest kilka.
• Split tylko dla wybranych rekordów
  Zewnętrzny DNS pokazuje minimum: np. tylko rekordy A/AAAA dla front-endów, MX, TXT dla SPF/DMARC. Wewnętrzny DNS dla tej samej domeny zawiera całą resztę, ale tylko z perspektywy LAN. Z punktu widzenia serwera to nadal pełne dwie strefy, ale zawartość zewnętrzna jest celowo okrojona.
• Strefy podrzędne (subdomeny) rozdzielone różnie
  Na zewnątrz istnieje tylko firma.pl z kilkoma rekordami, wewnątrz są dodatkowe subdomeny typu lan.firma.pl, srv.firma.pl, db.firma.pl, które w ogóle nie występują w wersji publicznej.

Ryzyka i pułapki przy split-horizon

Split-horizon rozwiązuje wiele problemów, ale dorzuca swoje miny. Najczęstsze z nich:

• Rozjechane rekordy między widokami
  Administrator zmienia rekord w jednym widoku, zapomina o drugim. Część użytkowników widzi nowy serwer, część stary. Pomaga prosta zasada: zmiana w strefie – sprawdź oba widoki, oraz automatyzacja (np. zarządzanie strefami z jednego repozytorium).
• Trudniejsza diagnostyka
  Użytkownik zgłasza „nie działa DNS”, a administrator patrzy z innej sieci i widzi inną odpowiedź. Dobrą praktyką jest mieć jump-host w każdej „perspektywie” (LAN, VPN, DMZ) i testować dig bezpośrednio stamtąd.
• Zależność od poprawnych ACL
  Granica między widokami to ACL-e po IP (lub sieci). Błąd w konfiguracji może spowodować, że:
  • świat zewnętrzny zobaczy wewnętrzne rekordy,
  • klienci wewnętrzni dostaną zewnętrzną wersję strefy i zaczną obijać się o firewall lub hairpin NAT.
• Komplikacja przy migracjach domeny
  Przenoszenie strefy na inny serwer lub operatora DNS wymaga uwzględnienia obu widoków. Łatwo wysłać na zewnątrz nie tę wersję, co trzeba.
• Problemy z DNSSEC
  Split-horizon z DNSSEC jest trudniejszy: trzeba utrzymywać spójne podpisy, pilnować, co jest publiczne, a co nie. W małych sieciach wewnętrzny DNS często pozostaje bez DNSSEC, a publiczny – podpisany.

Kiedy split-horizon ma sens, a kiedy lepiej go unikać

Split-horizon jest użyteczny, gdy:

• publiczna i prywatna wersja tej samej domeny muszą współistnieć (np. firma.pl używana na zewnątrz i w środku),
• użytkownik ma mieć ten sam URL wewnątrz i na zewnątrz (np. aplikacje SaaS z SSO, portale pracownicze),
• sieć ma wiele punktów wejścia (np. kilka lokalizacji, VPN, dostęp gościnny) i trzeba różnicować odpowiedzi.

Można z niego zrezygnować, jeśli:

• wewnętrzna domena jest inna niż publiczna (np. corp.lan vs firma.pl),
• usługi dostępne są wyłącznie z jednej strony (strict internal / strict external),
• sprzęt brzegowy dobrze obsługuje hairpin NAT i prostszy jest routing niż budowa dwóch widoków DNS.

Projektowanie stref DNS w sieci lokalnej

Wybór nazwy domeny wewnętrznej

Pierwsza decyzja to nazwa. Najczęściej pojawiają się trzy podejścia:

• Subdomena publicznej domeny – np. corp.firma.pl, lan.firma.pl.
  Plusy: łatwa integracja z publicznym DNS, spójne nazwy, łatwiejsze certyfikaty (SAN, wildcard).
  Minus: wymaga kontroli nad domeną publiczną i rozsądnej polityki, żeby nie wrzucić wewnętrznych rekordów do publicznego DNS.
• Oddzielna prywatna domena z końcówką .lan / .internal – np. firma.lan.
  Plusy: mniejsze ryzyko pomyłki z publicznym DNS, czytelne rozróżnienie „to jest wewnętrzne”.
  Minusy: brak w globalnym DNS, trudniejsze wystawianie certyfikatów (CA od lat nie wystawiają certów na niepubliczne TLD typu .lan).
• Ta sama domena publiczna i wewnętrzna – pełny split-horizon dla firma.pl.
  Plusy: maksymalna spójność nazw, proste certyfikaty, brak kombinacji z dwiema domenami.
  Minusy: większe ryzyko błędu, wymaga dojrzałej konfiguracji split-horizon.

Planowanie struktury nazw hostów

W małej sieci można obejść się prostą płaską strukturą (nas1.corp.lan, crm.corp.lan), ale przy większej infrastrukturze lepiej od razu uporządkować nazewnictwo.

Przykładowy prosty schemat:

• srv-* – serwery ogólne: srv-ad1.corp.lan, srv-files1.corp.lan,
• app-* – serwery aplikacyjne: app-crm1.corp.lan,
• db-* – bazy danych: db-crm1.corp.lan,
• prn-* – drukarki: prn-hp01.corp.lan,
• sw-*, ap-* – przełączniki, access pointy: sw-core1.corp.lan, ap-01.corp.lan.

Do tego dochodzą aliasy CNAME dla usług:

• files.corp.lan → srv-files1.corp.lan,
• crm.corp.lan → app-crm1.corp.lan,
• vpn.corp.lan → fw-01.corp.lan.

Umożliwia to zmianę sprzętu pod usługą bez zmiany nazwy widocznej dla użytkownika.

Podział stref po funkcji i lokalizacji

W większych środowiskach przydaje się podział stref na logiczne części. Zamiast jednego „wora” corp.lan zawierającego setki rekordów, można wprowadzić podstrefy:

• dc1.corp.lan, dc2.corp.lan – dla różnych data center lub serwerowni,
• brn.corp.lan, krk.corp.lan – dla oddziałów,
• srv.corp.lan, net.corp.lan – dla serwerów i urządzeń sieciowych.

Nie ma jednego idealnego schematu. Kluczem jest spójność i to, by nowa osoba w zespole była w stanie domyślić się przeznaczenia nazwy po samym FQDN.

Reverse DNS – decyzje projektowe

Strefy reverse zwykle odpowiadają podsieciom IP. Typowy układ:

• 192.168.10.0/24 → strefa 10.168.192.in-addr.arpa,
• 10.0.0.0/24 → strefa 0.0.10.in-addr.arpa.

Przy bardziej pociętej przestrzeni (np. /26, /28) pojawia się pytanie: jedna strefa czy kilka małych? Dwie proste zasady:

• jeśli podsieci odpowiadają różnym lokalizacjom/klientom – lepiej oddzielne strefy (łatwiejsze delegacje i uprawnienia),
• jeśli to sztucznie pocięta adresacja, ale logicznie jeden obszar – jedna strefa i nieużywane PTR-y zostają po prostu puste.

Polityka tworzenia rekordów: co trafia do DNS, a co nie

W LAN kusi, by wrzucać do DNS wszystkie możliwe hosty. Szybko robi się z tego bałagan. Przydaje się prosta polityka:

• rekordy A/PTR dla:
  • serwerów i urządzeń infrastrukturalnych (NAS, routery, switche, AP),
  • drukarek sieciowych,
  • urządzeń krytycznych (kamery, kontrolery dostępu),
  • klientów stacjonarnych i serwerów VDI (często przez DHCP + dynamiczny DNS).
• brak stałych rekordów dla:
  • gości (sieć guest),
  • urządzeń prywatnych BYOD (chyba że polityka jest inna),
  • krótkotrwałych laboratoriów/testów – można użyć osobnej strefy tymczasowej.

Konfiguracja split-horizon DNS w praktyce

Split-horizon w BIND – widoki (views)

W BIND kluczowym mechanizmem są views. Każdy widok ma własne strefy i własne ACL-e określające, kto z niego korzysta.

Prosty przykład: jedna domena firma.pl, dwa widoki – wewnętrzny i zewnętrzny.

acl "lan" {
    10.0.0.0/16;
    192.168.0.0/16;
    172.16.0.0/16;
};

view "internal" {
    match-clients { "lan"; 127.0.0.1; };
    recursion yes;

    zone "firma.pl" {
        type master;
        file "/etc/bind/zones/internal.firma.pl.zone";
    };

    zone "0.168.192.in-addr.arpa" {
        type master;
        file "/etc/bind/zones/0.168.192.rev";
    };
};

view "external" {
    match-clients { any; };
    recursion no;

    zone "firma.pl" {
        type master;
        file "/etc/bind/zones/external.firma.pl.zone";
    };
};

W tym układzie:

• klienci z LAN dostają odpowiedzi z pliku internal.firma.pl.zone,
• świat zewnętrzny – z external.firma.pl.zone,
• rekursja włączona jest tylko dla LAN.

Checklist przy wdrażaniu widoków w BIND

Checklist przy wdrażaniu widoków w BIND – na co spojrzeć dwa razy

• Spójne ACL-e
  Ustal jedną listę sieci wewnętrznych i używaj jej w wielu miejscach (np. ACL „lan”). Unika się w ten sposób sytuacji, gdzie jeden serwer widzi inne podsieci niż drugi.
• Rekursja tylko dla zaufanych
  W widoku zewnętrznym zawsze recursion no;. Publiczny serwer nie może być „otwartym resolverem” dla Internetu.
• Osobne pliki stref
  Nigdy nie współdziel tego samego pliku strefy między widokami. Osobne pliki ułatwiają kontrolę wersji i ograniczają ryzyko przypadkowego upublicznienia wewnętrznych rekordów.
• SOA i NS w obu wersjach strefy
  Nawet jeśli zewnętrzny DNS jest „okrojony”, nagłówki SOA/NS muszą być poprawne. Złe wartości serial potrafią utopić debugowanie.
• Monitoring z obu stron
  Skonfiguruj proste testy (np. z Prometheusa, Zabbiksa, SmokePing) odpytujące rekordy z perspektywy LAN i Internetu. Widać od razu, który widok „wypadł”.
• Jedna prawda w repozytorium
  Nawet przy osobnych plikach stref dobrze jest trzymać je w jednym repo (Git) i generować z szablonów. Mniej ręcznego klepania, mniej rozjazdów.

Split-horizon w Unbound – strefy prywatne i local-zone

Unbound nie ma views jak BIND, ale dobrze sprawdza się jako resolver w LAN z lokalnymi strefami i filtrowaniem zapytań.

Typowy scenariusz: publiczny DNS jest „normalny”, a na brzegu stoi Unbound, który dla swoich użytkowników nadpisuje wybrane domeny.

server:
    interface: 0.0.0.0
    access-control: 10.0.0.0/16 allow
    access-control: 192.168.0.0/16 allow
    access-control: 0.0.0.0/0 refuse

    # lokalna wersja domeny firma.pl
    local-zone: "firma.pl." static

    local-data: "app.firma.pl. 60 IN A 10.0.10.10"
    local-data: "db.firma.pl. 60 IN A 10.0.10.11"
    local-data: "vpn.firma.pl. 60 IN A 1.2.3.4"

    # forwardowanie reszty do zewnętrznych resolverów
    forward-zone:
        name: "."
        forward-tls-upstream: yes
        forward-addr: 9.9.9.9@853
        forward-addr: 1.1.1.1@853

W tym wariancie Unbound:

• odpowiada autorytatywnie dla firma.pl w LAN,
• resztę zapytań trzyma jako zwykły resolver,
• nie służy Internetowi jako rekursor (dzięki refuse na 0.0.0.0/0).

Gdy potrzeba bardziej złożonego split-horizon (np. różne odpowiedzi dla VPN i LAN), lepiej użyć BIND lub innego serwera z views. Unbound nadaje się świetnie do prostego nadpisywania wybranych domen i filtracji.

Split-horizon w Windows Server DNS – strefy warunkowe i rozdzielone

W środowiskach opartych o Active Directory dominującą rolę gra Windows DNS. Nie ma tam widoków znanych z BIND, ale ten sam efekt można uzyskać innymi mechanizmami.

• Dwie strefy o tej samej nazwie
  Jedna strefa jest AD-integrated (używana wewnątrz), druga – na serwerach stojących w DMZ, używana jako publiczna kopia. Rozdział realizuje się przez konfigurację serwerów, nie w ramach jednego procesu DNS.
• Strefy warunkowe (Conditional Forwarders)
  Dla wybranych domen definiuje się, do jakich serwerów DNS mają być przekazywane zapytania. Przykład: zapytania o partner.local lecą do konkretnego DNS partnera.
• „Split-brain” z AD
  Częsty wzorzec: domena AD i domena publiczna mają tę samą nazwę (firma.pl). Wewnątrz AD jest pełna strefa z hostami, na publicznych serwerach – okrojona. To też split-horizon, tylko realizowany poprzez fizycznie oddzielne serwery.

Kluczowa praktyka: serwery DNS w AD nie powinny odpowiadać światu. Na zewnątrz wystawia się osobną parę (często Linux + BIND) lub oddaje strefę operatorowi DNS. Miksowanie ról „AD DNS” i „publiczny DNS” na jednym Windowsie kończy się zwykle bałaganem.

Rekordy DNS w sieci lokalnej – praktyczne wzorce i antywzorce

Rekordy A/AAAA – adresy hostów

Podstawą są rekordy typu A (IPv4) i AAAA (IPv6). W LAN dobrze trzyma się kilku prostych zasad:

• Spójny schemat nazw
  Jeśli serwer nazywa się srv-files1, rekord A też powinien tak wyglądać. Alias „ładnej” nazwy robimy przez CNAME.
• Usługi na aliasach
  Zamiast wskazywać użytkownikom srv-files1.corp.lan, lepiej dać files.corp.lan → CNAME do serwera. Przeniesienie usługi na inny host to wtedy zmiana jednego rekordu.
• IPv6 z głową
  Jeśli IPv6 faktycznie działa w LAN, przypisuj AAAA dla tych samych nazw co A. Nie ma sensu utrzymywać oddzielnych FQDN tylko pod IPv6, bo mnoży to rekordy i kłopoty.

Rekordy CNAME – gdzie pomagają, gdzie szkodzą

CNAME to wygoda, ale przy nadużyciu robi się z tego ukryty labirynt.

• Dobry użytek
  Jedna maszyna hostuje kilka usług: app1.corp.lan, app2.corp.lan, files.corp.lan. W tle wszystkie CNAME prowadzą do srv-app01.corp.lan. Użytkownicy widzą nazwy usług, a administratorzy – jedną fizyczną maszynę.
• Antywzorzec – łańcuchy aliasów
  crm.corp.lan → CNAME → app-business.corp.lan → CNAME → srv-app01.corp.lan. Każdy dodatkowy krok to więcej czasu rozwiązywania i większe ryzyko pomyłki. Alias powinien wskazywać bezpośrednio na rekord A/AAAA, nie na kolejnego CNAME.
• CNAME a inne rekordy
  Nazwa będąca CNAME nie powinna mieć równolegle innych typów rekordów (MX, TXT, SRV). Typowy błąd przy konfiguracji poczty czy usług SIP.

MX, SRV, TXT – rekordy wspierające usługi

W sieci lokalnej te typy rekordów często pojawiają się przy integracjach i usługach katalogowych.

• MX
  Jeśli poczta wewnętrzna to inna domena niż publiczna, sensowny jest wewnętrzny MX, np. mail.corp.lan. Przy split-horizon można mieć inne MX-y wewnątrz i na zewnątrz, ale nazwa hosta powinna nadal wskazywać na realny serwer.
• SRV
  Używane intensywnie przez AD, SIP, niektóre aplikacje klienckie. Rekordy SRV w LAN rzadko ktoś „ręcznie” edytuje, ale ich brak lub błędne priorytety powodują dziwne objawy (np. klient używa wolnego serwera aplikacyjnego mimo dostępności szybszego).
• TXT
  Wewnątrz używane głównie do metadanych (np. informacje o lokalizacji urządzenia) albo do mechanizmów typu ACME DNS-01 w prywatnych CA. Sensownie opisane TXT bywa przydatne przy debugowaniu (np. „owner=network-team, rack=R2”).

PTR – reverse DNS w praktyce

Reverse DNS rzadko bywa krytyczny dla użytkownika końcowego, ale bardzo pomaga narzędziom i administratorom.

• Serwery i infrastruktura – zawsze
  Dla serwerów, switchy, routerów, firewalli zrób PTR obowiązkowo. Logi, SNMP, NetFlow, syslog od razu stają się czytelniejsze.
• Klienci – według potrzeb
  W większych sieciach PTR dla klientów generuje zwykle DHCP. Jeśli nie ma takiej potrzeby, można ograniczyć się do krytycznych podsieci (np. administracyjnych).
• Spójność z A/AAAA
  PTR powinien wskazywać na nazwę, która ma z kolei rekord A/AAAA zwrotny do tego samego IP. Niespójności potrafią zmylić monitoringi i systemy bezpieczeństwa.

TTL – ile czasu odpowiedzi mają żyć w cache

Długości TTL w LAN często ustawia się „z przyzwyczajenia”. Lepiej podejść do tego świadomie.

• Rekordy stabilne
  Serwery plików, drukarki, kontrolery domeny – spokojnie 1–8 godzin (3600–28800 s). Mniej ruchu DNS, rzadsze odświeżanie cache.
• Usługi zmienne / migracje
  W czasie migracji skraca się TTL do kilku minut (np. 60–300 s), a po zakończeniu wraca do wartości standardowej. Krótkie TTL na stałe zwiększają obciążenie serwerów DNS.
• Rekordy krytyczne
  Dla VPN, load balancerów czy serwerów, które często trafiają w zmienny routing, rozsądny bywa TTL rzędu 5–15 minut. Jeszcze krócej raczej tylko przy akcjach serwisowych.

DNS a DHCP: rejestracja dynamiczna i automatyzacja

Rola DHCP w aktualizacji DNS

DHCP zna aktualne powiązanie IP ↔ MAC ↔ nazwa hosta. Idealny kandydat do automatycznego karmienia DNS rekordami A i PTR.

Przykładowy przepływ:

1. Host zgłasza się po adres IP, podając swoją nazwę (client1).
2. DHCP przydziela IP (np. 10.0.20.15) i wysyła dynamiczny update do DNS:
   • client1.corp.lan IN A 10.0.20.15,
   • 15.20.0.10.in-addr.arpa IN PTR client1.corp.lan.
3. Przy wygaśnięciu dzierżawy lub zmianie IP, rekordy są aktualizowane/usuwane.

Dynamiczny DNS z ISC DHCP i BIND

Klasyczna para w środowiskach linuksowych to ISC DHCP + BIND. Konfiguracja sprowadza się do umożliwienia aktualizacji i ustawienia klucza TSIG.

# /etc/bind/named.conf
key "ddns-key" {
    algorithm hmac-sha256;
    secret "BASE64SECRET==";
};

zone "corp.lan" IN {
    type master;
    file "/etc/bind/zones/corp.lan.zone";
    allow-update { key "ddns-key"; };
};

zone "20.0.10.in-addr.arpa" IN {
    type master;
    file "/etc/bind/zones/20.0.10.rev";
    allow-update { key "ddns-key"; };
};

# /etc/dhcp/dhcpd.conf
ddns-update-style interim;
key ddns-key {
    algorithm hmac-sha256;
    secret "BASE64SECRET==";
}

zone corp.lan. {
    primary 10.0.0.10;
    key ddns-key;
}

zone 20.0.10.in-addr.arpa. {
    primary 10.0.0.10;
    key ddns-key;
}

subnet 10.0.20.0 netmask 255.255.255.0 {
    range 10.0.20.50 10.0.20.200;
    option routers 10.0.20.1;
    ddns-domainname "corp.lan.";
    ddns-rev-domainname "20.0.10.in-addr.arpa.";
}

Taki układ sprawia, że nowe komputery automatycznie dostają rekordy w DNS bez ręcznego dodawania.

Dynamiczny DNS w Windows DHCP/DNS

Windows Server z rolami DHCP i DNS domyślnie wspiera dynamiczne aktualizacje (secure dynamic updates). Wystarczy:

• ustawić strefę DNS jako Allow only secure dynamic updates,
• w DHCP zaznaczyć, by serwer DHCP zawsze rejestrował rekordy w DNS w imieniu klienta,
• zadbać, by konta serwisowe DHCP miały prawo do modyfikacji strefy.

Przy dobrze ustawionym GPO nazwy komputerów w AD, DHCP i DNS pozostają zsynchronizowane. Rozjazdy pojawiają się głównie wtedy, gdy ktoś ręcznie zmienia nazwę hosta bez poprawnego restartu lub mieszane są różne serwery DHCP w jednej podsieci.

Polityka nazewnicza przy automatycznym DNS

Automatyczne rejestrowanie hostów nie zwalnia z dbania o porządek. Trzeba ułożyć prostą politykę:

• klienci korporacyjni – nazwy zgodne ze standardem (pc-oddzial-numer),
• goście i BYOD – osobna podsieć bez DDNS,
• laboratoria – dedykowana strefa (np. lab.corp.lan) z krótkim TTL i możliwością szybkiego czyszczenia.

Bez tego DNS zacznie się zapełniać losowymi nazwami typu DESKTOP-XYZ123, a reverse strefy przestaną mieć jakąkolwiek wartość diagnostyczną.

Ataki na DNS w sieci lokalnej: spoofing, cache poisoning, rogue DNS

Najczęściej zadawane pytania (FAQ)

Jak poprawnie zaplanować DNS w małej sieci firmowej?

Na początek ustal jedną, spójną domenę wewnętrzną (np. firma.lan albo subdomenę Twojej domeny publicznej, np. corp.firma.pl). Do niej dodawaj nazwy wszystkich kluczowych hostów: serwer plików, CRM, NAS, drukarki sieciowe, kontroler domeny, VPN.

Drugi krok to integracja z DHCP: router lub serwer DHCP powinien dynamicznie tworzyć rekordy A/AAAA i PTR dla hostów. Stałe urządzenia (serwery, drukarki, sprzęt sieciowy) zwykle dostają rezerwacje DHCP albo statyczne IP + ręcznie dodany rekord DNS. Na końcu skonfiguruj strefy reverse dla używanych podsieci, żeby logi i monitoring widziały nazwy zamiast samych adresów.

Czym jest split-horizon DNS i kiedy go używać w sieci lokalnej?

Split-horizon DNS (split-brain) to sytuacja, w której ta sama domena ma różne odpowiedzi w zależności od tego, skąd przychodzi zapytanie. Użytkownik wewnątrz firmy dla crm.firma.pl dostaje lokalny adres LAN, a użytkownik z Internetu – publiczny adres wystawiony przez reverse proxy lub firewall.

Stosuje się to wtedy, gdy chcesz używać tej samej nazwy usługi w biurze i zdalnie, ale z innymi IP. Rozwiązuje to problem „podwójnych” nazw (typu crm.local wewnątrz i crm.firma.pl na zewnątrz) oraz ułatwia zarządzanie certyfikatami TLS – wystawiasz jeden certyfikat na jedną nazwę, a logika routingu jest ukryta w DNS.

Jakie rekordy DNS są kluczowe w sieci LAN i do czego służą?

W typowej sieci LAN używa się głównie kilku typów rekordów. Rekordy A i AAAA mapują nazwę hosta na adres IPv4/IPv6 i są podstawą działania wszystkich usług. CNAME pozwala zrobić alias usługi (np. files → filesrv1), dzięki czemu można wymienić serwer bez zmiany nazwy widocznej dla użytkowników. PTR obsługuje reverse DNS – mapuje IP na nazwę i jest bardzo przydatny w logach oraz systemach bezpieczeństwa.

Dodatkowe typy to MX dla lokalnych serwerów pocztowych oraz TXT, które często trzymają metadane dla systemów wewnętrznych (CMDB, identyfikatory usług, klucze). W praktyce: każdy host serwerowy powinien mieć parę A/AAAA + PTR, a usługi „ludzkie” nazwy zrobione przez CNAME.

Jak połączyć DNS z DHCP w sieci lokalnej, żeby uniknąć chaosu?

Najprostszy model: ten sam serwer obsługuje DNS i DHCP (np. Windows Server, router z OpenWrt, pfSense, Mikrotik). DHCP nadaje adres IP, a potem automatycznie rejestruje lub aktualizuje rekordy A/AAAA i PTR w DNS. Dzięki temu nazwa hosta z DHCP od razu działa w całej sieci i w logach.

W bardziej rozbudowanych sieciach stosuje się dynamiczne aktualizacje DNS z autoryzacją (np. DHCP zna klucz TSIG lub jest częścią domeny AD). Wtedy:

• adresy z DHCP zawsze mają odpowiadające rekordy DNS,
• łatwo śledzisz konkretnego klienta po nazwie,
• można automatycznie sprzątać stare rekordy po wygaśnięciu dzierżawy DHCP.

Jeśli DHCP i DNS są rozdzielone (np. DHCP na routerze ISP, DNS na serwerze), pojawia się rozjazd nazw i ręczne dopisywanie rekordów.

Po czym poznać, że DNS w mojej sieci LAN jest źle zaprojektowany?

Typowe objawy to: aplikacje „mielą” przy starcie, długo czekają na połączenie albo sporadycznie wyrzucają błędy, logowanie do domeny AD trwa bardzo długo, a użytkownicy narzekają, że „Czasem działa, czasem nie”. W logach firewalli i serwerów widzisz głównie surowe IP, brak czytelnych nazw hostów, a administratorzy często wpisują adresy IP ręcznie.

Inny sygnał to problemy z certyfikatami TLS – przeglądarka ostrzega, że nazwa w adresie nie zgadza się z certyfikatem, bo wewnątrz używasz np. crm.local, a certyfikat jest wystawiony na crm.firma.pl. Do tego dochodzą konflikty nazw (ta sama nazwa oznacza inny host w różnych segmentach) i różne wyniki zapytań DNS w zależności od tego, z której podsieci pytasz – choć nie było to zaplanowane jako split-horizon.

Jak użycie reverse DNS (PTR) pomaga w bezpieczeństwie i diagnostyce?

Reverse DNS pozwala szybko powiązać adres IP z nazwą hosta. Jeśli masz poprawnie skonfigurowane strefy reverse i przypisane rekordy PTR, logi z firewalli, serwerów, proxy i systemów monitoringu stają się czytelne: zamiast „192.168.10.37” widzisz np. „laptop-ksiegowosc3.corp.lan”. Ułatwia to szukanie źródła incydentów, analizę ruchu oraz korelację zdarzeń w SIEM.

Niektóre mechanizmy bezpieczeństwa (filtry antyspamowe, systemy kontroli dostępu, skanery podatności) używają reverse DNS jako jednego z elementów weryfikacji tożsamości hosta. W sieci LAN często przydaje się też prosta zasada: każdy adres używany przez serwer lub urządzenie infrastruktury ma PTR, adresy dla klientów mogą być generowane dynamicznie przez DHCP + DNS.

Dlaczego własny serwer DNS w firmie jest lepszy niż „DNS na routerze od dostawcy”?

DNS na routerze od ISP zwykle działa tylko jako prosty forwarder – przekazuje zapytania do DNS operatora i nie trzyma własnej, sensownej strefy lokalnej. Nazwy hostów, jeśli w ogóle istnieją, są losowe, nie ma reverse DNS, brak integracji z innymi usługami. Przy pierwszym poważniejszym wdrożeniu (NAS, CRM, VPN, VoIP, AD) zaczyna to przeszkadzać.

Własny serwer DNS (Windows, BIND, Unbound, dnsmasq czy dobrze skonfigurowany router z lokalnymi strefami) pozwala:

• zdefiniować przejrzystą przestrzeń nazw (corp.lan, lab.home itd.),
• integrować się z DHCP, AD, monitoringiem,
• wprowadzić split-horizon dla usług dostępnych też z Internetu,
• porządnie obsłużyć reverse DNS dla kluczowych hostów.

Dzięki temu użytkownicy korzystają z usług po nazwach, konfiguracje są stabilniejsze, a rozbudowa sieci nie wymaga grzebania w plikach hosts na każdej stacji.

Co warto zapamiętać

• DNS w LAN jest krytyczną usługą – bez poprawnego rozwiązywania nazw pojawiają się przestoje, problemy z logowaniem do domeny, niedziałający Outlook, niestabilny VPN i ogólny chaos w usługach.
• Wraz ze wzrostem skali (małe biuro → średnia firma → HomeLab) rośnie znaczenie świadomie zaprojektowanego DNS: własna strefa, spójne nazewnictwo, reverse DNS i obsługa certyfikatów TLS stają się koniecznością, a nie „opcją”.
• Ścisła integracja DNS z DHCP i usługą katalogową (AD/LDAP) jest kluczowa – DHCP musi dynamicznie rejestrować rekordy A/AAAA i PTR, inaczej logi, monitoring i logowanie do domeny przestają być przewidywalne.
• Źle zaprojektowany lub „domyślny” DNS (wszystko na routerze ISP) skutkuje: długimi timeoutami zapytań, błędami certyfikatów, nieczytelnymi logami bez reverse DNS oraz losowymi problemami aplikacji, które trudno powiązać z samym DNS.
• Własny serwer DNS z lokalną strefą (np. firma.lan, corp.firma.pl) porządkuje środowisko: urządzenia mają stałe nazwy, VPN korzysta z tych samych rekordów, a logi i narzędzia monitorujące wreszcie widzą hosty po nazwach.
• Spójne nazwy wewnątrz i na zewnątrz (często dzięki split-horizon DNS) znacznie ułatwiają pracę z certyfikatami TLS – ten sam FQDN działa lokalnie i z Internetu, zamiast mieszać IP, dziwne domeny typu .local i różne aliasy.