A DNS működése

A Unix/Linux szerverek üzemeltetése wikiből

A DNS -- leegyszerűsítve -- az a világméretű infrastruktúra és az általa használt protokoll, ami az IP-címekhez neveket rendel, és fordítva. Kicsit absztraktabban: a DNS egy elosztott, hierarchikus adatbázis. Ha relációs adatbázisként akarunk rá gondolni, gondolhatjuk azt, hogy egyetlen táblája van, amelynek az oszlopai a következők: név, rekordtípus, tartalom.

A protokoll kérdés-válasz alapú: a kliensek kérdeznek, a szerverek válaszolnak. A transzport-protokoll általában az UDP, de lehetőség van a TCP használatára is (sőt, bizonyos esetekben a TCP használata elkerülhetetlen; l. később). Azért van értelme UDP-t használni, mert általában mind a kérdések, mind a válaszok elférnek egy-egy adatcsomagban, így a TCP-kapcsolatfelépítés során küldendő csomagok körülfordulási időinek megspórolása jelentősen gyorsítja a protokoll működését. (Ugyanez mondjuk a HTTP-re azért nem igaz, mert ott a kapcsolatfelépítés (és -lebontás) során küldött csomagok száma elenyésző a kapcsolat során küldött összes csomag számához képest, viszont éppen a nagyszámú csomag miatt fontos a sorrendhelyes és veszteségmentes átvitel.)

Tartalomjegyzék

1 Fogalmak

Domain. A DNS-ben minden név, amelyhez valamilyen rekord (a DNS-ben nyilvántartott adat) tartozik, domain (a "hosztnév", mint fogalom, a DNS-ben igazából nem létezik).

Hierarchia. A DNS hierarchikus: a domainek fastruktúrába szerveződnek. A fa gyökere a gyökérdomain, amelynek a neve egyetlen pont (".") karakter. A domain-nevekben a hierarchiaszinteket szintén pontok választják el egymástól. Elvileg minden domain-név pontra végződik; ez az utolsó pont jelöli a DNS-fa gyökerét. A valóságban nem szokás kiírni, de tudjunk róla, hogy elvileg ott van. A domain-nevek tehát jobbról balra hierarchikusak, vagyis a leírt nevek a hierarchia legalacsonyabb szintjével kezdődnek és a legmagasabbal érnek véget. (Ez a postai címzésre hasonlít: először leírjuk a címzett nevét, aztán az utcát, a várost stb.)

Root server. A gyökérdomainért jelenleg (2009. végén) 13 szerver felelős, amelyek a világ számos táján helyezkednek el. Ezeknek az IP-címét minden DNS-kliens ismeri (igazából csak a rekurzív feloldásra képes kliensek; l. később). Ezek a szerverek elvileg minden DNS-kérésre tudják a választ, vagy ha magát a választ nem is, azt igen, hogy kinél (melyik másik szervernél) kell továbbérdeklődni.

  • A valóságban nem 13 egyedi szerverről van szó, hanem 13 látszólag egyedi IP-címről, amelyek mindegyikével egynél több számítógép is rendelkezik; 13-nál lényesen több root szerver van, de IP-címeik alapján 13 csoportba rendeződnek. Ha valamelyik csoportot megcímezzük, a hálózati topológia függvénye, hogy az adott csoport címét viselő konkrét szerverpéldányok közül melyik fog nekünk válaszolni. A root-servers.org honlapján közzétett térképen megnézhetjük, hol helyezkednek el a root serverek a Földön.

TLD. Top-level domain. A közvetlenül a gyökér alatt elhelyezkedő domaineket hívják így; pl. ".com", ".hu" stb.

Delegáció. A DNS hierarchikus jellegének azért van értelme, mert a hierarchiaszintek természetes módját jelentik a felelősségek (és így a terhelés) elosztásának is. Nem szükséges, hogy a gyökérdomainért felelős szerverek a világ összes domain-nevének összes adatát ismerjék; a teljes DNS-fa bizonyos részeivel kapcsolatos teendők ellátásával (vagyis az ezekre vonatkozó kérdések megválaszolásával) megbízhatnak más szervereket. Ezek a más szerverek a rájuk bízott domainek aldomainjeivel kapcsolatos kérdések megválaszolásának feladatát továbbháríthatják további alárendelt szervereknek, s.í.t. Ezt a továbbhárítást, amikor egy, az adott X domainért elvileg felelős Y szerver egy kérdésre azt válaszolja, hogy "tudhatnám, de nem tudom; Z tudja, kérdezd őt", delegációnak hívják (ebben az esetben Y Z-nek delegálja az X domaint, Z pedig a delegációt fogadó szerver). A DNS-fában, mint gráfban, a csúcsok az egy adott domainért felelős DNS-szerverek halmazai, az élek pedig a delegációk. Az élek címkéje az a domain, amelyet az adott delegációval egy másik szerver(halmaz) felelősségi körébe utalunk.

Autoritativitás. Egy W DNS-szervert akkor mondunk autoritatívnak egy domainre, ha a gyökérdomaintől elindulva delegációs lánc vezet ehhez a szerverhez a DNS-hierarchiában; tehát ha a gyökérszerverek valamelyikét erről a domainről kérdezzük, és követjük a delegációkat, akkor előbb-utóbb eljutunk ehhez a W szerverhez. Az autoritativitást úgy képzelhetjük el, mint valamiféle dicsfényt, amely a gyökérszerverek felől terjed a DNS-fában lefelé a delegációk mentén. (Ha pattanásig akarjuk feszíteni ezt a metaforát, akkor minden domainhez egy hullámhossztartományt rendelhetünk, és a dicsfénynek minden delegáció mentén csak az adott delegációban szereplő domain hullámhossztartományához tartozó része terjed tovább; de talán egyszerűbb csak egyetlen konkrét domainnel kapcsolatban gondolni erre, és akkor nem kell vacakolnunk a színekkel, cserébe a DNS-fa döntő része sötétbe borul.)

Ha egy adott V domainhez tartozó ágat a gyökértől indulva végigkövetünk, akkor az útközben érintett valamennyi szerver autoritatív a V domainre. A gyökérszerverek tehát definíció szerint minden domain-névre autoritatívak; a .com TLD-ért felelős szerverek minden .com végű domain-névre; azok a szerverek, amelyeknek pl. a google.com domaint delegálják, pedig minden google.com-ra végződő névre, s.í.t. Annak, hogy W autoritatív V-re, az intuitív jelentése az, hogy a W szervernek joga van nyilatkozni a V domainbe (vagy annak bármely szubdomainjébe) tartozó nevek rekordjairól.

Persze ahhoz, hogy ezt valóban képes is legyen megtenni, szükséges egy adatbázis, amelyben a nevekhez tartozó rekordokat tároljuk és amelyből ezeket az adatokat a DNS-szerver kiolvassa. Maga a W szerver amúgy nem tudja, hogy milyen domaineket delegálnak neki mások (honnan is tudná?), tehát valahogyan (általában a konfigurációban vagy az adatbázisban) meg kell neki mondani, mely domainekre tekintse magát autoritatívnak. Ha a V domaint a hierarchia egy magasabb szintjéről a W szervernek delegálják, de ez a szerver nem tekinti magát autoritatívnak erre a domainre, akkor nem tud értelmesen válaszolni a V-re vonatkozó kérdésekre; ezt hívják "béna delegációnak" (lame delegation).

Reverse DNS. Ilyen szigorúan véve nem létezik, csak a mi fejünkben. Az emberek azt hívják reverse DNS-nek, amikor nem nevekhez rendelünk IP-címeket, hanem fordítva: tehát azt tároljuk, hogy egy adott IP-címhez milyen név tartozik. A DNS szempontjából ez semmiben sem különbözik a "forward" DNS-től, hiszen itt is csak annyi történik, hogy valamilyen nevekhez valamilyen rekordok fognak tartozni; csak éppen történetesen a neveket IP-címekből képezzük, a rekordok pedig domain-neveket (halandóul hosztneveket) tartalmaznak. Erről később lesz szó részletesebben.

2 A DNS-feloldás menete

Legyen mondjuk az a kérdés, mi a www.bme.hu IP címe. Hogy kezdjünk neki?

Mit jelent egyáltalán az, hogy a www.bme.hu IP címe ez és ez?

Azt, hogy van valahol egy a www.bme.hu névre autoritatív szerver, amelyben a www.bme.hu névnek van egy A rekordja; a rekord tartalma az IP cím.

