A DNS működése

A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
a (A DNS-feloldás menete)
a (A TTL helyes megválasztása)
236. sor: 236. sor:
   
 
Egy rekord TTL-je akkora legyen, hogy lehetőleg éppen a következő tervezett módosítás előtt járjon le.
 
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 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.
+
* 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).
 
* Ö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;
 
** 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 lap 2011. augusztus 4., 09:39-kori változata

A DNS, mint azt tudjuk, az a világméretű infrastruktúra és az általa használt protokoll, ami az IP-címekhez neveket rendel, és fordítva. Ennél persze többről van szó: 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.

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:

  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.

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 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:
163 bytes, 1+0+3+3 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: ns.bme.hu 86400 28 \040\001\0078\040\001\200\001\000\000\000\000\000\000\000\002
additional: nic.bme.hu 86400 A 152.66.115.1
additional: nic.bme.hu 86400 28 \040\001\0078\040\001\040\001\000\000\000\000\000\000\000\002

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 28 \040\001\0078\040\001\200\001\000\000\000\000\000\000\000\002
additional: nic.bme.hu 14400 A 152.66.115.1
additional: nic.bme.hu 14400 28 \040\001\0078\040\001\040\001\000\000\000\000\000\000\000\002
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

  • 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.)

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 szerver az autoritatív szerver adatbázisának replikálását végzi.
  • 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 autoritatív (és rajtuk kívül senki).

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. NS ns.foo.com." ill.
    • "5.3.2.1.in-addr.arpa. 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).
  • 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", 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:

  • 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.
  • A másik 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. 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. 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 irreleváns Authority sectiont rak a támadó a válaszába
        • amiben pl. azt mondja, hogy bme.hu. NS ns.foo.bar. (holott ezt nem is kérdezte senki).
    • Védekezés: nem fogadunk el olyan glue-t, 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.
  • 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.
  • 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 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:

  • A root szerverek, természetesen, de bennük mondjuk megbízunk.
  • A .hu szerverek:
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.
  • Ezeknek az 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
akarmi.se	1000000		IN	CNAME	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.

8 Ajánlott irodalom

9 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