Hogyan működik a DNS?

Megint egy olyan téma, amihez fejlesztőként nem sok közünk van. Vagy mégis? Ha megnézzük a weboldalunk betöltési sebességét, akkor bizony ott figyel a DNS (Domain Name System) lekérdezés ideje, így hát nem lényegtelen, hogy hogyan működik.

A cikk folytatása a Weblaboron »

A rekurzor = rezolver szerver kitétellel vitáznék, én speciel úgy tanultam, hogy caching-only nameserver - azzal együtt is, hogy nem feltétlenül only, azaz inkább a caching nameserver. Az a jó, hogy ebből a 3 névből egyik sincs magyarul, így egy angolul nem tudónak majdnem teljesen mindegy (ráadásul a "rekurzor"-ban levő "kurzor" sokakat simán megtéveszthet).

A másik, hogy a split-dns szerintem nem kötelező, *érzésem* szerint nagyon sok helyen konfigurálnak úgy DNS-t, hogy ugyanaz a szerver csinálja mind a két funkciót (bár mivel a szervert azonosan egyenlővé tetted az IP-címmel, így már majdnem elfogadható :-) a megfogalmazás).

És akkor a cikk:

- Az elején szerintem a root domain össze van keverve a root nameserver-rel.

- Én mondjuk nagyon hiányoltam a cikkből néhány összefüggés részletesebb kifejtését; tudom, hogy szájbarágós, de gyanítom, van akinek még az NS = nameserver infót is le kell írni, de az AXFR (azaz all XFR = all transfer) és IXFR (incremental transfer) dolgot is le kell "fordítani". Ráadásul a vége felé sejtésem szerint sok embernek nem fog lejönni, hogy a CNAME = canonical name, pedig ez a megértést nagyban segítené.

- Ami viszont igen hiányzik, az az apróság, hogy egy jól felkonfigurált DNS-nél az A->PTR infón kívül van egy minimálisan szükséges PTR->A funkciója, ráadásul e nélkül gyakorlatilag semmi nem működik. Iszonyat mennyiségben állítanak be kezdők úgy DNS-t, hogy fingjuk nincs a reverz feloldás szükségességéről, e miatt aztán nem is igazán megy a dolog. (Nem ma volt, de az igazán szép, amikor egy internetszolgáltató teszi ezt meg; ekkor jönnek olyan viccek, hogy Kadlecsik Józsi kitiltotta az ftp.kfki.hu -ról a fél magyar ADSL-t, mert XYZ-nél nem volt reverze az ADSL-tartománynak.)

(Hamarosan egy általam írt DNS-doksi is elérhető lesz, mihelyt publikus lesz, lehet köpködni azt.)

Javaslat akár egy későbbi cikkhez: szerintem érdemes lenne beleírni, hogy a hostnévből hogyan lesz FQDN (DHCP opció, resolv.conf-ban search stb.), egy lookup-nál ezek mit befolyásolnak, mi épül ezekre (pl. wpad, afaik a Win tűzfal osztályozása etc.), milyem más módok vannak név feloldásra, amik gondot okozhatnak (WINS, mDNS [lásd a csomó .local Win tartományt és az Avahi-t], hosts fájl, NIS etc.); valahol annó olvastam egy perverz, de zseniális megoldást a konfigurációmentes dev/QA/prod környezetekre: három zóna (dev, qa, prod), mindháromban a komponensek ugyanazon hostnevekkel (pl. sql.dev, sql.prod, wwwPONTdev, wwwPONTprod etc.), a konfig fájlokban pedig csak a hostnév van.

Szerk.: Bugos a drupal url-keresője :)

BlackY

Úgy, hogy az app konfigjához nem kell hozzányúlni, amikor átviszed a következő rendszerre, mivel pl. az "sql" hosztnév feloldásánál a qa-n az "sql.qa"-t fogja feloldani, prod-ban az "sql.prod"-ot. Gyakorlatilag áttolod a DNS-re az alkalmazás konfigurációját, cserébe persze tükrözni kell N példányban a teljes infrastruktúrát.

