A DNS működése
(→Reverse DNS: classless delegáció belegyúrva) |
a (→Reverse DNS, classless delegáció: typo) |
||
325. sor: | 325. sor: | ||
** 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.) |
** 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. |
* 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 [http://www.faqs.org/rfcs/rfc1035.html 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. [[http://homepages.tesco.net/J.deBoynePollard/FGA/avoid-rfc-2317-delegation.html Avoid RFC 2317 style delegation of "in-addr.arpa."]]). |
+ | * Azáltal, hogy a reverse-rekordok neve nem generálható szisztematikusan, az [http://www.faqs.org/rfcs/rfc1035.html 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. [http://homepages.tesco.net/J.deBoynePollard/FGA/avoid-rfc-2317-delegation.html Avoid RFC 2317 style delegation of "in-addr.arpa."]). |
== Gyakori gondok a DNS-sel == |
== Gyakori gondok a DNS-sel == |
A lap 2009. december 28., 02:54-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 fastrukturá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ítjatjá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 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:
- 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.
- 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 queryt 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).
- 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.
- 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.
- 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.
- 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
- Főleg RBL-ek használják: 3.0.0.127.dnsbl.njabl.org. IN TXT "dial-up or dynamic -- 1035916206", 164.22.147.63.sbl.spamhaus.org. IN TXT "http://www.spamhaus.org/SBL/sbl.lasso?query=SBL44889"
- 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 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:
- Legyen kölcsönösen egyértelmű.
- 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.
- 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 írója 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.
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
- A DNS-feloldás menete
- Esettanulmány tűzfallal, kis belső hálózattal
- Megjegyzések a DNS működésével kapcsolatban
- DJB a classless delegációkról
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ó?