BIND9 od wielu lat pozostaje jednym z najczęściej wykorzystywanych serwerów DNS w systemach Linux. Jest stabilny, dobrze udokumentowany i oferuje duże możliwości konfiguracji. Jednak dla części administratorów jego codzienna obsługa może z czasem stać się uciążliwa. Praktycznie wszystkie ustawienia zapisuje się bowiem w plikach tekstowych.
Przy kilku niewielkich strefach nie stanowi to większego problemu. Sytuacja komplikuje się jednak wtedy, gdy serwer obsługuje wiele domen, strefy odwrotne, delegacje, dynamiczne aktualizacje oraz serwery secondary. Ponadto każda zmiana wymaga edycji odpowiedniego pliku, sprawdzenia składni i przeładowania usługi.
Alternatywą może być Technitium DNS Server, czyli otwartoźródłowy serwer DNS zarządzany za pomocą panelu WWW. Rozwiązanie obsługuje między innymi strefy autorytatywne, rekursję, DNSSEC, transfery AXFR i IXFR, DNS NOTIFY, TSIG oraz automatyzację przez API.
W tym artykule pokażę, jak bezpiecznie przeprowadzić migrację z BIND9 do Technitium DNS Server. Najpierw uruchomimy Technitium w kontenerze Docker. Następnie przeniesiemy strefy proste i odwrotne. Na końcu skonfigurujemy współpracę serwerów primary i secondary oraz wykonamy testy przed przełączeniem klientów.
Czy Technitium może zastąpić BIND9?
W wielu środowiskach odpowiedź brzmi: tak. Nie oznacza to jednak, że Technitium jest bezwarunkowo lepszy od BIND9. Oba systemy reprezentują po prostu inne podejście do zarządzania usługą DNS.
Konfiguracja i zarządzanie rekordami
W BIND9 większość ustawień zapisuje się w plikach tekstowych. Dotyczy to zarówno konfiguracji samego serwera, jak i zawartości poszczególnych stref DNS. Każdą zmianę trzeba następnie sprawdzić i przeładować za pomocą odpowiednich poleceń.
Technitium wykorzystuje inne podejście. Konfiguracja serwera oraz zarządzanie rekordami odbywają się przede wszystkim w panelu WWW. Dostępne jest również HTTP API, które pozwala automatyzować wykonywane operacje.
Strefy primary i secondary
Oba serwery obsługują klasyczną architekturę primary-secondary. Umożliwiają również pełne transfery AXFR, transfery przyrostowe IXFR oraz komunikaty DNS NOTIFY.
Dzięki temu Technitium może początkowo działać jako serwer secondary dla BIND9. Takie rozwiązanie pozwala bezpiecznie skopiować strefy i przetestować nową usługę przed właściwym przełączeniem.
DNSSEC
Zarówno BIND9, jak i Technitium obsługują DNSSEC. W przypadku BIND9 zarządzanie kluczami i podpisywaniem stref odbywa się głównie za pomocą plików konfiguracyjnych oraz narzędzi systemowych.
Technitium udostępnia natomiast odpowiednie opcje w panelu WWW. Upraszcza to codzienną obsługę, chociaż nadal wymaga znajomości zasad działania DNSSEC oraz ostrożności podczas zmiany kluczy.
Automatyzacja
BIND9 można automatyzować za pomocą skryptów, narzędzia rndc oraz programu nsupdate. Rozwiązanie dobrze współpracuje także z systemami zarządzania konfiguracją, takimi jak Ansible.
Z kolei Technitium oferuje HTTP API. Pozwala ono między innymi tworzyć strefy, dodawać rekordy oraz odczytywać konfigurację bez bezpośredniej edycji plików.
Logi i statystyki
BIND9 zapisuje informacje w plikach, systemie syslog albo journald. Zakres logowania można szczegółowo skonfigurować, jednak analiza danych zwykle wymaga użycia dodatkowych narzędzi.
Technitium prezentuje część informacji bezpośrednio w panelu administracyjnym. Administrator otrzymuje dostęp do statystyk zapytań, logów oraz podstawowych informacji diagnostycznych.
Serwer DHCP
BIND9 nie zawiera własnego serwera DHCP. W takim środowisku należy uruchomić oddzielną usługę, na przykład Kea DHCP albo ISC DHCP.
Technitium ma natomiast wbudowany serwer DHCP. Nie trzeba go jednak uruchamiać, jeżeli w sieci działa już router lub inna usługa przydzielająca adresy IP.
BIND9 nadal będzie dobrym wyborem tam, gdzie konfiguracja jest w pełni automatyzowana i przechowywana w repozytorium Git. Podobnie wygląda sytuacja w środowiskach wykorzystujących rozbudowane mechanizmy views, RPZ albo niestandardowe polityki dostępu.
Z kolei Technitium sprawdzi się szczególnie dobrze w małych i średnich sieciach, laboratoriach oraz środowiskach edukacyjnych. W praktyce administrator zachowuje zaawansowane funkcje serwera DNS, a jednocześnie otrzymuje wygodny panel WWW.
Najważniejsza zasada: nie wyłączaj od razu BIND9
Najbezpieczniejszą metodą migracji jest równoległe uruchomienie Technitium pod innym adresem IP. Dzięki temu można zaimportować strefy, porównać odpowiedzi obu serwerów i przygotować możliwość szybkiego powrotu do poprzedniego rozwiązania.
W przykładach przyjmuję następującą adresację:
- 192.168.10.10 – dotychczasowy serwer BIND9,
- 192.168.10.11 – nowy serwer Technitium DNS Server.
Nie należy uruchamiać obu usług na tym samym adresie IP i porcie 53. Jeżeli migracja odbywa się na jednym systemie, potrzebny będzie tymczasowy dodatkowy adres IP albo krótkie okno serwisowe.
Krok 1. Inwentaryzacja konfiguracji BIND9
Przed rozpoczęciem migracji trzeba ustalić, jakie funkcje pełni obecny serwer. Samo skopiowanie plików stref nie przeniesie bowiem całej konfiguracji BIND9.
Przede wszystkim należy sprawdzić:
- listę stref primary i secondary,
- strefy wyszukiwania wstecznego PTR,
- sekcje
forwarders i strefy typu forward,
- reguły
allow-query, allow-recursion i allow-transfer,
- dynamiczne aktualizacje DNS,
- klucze TSIG,
- obsługę DNSSEC,
- konfigurację BIND views,
- RPZ i inne mechanizmy filtrowania.
W Debianie definicje lokalnych stref najczęściej znajdują się w pliku:
/etc/bind/named.conf.local
Następnie warto sprawdzić poprawność całej konfiguracji:
sudo named-checkconf
Jeżeli polecenie nie zwróci żadnego komunikatu, składnia konfiguracji jest prawidłowa.
Krok 2. Kopia bezpieczeństwa BIND9
Przed migracją wykonujemy pełną kopię katalogów zawierających konfigurację i dane stref:
sudo tar -czf /root/bind9-backup-$(date +%F).tar.gz \
/etc/bind /var/cache/bind
Jeżeli BIND9 korzysta z dynamicznych aktualizacji, część aktualnych rekordów może znajdować się w plikach dziennika z rozszerzeniem .jnl. Dlatego przed skopiowaniem stref należy zsynchronizować dzienniki z plikami głównymi:
sudo rndc sync
Dla pojedynczej strefy można użyć polecenia:
sudo rndc sync example.com
Z kolei opcja -clean zapisuje zmiany w głównym pliku strefy i usuwa istniejący dziennik:
sudo rndc sync -clean example.com
Trzeba jednak pamiętać, że kolejne aktualizacje dynamiczne mogą ponownie utworzyć plik .jnl. Z tego powodu właściwe przełączenie serwerów najlepiej przeprowadzić w kontrolowanym oknie serwisowym.
Krok 3. Przygotowanie plików stref
Proste pliki stref BIND9 można zwykle bezpośrednio zaimportować do Technitium. Problem mogą jednak sprawić konstrukcje charakterystyczne dla BIND9, takie jak:
$INCLUDE,$GENERATE,- rekordy zapisane w plikach dziennika,
- strefy zapisane w formacie raw,
- strefy podzielone pomiędzy kilka plików.
Dlatego najbezpieczniej utworzyć ujednolicony plik za pomocą programu named-compilezone:
sudo named-compilezone -D \
-o /tmp/example.com.zone \
example.com \
/etc/bind/db.example.com
Program sprawdzi strefę, rozwinie część dyrektyw i zapisze wynik w jednym pliku. Podobnie przygotowujemy strefę odwrotną:
sudo named-compilezone -D \
-o /tmp/10.168.192.in-addr.arpa.zone \
10.168.192.in-addr.arpa \
/etc/bind/db.192.168.10
Na końcu każdą strefę warto dodatkowo zweryfikować:
sudo named-checkzone example.com /tmp/example.com.zone
Prawidłowy wynik powinien zakończyć się komunikatem:
OK
Krok 4. Uruchomienie Technitium w Dockerze
Technitium może działać jako zwykła usługa systemowa albo jako kontener. W tym przykładzie wykorzystamy Docker Compose.
services:
dns-server:
container_name: technitium
hostname: twister
image: docker.io/technitium/dns-server:latest
ports:
- "5380:5380/tcp"
- "53:53/udp"
- "53:53/tcp"
environment:
- DNS_SERVER_DOMAIN=twister.example.lan
- DNS_SERVER_RECURSION=AllowOnlyForPrivateNetworks
- DNS_SERVER_LOG_USING_LOCAL_TIME=true
volumes:
- ./config:/etc/dns
- ./logs:/var/log/technitium/dns
restart: unless-stopped
sysctls:
- net.ipv4.ip_local_port_range=1024 65535
Następnie uruchamiamy kontener:
docker compose up -d
Stan usługi można sprawdzić za pomocą dwóch poleceń:
docker compose ps
docker logs technitium
Panel administracyjny będzie dostępny pod adresem:
http://192.168.10.11:5380
Przy pierwszym logowaniu należy od razu zmienić hasło administratora. Ponadto dostęp do panelu warto ograniczyć na firewallu wyłącznie do sieci administracyjnej. Docelowo połączenie powinno być zabezpieczone przez HTTPS albo reverse proxy.
Ważne: zmienne środowiskowe służą głównie do początkowej konfiguracji. Po utworzeniu danych w katalogu /etc/dns kolejne zmiany najlepiej wykonywać w panelu WWW albo przez API.
Technitium i serwer DHCP
Powyższa konfiguracja wykorzystuje standardowe mapowanie portów i jest odpowiednia dla usługi DNS. Jeżeli jednak zamierzamy uruchomić również wbudowany serwer DHCP, należy rozważyć tryb sieciowy hosta:
network_mode: "host"
W takim przypadku sekcję ports trzeba usunąć. Serwer DHCP musi bowiem odbierać pakiety rozgłoszeniowe z lokalnej sieci, czego standardowa sieć bridge Dockera zwykle nie zapewnia.
Krok 5. Konfiguracja rekursji
Technitium może jednocześnie pełnić rolę serwera autorytatywnego i rekursywnego. Jednak dostęp do rekursji musi być prawidłowo ograniczony.
Dla serwera działającego wyłącznie w sieci lokalnej można zastosować ustawienie:
AllowOnlyForPrivateNetworks
W bardziej rozbudowanym środowisku lepiej wskazać konkretne podsieci za pomocą reguł dostępu. Dzięki temu z resolvera będą mogli korzystać wyłącznie uprawnieni klienci.
Nie należy udostępniać otwartej rekursji w Internecie. W przeciwnym razie serwer może zostać wykorzystany między innymi do ataków DNS amplification.
Jeżeli Technitium ma działać wyłącznie jako publiczny serwer autorytatywny, rekursję najlepiej całkowicie wyłączyć.
Krok 6. Import strefy do Technitium
W panelu Technitium przechodzimy do sekcji Zones, a następnie wybieramy Add Zone.
Dla strefy, której Technitium ma być głównym źródłem danych, wskazujemy:
- typ strefy: Primary,
- nazwę strefy, na przykład example.com,
- opcję importu pliku strefy.
Następnie importujemy przygotowany wcześniej plik:
/tmp/example.com.zone
Po zakończeniu importu należy sprawdzić przede wszystkim:
- rekord SOA,
- numer seryjny SOA,
- rekordy NS,
- rekordy A i AAAA,
- rekordy MX,
- rekordy TXT,
- rekordy CNAME,
- rekordy SRV,
- rekordy CAA,
- wartości TTL.
Szczególnie ważny jest numer seryjny w rekordzie SOA. Nie powinien być niższy niż numer używany na dotychczasowym serwerze. Serwery secondary porównują bowiem numery seryjne i pobierają strefę dopiero po wykryciu nowszej wersji.
Bezpieczniejsza metoda: Technitium najpierw jako secondary
Zamiast ręcznie importować strefę i natychmiast przełączać usługę, można najpierw skonfigurować Technitium jako serwer secondary dla działającego BIND9. Jest to bezpieczniejsza i wygodniejsza metoda migracji.
W konfiguracji strefy BIND9 zezwalamy nowemu serwerowi na transfer. Ponadto kierujemy do niego komunikaty DNS NOTIFY:
zone "example.com" {
type primary;
file "/etc/bind/db.example.com";
allow-transfer {
192.168.10.11;
};
also-notify {
192.168.10.11;
};
notify yes;
};
W starszych konfiguracjach zamiast słowa primary może występować master. Oba określenia są obsługiwane, chociaż obecnie zaleca się stosowanie nazw primary i secondary.
Po zapisaniu zmian sprawdzamy konfigurację i przeładowujemy usługę:
sudo named-checkconf
sudo rndc reconfig
W Technitium tworzymy natomiast strefę typu Secondary. Jako adres serwera primary podajemy:
192.168.10.10
Technitium pobierze pełną strefę za pomocą transferu AXFR. Kolejne zmiany mogą być przesyłane przyrostowo przez IXFR. Po otrzymaniu komunikatu DNS NOTIFY serwer secondary sprawdzi numer seryjny SOA i w razie potrzeby pobierze aktualizację.
Takie rozwiązanie ma kilka zalet. Po pierwsze, nie trzeba ręcznie kopiować kolejnych zmian. Po drugie, można przez dłuższy czas porównywać odpowiedzi obu serwerów. Co więcej, Technitium cały czas otrzymuje aktualną wersję strefy.
Dopiero po zakończeniu testów można zmienić rolę Technitium na primary. Następnie należy ponownie sprawdzić rekord SOA, rekordy NS oraz ustawienia transferu stref.
Porty wymagane dla DNS
Firewall musi przepuszczać zarówno UDP, jak i TCP na porcie 53.
- UDP 53 – większość standardowych zapytań DNS i komunikaty NOTIFY,
- TCP 53 – transfery AXFR i IXFR oraz większe odpowiedzi DNS.
Częstym błędem jest dopuszczenie wyłącznie UDP 53. W rezultacie zwykłe zapytania działają, natomiast transfer strefy kończy się błędem albo przekroczeniem czasu oczekiwania.
Zabezpieczenie transferów za pomocą TSIG
Ograniczenie transferu do konkretnego adresu IP jest podstawowym zabezpieczeniem. Nie zapewnia jednak kryptograficznego uwierzytelnienia serwera.
Dlatego w środowisku produkcyjnym warto zastosować klucz TSIG. Ten sam klucz należy skonfigurować po obu stronach transferu.
TSIG może zabezpieczać między innymi:
- sprawdzanie rekordu SOA,
- komunikaty DNS NOTIFY,
- transfery AXFR,
- transfery IXFR.
Kluczy TSIG nie należy umieszczać w publicznym repozytorium. Ponadto powinny być przekazywane wyłącznie bezpiecznym kanałem.
Krok 7. Migracja stref odwrotnych PTR
Podczas migracji nie wolno pominąć stref odwrotnych. Są one wykorzystywane między innymi przez systemy pocztowe, mechanizmy uwierzytelniania, monitoring i narzędzia diagnostyczne.
Dla sieci:
192.168.10.0/24
typowa nazwa strefy odwrotnej będzie wyglądała następująco:
10.168.192.in-addr.arpa
Po imporcie sprawdzamy wybrany rekord PTR:
dig @192.168.10.11 -x 192.168.10.20
Trzeba zachować szczególną ostrożność przy prefiksach innych niż /8, /16 i /24. Na przykład delegacja publicznej podsieci /26 może wykorzystywać mechanizm classless reverse DNS opisany w RFC 2317.
W takim przypadku nazwa strefy oraz rekordy CNAME zależą od sposobu delegowania zastosowanego przez operatora. Dlatego nie należy samodzielnie tworzyć uproszczonej strefy /24 bez wcześniejszego sprawdzenia delegacji.
Krok 8. Porównanie odpowiedzi serwerów
Przed przełączeniem klientów trzeba porównać odpowiedzi BIND9 i Technitium. Najpierw sprawdzamy rekord SOA:
dig @192.168.10.10 example.com SOA +noall +answer
dig @192.168.10.11 example.com SOA +noall +answer
Następnie porównujemy rekordy NS:
dig @192.168.10.10 example.com NS +noall +answer
dig @192.168.10.11 example.com NS +noall +answer
W podobny sposób sprawdzamy serwery pocztowe:
dig @192.168.10.10 example.com MX +noall +answer
dig @192.168.10.11 example.com MX +noall +answer
Później testujemy rekordy TXT:
dig @192.168.10.10 example.com TXT +noall +answer
dig @192.168.10.11 example.com TXT +noall +answer
Na końcu sprawdzamy zwykły rekord hosta oraz zapytanie odwrotne:
dig @192.168.10.10 www.example.com A +noall +answer
dig @192.168.10.11 www.example.com A +noall +answer
dig @192.168.10.10 -x 192.168.10.20 +noall +answer
dig @192.168.10.11 -x 192.168.10.20 +noall +answer
Ponadto warto przetestować rekordy SRV, CAA, DKIM oraz dane używane do weryfikacji usług chmurowych.
Krok 9. Przełączenie klientów
W sieci lokalnej adres serwera DNS jest najczęściej przekazywany przez DHCP. Dlatego wystarczy zmienić opcję DNS Server, zwykle oznaczoną jako DHCP Option 6.
Następnie odnawiamy dzierżawę DHCP na komputerze testowym i sprawdzamy konfigurację:
ipconfig /all
W systemie Linux można użyć polecenia:
resolvectl status
Jeżeli adresy DNS są skonfigurowane statycznie na serwerach, urządzeniach sieciowych albo hypervisorach, trzeba je zaktualizować oddzielnie.
W pierwszym okresie można przekazywać klientom oba adresy DNS. Technitium będzie wtedy serwerem podstawowym, natomiast BIND9 pozostanie serwerem dodatkowym.
Nie należy jednak traktować kolejności adresów jako gwarantowanego mechanizmu przełączania awaryjnego. System operacyjny może bowiem wysyłać zapytania do obu serwerów albo zmieniać ich kolejność na podstawie czasu odpowiedzi.
Przełączenie publicznej strefy DNS
W przypadku publicznej domeny migracja wymaga dodatkowych przygotowań. Przede wszystkim należy odpowiednio wcześniej obniżyć wartości TTL.
Następnie trzeba:
- uruchomić nowy serwer pod docelowym publicznym adresem IP,
- sprawdzić dostępność UDP i TCP 53 z Internetu,
- dodać nowy serwer do rekordów NS,
- w razie potrzeby zaktualizować glue records u rejestratora,
- odczekać co najmniej przez okres starego TTL,
- dopiero później usunąć stary serwer NS.
Jeżeli aktualny TTL wynosi 86400 sekund, jego obniżenie należy wykonać przynajmniej dobę przed migracją. Dzięki temu stare informacje szybciej znikną z pamięci podręcznej resolverów.
Migracja strefy zabezpieczonej DNSSEC
Migracja DNSSEC wymaga osobnego planu. Rekord DS zapisany w strefie nadrzędnej musi bowiem odpowiadać kluczowi publikowanemu przez serwery autorytatywne.
Jeżeli Technitium wygeneruje nowe klucze, a w strefie nadrzędnej pozostanie stary rekord DS, domena może przestać działać dla resolverów walidujących DNSSEC. Dlatego nie należy wymieniać kluczy bez wcześniejszego przygotowania.
Plan migracji powinien obejmować:
- publikację nowych rekordów DNSKEY,
- odczekanie wymaganych czasów propagacji,
- aktualizację rekordu DS u rejestratora,
- sprawdzenie odpowiedzi DNSSEC,
- kontrolowane wycofanie starych kluczy.
Po migracji można sprawdzić odpowiedź poleceniem:
dig +dnssec example.com SOA
Do dodatkowej walidacji przyda się również:
delv example.com
Primary i secondary w Technitium
Po zakończeniu migracji warto utrzymywać przynajmniej dwa serwery DNS. Na pierwszym tworzymy strefę typu Primary, natomiast na drugim strefę typu Secondary.
Na serwerze primary konfigurujemy:
- adres IP serwera secondary uprawnionego do transferu,
- wysyłanie komunikatów DNS NOTIFY,
- opcjonalny klucz TSIG,
- rekord NS wskazujący serwer secondary.
Z kolei na serwerze secondary podajemy:
- nazwę strefy,
- adres serwera primary,
- ustawienia transferu,
- klucz TSIG, jeżeli jest wymagany.
Strefa secondary pozostaje kopią tylko do odczytu. Dlatego wszystkie rekordy należy zmieniać na serwerze primary. Po zwiększeniu numeru seryjnego SOA secondary otrzyma komunikat DNS NOTIFY i pobierze aktualizację.
Czego nie przeniesie plik strefy?
Import pliku strefy przenosi rekordy DNS, ale nie przenosi całej logiki konfiguracji BIND9. Oddzielnie trzeba więc odtworzyć:
- ACL i ograniczenia dostępu,
- politykę rekursji,
- forwardery,
- conditional forwarders,
- klucze TSIG,
- reguły dynamicznych aktualizacji,
- aktualizacje rekordów wykonywane przez DHCP,
- ustawienia DNSSEC,
- BIND views,
- Response Policy Zones,
- niestandardowe mechanizmy logowania.
BIND views nie mają prostego odpowiednika w pliku importowanym do Technitium. Podobne działanie można jednak uzyskać za pomocą mechanizmu Split Horizon, stref warunkowych albo oddzielnych instancji serwera. Mimo to taki scenariusz wymaga indywidualnego projektu.
Typowe problemy podczas migracji
Port 53 jest już zajęty
Najpierw sprawdzamy proces nasłuchujący na porcie DNS:
sudo ss -lntup | grep ':53'
Port może być zajęty przez BIND9, dnsmasq, systemd-resolved albo inny kontener.
Panel działa, ale serwer nie odpowiada na zapytania
W pierwszej kolejności należy sprawdzić mapowanie obu protokołów:
53:53/udp
53:53/tcp
Następnie trzeba zweryfikować lokalny firewall, reguły sieci kontenerowej oraz ustawienia nasłuchiwania Technitium.
Secondary nie pobiera strefy
Najczęstsze przyczyny to:
- zablokowany TCP 53,
- brak adresu secondary na liście dozwolonych transferów,
- niezgodny klucz TSIG,
- błędny adres serwera primary,
- niezwiększony numer seryjny SOA,
- brak komunikatów DNS NOTIFY.
Po restarcie kontenera znika konfiguracja
Najczęściej oznacza to brak trwałego wolumenu dla katalogu:
/etc/dns
Konfiguracja i strefy muszą znajdować się poza zapisywalną warstwą kontenera. W przeciwnym razie zostaną utracone po odtworzeniu instancji.
Rekord PTR nie działa
W takim przypadku należy sprawdzić:
- nazwę strefy
in-addr.arpa,
- kolejność oktetów adresu IP,
- delegację strefy odwrotnej,
- rekordy NS,
- sposób delegowania podsieci przez operatora.
Serwer odpowiada rekursywnie klientom z Internetu
Jest to poważny błąd konfiguracji. Dlatego należy natychmiast wyłączyć rekursję albo ograniczyć ją do zaufanych podsieci.
Podsumowanie
Migracja z BIND9 do Technitium DNS Server nie musi oznaczać ryzykownego wyłączenia starej usługi i natychmiastowego uruchomienia nowej. Najbezpieczniej rozpocząć od równoległej instalacji i skonfigurować Technitium jako secondary.
Następnie należy zsynchronizować strefy oraz porównać odpowiedzi obu serwerów. Dopiero po sprawdzeniu rekordów SOA, NS, MX, TXT, rekordów hostów i stref odwrotnych można przełączyć klientów.
Technitium nie usuwa technicznej złożoności systemu DNS. Jednak znacznie upraszcza codzienną administrację, diagnostykę oraz delegowanie dostępu. Dlatego w środowisku, w którym BIND9 działa poprawnie, ale zarządzanie plikami staje się niewygodne, jest to rozwiązanie zdecydowanie warte przetestowania.
G
Tagi:
DNS,
Docker,
Linux,
serwer 
Podczas aktualizacji Nextcloud działającego w kontenerach Docker często pomija się jeden istotny element: indeksy bazy danych. 