A feloldás a következőképpen történik. A szemléletesség kedvéért baloldalt a DNS-feloldás menete látható, jobboldalt pedig az, ahogyan a www.bme.hu "telefonszámát" tudnánk meg egy olyan rendszerben, amelyben van világméretű tudakozó, regionális tudakozó s.í.t.

  1. Küldünk egy query-t (kérdést) az egyik root szervernek (amelynek a címét "mindenki tudja"), amelyben megkérdezzük, hogy A? www.bme.hu.
    • Erre ő, ha tudná a választ, mondhatná, hogy „Hohó, ídös fiam, a www.bme.hu A rekordja nem más, mint 152.66.115.35 .”.
    • De nem tudja, mert az ő feladata nem az, hogy minden gép címét ismerje, hanem az, hogy tudja, kit kell megkérdezni a címekről.
    • Ezzel együtt fontos tudnunk, hogy akár meg is mondhatná a választ.
  2. A root szervertől így azt a választ kapjuk, hogy ő nem tudja, de kérdezzük meg valamelyik olyan szervert, amely minden .hu-ra végződő domainre autoritatív; ezeknek a nevét meg is mondja.
    • Emellett elárulja a nevekhez tartozó IP-ket is, ez a glue.
    • Ha nem árulná el, esetleg bajban lennénk, mert a .hu szerverek neveit ugyan ismerjük, de a nekik küldendő DNS query-t az IP-címükre kell küldeni, amit valahonnan meg kell szerezni; vagyis rögtön újra a root szerverekhez fordulnánk, az ezekhez a szervernevekhez tartozó IP-ket firtatva. Ennek a kérdésnek megy elébe a glue, javítva ezzel a DNS sebességét és hatékonyságát (hiszen így kevesebb csomagra van szükség egy feloldás elvégzéséhez).
  3. Megkérdezzük valamelyik .hu-s szervertől, mondjuk az ns.nic.hu-tól (193.239.148.62), hogy A? www.bme.hu.
    • Erre ő, ha tudná a választ, mondhatná, hogy „Hohó, ídös fiam, a www.bme.hu A rekordja nem más, mint 152.66.115.35 .”.
    • De nem tudja, mert az ő feladata nem az, hogy minden .hu alatti gép címét ismerje, hanem az, hogy tudja, kit kell megkérdezni.
    • Ezzel együtt fontos tudnunk, hogy akár meg is mondhatná a választ.
  4. Az ns.nic.hu azt mondja, hogy ő nem tudja, de kérdezzük meg valamelyik olyan szervert, amely minden bme.hu-ra végződő névre autoritatív; ezeknek a nevét meg is mondja.
    • glue mint fent.
  5. Megkérdezzük valamelyik bme.hu-s szervertől, mondjuk a nic.bme.hu-tól (152.66.115.1), hogy A? www.bme.hu.
  6. A nic.bme.hu benyúl az adatbázisába, és azt mondja, hogy „Hohó, ídös fiam, a www.bme.hu A rekordja nem más, mint 152.66.115.35; írd fel a noteszedbe, hogy ne kelljen mindig hozzám szaladgálnod, de legkésőbb négy óra múlva radírozd ki!”.
    • Merthogy minden DNS-rekordnak van egy TTL-értéke (Time To Live): ennyi ideig szabad cache-elni.
  1. Felhívjuk a globális tudakozót (amelynek a telefonszámát mindenki tudja), és megkérdezzük, mi a www.bme.hu telefonszáma.
    • A globális tudakozó, ha tudná a választ, megmondaná.
    • De nem tudja, mert az ő feladata nem az, hogy minden telefonszámot tudjon, hanem az, hogy tudja a világ összes országos tudakozójának a telefonszámát.
  2. Így a globális tudakozó azt mondja, hívjuk fel a .hu-val foglalkozó tudakozók valamelyikét; az majd eligazít. Megmondja az ezeket a tudakozókat üzemeltető cégek nevét.
    • A cégnevekhez mellékeli a hozzájuk tartozó telefonszámokat is. (Ha nem mellékelné, nem sokra mennénk a cégnevekkel, hiszen nem tudnánk, milyen számon érhetjük el őket.)
  3. Felhívjuk valamelyik .hu-s tudakozót, mondjuk az ns.nic.hu-t (193-239-148-62), hogy mi a www.bme.hu telefonszáma.
    • Erre ő, ha tudná a választ, mondhatná, hogy „Hohó, ídös fiam, a www.bme.hu telefonszáma nem más, mint 152-66-115-35 .”.
    • De nem tudja, mert az ő feladata nem az, hogy minden .hu-s telefonszámot tudjon, hanem az, hogy ismerje az intézményi tudakozók telefonszámát.
  4. Az ns.nic.hu azt mondja, hogy ő nem tudja, de kérdezzük meg bme.hu-s tudakozók egyikét; ezeknek a nevét meg is mondja.
    • glue mint fent.
  5. Felhívjuk valamelyik bme.hu-s tudakozót, mondjuk a nic.bme.hu-t (152-66-115-1), hogy mi a www.bme.hu telefonszáma.
  6. A nic.bme.hu benyúl az adatbázisába, és azt mondja, hogy „Hohó, ídös fiam, a www.bme.hu telefonszáma nem más, mint 152-66-115-35; írd fel a noteszedbe, hogy ne kelljen mindig hívogatnod engem, de legkésőbb négy óra múlva radírozd ki!”.

Lássuk ugyanezt a parancssorból.

Először használjuk a hagyományos mosóport, a host(1) programot:

chardonnay:~% host -vvv -t a www.bme.hu 198.41.0.4        
Trying "www.bme.hu"
Using domain server:
Name: 198.41.0.4
Address: 198.41.0.4#53
Aliases: 

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59973
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 6, ADDITIONAL: 6

;; QUESTION SECTION:
;www.bme.hu.    IN   A

;; AUTHORITY SECTION:
hu.            172800 IN NS    NS.NIC.hu.
hu.            172800 IN NS    NS2.NIC.FR.
hu.            172800 IN NS    SUNIC.SUNET.SE.
hu.            172800 IN NS    NS1.NIC.hu.
hu.            172800 IN NS    NS2.NIC.hu.
hu.            172800 IN NS    NS3.NIC.hu.

;; ADDITIONAL SECTION:
NS.NIC.hu.     172800 IN A 193.239.148.62
NS2.NIC.FR.    172800 IN A 192.93.0.4
SUNIC.SUNET.SE.  172800 IN A   192.36.125.2
NS1.NIC.hu.    172800 IN A 193.239.149.3
NS2.NIC.hu.    172800 IN A 193.6.16.1
NS3.NIC.hu.    172800 IN A 195.70.35.250

Received 251 bytes from 198.41.0.4#53 in 114 ms

Látható, hogy megtudtuk, merre kell továbbérdeklődnünk, de magát a választ nem. Nézzük tovább:

chardonnay:~% host -vvv -t a www.bme.hu 193.239.148.62
Trying "www.bme.hu"
Using domain server:
Name: 193.239.148.62
Address: 193.239.148.62#53
Aliases: 

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 50701
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3

;; QUESTION SECTION:
;www.bme.hu.    IN   A

;; AUTHORITY SECTION:
bme.hu.        86400 IN NS ns.bme.hu.
bme.hu.        86400 IN NS nic.bme.hu.
bme.hu.        86400 IN NS ns2.pantel.net.

;; ADDITIONAL SECTION:
ns.bme.hu.     86400 IN AAAA   2001:738:2001:8001::2
nic.bme.hu.    86400 IN A  152.66.115.1
nic.bme.hu.    86400 IN AAAA   2001:738:2001:2001::2

Received 163 bytes from 193.239.148.62#53 in 2 ms

Közeledünk, közeledünk. Végül:

chardonnay:~# host -vvv -t a www.bme.hu 152.66.115.1  
Trying "www.bme.hu"
Using domain server:
Name: 152.66.115.1
Address: 152.66.115.1#53
Aliases: 

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13192
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 5

;; QUESTION SECTION:
;www.bme.hu.    IN   A

;; ANSWER SECTION:
www.bme.hu.    14400 IN A  152.66.115.35

;; AUTHORITY SECTION:
bme.hu.        14400 IN NS ns2.pantel.net.
bme.hu.        14400 IN NS ns.bme.hu.
bme.hu.        14400 IN NS nic.bme.hu.

;; ADDITIONAL SECTION:
ns.bme.hu.     14400 IN A  152.66.116.1
ns.bme.hu.     14400 IN AAAA   2001:738:2001:8001::2
nic.bme.hu.    14400 IN A  152.66.115.1
nic.bme.hu.    14400 IN AAAA   2001:738:2001:2001::2
ns2.pantel.net.  35857 IN  A   212.24.160.1

Received 211 bytes from 152.66.115.1#53 in 1 ms

Most próbáljuk meg ugyanezt egy kevésbé ismert eszközzel, a dnsq nevűvel (amely a djbdns ill. dbndns csomaghoz tartozik):

chardonnay:~% dnsq a www.bme.hu 198.41.0.4            
1 www.bme.hu:
251 bytes, 1+0+6+6 records, response, noerror
query: 1 www.bme.hu
authority: hu 172800 NS ns.nic.hu
authority: hu 172800 NS ns2.nic.fr
authority: hu 172800 NS sunic.sunet.se
authority: hu 172800 NS ns1.nic.hu
authority: hu 172800 NS ns2.nic.hu
authority: hu 172800 NS ns3.nic.hu
additional: ns.nic.hu 172800 A 193.239.148.62
additional: ns2.nic.fr 172800 A 192.93.0.4
additional: sunic.sunet.se 172800 A 192.36.125.2
additional: ns1.nic.hu 172800 A 193.239.149.3
additional: ns2.nic.hu 172800 A 193.6.16.1
additional: ns3.nic.hu 172800 A 195.70.35.250

chardonnay:~% dnsq a www.bme.hu 193.239.148.62
1 www.bme.hu:
179 bytes, 1+0+3+4 records, response, noerror
query: 1 www.bme.hu
authority: bme.hu 86400 NS ns.bme.hu
authority: bme.hu 86400 NS nic.bme.hu
authority: bme.hu 86400 NS ns2.pantel.net
additional: nic.bme.hu 86400 A 152.66.115.1
additional: nic.bme.hu 86400 AAAA 2001:738:2001:2001::2
additional: ns.bme.hu 86400 A 152.66.116.1
additional: ns.bme.hu 86400 AAAA 2001:738:2001:8001::2

chardonnay:~% dnsq a www.bme.hu 152.66.115.1  
1 www.bme.hu:
211 bytes, 1+1+3+5 records, response, authoritative, weird ra, noerror
query: 1 www.bme.hu
answer: www.bme.hu 14400 A 152.66.115.35
authority: bme.hu 14400 NS ns2.pantel.net
authority: bme.hu 14400 NS ns.bme.hu
authority: bme.hu 14400 NS nic.bme.hu
additional: ns.bme.hu 14400 A 152.66.116.1
additional: ns.bme.hu 14400 AAAA 2001:738:2001:8001::2
additional: nic.bme.hu 14400 A 152.66.115.1
additional: nic.bme.hu 14400 AAAA 2001:738:2001:2001::2
additional: ns2.pantel.net 35704 A 212.24.160.1

Talán látszik, hogy ennek az outputja scriptből könnyebben feldolgozható.

3 A DNS rekordtípusai

