Saját DNS‑szerver beállítása lépésről lépésre: szükséges eszközök, szoftverek és biztonsági beállítások

Az internet infrastruktúrájának egyik legkevésbé látható, mégis legfontosabb eleme a Domain Name System (DNS). Ez a rendszer felelős azért, hogy a könnyen megjegyezhető domain neveket (például: google.com) lefordítsa a gépek számára érthető IP-címekre (például: 172.217.160.142). Habár a legtöbb felhasználó az internetszolgáltatója által biztosított DNS-szervereket használja, egyre többen ismerik fel a saját DNS-szerver üzemeltetésében rejlő előnyöket. Ez a cikk részletesen bemutatja, hogyan állíthat be egy ilyen rendszert, milyen eszközökre és szoftverekre lesz szüksége, és hogyan biztosíthatja annak biztonságos működését.

Miért érdemes saját DNS-szervert üzemeltetni?

A saját DNS-szerver beállítása elsőre bonyolultnak tűnhet, de számos jelentős előnnyel járhat, amelyek indokolttá teszik a befektetett időt és energiát. Ezek az előnyök túlmutatnak a puszta technikai érdekességen, és valós értékkel bírnak mind magánszemélyek, mind kisebb vállalkozások számára.

Az egyik legfőbb motiváció a függetlenség és a kontroll. Amikor az internetszolgáltató DNS-szervereit használja, teljes mértékben rájuk van utalva. Egy saját szerverrel azonban Ön dönti el, hogyan működik a feloldás, milyen rekordokat kezel, és milyen szűrési szabályokat alkalmaz. Ez a kontroll különösen fontos lehet azok számára, akik nem szeretnék, ha adataikat harmadik felek gyűjtenék vagy manipulálnák a DNS-kérések alapján.

Függetlenség és kontroll a hálózat felett

A saját DNS-szerverrel a hálózati forgalom feletti kontroll jelentősen megnő. Nem csak a feloldási sebességet és megbízhatóságot optimalizálhatja, hanem a hozzáférési szabályokat is finomhangolhatja. Ez magában foglalja a belső hálózati erőforrások (pl. NAS, szerverek) elnevezését egyedi, könnyen megjegyezhető domain nevekkel, anélkül, hogy ezeket a nyilvános DNS-be regisztrálná.

A testreszabhatóság egy másik kulcsfontosságú szempont. Egy saját szerver lehetővé teszi, hogy egyéni szabályokat állítson be, például reklámblokkolást valósítson meg hálózati szinten. Ez azt jelenti, hogy minden, a hálózaton található eszköz (számítógép, okostelefon, okostévé) automatikusan szűrve lesz a reklámoktól, javítva ezzel a böngészési élményt és csökkentve az adathasználatot. Ezen felül, rosszindulatú webhelyek feketelistáit is integrálhatja, növelve ezzel a hálózat biztonságát.

Sebesség és megbízhatóság optimalizálása

A saját DNS-szerver beállításával javíthatja a sebességet és a megbízhatóságot. Az internetszolgáltatók DNS-szerverei gyakran túlterheltek lehetnek, vagy földrajzilag távol eshetnek, ami lassabb válaszidőket eredményez. Egy helyi, jól optimalizált DNS-szerver, amely gyorsítótárazza a gyakran látogatott oldalak IP-címeit, jelentősen felgyorsíthatja a weboldalak betöltését.

A megbízhatóság szempontjából, ha az internetszolgáltató DNS-szerverei leállnak, az internet-hozzáférés teljesen meghiúsulhat. Egy saját szerverrel ez a kockázat minimalizálható, különösen, ha redundáns beállításokat alkalmaz. Ez a fajta hálózati reziliencia kritikus lehet otthoni irodák és kisvállalkozások számára.

Adatvédelem és biztonság fokozása

Az adatvédelem és biztonság napjainkban egyre fontosabb. Amikor harmadik fél DNS-szervereit használja, DNS-kérései nyomon követhetők, és profilozásra használhatók fel. Egy saját DNS-szerverrel, amelyet megfelelően konfigurált és titkosított protokollokat (mint a DNS over TLS vagy DNS over HTTPS) használ, jelentősen csökkentheti ezt a kockázatot.

A saját DNS-szerver üzemeltetése nem csupán technikai kihívás, hanem egy befektetés a hálózati függetlenségbe, biztonságba és optimalizált teljesítménybe.

Ezenkívül, a DNSSEC (Domain Name System Security Extensions) implementálásával megakadályozhatja a DNS-hamisítást és a cache poisoning támadásokat, amelyek során rosszindulatú IP-címekre irányítanák át a felhasználókat. A saját szerver teljes kontrollt biztosít a DNSSEC beállítások felett, garantálva a válaszok hitelességét.

A DNS alapjai és működése

Mielőtt belevágnánk a saját DNS-szerver beállításába, elengedhetetlen, hogy alaposan megértsük a Domain Name System működését. A DNS az internet telefonkönyveként funkcionál, amely a könnyen megjegyezhető domain neveket a gépek által használt numerikus IP-címekké fordítja. Ennek hiányában minden webhelyet IP-cím alapján kellene elérnünk, ami gyakorlatilag lehetetlenné tenné az internet használatát.

Mi az a DNS és hogyan működik?

Amikor beír egy domain nevet a böngészőjébe, például example.com, a számítógépe nem tudja azonnal, hova kell csatlakoznia. Ehelyett elküld egy DNS-lekérdezést a konfigurált DNS-szerverének. Ez a szerver felelős azért, hogy megkeresse a example.com-hoz tartozó IP-címet.

A DNS-rendszer egy hierarchikus, elosztott adatbázis. Nincsen egyetlen központi szerver, amely az összes információt tárolja. Ehelyett a feladatot számos szerver osztja meg egymás között, a gyökérszerverektől (root servers) kezdve, a felső szintű domain (TLD) szervereken át, egészen az autoritatív névszerverekig.

A feloldási folyamat lépésről lépésre

A DNS-feloldás egy összetett folyamat, amely több lépésből áll:

1. A felhasználó beír egy domain nevet a böngészőbe.
2. A számítógép először ellenőrzi a helyi DNS-gyorsítótárát. Ha megtalálja az IP-címet, közvetlenül oda csatlakozik.
3. Ha nincs a gyorsítótárban, a számítógép elküldi a lekérdezést a rekurzív DNS-szervernek (általában az internetszolgáltató szervere vagy a saját szerverünk).
4. A rekurzív szerver felveszi a kapcsolatot a gyökérszerverekkel (root servers), amelyek megmondják neki, mely TLD szerver felelős a .com domainekért.
5. Ezután a rekurzív szerver a TLD szerverhez fordul, amely megadja az example.com autoritatív névszerverének címét.
6. Végül a rekurzív szerver az autoritatív névszerverhez fordul, amely közvetlenül ismeri az example.com IP-címét, és ezt az információt visszaküldi a rekurzív szervernek.
7. A rekurzív szerver elmenti az IP-címet a gyorsítótárába (TTL – Time To Live értékig), és elküldi a felhasználó számítógépének.
8. A számítógép ezután csatlakozik az IP-címhez, és betölti a weboldalt.

Autoritatív és rekurzív DNS-szerverek

Két fő típusa van a DNS-szervereknek, amelyek eltérő szerepeket töltenek be a feloldási folyamatban:

• Autoritatív névszerver (Authoritative Name Server): Ez a szerver tárolja az adott domainhez tartozó összes DNS-rekordot (pl. A, AAAA, MX, CNAME, NS rekordok). Amikor egy rekurzív szerver lekérdezi egy domain IP-címét, az autoritatív szerver adja meg a végleges, „autoritatív” választ. Egy weboldal, amelynek domainje example.com, rendelkezik legalább két autoritatív névszerverrel (pl. ns1.example.com, ns2.example.com), amelyek a domain regisztrátornál vannak beállítva.
• Rekurzív névszerver (Recursive Name Server) / Gyorsítótárazó névszerver (Caching Name Server): Ez a szerver az, amellyel a felhasználó számítógépe közvetlenül kommunikál. Feladata, hogy a felhasználó nevében végigjárja a DNS-hierarchiát, lekérdezze a szükséges információkat az autoritatív szerverektől, majd visszaküldje az eredményt a felhasználónak. Emellett gyorsítótárazza (cache-eli) a már lekérdezett információkat, hogy a jövőbeli kérésekre gyorsabban tudjon válaszolni. A saját DNS-szerverünk általában rekurzív és gyorsítótárazó szerverként működik.

Egy saját DNS-szerver beállításakor általában egy rekurzív/gyorsítótárazó szervert hozunk létre a saját hálózatunk számára. Ha azonban saját domain nevet is üzemeltetünk, akkor érdemes lehet egy autoritatív szervert is beállítani a domain rekordjainak kezelésére.

Szükséges előismeretek és hardveres feltételek

A saját DNS-szerver telepítése és konfigurálása nem egy plug-and-play megoldás, hanem bizonyos szintű technikai tudást és alapvető infrastruktúrát igényel. Fontos, hogy tisztában legyünk ezekkel az előfeltételekkel, mielőtt belevágnánk a projektbe.

Technikai tudás és készségek

A DNS-szerver üzemeltetéséhez az alábbi területeken szükséges legalább alapvető, de inkább középszintű ismeretekkel rendelkezni:

• Linux operációs rendszer ismerete: A legtöbb DNS-szerver szoftver Linux alapú rendszereken fut a legstabilabban és legbiztonságosabban. Ismerni kell az alapvető parancssori műveleteket, a fájlrendszer struktúráját, a csomagkezelést (pl. apt, yum), és a rendszerindítási folyamatokat.
• Hálózati alapok: Meg kell érteni az IP-címeket, alhálózatokat, átjárókat, tűzfalakat és a portok működését. A statikus IP-cím beállítása és a hálózati konfigurációs fájlok szerkesztése mindennapos feladat lesz.
• DNS alapok: Ahogy azt korábban tárgyaltuk, a DNS működésének, a rekordtípusoknak (A, AAAA, MX, NS, CNAME, TXT, SRV, PTR) és a zónafájloknak az ismerete elengedhetetlen.
• Biztonsági alapelvek: A tűzfalak konfigurálása, a szoftverek frissen tartása, a naplók értelmezése és a biztonsági rések felismerése kulcsfontosságú.
• Szövegszerkesztő használata: A konfigurációs fájlok szerkesztéséhez a nano, vi vagy vim parancssori szövegszerkesztők ismerete hasznos.

A saját DNS-szerver beállítása egy kiváló lehetőség a hálózati ismeretek elmélyítésére, de ne becsüljük alá a szükséges tanulási görbét.

Hardver opciók: mit használjunk DNS-szervernek?

A DNS-szerver nem igényel hatalmas erőforrásokat, de stabil és folyamatos működést biztosító hardverre van szükség. Több lehetőség is szóba jöhet:

Hardver típus	Előnyök	Hátrányok	Ajánlott felhasználás
Virtuális magánszerver (VPS)	Könnyű telepítés, skálázhatóság, külső elérés, megbízható infrastruktúra.	Havi díj, kevesebb fizikai kontroll, megosztott erőforrások.	Kisebb vállalkozások, nyilvánosan elérhető autoritatív szerverek.
Dedikált szerver	Teljes kontroll, magas teljesítmény, fizikai biztonság.	Magasabb költségek (beszerzés, üzemeltetés), karbantartás.	Nagyobb hálózatok, kritikus infrastruktúrák.
Raspberry Pi vagy más mini PC	Alacsony beszerzési és üzemeltetési költség, kis méret, csendes működés.	Korlátozott teljesítmény, otthoni internetkapcsolat függősége, áramkimaradás kockázata.	Otthoni hálózatok, kisebb irodák, gyorsítótárazó DNS-szerver.
Régebbi PC	Nincs beszerzési költség, ha van otthon felesleges gép.	Magasabb fogyasztás, nagyobb zaj, helyigény, megbízhatósági kérdések.	Kísérletezés, fejlesztés, nem kritikus feladatok.