BlackY

Legyszi az NS = NameServer feloldast is ird bele. A "hol kell keresni" nem elegge fedi ezt, illetve nem elegge szakmai modon fedi ezt.

Illetve a TCP-nel emlites szintjen meg lehetne emliteni, hogy az a nevszerverek kozotti kommunikaciora van hasznalva, nem kifejtve ezt.

"mert a referenciaimplementációként is funkcionáló BIND egészen a 10-es verzióig kizárólag fájlból tudott olvasni."

Azert ennel picit arnyaltabb a helyzet, mert mar a BIND9-hez is keszultek olyan patchek, amelyek lehetove tettek az LDAP alapu menedzsmentet, es ezek kozul par el is terjedt.

"Hogy az egész hivatalos is legyen, a zónát egy úgynevezett SOA (Start of Authority, avagy hatókör kezdete) rekord jelöli meg. Ez a rekord jelzi, hogy igen, ez a szerver autoritatívan (hivatalosan) szolgáltatja a zónát, nem mástól kérdezte le (lásd rekurzió a következő bekezdés alatt)."

Ez kisse felrevezeto. Magat a SOA rekordot el lehet kerni egy caching DNS szervertol is, es az mindenfele ellenvetes nelkul fogja neked kiadni, vagyis a SOA rekord lete vagy nem lete konkretan nem bizonyito ereju arra nezve, hogy az adott szerver authoritativ-e a domain kiszolgalasahoz. Ami authoritativva teszi, az elsosorban az, hogy a kerdezett nevszerver meg van-e jelolve a zonaban mint nevszerver.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Illetve a TCP-nel emlites szintjen meg lehetne emliteni, hogy az a nevszerverek kozotti kommunikaciora van hasznalva, nem kifejtve ezt.

TCP-t akkor szokas hasznalni, ha a valasz meghalad egy csomagmeretet, mert ugye a dns alapvetoen UDP-n megy. Ha pedig a valasz nagy (emlekszik valaki arra, amikor a google "okosan" felvett egy 2km hosszu mx listat, aztan egy csomo rezolver erre bemutatott? :-)), akkor a kliens (pl. a te pc-d) udp-n vagy tcp-n kapja meg a valaszt?

--
"Pontosan ez a ti bajotok. Ez a kurva nagy csőlátás. [...]" (bviktor)

Ebben igazad van, es sejtettem is, hogy ez fel fog merulni. A legtobb esetben a kliensnek adott valasz belefer az UDP korlatjaba, mert nagyon ritka, hogy nehany IP cimnel tobbet kell visszaadni. A TCP kommunikacio tipikusan AXFR/IXFR soran kerul hasznalatra, amikor legalabbis valoszinusitheto, hogy a valasz nagyobb lesz, mint ami beleferne egy UDP packetbe. Persze, vannak kivetelek.

Akkor viszont forditva kellene, vagyis a zonatranszfernel (inkrementalisan irtam a kommentet, amikor a TCP-s reszt irtam, meg nem vegeztem a cikkel) megemliteni, hogy altalaban ez TCP-n zajlik. Ahogy elneztem szinte mindig TCP response jon az AXFR-re, akkor is, ha egyebkent 2-3 cimnel tobbet nem kapok vissza.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant.

Bár nem A->PTR PTR->A, de AAAA még most is van itthon:)

host 2001:4c48:111::0
0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1.1.1.0.8.4.c.4.1.0.0.2.ip6.arpa domain name pointer 20014C48011100000000000000000000.dsl-dp.pool.telekom.hu.

host 20014C48011100000000000000000000.dsl-dp.pool.telekom.hu
Host 20014C48011100000000000000000000.dsl-dp.pool.telekom.hu not found: 3(NXDOMAIN)