(Teljesebb listát l. pl. a Wikipédián.)

  • A: név->IP
    • www.bme.hu. IN A 152.66.115.35
    • Ha egy domainnek van A rekordja, akkor tekinthetjük hosztnak (de a DNS-ben ez a fogalom nem létezik).
    • Egy névhez "akárhány" A rekord tartozhat.
  • PTR: IP->név
    • 35.115.66.152.in-addr.arpa. IN PTR torpapa.eik.bme.hu.
    • Azért így, hogy hierarchikusan lehessen delegálni; l. alant.
    • Egy IP-hez "akárhány" PTR-rekord tartozhat, de csak ritkán tartozik egynél több.
  • MX: melyik szerver fogadja a domainbe címzett leveleket
    • bme.hu. IN MX 10 nic.bme.hu.
    • A "10" a prioritás; ha egy domainnek több MX-e van, akkor a prioritásaik emelkedő sorrendjében kell megpróbálni átadni nekik a leveleket.
  • NS: ki nameservere egy domainnek
    • bme.hu. IN NS ns.bme.hu.
    • Egy domainnek "akárhány" névszervere lehet. Ezek a kliensek szemszögéből egyenrangúak.
  • SOA: a domain „tulajdonságai”
    • bme.hu. IN SOA nic.bme.hu. hostmaster.bme.hu. 2006091400 43200 14400 2592000 86400
    • elsődleges nameserver, hostmaster emailcíme, sorozatszám, refresh time, retry time, expire time, minimum time.
      • refresh time: ilyen gyakran frissítik magukat a secondary-k (vagy NOTIFY hatására, vagy ...)
      • retry time: ennyi időnként próbálkozik egy secondary, ha elsőre nem sikerült a frissítés
      • expire time: ha ennyi ideig nem volt kapcsolat a primary-val, a secondary tekintse elavultnak az adatokat és tagadja meg a választ
      • minimum time: korábban az alapértelmezett TTL, ma az NXDOMAIN (nincs ilyen cím) TTL-je
  • TXT: megjegyzés
  • CNAME: átirányítás; minden, erre a névre vonatkozó queryvel kapcsolatban l. a másik megadott nevet. Ha egy névhez CNAME rekord tartozik, semmilyen más rekord nem tartozhat hozzá (ill. ha tartozik is, azokat soha senki nem fogja látni, mert a CNAME-et követve a megadott név alatt keresik tovább a rekordot).
    • www.math.bme.hu. IN CNAME proof.math.bme.hu.
    • Általában ne használjunk CNAME-et. Nem nehéz vele hurkokat létrehozni, ráadásul
    • az aktuális domainből "kimutató" CNAME esetén a feloldóprogramnak újra a gyökértől indulva kell elkezdeni a feloldást (pl. www.foo.com CNAME www.foo.net esetén).
  • HINFO: hardware info
    • Ma már nem használják.
  • stb.

4 A TTL helyes megválasztása

Egy rekord TTL-je akkora legyen, hogy lehetőleg éppen a következő tervezett módosítás előtt járjon le.

  • Ha nem tudjuk, mikor lesz a következő módosítás, akkor akkora legyen, amennyi ideig vállalható, hogy a kliensek esetleg még a rekord régi tartalma szerint járnak el; tehát pl. az előző címén keresik a webszervert.
  • Ökölszabály: várhatóan lassan változó rekordok TTL-je legyen néhány órás (vagy akár néhány napos).
    • Nem valószínű, hogy gyakran változna pl. egy domain MX-ének a neve, tehát az MX rekord TTL-je akár egy hét is lehet;
    • a névhez tartozó IP viszont talán megváltozhat "váratlanul" (pl. mert átmegyünk másik hosting-szolgáltatóhoz, vagy mert DNS-alapú failovert valósítottunk meg), így ennek a TTL-je lehet jóval alacsonyabb (néhány óra, vagy failover esetén akár csak öt perc).
  • Ha a TTL túl nagy, az azért baj, mert akkor a rekord tartalmának megváltoztatása után sokáig lehetnek olyan kliensek, akik a rekordnak még az előző tartalmát ismerik, és rossz gépnek próbálják kézbesíteni a leveleinket, rossz DNS-szervertől érdeklődnek a hosztneveinkről s.í.t.
    • Ha az ebből adódó problémákat el akarjuk kerülni, akkor a rekord megváltoztatása után még legalább a TTL-ben megadott ideig mindkét címen (az újon és a régin) nyújtanunk kell a szolgáltatást.
  • Ha a TTL túl kicsi, az azért baj, mert a kliensek csak rövid ideig cache-elik a rekordok tartalmát és feleslegesen gyakran fordulnak a DNS-szerverünkhöz; így
    • a szervernek megnő a terhelése,
    • a kliensek pedig lelassulhatnak (mert pl. két kattintás között megint le kell kérdezni a webszerver IP-címét).

(Van olyan DNS-szerver, pl. a djbdns, amely tervezett DNS-változtatásokat úgy támogat, hogy a megváltoztatandó rekord TTL-jét minden válaszhoz egyenként kiszámítja úgy, hogy éppen a tervezett változtatás pillanatában járjon le.)

Olyan domaineknél (zónáknál), amelyekbe viszonylag gyakran jegyzünk be új neveket, érdemes lehet a SOA minimum time-ot (ami az NXDOMAIN TTL-je) alacsonyra venni.

5 A DNS-szolgáltatások típusai

A DNS igazából több, jól elkülöníthető szolgáltatás összessége. Ezek:

  • Autoritatív DNS
Az autoritatív DNS-szervernek van egy adatbázisa, és az abban található adatokra vonatkozó kérdésekre válaszol. Más (pl. rekurzív) kérdésekre nem.
  • Rekurzív, cache-elő DNS
Az ilyen szerver a DNS-fa rekurzív bejárását végzi el a kliensek számára, és az eredményeket cache-eli a gyorsabb kiszolgálás érdekében.
  • Zónatranszfer (AXFR)
Ez a szolgáltatás az autoritatív szerver adatbázisának replikálását végzi (átmásolja az adatbázist a "primary" szerverről a "secondary" szerverre).
  • Resolver stub library
Olyan függvénykönyvtár, amelyben a DNS-sel kapcsolatos funkciók vannak megvalósítva, hogy ne kelljen minden programban egyenként implementálni. Elsősorban rekurzív szerverrel kell tudnia szót érteni.

Ezekből az első hármat a BIND és a rá hasonlítani akaró szoftverek a közelmúltig összemosták.

6 Reverse DNS, classless delegáció

Az elején már volt szó arról, hogy a reverse DNS az, ami IP-címekhez rendel "hosztneveket" (amik, mint tudjuk, "igazából" domain-nevek). Mivel a DNS nevekhez rendel rekordokat, az IP-címekből is valahogyan neveket kell képezni, hogy aztán ezekhez a nevekhez tartozhassanak azok a PTR-rekordok, amelyek az adott IP-címekhez tartozó hosztneveket tartalmazzák. Erre a célra bevezettek egy külön zónát (domaint): a neve in-addr.arpa.. Erre a domainre 2009. végén a 13 gyökérszerverből 12 volt autoritatív (és rajtuk kívül senki); 2012-ben már 6 dedikált in-addr-arpa-servers.arpa. domainbeli szerver szolgálta ki (a.in-addr-servers.arpa., b.in-addr-servers.arpa. stb.)

Hogyan képezzük le az IP-címeket in-addr.arpa domain alá tartozó nevekre? A leképezésnek a következő tulajdonságokkal kell rendelkeznie:

  1. Legyen kölcsönösen egyértelmű.
  2. Legyen kölcsönösen egyértelmű megfeleltetés IP-alhálózatok és a belőlük képzett DNS-domainek között.
  3. A domainek hierarchiája tükrözze az IP-alhálózatok hierarchiáját.

Talán a második és a harmadik pont igényel bővebb magyarázatot. Az IP-címek kiosztása hierarchikusan történik. Az idők hajnalán háromféle címtartományt lehetett igényelni: A, B ill. C osztályút. Ezek rendre /8-as, /16-os, ill. /24-es hálózatoknak felelnek meg. Tehát ha egy szervezet úgy látta, hogy 254-nél több végpontot kell egyedi IP-címmel ellátnia (ez még a címfordítás térhódítása előtt volt!), akkor igényelt egy B osztályú címtartományt, és így kapott 65536 olyan IP-t, amely ugyanazzal a két byte-tal (octettel) kezdődik. (Ebben aztán kényelmesen elfért mind a 300 gép, és még maradt is egy kis hely a bővítésre.)

Emlékezzünk vissza, hogy a statikus routing során az IP-címeket balról jobbra olvasva tekintjük hierarchikusnak, míg a domain-neveket jobbról balra. Kívülről nézve mondjuk a BME példáját tehát a 152.66-tal kezdődő IP-címek halmaza alkot egy olyan tömböt, amely ugyanahhoz a szervezethez tartozik (tehát az összes 152.66-tal kezdődő címre szóló csomagot ugyanafelé a router felé kell továbbítani).

Első ránézésre kézenfekvő lenne tehát, hogy delegáljuk a 152.66.in-addr.arpa domaint a BME névszervereinek. Csakhogy a DNS jobbról balra hierarchikus; tehát ha pl. a 152.66.0.1-es IP-hez a 152.66.0.1.in-addr.arpa domain-név tartozna a "reverse" DNS szempontjából, akkor ez a név nem tartozna bele a 152.66.in-addr.arpa domainbe, vagyis nem lehetne egyetlen tömbben delegálni a BME-nek.

Azt a megoldást találták ki, hogy az IP-címeket megfordítják: a 152.66.0.1-hez tartozó azon DNS-név, amelynek a PTR rekordja ennek az IP-nek a "hosztnevét" tartalmazza, tehát az 1.0.66.152.in-addr.arpa; a BME összes IP-címéhez tartozó reverse-DNS-nevet tartalmazó domain pedig a 66.152.in-addr.arpa. Ha pl. a 4.0.0.0/8-as hálózat teljes reverse-tartományát akarjuk delegálni egy nameservernek, akkor valami ilyesmit írhatunk az in-addr.arpa. zónafájljába: "4.in-addr.arpa. IN NS ns1.Level3.net.". Hasonlóképpen, ha a 152.66.0.0/16-os hálózat reverse delegációját nézzük, akkor egy "66.152.in-addr.arpa. IN NS ns.bme.hu." jellegű bejegyzést találunk majd a 152.in-addr.arpa. zónafájljában.

Ez a rendszer kiválóan működik addig, amíg nincs szükség olyan delegációkra, amelyek nyolccal nem osztható maszkhosszúságú hálózatokba eső IP-címekből képzett nevekkel kapcsolatosak.

  • Ha pl. a 172.16.0.0/12-höz tartozó reverse domaint akarnánk delegálni, gondban lennénk, mert
    • a 16.172.in-addr.arpa túl szűk (a /12-es tartomány a 172.16.0.0-172.31.255.255 címeket foglalja magában),
    • a 172.in-addr.arpa pedig túl tág.
  • Kézenfekvő, hogy delegáljuk egyenként az összes reverse zónát 16.172.in-addr.arpától 31.172.in-addr.arpáig;
    • ez 16 db NS rekord felvételét jelentené.
  • A módszer kifogástalanul működik is, csak
    • az a hátránya, hogy ha a delegációt fogadó, tehát a reverse zónáért ténylegesen felelős szerveren BIND, vagy egy BIND-ra hasonlítani vágyó program fut, akkor mind a 16 "önálló" domainhez külön zónafájlt kell létrehozni, és ezekre hivatkozni kell a konfigurációs fájlban.
    • Ez nyilván olyan rettenetes megterhelést jelent, hogy mindenáron el kell kerülni; ezt a célt szolgálja a "classless" delegáció (amúgy érdemes elolvasni az RFC2317-et, akad benne marhaság a javából).
    • A BIND-felhasználók számára amúgy még rosszabb lenne a helyzet, ha pl. egy /25-ös hálózat reverse zónáját delegálná nekik valaki 128 darab NS rekorddal: 128 darab zónafájlt kellene létrehozniuk.
    • Természetes, hogy egy szoftver tervezési hibáit egy új szabvánnyal kell maszkolni; ezért született meg az RFC2317.
      • Nyilván a véletlen műve, hogy az RFC egyik szerzője az a Paul Vixie, aki a BIND-ot jegyző Internet Software Consortium munkatársa és a BIND egyik fejlesztője is.
      • A sorok között ne olvassatok, oda nem írtam semmit! :)