Otthoni használatra a Raspberry Pi kiváló választás lehet gyorsítótárazó és rekurzív DNS-szervernek, esetleg egy kisebb autoritatív szervernek, ha a domainje nem kritikus fontosságú. A VPS ideális, ha nyilvánosan elérhető autoritatív szervert szeretne üzemeltetni, vagy ha a megbízhatóság és a külső elérés prioritás.

Operációs rendszer kiválasztása

A DNS-szerverekhez a Linux operációs rendszerek a legelterjedtebbek és legmegbízhatóbbak. Az alábbi disztribúciók különösen népszerűek a szerverekhez:

• Ubuntu Server: Nagyon népszerű, széles körű közösségi támogatással és rengeteg online dokumentációval rendelkezik. Kezdők számára is viszonylag könnyen kezelhető.
• Debian: Az Ubuntu alapja, rendkívül stabil és megbízható. Kevésbé gyakori frissítésekkel, ami stabilitást jelent, de néha régebbi szoftververziókat is.
• CentOS / Rocky Linux / AlmaLinux: Red Hat alapú disztribúciók, amelyek a vállalati környezetben népszerűek. Robusztusak és hosszú távú támogatást biztosítanak.
• FreeBSD: Bár nem Linux, hanem egy Unix-szerű operációs rendszer, kiválóan alkalmas szerverfeladatokra a stabilitása és biztonsága miatt. Némi plusz ismeretet igényelhet.

A választás során vegye figyelembe saját tapasztalatát és azt, hogy melyik disztribúcióhoz talál a legtöbb segítséget az interneten. Kezdőknek az Ubuntu Server vagy a Debian ajánlott.

Szoftverek választéka DNS-szerverhez

A DNS-szerver funkcionalitását különböző szoftverek biztosítják, amelyek eltérő képességekkel, konfigurációs lehetőségekkel és teljesítményjellemzőkkel rendelkeznek. Fontos, hogy a projektjéhez leginkább illő szoftvert válassza ki.

BIND (Berkeley Internet Name Domain)

A BIND (gyakran BIND9 néven emlegetik a jelenlegi verzió miatt) a legelterjedtebb DNS-szerver szoftver az interneten. Szinte az összes domain névhez tartozó autoritatív szerverek jelentős része BIND-et futtat.

• Előnyök: Rendkívül robusztus, stabil, nagy teljesítményű, széles körű funkcionalitással rendelkezik (autoritatív és rekurzív is lehet), kiválóan skálázható, és rengeteg dokumentáció, valamint közösségi támogatás áll rendelkezésre. Támogatja a DNSSEC-et.
• Hátrányok: Konfigurálása bonyolult lehet a kezdők számára, a konfigurációs fájlok szintaxisa összetett. A biztonsági beállítások gondos odafigyelést igényelnek.
• Ajánlott felhasználás: Publikus autoritatív névszerverek, nagyvállalati környezetek, tapasztalt rendszergazdák számára, akik teljes kontrollt szeretnének.

Unbound

Az Unbound egy modern, validáló, rekurzív és gyorsítótárazó DNS-szerver, amelyet kifejezetten a biztonságra és a teljesítményre optimalizáltak. Csak rekurzív funkciókat lát el, autoritatív szerverként nem működik.

• Előnyök: Kiemelkedő sebesség, alacsony erőforrás-igény, egyszerűbb konfiguráció mint a BIND-nél, beépített DNSSEC validáció, DNS over TLS (DoT) támogatás.
• Hátrányok: Csak rekurzív szerverként működik, nem alkalmas autoritatív szerepkörre.
• Ajánlott felhasználás: Otthoni hálózatok, kisebb irodák, személyes gyorsítótárazó és validáló DNS-szerver, ahol a sebesség és a biztonság prioritás.

PowerDNS

A PowerDNS egy moduláris DNS-szerver, amely különféle „backendek” (pl. adatbázisok, LDAP, fájlok) segítségével képes kezelni a DNS-rekordokat. Két fő komponense van: a PowerDNS Authoritative Server és a PowerDNS Recursor.

• Előnyök: Rendkívül rugalmas és skálázható, könnyen integrálható meglévő adatbázis-rendszerekkel, kiválóan alkalmas dinamikus DNS-re és API-alapú kezelésre. Támogatja a DNSSEC-et.
• Hátrányok: A moduláris felépítés miatt a konfiguráció bonyolultabb lehet, mint az Unbound esetében.
• Ajánlott felhasználás: Nagyobb, dinamikus környezetek, ahol az adatbázis alapú rekordkezelés előnyös, vagy ahol API-n keresztül szeretnék automatizálni a DNS-t.

Dnsmasq

A Dnsmasq egy könnyűsúlyú DNS-gyorsítótárazó és DHCP-szerver, amelyet kis hálózatokhoz terveztek. Képes DNS-lekérdezéseket továbbítani (forwarding) és helyi DNS-rekordokat is kezelni.

• Előnyök: Rendkívül egyszerű telepítés és konfiguráció, alacsony erőforrás-igény, integrált DHCP-szerver.
• Hátrányok: Korlátozott funkcionalitás a nagyobb szerverekhez képest, nem támogatja a DNSSEC-et natívan, nem alkalmas autoritatív szervernek.
• Ajánlott felhasználás: Otthoni routerek, Raspberry Pi alapú hálózati eszközök, ahol egy egyszerű, gyorsítótárazó DNS-re és DHCP-re van szükség.

Melyiket válasszuk?

A választás a projekt céljától és a technikai jártasságtól függ:

• Ha egy egyszerű, gyors, biztonságos és gyorsítótárazó DNS-szervert szeretne otthoni vagy kisebb irodai használatra, a Unbound a legjobb választás. Kiemelkedő teljesítményt nyújt, és egyszerűbb a konfigurációja.
• Ha egy teljes értékű autoritatív DNS-szervert szeretne üzemeltetni saját domainjéhez, vagy egy komplexebb rekurzív szerverre van szüksége, és nem riad vissza a bonyolultabb konfigurációtól, a BIND vagy a PowerDNS jöhet szóba. A BIND a „de facto” standard.
• Ha a legegyszerűbb megoldásra van szüksége, ami gyorsítótáraz és DHCP-t is szolgáltat, például egy Raspberry Pi-n, a Dnsmasq tökéletes.

Ebben a cikkben a továbbiakban a BIND9 telepítésére és konfigurálására fogunk fókuszálni, mint a legelterjedtebb és legátfogóbb megoldásra, de az alapelvek más szoftvereknél is hasonlóak. Az Unboundot is érdemes megfontolni a rekurzív szerepkörre.

A DNS-szerver beállítása lépésről lépésre (Példa: BIND9 Ubuntu rendszeren)

Most, hogy megismertük az elméleti alapokat és kiválasztottuk a szoftvert, lássuk a gyakorlati lépéseket egy BIND9 alapú DNS-szerver beállításához egy Ubuntu Server operációs rendszeren. Ez a leírás feltételezi, hogy már telepítette az Ubuntu Servert, és hozzáfér a parancssorhoz.

Előkészületek: statikus IP, tűzfal

Mielőtt bármilyen DNS-szoftvert telepítene, létfontosságú, hogy a szerver rendelkezzen statikus IP-címmel. Egy dinamikus IP-cím változhat, ami megszakítaná a DNS-szolgáltatást.

