Serwer DNS
Konfiguracja Serwera DNS3 minute read
DNS (Domain Name System) to podstawowy mechanizm infrastruktury sieciowej odpowiedzialny za zamianę nazw domenowych na adresy IP (forward lookup) oraz adresów IP na nazwy domenowe (reverse lookup – rekordy PTR).
W projekcie iac-mikrotik serwer DNS oparty jest o resolver systemu RouterOS i zarządzany deklaratywnie przy użyciu OpenTofu.
Struktura plików
Konfiguracja DNS znajduje się w katalogu:
router.rachuna-net.pl/dns-server/main.tf
Zalety takiego podejścia:
- centralne zarządzanie resolverem,
- wersjonowanie konfiguracji,
- szybki rollback,
- spójność dla całego środowiska.
Przykład konfiguracji serwera DNS
module "dns_server" {
source = "git@gitlab.rachuna-net.pl:pl.rachuna-net/infrastructure/opentofu/modules/routeros-dns.git?ref=v1.0.0"
allow_remote_requests = true
cache_max_ttl = "1d"
max_concurrent_queries = 1000
servers = ["1.1.1.1", "8.8.8.8"]
dynamic_servers = []
comment = "DNS resolver/router"
}
Omówienie parametrów technicznych
1. Parametry instancji serwera DNS
| Parametr | Znaczenie |
|---|---|
allow_remote_requests |
Zezwala klientom sieciowym na korzystanie z resolvera |
cache_max_ttl |
Maksymalny czas przechowywania odpowiedzi w cache |
max_concurrent_queries |
Limit równoległych zapytań DNS |
servers |
Lista serwerów DNS upstream |
dynamic_servers |
Serwery DNS pobierane dynamicznie (np. z DHCP ISP) |
comment |
Opis administracyjny |
2. Rola cache DNS
Mechanizm cache:
- znacząco redukuje liczbę zapytań wychodzących,
- poprawia wydajność sieci,
- zwiększa odporność na chwilowe awarie upstream.
W konfiguracji:
cache_max_ttl = "1d"
oznacza, że odpowiedzi mogą być przechowywane przez maksymalnie 24 godziny.
3. Serwery upstream
servers = ["1.1.1.1", "8.8.8.8"]
Oznacza to wykorzystanie:
- **Cloudflare DNS –
1.1.1.1, - **Google DNS –
8.8.8.8.
Zastosowanie co najmniej dwóch niezależnych operatorów DNS zwiększa odporność na awarie.
Integracja DNS z DHCP
W projekcie iac-mikrotik DNS jest bezpośrednio powiązany z DHCP:
-
każdy lease z
hostname, -
automatycznie tworzy:
- rekord A,
- rekord PTR,
-
umożliwia rozwiązywanie nazw lokalnych:
pve-s1.rachuna-net.pl → 10.3.0.11
10.3.0.11 → pve-s1.rachuna-net.pl
Dzięki temu:
- hosty są widoczne po nazwach,
- działa poprawnie Kerberos, LDAP, TLS, monitoring, HA Proxmox.
Zasady projektowe i dobre praktyki
1. Ogólne zasady
- Jeden centralny resolver DNS dla całej infrastruktury
- DNS zawsze wskazywany przez DHCP
- DNS zawsze działa na routerze brzegowym
- Brak konfiguracji DNS bezpośrednio na hostach
2. Bezpieczeństwo
-
allow_remote_requestspowinien być:- włączony tylko dla sieci zaufanych,
-
brak otwartego DNS do Internetu,
-
firewall powinien blokować:
- zapytania DNS spoza infrastruktury.
3. Spójność DNS i TLS
-
Każdy host produkcyjny powinien posiadać:
- rekord A,
- rekord PTR,
-
Brak PTR = problemy z:
- pocztą,
- certyfikatami,
- monitoringiem,
- logami.
Typowe błędy i jak ich unikać
| Problem | Przyczyna | Rozwiązanie |
|---|---|---|
| DNS nie odpowiada | allow_remote_requests = false |
Ustaw na true |
| Brak internetu mimo IP | Brak upstream DNS | Ustaw servers |
| Brak PTR | Brak integracji z DHCP | Używaj hostname w lease |
| Timeouty DNS | Zbyt niski max_concurrent_queries |
Zwiększ limit |
Podsumowanie
Serwer DNS w iac-mikrotik zapewnia:
- centralny, cache’ujący resolver,
- dynamiczne rekordy A i PTR z DHCP,
- wysoką wydajność dzięki cache,
- pełną deklaratywność w IaC,
- brak ręcznej konfiguracji RouterOS,
- spójność nazw w całym środowisku IT.
Jeżeli chcesz, mogę dodatkowo przygotować:
- dokumentację rekordów statycznych DNS (A, CNAME, TXT),
- integrację DNS z Vault PKI,
- model DNS dla Proxmox + Kubernetes + Wi-Fi + DMZ,
- checklistę audytową DNS pod bezpieczeństwo.