Az RFC2317 szerzői által kitalált megoldás, amelyet classless delegációnak hívnak:

  • Tegyük fel, hogy
    • az 1.2.3.4-es és az 1.2.3.5-ös IP-cím a miénk;
    • a nameserverünk az ns.foo.com.
  • Ez ugye az 1.2.3.4/31-es hálózat.
  • "Classful" delegáció esetén két darab NS rekorddal intéznénk el a delegációt:
    • "4.3.2.1.in-addr.arpa. IN NS ns.foo.com." ill.
    • "5.3.2.1.in-addr.arpa. IN NS ns.foo.com."
    • Sőt, még jobb lenne, ha nem glueless delegáció lenne, tehát mondjuk az ns.4.3.2.1.in-addr.arpa nevet (is) viselné a nameserverünk (azért "is", mert nyilván ugyanannak a nameservernek akárhány neve is lehet):
4.3.2.1.in-addr.arpa.		IN NS	ns.4.3.2.1.in-addr.arpa.
5.3.2.1.in-addr.arpa.		IN NS	ns.4.3.2.1.in-addr.arpa.
ns.4.3.2.1.in-addr.arpa.	IN A	1.2.3.4
  • Classless delegáció esetén ugyanez úgy történik, hogy
    • felveszünk egy darab NS-rekordot így: "4/31.3.2.1.in-addr.arpa. NS ns.foo.com.".
    • Ezzel létrehoztunk egy új zónát, a 4/31.3.2.1.in-addr.arpa nevűt.
      • Érdekesség: az RFC2317 nemcsak nem specifikálja, milyen karaktert használjunk az IP és a netmask között, hanem egyenesen azt ajánlja, hogy mindenki találjon ki saját szintaxist.
    • Most már csak az a dolgunk, hogy az egyes PTR-rekordokat áthelyezzük ebbe a zónába, ezt pedig két CNAME rekorddal lehet megtenni:
      • "4.3.2.1.in-addr.arpa. CNAME 4.4/31.3.2.1.in-addr.arpa." és
      • "5.3.2.1.in-addr.arpa. CNAME 5.4/31.3.2.1.in-addr.arpa.".
    • Így a DNS-kliens, amikor a 4.3.2.1 PTR rekordját keresi,
      • megtalálja a 4.4/31.3.2.1.in-addr.arpára mutató CNAME-et, úgyhogy
      • megpróbálja a 4.4/31.3.2.1.in-addr.arpa PTR rekordját feloldani, erre pedig
      • a delegációt fogadó szerver a keresett PTR rekorddal válaszol.

(Az RFC2317 egyik szerzője után a classless delegációt "de Groot"-delegációnak is hívják.)

A classless delegációkkal több probléma is van:

  • Nyilván felesleges bonyolítás.
    • Még a BIND-felhasználók is megúszhatnák a sok zónafájlt; pl. megtehetnék, hogy a reverse DNS szempontjából felkerekítik a hálózatuk netmaskját a legközelebbi nyolccal oszthatóra (tehát 24-esre, 16-osra vagy 8-asra), és az ebből adódó reverse zónát veszik fel a konfigurációba. A fenti példában pl. a BIND-felhasználó beállíthatta volna a BIND-ját úgy, hogy az egész 3.2.1.in-addr.arpa domainre képzelje magát autoritatívnak; ebben a domainben aztán csak a két konkrét IP-hez tartozó rekordokat venné fel. Ez ugyan nem "szép" (például mert az NS rekordokkal delegált, egy-egy PTR rekordot tartalmazó "domaineknek" nem lenne SOA rekordja), de működik; ha valaki ki tud találni olyan értelmes támadást, amely ezt a hazugságot aknázza ki, akkor árulja el, mi az.
  • Növel(het)i a DNS reakcióidejét, mivel több kérésre van/lehet szükség a válasz megszerzéséhez.
  • Azáltal, hogy a reverse-rekordok neve nem generálható szisztematikusan, az RFC1035-ben leírt módon, az IP-címből, számos DNS-szoftver bizonyos kényelmi szolgáltatásai használhatatlanná válnak (l. Avoid RFC 2317 style delegation of "in-addr.arpa.").

7 Gyakori gondok a DNS-sel

7.1 Poisoning

A poisoning olyan támadás, amelynek a során a támadó eléri, hogy egy kliens DNS cache-ébe hamis adat kerüljön.

Legalább háromféle DNS poisoningot érdemes megkülönböztetni:

  1. Az egyik esetben a támadó az általunk megszólított nameserver helyett válaszol, és a válasz tartalmával mérgezi meg a cache-ünket.
    • Ezt akkor tudja könnyen megtenni, ha le tudja hallgatni a kérdést.
    • Ezt a támadást DNS spoofingnak vagy DNS forgerynek (hamisításnak) is nevezik.
    • Gyakorlatilag nem lehet ellene védekezni (nem húzhatunk ki VPN-t a világ összes DNS-szerveréhez).
    • A saját ellenőrzésünk alá tartozó szakaszon megnehezíthetjük a lehallgatást, de nagyjából ennyi.
    • A lehallgatásra amúgy azért van szükség, mert minden DNS-kérés tartalmaz egy 16 bites azonosítót (amit amúgy nonce-nak hívnak), aminek a válaszban is szerepelnie kell; ha a támadó nem tudja, milyen nonce-szal ment ki a kérés, meg kell tippelnie, mit írjon a válaszba.
    • Ha emellett a kérés forrásportja is véletlenszerű, összesen kb. 31-32 bitnyi véletlenséget (azért nem 32, mert jó pár forrásport kizárható) tudunk vinni a kérésbe, úgyhogy a vak tippelés nehézzé válik. (De nem lehetetlenné: pár száz GB-nyi csomaggal végig lehet próbálni minden lehetőséget.)
      • A jobb DNS-termékekben még 2000 előtt megjelent a forrásport véletlenszerű megválasztása; a BIND-ban és leszármazottaiban csak 2008-ban, "emergency patch"-ként.
    • Szintén segít, ha minden kérést többször küldünk el (más-más véletlen azonosítókkal) és a válaszokat csak akkor fogadjuk el, ha megegyeznek.
  2. A második eset az, amikor a támadónak van egy domainje, mondjuk a foo.bar, és ennek valamelyik szubdomainjét delegálja - mondjuk - az ns.bme.hu-nak.
    • Pl. ize.foo.bar. IN NS ns.bme.hu.
    • Ehhez a válaszhoz glue-ként mellékeli az ns.bme.hu állítólagos IP-címét, de nem a valódit, hanem egy olyan címet, amit ő ellenőriz.
      • Pl. ns.bme.hu. IN A 1.2.3.4 , ahol 1.2.3.4 a támadó szervere.
    • Ha a kliensszoftver hibás, és elfogadja a glue-t annak ellenére, hogy a foo.bar nameserver nem autoritatív a bme.hu domainre (és így nincs joga nyilatkozni az ns.bme.hu IP-jéről), akkor
      • a cache-ben a támadó által megadott - vélhetően jó hosszú - TTL lejártáig tárolja, hogy az ns.bme.hu IP-je 1.2.3.4.
      • Ezután, ha ez a kliens olyan domainhez tartozó nevet próbálna feloldani, amire az ns.bme.hu autoritatív, az 1.2.3.4-hez fog fordulni, hiszen "tudja", hogy az ns.bme.hu IP-je ez.
      • Így a támadó az ilyen módon "eltérített" szervernek szóló összes kérdésre adott választ ellenőrizheti, átírhatja.
      • Ennek a támadásnak egy variánsa az, ha a támadó a válaszába irreleváns rekordot rak az Authority section-be,
        • amiben pl. azt mondja, hogy bme.hu. IN NS ns.foo.bar. (holott ezt nem is kérdezte senki).
    • Védekezés: nem fogadunk el olyan glue-t vagy authority rekordot, amelyre az a szerver, amelytől kapjuk, nem autoritatív;
      • a példában az ns.bme.hu IP-címét a gyökértől indulva külön meg kellett volna keresni a "hagyományos" feloldóalgoritmussal.
    • Természetesen abban az esetben, ha a támadó szervere valóban autoritatív a .hu-ra vagy a .bme.hu-ra, azt hazudik az ns.bme.hu IP-jével kapcsolatban, amit csak akar;
      • sőt, mivel ő mondja, definíció szerint az lesz az igazság.
    • Ezért veszélyes, ha egy a DNS-hierarchiában "magas szinten álló" nameserverre betör valaki.
    • Ez ellen max. úgy védekezhetünk, ha megpróbáljuk az összes választ az összes, rá autoritatív szervertől beszerezni, aztán pl. többségi szavazással eldöntjük, melyik választ fogadjuk el.
      • Ez elég lassú lenne.
  3. A harmadik fajta támadás során a támadó man-in-the-middle támadást valósít meg egy primary és egy secondary nameserver között
    • (vagy egyéb módon eléri, hogy a secondary őhozzá forduljon AXFR-rel a primary helyett), és
    • az AXFR-rel átvitt adatokat "röptükben" átírja.
    • Így a secondaryn a támadó által elhelyezett hamis adatok lesznek, úgyhogy azok a kliensek, akik a secondaryhoz fordulnak, a hamis válaszokat fogják megkapni.
    • Ha a primaryt a támadó valahogyan ki tudja vonni a forgalomból, akkor minden kliens a hamis adatokat látja.
    • Ez ellen a saját szervereink esetében úgy védekezhetünk, hogy
      • biztonságos VPN-t húzunk ki a két szerver között, és efölött AXFR-ezünk, vagy
      • AXFR helyett valamilyen más, biztonságos, hitelesített átviteli módszert alkalmazunk (pl. rsync over ssh).
    • Más szerveren így elhelyezett hamis adatok ellen gyakorlatilag nem tudunk védekezni
      • (max. a többségi szavazásos módszerrel, de az nem hatékony és nem is 100%-os).