1. Statikus IP-cím beállítása:

   Az Ubuntu Serveren a hálózati beállítások a /etc/netplan/*.yaml fájlokban találhatók. Nyissa meg a megfelelő fájlt (általában 00-installer-config.yaml vagy hasonló) egy szövegszerkesztővel:

   sudo nano /etc/netplan/00-installer-config.yaml

   Módosítsa a fájlt a következőképpen (cserélje ki az IP-címeket, átjárót és DNS-szervereket a saját hálózati adataira):

   network:
     ethernets:
       enp0s3: # Cserélje ki a saját hálózati interfészére (pl. eth0)
         dhcp4: no
         addresses: [192.168.1.100/24] # Saját statikus IP-cím és alhálózati maszk
         routes:
           - to: default
             via: 192.168.1.1 # Saját alapértelmezett átjáró
         nameservers:
           addresses: [127.0.0.1, 8.8.8.8] # Kezdetben használhatja magát és egy publikus DNS-t
     version: 2

   Alkalmazza a Netplan konfigurációt:

   sudo netplan apply

   Ellenőrizze az IP-címet:

   ip a

2. Tűzfal beállítása (UFW):

   A Uncomplicated Firewall (UFW) egy egyszerűsített felület az iptables-hez. Telepítse, ha még nincs:

   sudo apt update
   sudo apt install ufw

   Engedélyezze a DNS-forgalmat (UDP/TCP port 53):

   sudo ufw allow 53/udp
   sudo ufw allow 53/tcp

   Ha SSH-n keresztül dolgozik, ne felejtse el engedélyezni az SSH-t (port 22):

   sudo ufw allow OpenSSH # vagy sudo ufw allow 22/tcp

   Engedélyezze a tűzfalat:

   sudo ufw enable

   Ellenőrizze az UFW állapotát:

   sudo ufw status verbose

BIND9 telepítése

A BIND9 telepítése Ubuntu rendszeren viszonylag egyszerű a csomagkezelő segítségével.

sudo apt update
sudo apt install bind9 bind9utils bind9-doc

Ezzel telepíti a BIND szervert, a segédprogramokat és a dokumentációt.

Alapvető konfiguráció (named.conf)

A BIND konfigurációs fájljai a /etc/bind/ könyvtárban találhatók. A fő konfigurációs fájl a named.conf, de gyakran több kisebb fájlra van bontva az átláthatóság érdekében.

1. named.conf.options:

   Nyissa meg a named.conf.options fájlt, és állítsa be a forwarder szervereket (ezekhez fordul majd a DNS-szerverünk, ha nem tudja feloldani a kérést):

   sudo nano /etc/bind/named.conf.options

   Keresse meg a forwarders { }; szakaszt, és adja meg a kívánt publikus DNS-szerverek IP-címeit (pl. Google DNS, Cloudflare DNS):

   options {
           directory "/var/cache/bind";
   
           // If there is a firewall between you and nameservers you want
           // to talk to, you may need to uncomment the query-source
           // directive and provide an address or port to use.
           // query-source address * port 53;
   
           // If your ISP provided one or more IP addresses for stable
           // nameservers, you probably want to use them as forwarders.
           // Uncomment the following block, and insert the addresses below.
           forwarders {
                   8.8.8.8; // Google Public DNS
                   1.1.1.1; // Cloudflare DNS
           };
   
           // ... többi opció ...
           dnssec-validation auto; // Fontos a DNSSEC validációhoz
           listen-on { any; }; // Meghallgatja az összes interfészt
           allow-query { any; }; // Mindenki kérdezhet (finomhangolható)
   };

   A listen-on { any; }; és allow-query { any; }; beállításokkal a szerver minden hálózati interfészen fogad kéréseket, és minden forrásból érkező lekérdezést engedélyez. Ezt érdemes később finomhangolni, hogy csak a megbízható IP-címekről fogadjon kéréseket (pl. allow-query { 192.168.1.0/24; };).

2. named.conf.local:

   Ez a fájl tartalmazza a helyi zónadefiníciókat, azaz azokat a domaineket, amelyeknek az autoritatív szervere a mi BIND szerverünk. Nyissa meg:

   sudo nano /etc/bind/named.conf.local

   Ide adhatja hozzá a saját domainjeinek (forward zóna) és a reverse zónáknak a definícióit. Például, ha a sajatdomain.hu domainhez és a 192.168.1.0/24 hálózathoz szeretne zónákat létrehozni:

   // Forward zóna a sajatdomain.hu-hoz
   zone "sajatdomain.hu" {
           type master;
           file "/etc/bind/db.sajatdomain.hu";
           allow-update { none; };
   };
   
   // Reverse zóna a 192.168.1.0/24 hálózathoz
   zone "1.168.192.in-addr.arpa" {
           type master;
           file "/etc/bind/db.192";
           allow-update { none; };
   };

   A type master; azt jelenti, hogy ez a szerver az elsődleges autoritatív forrás a zónához. A file megadja a zónafájl helyét.

Zónafájlok létrehozása (forward és reverse zónák)

A zónafájlok tartalmazzák a tényleges DNS-rekordokat. A BIND telepítésekor példafájlok is létrejönnek, amelyeket másolhat és módosíthat.

1. Példafájlok másolása:

   sudo cp /etc/bind/db.local /etc/bind/db.sajatdomain.hu
   sudo cp /etc/bind/db.127 /etc/bind/db.192

2. Forward zónafájl (db.sajatdomain.hu) szerkesztése:

   Nyissa meg a db.sajatdomain.hu fájlt:

   sudo nano /etc/bind/db.sajatdomain.hu

   Módosítsa a fájlt a saját adataira. Különösen figyeljen a SOA (Start of Authority) rekordra és a NS (Name Server) rekordokra. A @ jel a domain nevet jelöli (sajatdomain.hu).

   $TTL    604800
   @       IN      SOA     ns1.sajatdomain.hu. admin.sajatdomain.hu. (
                                 3         ; Serial
                            604800         ; Refresh
                             86400         ; Retry
                           2419200         ; Expire
                            604800 )       ; Negative Cache TTL
   ;
   @       IN      NS      ns1.sajatdomain.hu.
   @       IN      A       192.168.1.100 ; A domain IP-címe
   
   ns1     IN      A       192.168.1.100 ; A névszerver IP-címe
   www     IN      A       192.168.1.100 ; www aldomain IP-címe
   mail    IN      A       192.168.1.101 ; Mail szerver IP-címe
   admin   IN      A       192.168.1.102 ; Admin felület IP-címe
   ; További rekordok hozzáadása szükség szerint
   ; Például CNAME rekord:
   ; blog    IN      CNAME   www

   A Serial számot minden alkalommal növelni kell, amikor módosítja a zónafájlt, hogy a többi DNS-szerver észlelje a változást.

3. Reverse zónafájl (db.192) szerkesztése:

   A reverse zónafájl az IP-címeket fordítja vissza domain nevekké (PTR rekordok). Nyissa meg a db.192 fájlt:

   sudo nano /etc/bind/db.192

   Módosítsa a fájlt a saját hálózatára és domainjére. Figyeljen a SOA és NS rekordokra, valamint a PTR rekordokra.

   $TTL    604800
   @       IN      SOA     ns1.sajatdomain.hu. admin.sajatdomain.hu. (
                                 3         ; Serial
                            604800         ; Refresh
                             86400         ; Retry
                           2419200         ; Expire
                            604800 )       ; Negative Cache TTL
   ;
   @       IN      NS      ns1.sajatdomain.hu.
   100     IN      PTR     ns1.sajatdomain.hu. ; 192.168.1.100 -> ns1.sajatdomain.hu
   100     IN      PTR     sajatdomain.hu.     ; 192.168.1.100 -> sajatdomain.hu
   101     IN      PTR     mail.sajatdomain.hu.
   102     IN      PTR     admin.sajatdomain.hu.

   A PTR rekordoknál csak az IP-cím utolsó oktettjét kell megadni, mivel a zóna már definiálja az első három oktettet (1.168.192.in-addr.arpa).

Regisztráció a domain regisztrátornál (ha autoritatív szerver)

Ha a BIND szerverét a sajatdomain.hu domain autoritatív szervereként szeretné használni (azaz a nyilvános internetről is elérhetőnek kell lennie), akkor a domain regisztrátornál be kell állítania a névszervereket (NS rekordokat).

Ehhez szüksége lesz a DNS-szerverének nyilvános IP-címére. A regisztrátora felületén adja meg a következőt:

• Névszerver 1: ns1.sajatdomain.hu (IP-cím: a szerver nyilvános IP-címe)
• Névszerver 2: ns2.sajatdomain.hu (IP-cím: egy másik, redundáns DNS-szerver nyilvános IP-címe, ha van ilyen)

Ez a folyamat elengedhetetlen ahhoz, hogy a világ DNS-rendszere tudomást szerezzen arról, hol keresse a sajatdomain.hu rekordjait. A változások propagálása (elterjedése az interneten) akár 24-48 órát is igénybe vehet.

Tesztelés és ellenőrzés

Miután minden konfigurációs fájlt beállított, indítsa újra a BIND szolgáltatást:

sudo systemctl restart bind9

Ellenőrizze, hogy a szolgáltatás fut-e, és nincsenek-e hibák:

sudo systemctl status bind9
sudo journalctl -u bind9 --since "5 minutes ago"

A konfigurációs fájlokat a named-checkconf és named-checkzone parancsokkal ellenőrizheti:

sudo named-checkconf /etc/bind/named.conf
sudo named-checkzone sajatdomain.hu /etc/bind/db.sajatdomain.hu
sudo named-checkzone 1.168.192.in-addr.arpa /etc/bind/db.192

Ha ezek a parancsok nem adnak vissza hibát, a konfiguráció szintaktikailag helyes.

Tesztelje a DNS-feloldást a dig paranccsal (telepítse, ha még nincs: sudo apt install dnsutils):

dig @127.0.0.1 sajatdomain.hu
dig @127.0.0.1 www.sajatdomain.hu
dig @127.0.0.1 -x 192.168.1.100

Ha a válaszok helyesek, a DNS-szerver sikeresen működik. Ne felejtse el a hálózati eszközeit (számítógépek, routerek) átállítani, hogy a saját DNS-szerverét használják (pl. 192.168.1.100).

Biztonsági beállítások és védelem

Egy DNS-szerver, különösen ha publikusan elérhető, gyakori célpontja a támadásoknak. Ezért a biztonsági beállítások kiemelt fontosságúak. A megfelelő védelem nélkül a szerver sebezhetővé válhat cache poisoning, DDoS támadások vagy adatszivárgás ellen.

Tűzfal szabályok finomhangolása

Az UFW-vel korábban már engedélyeztük az 53-as portot UDP-n és TCP-n. Ezt azonban érdemes szigorítani.

• Rekurzív szerverek esetén (otthoni hálózat):

  Csak a belső hálózatról érkező kéréseket engedélyezze.

  sudo ufw allow in on eth0 from 192.168.1.0/24 to any port 53 proto udp
  sudo ufw allow in on eth0 from 192.168.1.0/24 to any port 53 proto tcp

  Cserélje az eth0-t a saját interfészére, és a 192.168.1.0/24-et a saját hálózati tartományára. Ha csak a localhostról érkező kéréseket szeretné engedélyezni, akkor a from 127.0.0.1 opciót használja.

• Autoritatív szerverek esetén (nyilvános elérés):

  Mivel a szervernek fogadnia kell kéréseket az internetről, a from any beállítás szükséges, de érdemes lehet rate limitinget alkalmazni (lásd alább).

DNSSEC (Domain Name System Security Extensions) beállítása

A DNSSEC kiterjeszti a DNS-t digitális aláírásokkal, amelyek biztosítják a DNS-válaszok hitelességét és integritását. Megakadályozza a DNS-hamisítást és a cache poisoning támadásokat.

A BIND9 alapértelmezésben támogatja a DNSSEC-et. A named.conf.options fájlban a dnssec-validation auto; sor már engedélyezi a validációt. Ahhoz, hogy a saját domainje is DNSSEC-kompatibilis legyen, alá kell írnia a zónafájljait, és a domain regisztrátornál be kell állítania a DS (Delegation Signer) rekordokat.

1. Zónafájlok aláírása:

   Használja a dnssec-keygen és dnssec-signzone eszközöket. Ez egy komplex folyamat, amely magában foglalja a kulcsgenerálást (KSK – Key Signing Key, ZSK – Zone Signing Key), a zóna aláírását, és a kulcsok rendszeres cseréjét.

   # Kulcsok generálása
   sudo dnssec-keygen -a NSEC3RSASHA1 -b 2048 -n ZSK sajatdomain.hu
   sudo dnssec-keygen -a NSEC3RSASHA1 -b 4096 -n KSK sajatdomain.hu
   
   # Zóna aláírása
   sudo dnssec-signzone -o sajatdomain.hu -t /etc/bind/db.sajatdomain.hu Ksajatdomain.hu.+007+xxxxx Ksajatdomain.hu.+007+yyyyy

   Az aláírás után egy db.sajatdomain.hu.signed fájl jön létre, ezt kell használnia a named.conf.local fájlban.

2. DS rekordok beállítása a regisztrátornál:

   A dnssec-dsfromkey paranccsal generálja le a DS rekordokat a KSK-ból, és adja meg ezeket a domain regisztrátorának. Ez összekapcsolja a domainjét a DNSSEC-kel.

A DNSSEC beállítása haladó szintű feladat, és nagy odafigyelést igényel, mivel egy hibás konfiguráció a domain elérhetetlenségét okozhatja. Részletesebb útmutatókat a BIND dokumentációjában talál.

Rate Limiting (forgalomkorlátozás)

A Rate Limiting segít megvédeni a szervert a DDoS támadásoktól és a túlterheléstől, korlátozva az egy forrásból érkező DNS-kérések számát egy adott időintervallumban.

A BIND9 támogatja a Response Rate Limiting (RRL) funkciót. Ezt a named.conf.options fájlban konfigurálhatja:

options {
    // ...
    rate-limit {
        responses-per-second 5; // Maximum 5 válasz másodpercenként egy forrásból
        window 5;               // A mérési ablak 5 másodperc
        qps-scale 100;          // A qps arány skálázása
        errors-per-second 2;    // Maximum 2 hiba válasz másodpercenként
        all-per-second 10;      // Összes kérés korlátozása
        slip 2;                 // Hányadik kérésre adjon vissza SLIP választ (nem válasz)
    };
    // ...
};

Ezeket az értékeket a saját forgalmához és hálózati igényeihez kell igazítani. A túl szigorú korlátozás legitim kéréseket is blokkolhat.

ACL-ek (Hozzáférés-vezérlő listák)

Az ACL-ek (Access Control Lists) segítségével pontosan meghatározhatja, mely IP-címekről vagy hálózatokról fogadjon el kéréseket a DNS-szerver. Ez alapvető fontosságú a biztonság szempontjából.

Definiálhat ACL-eket a named.conf.options fájlban, majd hivatkozhat rájuk a allow-query, allow-recursion, allow-transfer beállításokban.

acl "trusted_clients" {
    192.168.1.0/24; // Saját belső hálózat
    10.0.0.0/8;     // Egy másik belső hálózat
    203.0.113.1;    // Egy megbízható IP-cím
};

options {
    // ...
    allow-query { trusted_clients; };
    allow-recursion { trusted_clients; }; // Csak a megbízható klienseknek engedélyezi a rekurziót
    // ...
};

Soha ne engedélyezze a rekurziót az internetről (allow-recursion { any; };), mert ez nyílt rekurzív szerverré tenné a DNS-ét, ami DDoS támadásokban való felhasználásra ad lehetőséget (DNS amplification attack).

Szoftverfrissítések és sebezhetőségek

Tartsa naprakészen a DNS-szerver szoftverét és az operációs rendszert. A rendszeres frissítések elengedhetetlenek a biztonsági rések bezárásához.

sudo apt update
sudo apt upgrade
sudo apt dist-upgrade
sudo reboot # Szükség esetén

Iratkozzon fel a BIND vagy az operációs rendszer biztonsági értesítéseire, hogy időben értesüljön a kritikus sebezhetőségekről.

DDoS támadások elleni védelem

A Rate Limiting mellett további intézkedések is szükségesek a DDoS támadások ellen:

• Elegendő sávszélesség: Győződjön meg róla, hogy a szervernek elegendő hálózati sávszélessége van a forgalom kezelésére.
• Redundancia: Két vagy több DNS-szerver üzemeltetése különböző hálózatokon vagy adatközpontokban növeli a rendelkezésre állást.
• DNS anycast: Ez a technológia több szerveren keresztül terjeszti a DNS-forgalmat, javítva a teljesítményt és a DDoS elleni védelmet.
• Felhőalapú DDoS védelem: Ha a szerver nyilvánosan elérhető, fontolja meg egy felhőalapú DDoS védelmi szolgáltatás igénybevételét (pl. Cloudflare, Akamai).

Cache poisoning megelőzése

A cache poisoning támadások során a támadók hamis DNS-rekordokat próbálnak bejuttatni a DNS-szerver gyorsítótárába.

A DNSSEC implementálása az egyik leghatékonyabb védelem a cache poisoning ellen. Ezen kívül:

• Randomizált forrásportok: A BIND alapértelmezetten randomizált forrásportokat használ a kimenő kérésekhez, ami megnehezíti a támadók számára a válaszok előrejelzését.
• Minimális rekurzió: Csak a megbízható klienseknek engedélyezze a rekurziót az ACL-ek segítségével.
• Naplózás és monitoring: Rendszeresen ellenőrizze a DNS-szerver naplóit a gyanús aktivitások jelei után kutatva.

Speciális funkciók és optimalizációk

A saját DNS-szerver nem csupán a domainek feloldására szolgálhat. Számos speciális funkcióval és optimalizációval bővíthető, amelyek tovább növelik az értékét és a hálózati élményt.

DNS over HTTPS (DoH) és DNS over TLS (DoT)

A hagyományos DNS-kérések titkosítatlanul utaznak az interneten, ami azt jelenti, hogy bárki, aki figyeli a hálózati forgalmat, láthatja, milyen weboldalakat látogat. A DNS over HTTPS (DoH) és a DNS over TLS (DoT) titkosított csatornán keresztül küldik a DNS-lekérdezéseket, jelentősen növelve az adatvédelmet és a biztonságot.

• DoT (DNS over TLS): A DNS-forgalmat a TLS protokollon keresztül titkosítja. A 853-as portot használja. Egyes DNS-szerver szoftverek (pl. Unbound, PowerDNS) natívan támogatják.
• DoH (DNS over HTTPS): A DNS-kéréseket HTTPS-en keresztül küldi, általában a 443-as porton. Ez a böngészőkben (Chrome, Firefox) egyre elterjedtebb, mivel nehezebb blokkolni vagy megkülönböztetni a normál webes forgalomtól.

Saját DoT/DoH szerver beállításához általában egy proxy-ra (pl. Nginx, Caddy) van szükség, amely a DNS-kéréseket titkosítja, majd továbbítja a BIND vagy Unbound szervernek. Ehhez SSL/TLS tanúsítvány is szükséges.

Reklámblokkolás és rosszindulatú oldalak szűrése

Ez az egyik legnépszerűbb ok, amiért az emberek saját DNS-szervert állítanak be. A DNS szintű reklámblokkolás hatékonyabb, mint a böngészőbővítmények, mivel az egész hálózaton működik, minden eszközön.

• Pi-hole: Egy dedikált szoftver (általában Raspberry Pi-n fut), amely egy gyorsítótárazó DNS-szerverként működik, és feketelisták alapján blokkolja a reklámokat és a rosszindulatú domaineket. Könnyen telepíthető és webes felületen keresztül kezelhető.
• Egyedi feketelisták BIND-ben: Manuálisan is létrehozhat feketelistákat a BIND-ben úgy, hogy a reklám- vagy malware-domaineket a /etc/bind/named.conf.local fájlban zone "ad.example.com" { type master; file "/etc/bind/db.blackhole"; }; módon definiálja, ahol a db.blackhole egy üres zónafájl, vagy egy olyan, ami a 0.0.0.0 IP-címre mutat.

Split-horizon DNS

A Split-horizon DNS (vagy Split-DNS) lehetővé teszi, hogy különböző válaszokat adjon ugyanarra a DNS-kérésre, attól függően, hogy honnan érkezik a kérés. Ez hasznos lehet, ha egy domain névnek van egy nyilvános (külső) és egy belső (privát) IP-címe.

Például, a szerver.sajatdomain.hu domain kívülről a nyilvános IP-címére mutat, de a belső hálózatról a privát IP-címére. Ezt a BIND-ben a view direktíva segítségével valósíthatja meg:

acl "internal" { 192.168.1.0/24; };
acl "external" { any; };

view "internal_view" {
    match-clients { internal; };
    recursion yes;
    zone "sajatdomain.hu" {
        type master;
        file "/etc/bind/db.sajatdomain.hu.internal";
    };
    // ... egyéb belső zónák ...
};

view "external_view" {
    match-clients { external; };
    recursion no; // Külső klienseknek ne engedélyezzük a rekurziót!
    zone "sajatdomain.hu" {
        type master;
        file "/etc/bind/db.sajatdomain.hu.external";
    };
    // ... egyéb külső zónák ...
};

Ebben a beállításban két különböző zónafájlt használunk a sajatdomain.hu-hoz, az egyiket a belső, a másikat a külső kliensek számára.

Naplózás és monitoring

A naplózás (logging) és a monitoring létfontosságú a DNS-szerver állapotának, teljesítményének és biztonságának figyelemmel kíséréséhez.

• BIND naplózás: A BIND részletes naplókat generál, amelyeket a named.conf.options fájlban konfigurálhat. Meghatározhatja a naplófájlok helyét, méretét és a naplózott események szintjét.
• Rendszer naplók: A Linux rendszernaplók (/var/log/syslog vagy journalctl) szintén tartalmaznak fontos információkat a BIND és a rendszer működéséről.
• Monitoring eszközök: Használhat olyan eszközöket, mint a Prometheus és Grafana, Zabbix vagy Nagios a DNS-szerver statisztikáinak (lekérdezések száma, hibaarány, CPU/memória használat) valós idejű monitorozására.

Teljesítményoptimalizálás

A DNS-szerver teljesítményének optimalizálása kulcsfontosságú a gyors válaszidőkhöz.

• Gyorsítótár méretének beállítása: A BIND automatikusan kezeli a gyorsítótárat, de bizonyos esetekben finomhangolható (pl. max-cache-size).
• Hardver erőforrások: Elegendő RAM és gyors lemez (SSD) biztosítása.
• Hálózati optimalizáció: Alacsony késleltetésű hálózati kapcsolat, megfelelő sávszélesség.
• Tiszta zónafájlok: A felesleges rekordok eltávolítása és a zónafájlok rendezett tartása javíthatja a feldolgozási időt.

Gyakori problémák és hibaelhárítás

A DNS-szerver beállítása során számos probléma adódhat. Fontos, hogy tudja, hogyan diagnosztizálhatja és háríthatja el ezeket a hibákat.

Konfigurációs hibák

A leggyakoribb problémák a konfigurációs fájlokban elkövetett hibák.

• Szintaktikai hibák: Elírások, hiányzó pontosvesszők, zárójelek.

  Megoldás: Használja a named-checkconf és named-checkzone parancsokat a hibák ellenőrzésére. Ezek pontosan megmondják, hol van a hiba.

  sudo named-checkconf /etc/bind/named.conf
  sudo named-checkzone sajatdomain.hu /etc/bind/db.sajatdomain.hu

• Serial szám nem növelése: Ha nem növeli a zónafájlban a serial számot egy módosítás után, a slave szerverek vagy a gyorsítótárazó szerverek nem frissítik a rekordjaikat.

  Megoldás: Minden zónafájl módosítás után növelje a serial számot, majd indítsa újra a BIND szolgáltatást.

• Helytelen IP-címek vagy domain nevek: Hibásan megadott IP-címek, elírt domain nevek a zónafájlokban.

  Megoldás: Gondosan ellenőrizze a zónafájlokat, és használja a dig parancsot a feloldás tesztelésére.

Tűzfal problémák

A tűzfal túl szigorú beállításai megakadályozhatják a DNS-forgalmat.

• Nem nyitott portok: Az 53-as port (UDP és TCP) nincs nyitva a DNS-szerver felé.

  Megoldás: Ellenőrizze az UFW (vagy más tűzfal) szabályait, és győződjön meg róla, hogy az 53-as port nyitva van a megfelelő forrásokból.

  sudo ufw status verbose

• Helytelen ACL-ek: Az ACL-ek túl szigorúak, és blokkolják a legitim klienseket.

  Megoldás: Ellenőrizze a named.conf.options és named.conf.local fájlokban az allow-query és allow-recursion beállításokat. Ideiglenesen engedélyezheti a any-t teszteléshez, majd szigoríthatja.

Hálózati kapcsolódási gondok

A DNS-szervernek szüksége van stabil hálózati kapcsolatra.

• Statikus IP-cím hiánya vagy hibás beállítása: A szerver IP-címe dinamikusan változik, vagy rosszul van konfigurálva.

  Megoldás: Ellenőrizze a /etc/netplan/*.yaml fájlt, és győződjön meg róla, hogy a statikus IP-cím helyesen van beállítva. Alkalmazza a Netplan konfigurációt, és indítsa újra a szervert.

• Elérhetetlen forwarder szerverek: Ha a BIND-et forwarderként használja, és a megadott forwarder szerverek nem elérhetők, a feloldás nem fog működni.

  Megoldás: Ellenőrizze a named.conf.options fájlban a forwarder IP-címeket, és győződjön meg róla, hogy azok elérhetők (pl. ping 8.8.8.8).

DNSSEC validációs hibák

A DNSSEC beállítása bonyolult, és könnyen adódhatnak hibák.

• Hibás kulcsok vagy aláírások: A zónafájlok hibásan vannak aláírva, vagy a kulcsok sérültek.

  Megoldás: Ellenőrizze a DNSSEC kulcsokat és az aláírási folyamatot. Használja a dnssec-signzone parancsot a zóna újbóli aláírásához.

• Helytelen DS rekordok a regisztrátornál: A domain regisztrátornál megadott DS rekordok nem egyeznek a generált kulcsokkal.

  Megoldás: Generálja újra a DS rekordokat, és ellenőrizze, hogy pontosan megegyeznek-e a regisztrátornál megadottakkal.

• Időeltérés (Clock Skew): A szerver órája nem pontos, ami problémákat okozhat a digitális aláírások validálásakor.

  Megoldás: Győződjön meg róla, hogy az NTP (Network Time Protocol) szolgáltatás fut a szerveren, és az idő szinkronizálva van.

  sudo timedatectl status

Teljesítményproblémák

Lassú válaszidők vagy túlterhelt szerver.

• Túlterhelés: Túl sok kérés érkezik a szerverre, vagy a szerver erőforrásai (CPU, RAM) elégtelenek.

  Megoldás: Ellenőrizze a szerver erőforrás-használatát (htop, free -h). Finomhangolja a BIND beállításait (pl. gyorsítótár mérete, rate limit). Fontolja meg a hardver bővítését vagy egy erősebb VPS használatát.

• Hálózati késleltetés: A hálózati kapcsolat lassú, vagy a szerver földrajzilag távol van a kliensektől.

  Megoldás: Optimalizálja a hálózati infrastruktúrát, vagy válasszon egy földrajzilag közelebbi VPS szolgáltatót.

• Hibás forwarder beállítások: A forwarder szerverek lassúak vagy nem megbízhatóak.

  Megoldás: Válasszon gyorsabb és megbízhatóbb publikus DNS-szervereket forwarderként (pl. Cloudflare: 1.1.1.1, Google: 8.8.8.8).

A naplófájlok (/var/log/syslog, /var/log/daemon.log, vagy journalctl -u bind9) mindig az első hely, ahol a hibák okát keresni kell. A BIND rendkívül részletes naplókat tud generálni, amelyek segítenek a problémák azonosításában.