Problemy s DNS

Pavel Satrapa PAVEL.SATRAPA at vslib.cz
Fri Jan 26 07:22:25 CET 1996


Rekneme, ze hledate wuarchive.wustl.edu

> 1.  Mam uz ho v cache a nevyprsela doba po kterou ho tam mohu mit?

Dal uz je to trochu jinak

2. Zeptam se sveho name serveru
   Name server se podiva, jestli ma jmeno ve vyrovnavaci pameti. Pokud
   ano, odpovi (tzv. neautoritativni odpoved).
   V opacnem pripade se obrati na jeden z _korenovych_ serveru Internetu
   (povera o postupnem splhani hierarchii je dost rozsirena; ve
   skutecnosti se hierarchii domen postupuje jen dolu, pri ceste vzhuru se
   server obraci rovnou na korenove servery).

3. Korenovy server nejsis odpovi "Hele, ja nevim, ale domenu edu ma na
   starosti XXX. Zeptej se tam."

4. Server se zepta prislusneho serveru a muze dostat odpoved "Hele, ja
   nevim, ale domenu wustl.edu ma na starosti YYY. Zeptej se tam."

Tak to pokracuje, dokud se nedostane k nekomu, kdo odpovi "Ja jsem ten
jediny povolany, kdo zna adresu wuarchive.wustl.edu a ta je ......."
(autoritativni odpoved). Takova odpoved muze prijit z primarniho serveru,
ktery definuje obsah domeny, nebo z nektereho sekundarniho serveru.
Sekundarni servery v podstate udrzuji kopii primarniho, aby byl cely
system robustnejsi.

Aby to nebylo tak jednoduche:

A) Kdekoli po ceste za autoritativnim serverem se muze uplatnit
   vyrovnavaci pamet nektereho z dotazovanych. V tom pripade
   od nej prijde neautoritativni odpoved.
   Do vyrovnavacich pameti jsou ukladany take informace o serverech,
   zodpovidajicich za jednotlive domeny.

B) Kazdy z dotazanych serveru se muze rozhodnout pro rekurzivni nebo
   nerekurzivni reseni dotazu.

   Rekurzivni reseni znamena, ze dotazany server vezme vyreseni problemu
   na sva bedra. Dostane-li jako odpoved na dotaz odkaz na dalsi server,
   sam se ho zepta a dal se pidi po pozadovane adrese. Kdyz ji zjisti,
   posle klientovi odpoved. Nevyhoda: zatezuje to server. Vyhoda: ziskanou
   adresu si muze ulozit do vyrovnavaci pameti a priste rovnou posilat
   neautoritativni odpoved. (V postupu popsanem vyse se rekurzivne choval
   prvni name server.)

   Pri nerekurzivnim zpusobu da server od reseni otazky ruce pryc. Kdyz
   dostane jako odpoved odkaz na jiny server, odpovi tomu, kdo se ho
   zeptal "Hele, ja to nevim, zeptej se tamhle..." (Korenove servery
   Internetu se typicky chovaji nerekurzivne, jinak by se z toho
   zblaznily.)

A ted potencialni zdroje komplikaci:

1) Nekonzistence sekundarnich serveru. Sekundarni servery se cas od casu
   obrati na server primarni a vezmou si od nej nove udaje (pokud jsou).
   Dojde-li ke zmene, obsah sekundarniho serveru bude zmenen teprve tehdy,
   az se priste obrati na primarni server. V dusledku toho se muze stat,
   ze primarni server ma nova data, zatimco sekundarni (nebo nektery ze
   sekundarnich) jeste ne. Pritom vsak sekundarni server posila
   autoritativni odpoved - bohuzel v dane chvili vychazejici ze starych
   udaju. Vec se spravi pri pristim kontaktu s primarnim serverem.

2) Definice domeny zacina zaznamem SOA (Start Of Authority). V nem jsou
   obsazeny dve polozky, dulezite pro popsany mechanismus - seriove cislo
   a doba platnosti. Podle serioveho cisla poznava sekundarni server, ze
   doslo ke zmene. Je treba je pri kazdem zasahu do dat zvetsit, jinak
   nova data nebudou propagovana na sekundarni servery. Doba platnosti (ve
   skutecnosti je casovych udaju vic) urcuje, za jak dlouho se ma
   sekundarni server znovu poptat.
   Spatne nastaveni techo udaju zpusobi problemy s konzistenci
   sekundarnich serveru (viz predchozi bod).

3) Cele DNS pouziva pro prenos UDP, nikoli TCP. To znamena, ze jednotlive
   dotazy a odpovedi prochazeji Internetem v samostatnych datagramech bez
   jakehokoli hlidani ci zajisteni. Mohou se klidne ztratit a je na
   tazateli, aby na to prisel a po case dotaz zopakoval. Reseni jednoho
   jmena vsak muze znamenat radu dotazu a odpovedi => radu prilezitosti ke
   ztrate, pokud jsou linky pretizene.

A nebo je spatne neco uplne jineho (Internet pouzivam dost intenzivne a
problemy typu "nic takoveho neexistuje" mivam zcela sporadicky).

Uf! Nemel bych tolik zvanit  :-)

Preji vsem pekny vikend

----------------------------------------------------------------------
 Pavel Satrapa                    Liberec University of Technology
 E-Mail: Pavel.Satrapa at vslib.cz   Dept. of Computer Science
 Phone:  +42-48-5227-374          Halkova 6, 461 17 Liberec
 Fax:    +42-48-5100-865          Czech Republic
----------------------------------------------------------------------



More information about the net mailing list