Érdemes a Wikipédián utánaolvasni, ha nem lenne világos.

7.2 Glue hiánya

Egy delegáció kétféleképpen lehet glueless.

  • Az egyik eset az, amikor olyan szervernek delegálunk egy domaint, amelynek a nevére nem vagyunk autoritatívak:
    • pl. a .hu-ra autoritatív ns.nic.hu az ns2.pantel.net-nek delegálja a bme.hu domaint.
  • Ebben az esetben az ns.nic.hu nem adhatja át glue-ként az ns2.pantel.net A rekordját a kliensnek, mivel nincs joga nyilatkozni arról, hogy a .net domain alá tartozó ns2.pantel.net gépnek mi a címe.
    • Ha véletlenül amúgy az ns.nic.hu egyben .net szerver is lenne, tehát autoritatív lenne a .pantel.net-re, az sem sokat segítene, mert a kliens a .hu-delegációt követve jutott el hozzá, és nem tudja, hogy a .net-re is autoritatív (mivel a root szervertől nem a .net-et kérdezte).
    • Így a kliens mindenképpen újra a roottól indul el, de most a .net-re autoritatív szerverek adatait kérdezi le.
    • Ez a delegáció az ns.nic.hu üzemeltetőjének egyébként kényelmesebb, mert nem kell foglalkoznia az ns2.pantel.net A rekordjával és annak változásaival.
    • Sokkal jobb lenne, ha a BME rendszergazdái bejegyeznének egy -- teszemazt -- pantel.ns.bme.hu-t az ns2.pantel.net IP-jével:
      • Így ez az IP megjelenhetne glue-ként a .hu zónában, és a kliensek megkaphatnák a .hu-s szerverektől a panteles névszerver IP-jét is.
  • A másik eset az, amikor a delegáló szerver adatbázisába szándékosan nem vesszük fel az alárendelt szerver A rekordját annak ellenére, hogy megtehetnénk (mert autoritatívak vagyunk a nevére).
    • Ez elég nagy marhaságnak tűnik; remélem, a valóságban senki nem csinál ilyet.
    • Az motiválhatja mégis, hogy így a zónába nem kell felvenni a delegációt kapó DNS-szerver A rekordját, így ezt a rekordot karbantartani sem kell, ha megváltozna
      • (ehhez persze viszonylag bonyolult üzleti folyamatok tartozhatnak, úgyhogy nem feltétlenül egyszerű).
      • Ez roppant kényelmes a delegációt végző szerver üzemeltetője számára, csak mindenki mással kitolás.
      • Nem csinálhatja ezt az összes delegáló szerver, mert akkor a delegált domain elérhetetlen lesz.
  • A baj a glueless delegációval az, hogy a kliensnek újra kell kezdenie a feloldást, esetleg a gyökértől, hogy megtudja a megkérdezendő szerver IP-címét; ha közben újabb glueless delegációval találkozik, akkor megint, s.í.t.
  • Így nem biztos, hogy adható felső korlát egy feloldás memóriaigényére.
  • Ráadásul a glueless-ség körbeérhet, és ebben az esetben a körben szereplő egyetlen domain sem oldható fel.
    • Pl. ha az a.com nameservere az ns.b.net, a b.net-é az ns.c.hu, a c.hu-é az ns.d.org, a d.org-é pedig az ns.a.com, akkor egyik domain sem elérhető, ha a delegációk glueless-ek, de mire ez kiderül, a rekurzív rezolver elpazarolt egy csomó időt és memóriát.
  • Hogy a mi domainjeinkre mutató delegációk gluelessek-e, azt mi magunk is befolyásolhatjuk; ha ügyelünk arra, hogy a domainre autoritatív szerver neve a domainen belül legyen (tehát a foo.com nameserverének neve a foo.com domainbe tartozzon, mondjuk ns.foo.com vagy a.ns.foo.com), akkor adunk esélyt a glue-nak.

7.3 CNAME-láncok

Ugyanaz a gond, mint a sok egymásra mutató glueless delegációnál.

  • Fel kell jegyeznünk, melyik CNAME-et láttuk már, hogy ha körbeér, ne kerüljünk végtelen ciklusba.
  • Emiatt nem adható felső korlát egy lekérdezés memóriaigényére.

7.4 Joker-bejegyzések

(A wildcard magyarul bizonyára vadkártya...)

Ha sok apró .com domainünk van, kísértést érezhetünk arra, hogy a szerverünket az egész .com-ra autoritatívvá tegyük, mivel

  • így kevesebb zónafájlt kell létrehozni (ugye, megint a BIND :), és
  • "nem okoz bajt", hiszen "úgysem kérdez minket senki olyan domainről, ami nem a miénk".

Ha

  • minden külön be nem jegyzett névvel kapcsolatos A kérdésre a webszerverünk IP-jével válaszolunk
    • (l. pl. "*.freeweb.hu")
  • és valaki véletlenül nekünk delegálja a teljes .com zónát
  • és valaki más ezt elhiszi neki (pl. egy Windows 2000), akkor

az, akinek a cache-e megmérgeződött, az összes .com oldal helyett a mi weboldalunkat fogja látni.

  • Újsághír: "a Kukutyin Bt feltörte a google.com-ot", és magyarázkodhatunk.

Tanulság: a szerverünk csak olyan kérésekre válaszoljon, amikre valóban (a root szerverek szerint is) autoritatív.

7.5 A delegációs rendszer törékenysége

Váratlan, félreeső helyeken található, rég elfeledett, rosszul karbantartott gépeken is múlik, hogy a domainünk (ide értve akár egy teljes TLD-t) helyesen működik-e.

Nézzük meg például, mely gépek befolyásolhatják a bme.hu zóna látszólagos tartalmát:

Példa
  1. A támadó a hatalmába keríti az egyik, a .se domainre autoritatív szervert.
  2. A támadó bejegyzi ezen a szerveren az akarmi.se domaint.
  3. Az akarmi.se zónafájljában elhelyezi a baloldalt látható rekordokat.
  4. Küld az áldozatnak egy HTML formátumú levelet, amelyben hivatkozik a http://www.bme.hu/1.gif-re és a http://valami.akarmi.se/1.gif-re.
    • Egyik kép sem kell, hogy létezzen.
    • Számos módszer van arra, hogy egy áldozatot meghatározott DNS-lekérdezések elvégzésére motiváljunk; ez csak az egyik.
  5. A kliens DNS cache-e feloldja a www.bme.hu-t és megjegyzi, amit a root szerverektől hall, így többek között azt is, hogy a .hu-ra autoritatív a sunic.sunet.se.
  6. A kliens DNS cache-e feloldja a valami.akarmi.se-t; ha a támadónak szerencséje van, a .se-re autoritatív szerverek közül éppen a támadó által ellenőrzöttnél érdeklődik, így megkapja a támadó által ott elhelyezett, baloldalt látható két rekordot: az egyikkel a sunic.sunet.se-nek delegálja a valami.akarmi.se-t, a másik pedig ehhez tartozó glue.
  7. Mivel a glue egy a .se-re autoritatív szervertől érkezett, a kliens elmenti, és innentől azt fogja hinni, hogy a sunic.sunet.se IP-címe 1.2.3.4.
  8. Mivel a cache-ében az is megvan, hogy a sunic.sunet.se autoritatív a .hu-ra, a továbbiakban a .hu-val kapcsolatos kéréseinek egy részét az 1.2.3.4-nek fogja küldeni.
  9. A támadó ezekre a kérésekre azt válaszol, amit akar; az áldozat szemszögéből nézve az egész .hu zóna teljes tartalmát a támadó ellenőrzi (feltéve, hogy valamilyen más módszerrel arról is gondoskodik, hogy a kliens a többi .hu-ra autoritatív szerverhez ne tudjon fordulni).
  • A root szerverek, természetesen (hiszen ők definíció szerint minden zónára autoritatívak), de bennük mondjuk megbízunk.
  • A .hu szerverek (2008 körüli állapot; 2012-re jelentősen javult a helyzet):
hu. 172800 IN NS NS3.NIC.hu.
hu. 172800 IN NS SUNIC.SUNET.SE.
hu. 172800 IN NS NS.NIC.hu.
hu. 172800 IN NS NS1.NIC.hu.
hu. 172800 IN NS NS2.NIC.FR.
hu. 172800 IN NS NS2.NIC.hu.
  • Ezek a szerverek, mivel az egész .hu domainre autoritatívak, bármit mondhatnak a bme.hu domainbe tartozó nevekről.
  • A .hu-s szerverek IP-jét megkapjuk glue-ként, de pl. egy .se-szerver kiütheti a sunic.sunet.se-re vonatkozó korábbi glue-t a cache-ünkből egy olyasmi válasszal, hogy
valami.akarmi.se 1000000 IN NS sunic.sunet.se
sunic.sunet.se   1000000 IN A  1.2.3.4
  • Mivel a szerver autoritatív a .se domainre, a fenti glue-t a cache-ünk elfogadja és elmenti; a root szerverektől kapott sunic.sunet.se glue-t eldobja.
  • Mivel a sunic.sunet.se autoritatív a .hu-ra, autoritatív a .bme.hu-ra is.
    • Mivel minden .se-szerver autoritatív a sunic.sunet.se névre, mindegyik megadhat hozzá egy olyan IP-t, ami a .bme.hu-ra vonatkozó kérdésekre hamis adatokkal válaszol.
    • Ugyanez érvényes a .sunet.se-szerverekre is.
  • Melyek a .sunet.se szerverek?
sunet.se.               86400   IN      NS      b.ns.kth.se.
sunet.se.               86400   IN      NS      foot.snowman.sunet.se.
sunet.se.               86400   IN      NS      head.snowman.sunet.se.
sunet.se.               86400   IN      NS      sunic.sunet.se.
sunet.se.               86400   IN      NS      server.nordu.net.
  • Vagyis a kth.se és a nordu.net szerverei is megmondhatják, mi a www.bme.hu IP-címe. Ezek:
kth.se.                 86400   IN      NS      a.ns.kth.se.
kth.se.                 86400   IN      NS      b.ns.kth.se.
kth.se.                 86400   IN      NS      nic.lth.se.
nordu.net.              172800  IN      NS      nn.uninett.no.
nordu.net.              172800  IN      NS      sunic.sunet.se.
nordu.net.              172800  IN      NS      server.nordu.net.
  • Mit tudtunk meg eddig?
    • Ha egy támadó, akié az 1.2.3.4-es IP, a hatalmába keríti az nn.uninett.no-t, akkor
    • hazudhatja azt, hogy a server.nordu.net IP-je 1.2.3.4, így
    • a sunet.se-re vonatkozó kérések (egy része) az ő szerverére fut be.
    • A sunic.sunet.se IP-jét firtató kérdésekre szintén válaszolhatja azt, hogy 1.2.3.4, így
    • a .hu-val kapcsolatos kérések egy része is hozzá fut be.
  • Tanulság: egy norvég számítógép biztonságosságán (is) múlik az összes .hu domain elérhetősége és helyes működése.
  • De nézzük tovább, hátha vége lesz a láncnak egyszer:
lth.se.                 86400   IN      NS      b.ns.kth.se.
lth.se.                 86400   IN      NS      nic.lth.se.
lth.se.                 86400   IN      NS      nic2.lth.se.
  • Ez jó, az lth.se domainről csak lth.se-n belüli gépek nyilatkozhatnak (meg persze az összes .se szerver).
    • Azért jó, mert itt véget ér a "bizalmi lánc", nincsenek újabb domainek, amelyeknek a szervereiben meg kell bíznunk.
      • Valójában külön meg kellene győződni arról is, nem delegálják-e a nic.lth.se és/vagy a nic2.lth.se nevet lth.se-n kívüli nevű szervernek. Most egyszerűen fogadjuk el, hogy nem.
uninett.no.             82647   IN      NS      nn.uninett.no.
uninett.no.             82647   IN      NS      nac.no.
uninett.no.             82647   IN      NS      biff.uninett.no.
uninett.no.             82647   IN      NS      benoni.uit.no.
uninett.no.             82647   IN      NS      server.nordu.net.
nac.no.                 86400   IN      NS      nn.uninett.no.
nac.no.                 86400   IN      NS      nac.no.
nac.no.                 86400   IN      NS      biff.uninett.no.
uit.no.                 83041   IN      NS      nac.no.
uit.no.                 83041   IN      NS      lozen.uit.no.
uit.no.                 83041   IN      NS      benoni.uit.no.
  • Ezzel a skandináv vonalat nagyjából lefedtük (az összes .se szerver .se alatti), nézzük a franciákat:
fr.                     172537  IN      NS      A.EXT.NIC.fr.
fr.                     172537  IN      NS      A.NIC.fr.
fr.                     172537  IN      NS      B.EXT.NIC.fr.
fr.                     172537  IN      NS      B.NIC.fr.
fr.                     172537  IN      NS      C.EXT.NIC.fr.
fr.                     172537  IN      NS      C.NIC.fr.
fr.                     172537  IN      NS      D.EXT.NIC.fr.
fr.                     172537  IN      NS      E.EXT.NIC.fr.
fr.                     172537  IN      NS      E.NIC.fr.
nic.fr.                 166205  IN      NS      dns.inria.fr.
nic.fr.                 166205  IN      NS      ns0.oleane.net.
nic.fr.                 166205  IN      NS      ns1.nic.fr.
nic.fr.                 166205  IN      NS      ns1.oleane.net.
nic.fr.                 166205  IN      NS      ns2.nic.fr.
nic.fr.                 166205  IN      NS      ns3.nic.fr.
nic.fr.                 166205  IN      NS      ns-sec.ripe.net.
inria.fr.               172391  IN      NS      dns.cs.wisc.edu.
inria.fr.               172391  IN      NS      dns.inria.fr.
inria.fr.               172391  IN      NS      dns.princeton.edu.
inria.fr.               172391  IN      NS      ns2.nic.fr.
inria.fr.               172391  IN      NS      imag.imag.fr.
inria.fr.               172391  IN      NS      nez-perce.inria.fr.
oleane.net.             84317   IN      NS      ns0.oleane.net.
oleane.net.             84317   IN      NS      ns1.oleane.net.
oleane.net.             84317   IN      NS      ns2.nic.fr.
ripe.net.               167216  IN      NS      ns3.nic.fr.
ripe.net.               167216  IN      NS      sunic.sunet.se.
ripe.net.               167216  IN      NS      ns-ext.isc.org.
ripe.net.               167216  IN      NS      ns-pri.ripe.net.
edu.                    172787  IN      NS      A3.NSTLD.COM.
edu.                    172787  IN      NS      C3.NSTLD.COM.
edu.                    172787  IN      NS      D3.NSTLD.COM.
edu.                    172787  IN      NS      E3.NSTLD.COM.
edu.                    172787  IN      NS      G3.NSTLD.COM.
edu.                    172787  IN      NS      H3.NSTLD.COM.
edu.                    172787  IN      NS      L3.NSTLD.COM.
edu.                    172787  IN      NS      M3.NSTLD.COM.
wisc.edu.               85121   IN      NS      cs.wisc.edu.
wisc.edu.               85121   IN      NS      dns.cs.wisc.edu.
wisc.edu.               85121   IN      NS      dns2.cs.wisc.edu.
wisc.edu.               85121   IN      NS      dns2.itd.umich.edu.
umich.edu.              172601  IN      NS      DNS.CS.WISC.edu.
umich.edu.              172601  IN      NS      DNS.ITD.umich.edu.
umich.edu.              172601  IN      NS      DNS2.ITD.umich.edu.
princeton.edu.          169170  IN      NS      dns.princeton.edu.
princeton.edu.          169170  IN      NS      ns1.fast.net.
princeton.edu.          169170  IN      NS      ns1.ucsc.edu.
princeton.edu.          169170  IN      NS      ns2.fast.net.
princeton.edu.          169170  IN      NS      ns3.nic.fr.
princeton.edu.          169170  IN      NS      arizona.edu.
fast.net.               2579    IN      NS      dns1.uslec.net.
fast.net.               2579    IN      NS      dns2.uslec.net.
fast.net.               2579    IN      NS      dns3.uslec.net.
fast.net.               2579    IN      NS      dns4.uslec.net.
fast.net.               2579    IN      NS      dns5.uslec.net.
arizona.edu.            172196  IN      NS      CS.arizona.edu.
arizona.edu.            172196  IN      NS      arizona.edu.
arizona.edu.            172196  IN      NS      NS-REMOTE.arizona.edu.
arizona.edu.            172196  IN      NS      PENDRAGON.CS.PURDUE.edu.
purdue.edu.             82957   IN      NS      ns.purdue.edu.
purdue.edu.             82957   IN      NS      ns1.rice.edu.
purdue.edu.             82957   IN      NS      ns2.rice.edu.
purdue.edu.             82957   IN      NS      harbor.ecn.purdue.edu.
purdue.edu.             82957   IN      NS      pendragon.cs.purdue.edu.
rice.edu.               2998    IN      NS      ns.purdue.edu.
rice.edu.               2998    IN      NS      moe.rice.edu.
rice.edu.               2998    IN      NS      ns1.rice.edu.
rice.edu.               2998    IN      NS      ns2.rice.edu.
...
  • A fenti gépek mind-mind elérhetik, hogy bizonyos kliensek hibás/hamis információval rendelkezzenek a .hu alatti domainekről.
  • Pl. az ns1.rice.edu autoritatív a purdue.edu-ra, úgyhogy ha valaki betör rá, meghamisíthatja az ns.purdue.edu és a pendragon.cs.purdue.edu címét;
  • a pendragon.cs.purdue.edu autoritatív az arizona.edu-ra;
  • az arizona.edu autoritatív a princeton.edu-ra;
  • a dns.princeton.edu autoritatív az umich.edu-ra;
  • a dns2.itd.umich.edu autoritatív a wisc.edu-ra;
  • a dns.cs.wisc.edu autoritatív az inria.fr-re;
  • a dns.inria.fr autoritatív a nic.fr-re;
  • az ns2.nic.fr autoritatív a .hu-ra.

Vagyis, közvetve, az ns1.rice.edu is "autoritatív" a .hu-ra, pedig ezt kifejezetten biztosan nem akarta senki.

Általában több száz számítógép biztonságosságán múlik minden domain helyes működése. Ha ebből a többszázból csak egyre betörnek, a kliensek egy részét el tudják téríteni. Az eltérített felhasználók hányada viszonylag egyszerűen növelhető; ezzel kapcsolatban l. DJB egyik levelét a bugtraq listára.

7.6 Bitsquatting

A számítógépek időnként hibáznak: pl. egy-egy bit átállítódik a memóriában. Ha ez egy domain-névvel történik, akkor a DNS-kliens esetleg nem a megfelelő domaint oldja fel, hanem egy attól 1 bitnyi Hamming-távolságra levőt (pl. cnn.com helyett con.com). Ha ilyen domaineket jegyzünk be, sok esetben hozzánk futnak be a felhasználók kérései, és azt válaszolhatunk rájuk, amit akarunk (http esetén pl. rosszindulatú kódot injektálhatunk az oldalakba; SMTP esetén leveleket lophatunk el stb.). A https sem segít, hiszen rendelkezhetünk az általunk bejegyzett névre szóló érvényes tanúsítvánnyal.

A typosquatting ellen az ismertebb domainek próbálnak védekezni (úgy, hogy a gyakori elgépelésekhez tartozó domaineket is bejegyzik), de a bitsquatting azokat a domaineket is érinti, amiknek a nevét a felhasználók (szinte) sosem írják be közvetlenül: fbcdn.net, cloudfront.net, google-analytics.com stb.

Konkrét klienst nehézkes így megtámadni, de szőnyegbombázásszerű támadásokra nagyon is alkalmas lehet ez a nem túl ismert módszer.

8 Kísérletek a DNS biztonságának fokozására

(Megjegyzendő, hogy ahogy az IT más területein, itt sem feltétlenül az informatikai komponensek a legsebezhetőbbek. 2013. októberében például hamis fax-üzenetekkel sikerült domainek DNS-szervereit átiratni egy regisztrátornál.)

A DNS algoritmikus, protokoll-szintű biztonságának javítására két értékelhető próbálkozás történt: a DNSSEC és a DNSCurve. Természetesen(?) sikerült a kettő közül a problémásabbat szabványosítani.

8.1 DNSSEC

  • "Szabvány" (amennyire egy IETF RFC az): RFC4033, RFC4034, RFC4035.
    • Alapja az EDNS (a sima DNS protokoll bővítése úgy, hogy az adatcsomagok és néhány mező lehetséges méretét megnövelték: RFC2671).
      • Működés lényege: kamu "OPT" típusú rekordok beszúrása a válaszokba. A részletek nem érdekesek.
      • Komoly hátrány: kis kérdéscsomagra másfél nagyságrenddel nagyobb válaszcsomag generálódik; ez felhasználható támadásra.
  • A DNSSEC célja: kliensek védelme a cache poisoning ellen.
    • Minden válaszcsomag digitális aláírást tartalmaz.
    • Alá kell tudni írni az NXDOMAIN tartalmú válaszokat is.
      • Az első, 1993-as DNSSEC-javaslatban erre még nem gondoltak.
  • Nem cél a lehallgatás elleni védelem.
  • Nem cél az AXFR biztonságossá tétele.
  • Cél, hogy ne legyen szükség az aláírásra használt titkos kulcsra a DNS-szerverek működéséhez (az összes aláírandó adatot alá lehessen írni előre).
    • Állítólag a valódi motiváció az volt, hogy azt gondolták, a kriptográfia annyira lassú, hogy egy DNS-szervernek amúgy sem lenne ideje (CPU-kapacitása) rá.
  • (Nyilván) nem véd az olyan jellegű megalapozatlan feltételezések következményei ellen, mint pl. hogy a cégnév.com mindenképpen az adott cég domainje.
  • Többféle titkosítást/hasht támogat és lehetőség van újak bevezetésére, ha a meglevők gyengének bizonyulnak.
    • A jelenlegi választás, az 1024 bites RSA, már viszonylag gyenge: egy nagy botnet számára reális a feltörése.
  • Nehézségek:
    • Kompatibilisnek kell maradnia a meglevő, régi DNS-szerverekkel és kliensekkel, különben nem tud elterjedni.
    • Lehetőség szerint kerülni kell azt, hogy akárki könnyedén megszerezhesse az összes zóna teljes tartalmát.
      • Ezt a DNSSEC nem teljesíti; az NXDOMAIN kezelése miatt viszonylag könnyen előállítható egy domainben regisztrált valamennyi név:
        • Nem írhatunk alá előre egy általános NXDOMAIN választ, mert ez lehallgatható és visszajátszható lenne.
        • Nem írhatjuk alá a konkrét névre vonatkozó NXDOMAINt, mert nem tudjuk előre, milyen neveket fognak keresni a kliensek, menet közben pedig nem férünk hozzá a kulcshoz.
        • A kitalált megoldás: a DNSSEC azt, hogy pl. nem létezik az n.példa.hu, úgy fogalmazza meg, hogy "nincs rekord a mail.példa.hu és a számlázás.példa.hu között".
          • Ezzel felfedi a mail.példa.hu és a számlázás.példa.hu létezését.
      • Ezt a problémát a 2008-ban publikált RFC5155 enyhíti az NSEC3 rekordtípus bevezetésével. Lényege:
        • "Nincs olyan rekord, amely nevének hash-e X és Y közé esik." -- vagyis X-et és Y-t szótáralapú támadás segítségével felderíthetjük.
        • Tényleg csak enyhíti, l. pl. http://dnscurve.org/nsec3walker.html.
    • Világméretű PKI (nyilvános kulcsú titkosítási/hitelesítési infrastruktúra) kell hozzá, ami komoly szervezeti kihívás.
      • A klienseknek kell olyan kulcs -- pl. a root zónáé --, aminek eleve, a DNS-től függetlenül a birtokában vannak.
    • Nem terjed el, mert egyelőre nagyobb költség bevezetni, mint amekkora hasznot hoz -- a penetráció növekedésével ez talán változna.
      • Ahhoz, hogy egy domain aláírását hitelesíteni lehessen, ismernünk kell a DNS-től független forrásból egy olyan nyilvános kulcsot, amelyhez tartozó titkos kulccsal VAGY az adott domaint, VAGY valamelyik fölérendelt domaint aláírták; utóbbi csak akkor megfelelő, ha az összes köztes domaint is aláírták.
      • Pl.: ha az src.doc.ic.ac.uk aláírását akarjuk hitelesíteni, és az ac.uk domain nincs aláírva, akkor hiába van aláírva a gyökér és akár a .uk zóna is, az ic.ac.uk domain kulcsa nélkül nem tudjuk elvégezni a hitelesítést.
      • A gyökérzóna csak 2010 nyara óta van aláírva.
      • 2011 novemberében a TLD-knek csak 25%-a volt aláírva (a második szintű domaineknek pedig csak töredéke).
    • Politika: a DNSSEC elvileg lehetővé teszi nyilvános kulcsok hitelesített terjesztését (CERT rekordokban). Ennek nem minden kormány örül.
    • Az aláírt DNS-rekordok visszajátszhatóak; az aláírások általában durván egy hónapig érvényesek (l. RFC4641, 4.4.4-es szakasz).
      • Így, ha az 1.2.3.4-es IP és a példa.hu domain a miénk volt, de valami miatt IP-t váltottunk és az 1.2.3.4 egy támadóé lett, a régi DNSSEC-rekordjaink visszajátszásával továbbra is elhitetheti a kliensekkel, hogy -- pl. -- a www.példa.hu IP-je az 1.2.3.4, és ezen a címen hamis website-ot üzemeltethet.
      • Ez azt is jelenti, hogy kb. havonta újra alá kell írni az összes adatot, akkor is, ha nem volt változás. Ha elfelejtjük, eltűnünk az Internetről.
        • Ilyen és hasonló problémák miatt ideiglenesen elérhetetlen domainek listáját láthatjuk a Comcast listáján.
      • A visszajátszás segítségével lassíthatók a DNS-alapú terheléselosztók kliensei (pl. akamai): pl. ausztrál szerverhez irányíthajtuk a francia klienst.
  • Működése (kivonat):
    • Kitaláltak néhány új rekordtípust (DNSKEY, DS, NSEC, NSEC3, NSEC3PARAM, RRSIG).
    • Minden válaszcsomagban van a válasz mellett egy RRSIG rekord is, amely a válasz többi részének digitális aláírását tartalmazza.
    • Az aláírást a megfelelő DNSKEY rekordban levő nyilvános kulcs segítségével hitelesíthetjük.
      • Ez a DNSKEY rekord ugyanabban a domainben van, amelyre az aláírás vonatkozik, tehát önmagát (is) hitelesíti.
      • Mivel ez nyilván nem elegendő, a szülődomainben (a példa.hu esetében pl. a .hu-ban) az adott domain DS rekordja tartalmazza a domain kulcsának a kivonatát.
      • Tehát:
        • Ha feloldjuk a www.példa.hu-t, a válaszban szereplő A rekord tartalmát a válaszban szereplő RRSIG rekordban levő aláírás hitelesíti.
        • Ezt az aláírást a példa.hu domain DNSKEY rekordjában levő nyilvános kulcs titkos párjával készítik. (Tehát a DNSKEY rekordban levő kulcs segítségével hitelesíthető.)
        • A példa.hu DNSKEY rekordjának hitelességéről úgy győződhetünk meg, hogy megnézzük a példa.hu DS rekordját (amely a .hu zónafájlban van).
        • A DS rekordot a .hu-ra autoritatív szervertől kapott RRSIG rekordban levő aláírás hitelesíti.
        • Ezt a .hu domain DNSKEY rekordjában levő nyilvános kulcs titkos párjával készítik. (Tehát a DNSKEY rekordban levő kulcs segítségével hitelesíthető.)
        • A .hu DNSKEY rekordját a root zónában levő, .hu-ra vonatkozó DS rekord tartalmával tudjuk hitelesíteni.
        • A .hu domain DS rekordját a root szervertől kapott RRSIG rekordban levő aláírás hitelesíti.
        • Az aláírás a root domain DNSKEY rekordjában levő nyilvános kulccsal hitelesíthető.
        • Ezt a nyilvános kulcsot magát a DNS segítségével nem tudjuk hitelesíteni; elvileg más, biztonságos forrásból már ismerjük.

8.2 DNSCurve

  • Nem szabvány.
  • Céljai:
    • Kompatibilitás a meglevő DNS-sel.
    • A DNSSEC DoS-erősítő hatásának elkerülése.
      • A DNSCurve ugyan kicsivel megnöveli a DNS-csomagok méretét, de csak néhány százalékkal.
    • A DNS-kérdések és válaszok titkosítása és hitelesítése.
    • Ha nem akarjuk, ne kelljen lecserélni a meglevő autoritatív szervert (elég elérakni pl. a CurveDNS nevű proxyt).
    • Ne kelljen változtatni a DNS-adatok karbantartásának folyamatán.
    • Nem cél, hogy menet közben ne legyen szükség a titkos kulcsra.
  • Működési elve:
    • Speciális nevet kell választani az autoritatív szervernek.
      • Pl: példa.hu. IN NS uz5xgm1kx1zj8xsh51zp315k0rw7dcsgyxqh2sl7g8tjg25ltcvhyw.példa.hu.
      • Ez a név tartalmazza a szerver 255 bites nyilvános kulcsát.
      • Ha egy kliens lekérdezi egy domain névszervereit, el tudja dönteni, van-e köztük olyan, amelyiknek a neve érvényes nyilvános kulcsot tartalmaz.
      • Ha igen, az ennek a szervernek küldött kéréseket a kliens ezzel a nyilvános kulccsal titkosítja.
    • A kliens a kérésben elküldi saját (pl. indításkor generált) nyilvános kulcsát a szervernek.
    • A kérésekben 96 bites nonce van.
      • Ugyanazzal a kulccsal ugyanazt a nonce-t nem szabad egynél többször használni; ha 296-nál több kérést akarunk küldeni, új kulcsot kell generálnunk.
      • A magánszféra védelme érdekében amúgy is édemes lehet időnként új kulcsot generálni, mert a DNS-szerverek a kulcs alapján egyértelműen azonosíthatják a klienseket.
      • A DNSCurve honlapján további tanácsokat találunk a nonce megválasztásával kapcsolatban.
    • A kérés-csomag plaintextben csak a kliens nyilvános kulcsát és a nonce-t tartalmazza; minden más a titkosított mellékletben található.
    • A kérés-csomag titkosított részének titkosításában szerepet játszik:
      • a nonce,
      • a kliens titkos kulcsa és
      • a szerver nyilvános kulcsa.
    • A szerver titkosítja és hitelesíti a válaszcsomagot.
    • A válaszcsomag plaintextben csak a kliens- és szerveroldali nonce-t tartalmazza; minden más a titkosított mellékletben található.
    • A válaszcsomag titkosított részének titkosításában szerepet játszik:
      • A kliens által küldött nonce,
      • a szerver által választott 96 bites nonce,
      • a kliens nyilvános kulcsa és
      • a szerver titkos kulcsa.
    • Ha a mellékletet nem sikerül visszafejteni, akkor hamisítvány és el kell dobni.
    • A melléklet tartalma egy hagyományos DNS-válasz.
  • Nehézségek:
    • Ugyanúgy szükség van nem a DNS-ből származó kulcsok ismeretére, mint a DNSSEC esetében.
    • A DNS-csomagok formátuma megváltozik, így esetleg nem megy át olyan tűzfalakon, amelyek kényesek erre.
      • Van rá kerülőutas megoldás: a DNSCurve-vel összefüggő adatokat TXT rekordokban utaztatják. Hátrány: kevésbé hatékony.
    • Nem lehet hierarchiába szervezni a cache-eket (pontosabban: ha megtesszük, a DNSCurve csak a legfelsőbb szintű cache és az autoritatív szerver közötti szakaszt védi).
      • Ez nem valódi probléma: a saját klienseink és saját cache-eink között használhatunk más titkosított és hitelesített kapcsolatot (IPSec, OpenVPN stb.).

9 Gyakorlati tanácsok

A valóságban nemcsak technikai, hanem ügyviteli, emberi és jogi problémákkal is találkozhatunk, ha domainjeink vannak. Néhány trükkel ezeknek a hatásai csökkenthetők.

  • Legyen legalább két, de inkább több névszerverünk. Egy autoritatív szerver nem túl erőforrásigényes; ha úgyis van hosztolt gépünk, vagy akár fix IP-s DSL-ünk, bérelt vonalunk stb., tegyünk rá egy DNS-szervert. Ha akarjuk, havi egy euróért már bérelhetünk egy olyan virtuális szervert, ami alkalmas erre.
  • A névszervereink IP-ihez több különböző domainbe tartozó név is tartozzon.
    • Pl. a.ns.domain1.com; a.ns.domain2.net; a.ns.domain3.hu és ugyanez b-vel.
    • Ha sok különböző hálózatban levő fix IP-nk van, érdemesebb a fenti neveknél egy-egy névhez több IP-t bejegyezni, mint több nevet egy-egy IP-vel; így kevesebb memóriát használunk el a cache-ekben és az eredmény ugyanaz.
      • Igazából egyetlen név is elég lenne, több IP-vel, de bizonyos TLD-k ragaszkodhatnak ahhoz, hogy két különböző nevű DNS-szerverünk legyen.
  • Ha domaint jegyzünk be, a glue érdekében legyen olyan nameservere is, ami része a domainnek (tehát, ha mondjuk a pelda.hu-t jegyezzuk be, akkor legyen mondjuk a.ns.pelda.hu és b.ns.pelda.hu), de a domainen kívüli is, olyan domainben, amiben könnyen tudjuk módosítani a névszerverekhez tartozó IP-t (pl. a.ns.pelda.org ill. b.ns.pelda.org).
    • A .hu zóna régebben nagyon bürokratikusan működött; nehézkes és lassú volt a domainek bejegyzése és például a névszerverekhez tartozó glue frissítése, vagy a névszerverek listájának módosítása. A folyamatok mára karcsúsodtak: 2017. végén már csak az igénylés és a tulajdonosváltás viszonylag bürokratikus (kellhet hozzá például aláírási címpéldány). Ennek előnyei is vannak: nem történhet meg olyan eset, mint például a a hix.com-al. A névszerverek listájának módosítása az ISZT oldalán automatizált, néhány órán belül megtörténik (ezzel a .hu messze nincs a TLD-k élvonalában, de a párórás reakcióidő többnyire kibírható). Ehhez a néhány órához hozzáadódik a regisztrátor üzleti folyamatainak időigénye; van olyan regisztrátor, aki lehetővé teszi, hogy webes felületen magunknak kattintgassuk át a zónánk adatait, másoknál esetleg papírozni kell ehhez, ne adj' Isten faxolni is. Érdemes gondosan választani regisztrátort; nem biztos, hogy a nagyok jobbak, mint a kicsik. Szerencsére viszonylag könnyen átmehetünk másikhoz, ha az első nem tetszik.
    • Az a.ns.pelda.org és az a.ns.pelda.hu IP-i nyilván lehetnek azonosak.
    • Az egésznek az az értelme, hogy ha pl. a szolgáltatónk hirtelen megváltoztatja az IP-címünket, akkor ne egyetlen TLD rugalmasságától, működési sebességétől függjön, milyen hamar tudjuk újra elérhetővé tenni a domainünket. Az a.ns.pelda.org és a b.ns.pelda.org IP-jének átírásával perceken belül általában újra feloldhatóvá tehetjük a domaint. Utána már nem baj, hogy a .hu zónában órás nagyságrendű időbe telik a változtatás. (Persze azok a kliensek, akiknek megvan cache-ben az előző NS IP, a TTL lejártáig még próbálkozhatnak a régi IP-n.)
    • Emiatt aztán az se baj, ha arra is vigyázunk, hogy minden domainünknek legyen olyan nevű névszervere, ami olyan domainbe tartozik, amit másik regisztrátornál jegyeztettünk be, hogy ha az első regisztrátor webes felülete azon a napon, amikor kéne, épp nem működik, a másikon keresztül átírhassuk a ("másik") névszerver IP-jét.
      • Ehhez nem kell sok névszerver, mert akár ugyanazt a névszervert is szerepeltethetjük több különböző néven.
    • Azzal, hogy olyan nevet is adunk a névszervernek, amire ő maga autoritatív (mert azon a zónán belül van, amit delegálni fognak neki: az a.ns.pelda.hu szubdomainje a pelda.hu-nak), elkerülhetjük, a pelda.hu domain elérhetetlenné váljon azért, mert egy idióta a megkérdezésünk nélkül felmondja a látszólag haszontalan pelda.org domaint, amiben a "másik" két névszerver van (ezzel kb. évi 10 eurót takarítva meg a cégnek).
  • Nekem autoritatív szerverként bevált a tinydns (amely a djbdns/dbndns csomag része).
    • A DNS-adatokat egy Subversion-repositoryban tárolom;
    • ebből nyilván bárhová tudok checkoutot csinálni (notebookra, okostelefonra stb.);
    • van benne egy Makefile, ami a szöveges reprezentációból előállítja a tinydns számára a bináris data.cdb-t, majd csinál egy svn commit-ot;
    • az svn-szerver post-commit hook scriptje, ha a commit megváltoztatta a data.cdb-t, szól az autoritatív névszervereknek, hogy svn update-tel frissítsék maguknál a data.cdb-t, olyan módon, hogy
      • minden autoritatív szerverhez tartozik egy runit service, ami egy csak erre a célra használt kulccsal a tinydns user nevében ssh-val belép a service-hez tartozó autoritatív szerverre, ahol
      • a ~tinydns/.ssh/authorized_keys fájlban be van állítva, hogy ha ezzel a kulccsal lépnek be, akkor egy svn update műveletet kell futtatni a dns-adatokon;
      • a runit service leállítja magát, ha az ssh visszatérési értéke sikeres volt; kis várakozás után hibával kilép, ha nem (így a runit újra fogja indítani);
      • a post-commit hook script minden autoritatív szerverhez tartozó runit service-t "up" állapotba visz;
      • ha egy-egy DNS-szerver nem elérhető, a runit service addig próbálkozik az elérésével, amíg szükséges, így idővel minden DNS-szerver megkapja a friss adatokat, de a frissítés általában szinte azonnali.

10 Ajánlott irodalom

11 Potenciális zh-kérdések

Itt felsorolok néhány olyan kérdést, ami előfordulhat a ZH-ban, vagy vizsgán. Ha gondoljátok, gyűjthettek ide válaszokat - de ne a válaszokat tanuljátok meg, mert egyrészt nem biztos, hogy éppen ezek a kérdések lesznek, másrészt pedig nem biztos, hogy a valaki által ideírt válaszok helyesek, pontosak és teljesek. A hallgatók által írt válaszok helye a vita-oldal.

  • Mi a TTL szerepe a DNS-ben?
  • Mekkora legyen egy DNS-rekord TTL-je? Miért éppen annyi? Miért baj, ha túl nagy, és miért baj, ha túl kicsi?
  • Mit jelent a CNAME?
  • Mi a baj a CNAME-mel? Miért nem jó ötlet CNAME rekordokat használni a DNS-ben?
  • Mit jelent az NXDOMAIN?
  • Mi a DNS-ben a glue? Mondjon példát olyan esetre, amikor jó, hogy van, és olyanra, amikor nem jó (ez ugyanaz az eset is lehet, más-más szemszögből)! Hogyan lehet visszaélni a glue-val?
  • Mi a baj a glueless delegációkkal? Mi motiválhatja mégis azokat, akik glueless delegációkkal dolgoznak?
  • Ismertesse azt a folyamatot, ahogyan egy cache-elő rekurzív DNS-feloldó megkeresi a www.google.com névhez tartozó A-rekordot!
  • Mi a DNS poisoning, hogyan működik és hogy lehet ellene védekezni?
  • Mi a baj a joker bejegyzésekkel, és milyen esetben van velük baj egyáltalán? Pl. ha a bme.hu zónában bejegyezzük, hogy "*.bme.hu IN MX 10 mail.bme.hu", az baj? És ha azt jegyezzük be, hogy "*.hu IN A 152.66.115.35"?
  • Milyen problémákat okozott, amikor a Verisign ahelyett, hogy a nemlétező .com domainekre NXDOMAIN-t adott volna vissza, a saját webszerverének IP-címét adta meg?
  • Milyen markánsan különböző alszolgáltatásokra osztható a DNS, mint komplex szolgáltatáscsoport?
  • Miért „törékeny” a DNS delegációs rendszere? Hogyan lehet vele visszaélni, és ki élhet vele vissza?
  • Mit jelent az, hogy egy DNS-szerver autoritatív egy domainre? Mitől válik azzá? Ki határoz erről?
  • Mit jelent a delegáció? Mit jelent a "classless" delegáció? Mikor használnak classless ("de Groot") delegációt és miért?
  • Mit jelent a DNS-ben a delegáció? Találjon ki egy példát! A példában szerepeljen, milyen kérdést tesz fel a kliens, melyik szerver mit válaszol és miért?
  • Mit jelent a DNS-ben a "classless" delegáció? Mikor használnak classless ("de Groot") delegációt és miért? Mutasson (fiktív) példát classless delegációra!
  • Soroljon fel legalább öt DNS-rekordtípust, és röviden írja le, mire valók!
  • Mi a zónatranszfer?
  • Soroljon fel legalább két DNS-szerverszoftvert!
  • Mi az AXFR, és mire való?
Személyes eszközök