Rodina protokol TCP/IP, verze 2.2. ást 4: Systém DNS

Transkript

1 v. 2.2 Katedra softwarového inženýrství, Matematicko-fyzikální fakulta, Univerzita Karlova, Praha Rodina protokol, verze 2.2 ást 4: Systém DNS Jií Peterka, 2005

2 v. 2.2 Pro DNS? k jednoznané identifikaci uzl a pro fungování penosových mechanism staí IP adresy ale jsou málo mnemonické v nkterých speciálních situacích a pro nkteré úely nepostaují aliasy dynamicky pidlované IP adresy pro nkteré úely nejsou vhodné když je poteba "oslovit" poskytovatele urité služby, ne konkrétní uzel pro flexibilní doruování elektronické pošty ("na doménu").. když hrozí peíslování nevypovídají nic o povaze/urení/umístní uzlu vs. ksi.ms.mff.cuni.cz DNS je ešení, které umožuje používat symbolická jména místo íselných adres DNS = Domain Name System zahrnuje: pravidla pro tvorbu jmen a fungování celého systému založená na principu domén databázi symbolických jmen a jim odpovídajícííselných adres dnes i dalších údaj pevodní mechanismy.. pro pevod mezi symbolickými a doménovými jmény J.Peterka, MFF UK,

3 v. 2.2 Pvodníešení (ped DNS) Symbolická jména pro uzly se používala již v zárodeném ARPANETu a zastupovala jejich íselné adresy ešení: existovala centrální autorita, která vedla evidenci symbolických jmen a pevodní tabulku ve stylu: UCLA= zajišovala všechny aktualizace distribuovala tuto tabulku všem zájemcm ve form souboru HOSTS symbolická jména mohla být "jednorozmrná" nemusela být lenna na ásti/složky celé to mohlo fungovat pouze pi velmi malém potu uzl a malé frekvenci zmn. vtší poet uzl a vtší frekvence zmn vyžadují jinéešení nikoli centralizované nikoli "jednorozmrné" dostaten škálovatelné!!! DNS zaalo vznikat poátkem 80. let postupn zaalo plnit i další funkce (nap. v oblasti el. pošty) J.Peterka, MFF UK,

4 v. 2.2 Koncepce DNS musí to být distribuované ešení distribuované co do umístní dat objemy dat budou velké data by mla být uchovávána co nejblíže místu kde vznikají a kde "žijí" (mní se) distribuované co do pravomocí aby rzné subjekty mohly pijímat uritá rozhodnutí a vykonávat úkony bez nutnosti koordinace s jinými subjekty aby bylo možné pidlovat nová jména bez nutnosti ptát se, zda jsou již použita jinde. distribuované co do fungování kvli spolehlivosti i kvli vytížení to nesmí mít jeden centrální prvek dotazy týkající se uritých dat se budou zodpovídat tam, kde se tato data nachází musí to fungovat efektivn týká se to hlavn pevodních mechanism mezi symbolickými jmény a íselnými IP adresami mže to využívat "princip lokality" dotazy nejastji smují na "místní" uzly, nebo na stále stejná jména "cizích" uzl má smysl optimalizovat fungování pomocí vyrovnávacích pamtí (cache) J.Peterka, MFF UK,

5 v. 2.2 Plochý vs. hierarchický prostor jmen Plochý jmenný prostor všechna jména jsou "jednorozmrná" nap. ALPHA, Sun, PC1 je omezený poet "smysluplných" jmen jména se pidlují z jedné "množiny" musí to být centráln koordinováno ten kdo chce njaké jméno se musí ptát zda ješt nebylo použito nevýhody: je to nepružné, neškálovatelné, organizan nároné Hierarchický jmenný prostor existuje hierarchie (strom) dílích jmenných prostor, tmto dílím jmenným prostorm se íká domény "výsledná" jména budou mít více složek organizan to je zaízeno tak, aby (dílí, složková..) jména v rámci domén bylo možné "erpat" nezávisle na ostatních doménách tomu musí odpovídat i "sestavování" dílích složek jmen do vtších celk J.Peterka, MFF UK,

6 v. 2.2 cz cz cuni Pedstava hierarchického jmenného prostoru hierarchie jmenných prostor / domén každá doména má své jméno (label) mff ms ms www kocour www (jméno pidlené v domén "cuni.cz", pln kvalifikované jméno je www (jméno pidlené v domén "mff.cuni.cz", pln kvalifikované jméno je ksi (jméno pidlené v domén "ms.mff.cuni.cz", pln kvalifikované jméno je ksi.ms.mff.cuni.cz J.Peterka, MFF UK,

7 v. 2.2 Symbolická doménová jména cz cz obecn nemusí být uvedeny všechny složky (všechna dílí jména) cuni mff ms ms ksi kocour www www www jednotlivá dílí jména se zapisují za sebou a oddlují tekami poadí: nejvíce vlevo je "nejnižší" jméno ve smyslu hierarchie domén J.Peterka, MFF UK,

8 v. 2.2 cz cz Pln kvalifikovaná symbolická doménová jména teprve pln kvalifikovaná jména jsou jednoznaná cuni mff ms ms ksi kocour www www www obsahuje celou posloupnost dílích jmen až po nejvyšší doménu (ve smyslu jejich hierarchie) J.Peterka, MFF UK,

9 v. 2.2 Syntaxe doménových jmen každá složka (dílí jméno, label) smí mít nejvýše 63 znak mohou se používat pouze písmena, íslice a pomlka ne háky a árky!! pomlka nesmí být na zaátku ani na konci velká a malá písmena se nerozlišují pozor, neplatí pro celé URL!! celé doménové jméno musí mít max. 255 znak v praxi lze používat i doménová jména, která nejsou pln kvalifikovaná chybí jim nco "zprava" mže se doplnit automaticky nap. mailto:peterka@ksi se doplní na peterka@ksi.ms.mff.cuni.cz ale jen v "psobnosti" domény ms.mff.cuni.cz pesný mechanismus "doplování" je v kompetenci místní sít nemusí být pesn známo jak to dopadne dsledek: nepoužívat 2-písmenná jména shodná se jmény TLD nebylo by zejmé, zda jde i nejde o pln kvalifikované jméno nap. peterka@ksi.ms?????.ms je TLD Montserratu J.Peterka, MFF UK,

10 v. 2.2 Princip delegace pravomoci v každé domén mohli pidlit jméno www, aniž se museli kohokoli ptát!!!! cz cz cuni mff Pravidlo: v jedné domén nesmí být stejné jméno použito dvakrát!!! ms ms troja karlin www www www www J.Peterka, MFF UK,

11 v. 2.2 Co je doména? prvek v rámci hierarchického lenní jmenného prostoru není apriorn stanovena ani hloubka, ani košatost hierarchie (stromu)!! "okruh psobnosti" nkoho, kdo má právo pidlovat symbolická jména emu má doména odpovídat? organizanímu lenní? teritoriálnímu lenní? jinému lenní? NENÍ TO PEDEPSÁNO!!! je to ponecháno na uvážení správce nadazené domény výjimka: je pedepsán charakter domén nejvyšší úrovn tzv. TLD domén (Top Level Domén) existují cctld (country code TLD), odpovídající státním útvarm, tvar dle normy ISO-3166.cz pro R.sk pro Slovesko.us pro USA.ru pro Rusko existují gtld (generic TLD), vyjadující charakter subjektu.edu pro školské instituce pidluje IANA/ICANN.com pro komerní organizace.int,.net,.gov,.mil,.org,.arpa J.Peterka, MFF UK,

12 v. 2.2 Jak má být doména "velká"? není apriorn stanoveno to co komu vyhovuje, co do velikosti i logice lenní "píliš velká" doména není smysluplné, aby se pímo v této domén pidlovala jména uzlm spadajícím do domény nap. z organizaních dvod eší se "delegováním pravomoci" (parcelací "okruhu psobnosti") vytváí se dceinné domény "vhodn velká" doména s takovým potem uzl, aby se nevyerpala smysluplná/požadovaná jména netýká se to až tak správy domény!! píklady: pro malou organizaci bývá "vhodn velká" doména druhé úrovn pro velkou organizaci je vhodnjší víceúrovové lenní nap. UK (cuni.cz) J.Peterka, MFF UK,

13 v. 2.2 Autorita nad doménou autorita = právo provádt zmny pidlovat nová jména, mnit je. zizovat dceinné domény obecn: ten kdo má autoritu nad doménou, má autoritu i nad jejími dceinnými doménami získává ji pi vytvoení dceinné domény ale mže se jí vzdát, resp. delegovat ji na jiný subjekt!!! píklad: provider má autoritu nad doménami nkterých svých zákazník (kterým spravuje jejich domény), nemá autoritu nad doménami jiných svých zákazník ISP1 J.Peterka, MFF UK, Z1 Z1 Z2 Z2 cz cz X1 X1 Y1 Y1 ISP2 X2 X2 Y2 Y2 zóna X3 X3

14 v. 2.2 Zóny zóna oblast tvoená skupinou domén, nad kterou má nkdo konkrétní (jeden subjekt) autoritu zóny se "zvtšují" vytváením dceinných domén zóny se "zmenšují" delegováním pravomoci (autority) nad dceinnými doménami dohází k "vykousnutí" celých podstrom domén ze stávající zóny a ke vzniku nové zóny zone file všechny údaje týkající se domén nad kterými má nkdo autoritu (týkající se jedné zóny) jsou uchovávány na jednom míst v jedné databázi, resp. jednom souboru, tzv. zone file tam kde "žijí" a kde s nimi správce pracuje J.Peterka, MFF UK,

15 v. 2.2 Name servery vs. domény v rámci každé domény se "pamatují" urité informace nap.: poíta se jménem X má IP adresu poštu pro doménu doruuj na uzel X.domena.cz slouží jako podklad k zodpovídání dotaz typu" jako IP adresu má poíta X? tyto informace nejsou uchovávány centráln, ale jsou distribuovány a také se s nimi pracuje tam, kde se nachází Name server vždy písluší k njaké konkrétní domén je to server (uzel) který má k dispozici data píslušné domény a odpovídá na dotazy které se jich týkají pedstava: každá doména má svj name server poskytuje službu spoívající v pevodu jmen na IP adresy 1 poíta mže plnit roli name serveru pro více domén 1 zóna = 1 uzel který dlá name server pro všechny domény v zón J.Peterka, MFF UK,

16 v. 2.2 Struktura name server ms ms ms ms cz cz root cz cz cuni cuni mff mff troja troja karlin karlin struktura name server logicky odpovídá struktue domén každá doména má svj name server existuje tzv. koenový (root) name server, který "zná" name servery všech TLD (domén nejvyšší úrovn) fyzicky jsou name servery lenny jinak 1 zóna má 1 name server kvli dostupnosti jsou name servery nejmén zdvojeny name server doména J.Peterka, MFF UK,

17 v. 2.2 Princip pekladu tazatel se nejprve ptá koenového name serveru, jehož adresa je všeobecn známa tazatel ptá se na IP adresu uzlu ksi.ms.mff.cuni.cz až se dostane k takovému name serveru, který mu dokáže odpovdt ms ms uzel ksi.ms.mff.cuni.cz ms ms J.Peterka, MFF UK, cz cz root cz cz 3 cuni cuni 4 mff mff troja troja 1 karlin karlin tazatel je postupn odkazován na další name servery

18 v. 2.2 Skutený prbh pekladu (rekurzivní dotaz) oslovený name server sám zprostedkuje zodpovzení dotazu cz cz root cz cz ksi.ms.mff.cuni.cz? name server cuni cuni tazatel se ptá "nejbližšího" name serveru nejbližší je ten, jehož existenci má zanesenu ve své konfiguraci ms ms ms ms mff mff troja troja karlin karlin J.Peterka, MFF UK,

19 v. 2.2 oslovený name server pouze doporuí jiný name server Skutený prbh pekladu (iterativní dotaz) ksi.ms.mff.cuni.cz? 1 2 zeptej se root-a tazatel se nejprve ptá "nejbližšího" name serveru name server ksi.ms.mff.cuni.cz? ksi.ms.mff.cuni.cz? zeptej se.cz ms ms ms ms J.Peterka, MFF UK, cz cz root cz cz cuni cuni mff mff troja troja pvodní tazatel se postupn obrací na jednotlivé name servery žádný mu nedá odpov každý jej pouze nasmruje jinam karlin karlin

20 v. 2.2 Primární a sekundární name servery z pohledu tazatel jsou ekvivalentní primární name server zone file je na místním disku sekundární name server získává data z primárního name serveru každá doména musí mít (hlavní) name server, který je tzv. primární primární name server má pímo k dispozici relevantní data o domén svj zone file získává z místního disku krom toho by mla mít nejmén jeden (záložní) name server, tzv. sekundární sekundární name server by ml být umístn v jiné síti nejastji u (nadazeného) providera sekundární name server "seizuje svj obsah" sám a automaticky podle obsahu primárního name serveru vyžádá si tzv. zone transfer J.Peterka, MFF UK,

21 v. 2.2 DNS servery a resolvery aplikace data resolver resolver cache name server dotazy odpovdi dotazy odpovdi dotazy odpovdi DNS má architekturu klient/server name server odpovídá na dotazy plní roli serveru resolver pokládá dotazy name serverm plní roli klienta na uzlu který plní roli name serveru musí být implementovány ob složky i name server se ptá jiných name server, k tomu potebuje resolver na ostatních uzlech staí jen resolver J.Peterka, MFF UK,

22 v. 2.2 Optimalizace fungování DNS replikace name servery domén jsou replikovány jako primární a alespo jeden sekundární v praxi bývá i více záložních name server replikovány jsou i koenové name servery všechny jsou primární slouží i k rozložení zátže cache-ování odpovdi autoritativních name server si ostatní servery ukládají do svých cache pamtí a pak je používají pro pímou (neautoritativní) odpov ) cacheování pináší nejvtší optimalizaci!! forwarding name server pijímá rekurzivní dotazy, ale neeší je, nýbrž pouze pedává (forwarduje) jinému name serveru obvykle kvli snazší konfiguraci klient J.Peterka, MFF UK,

23 v. 2.2 Neautoritativní odpovdi data resolver cache name server autoritativní pro konkrétní doménu jsou její primární a sekundární server kvli optimalizaci fungování jsou získané odpovdi ukládány do vyrovnávací pamti (cache pamti) pouze po uritou dobu TTL je atributem odpovdi další odpovdi na stejné dotazy jsou pak zodpovídány z vyrovnávací pamti odpov z cache pamti má jiný statut než odpov od autoritativního name serveru je tzv. neautoritativní, nebo pochází od nkoho kdo nemá autoritu hovoit za píslušnou doménu tazatel to z odpovdi pozná a mže si vyžádat pouze autoritativní odpov existují "caching only" name servery které pouze cacheují, ale nejsou pro žádnou doménu autoritativní J.Peterka, MFF UK,

24 v. 2.2 Koenové name servery name org city a InterNIC Herndon,VA, US b ISI Marina del Rey,CA, US c PSInet Herndon,VA, US d UMD College Park,MD, US e NASA Mt View, CA, US f ISC Palo Alto, CA, US g DISA Vienna, VA, US h ARL Aberdeen, MD, US i NORDUnet Stockholm, SE j (TBD) (colo w/ A) k RIPE London, UK l ICANN Marina del Rey,CA, US m WIDE Tokyo, JP celkem 13 po celém svt na 7 rzných HW platformách na 8 rzných variantách OS (Unix) J.Peterka, MFF UK,

25 v. 2.2 Koenové name servery J.Peterka, MFF UK,

26 v. 2.2 RR - Resource Records DNS je distribuovaná databáze logicky lenná podle domén data jsou v ní uložena ve form vt tzv. RR Resource Records nap. údaj o IP adrese uzlu s konkrétním jménem NAME TYPE 2B CLASS 2B TTL 4B RDLENGTH 2B RDATA jméno položky typ položky 1 = Internet samotná data skutená velikost dat doba, po kterou smí být data (jako odpov ) uložena v cache pamti, v sekundách J.Peterka, MFF UK,

27 v. 2.2 RR Resource Records (píklady) Typ A NS CNAME HINFO MX AAA. anglický název A host address Authoritative name server Cannonical name Host INFO Mail exchange IPv6 address. význam pole RDATA IP adresa uzlu doménové jméno name serveru, který je autoritativní pro danou doménu kanonické synonymum k NAME popis HW s SW kam má být doruována el. pošta pro doménu 128-bitová adresa dle IP verze 6. J.Peterka, MFF UK,

28 v. 2.2 Píklady Name=ksi.ms.mff.cuni.cz RDATA Type=A, Class=1, TTL=86400 (1 Day), RDLENGTH=4 IP Address= Name=kki.ms.mff.cuni.cz Type=CNAME, Class=1, TTL=86400 (1 Day), RDLENGTH=20 CNAME=ksi.ms.mff.cuni.cz Name=peterka.cz Type=MX, Class=1, TTL=86400 (1 Day), RDLENGTH=18 Preference=10, Mail Exchange=mail.czech.net Name=peterka.cz Type=MX, Class=1, TTL=86400 (1 Day), RDLENGTH=11 Preference=100, Mail Exchange=mspool.czech.net RDATA J.Peterka, MFF UK,

29 v. 2.2 DNS protokol DNS klient a server spolu komunikují pomocí jednoduchého aplikaního protokolu protokolu DNS pro transport je nejastji využíván protokol UDP ale mže být použit i TCP pro dotazy na peklad jména je preferován protokol UDP DNS server "poslouchá" na portu 53 pes TCP i UDP DNS protokol používá stejný formát paketu (DNS QUERY) pro dotaz i odpov HEADER QUESTION ANSWER AUTHORITY ADDITIONAL J.Peterka, MFF UK,

30 v. 2.2 Píklad DNS QUERY (1. ást) Header: ID=1282, QR=Query, Opcode=QUERY, RCODE=NO ERROR Authoritative Answer=Yes, Truncation=No Recursion Desired=Yes, Recursion Available=Yes QDCOUNT=1, ANCOUNT=2, NSCOUNT=2, ARCOUNT=3 Question: Name=peterka.cz, QTYPE=MX, QCLASS=1 Answer Section: - Name=peterka.cz Type=MX, Class=1, TTL=86400 (1 Day), RDLENGTH=18 Preference=10, Mail Exchange=mail.czech.net - Name=peterka.cz Type=MX, Class=1, TTL=86400 (1 Day), RDLENGTH=11 Preference=100, Mail Exchange=mspool.czech.net J.Peterka, MFF UK,

31 v. 2.2 Píklad DNS QUERY (2. ást) Authority Records Section: - Name=peterka.cz Type=NS, Class=1, TTL=86400 (1 Day), RDLENGTH=5 Name Server=ns.czech.net - Name=peterka.cz Type=NS, Class=1, TTL=86400 (1 Day), RDLENGTH=11 Name Server=scretchy.czech.net Additional Records Section: - Name=mspool.czech.net Type=A, Class=1, TTL=86400 (1 Day), RDLENGTH=4 IP Address= Name=ns.czech.net Type=A, Class=1, TTL=86400 (1 Day), RDLENGTH=4 IP Address= Name=scretchy.czech.net Type=A, Class=1, TTL=86400 (1 Day), RDLENGTH=4 IP Address= J.Peterka, MFF UK,

32 v. 2.2 Domény a diakritika standardn: diakritika není pípustná, jen isté ASCII snaha: pipustit také použití znak národních abeced ve jménech domén v R: s háky&árkami, nap. žluouký.k.cz motivace: rozšíení jmenného prostoru, více možných registrací možnost registrovat takové domény, jaké dnes neexistují IDN (Internationalized Domain Names) ešení dle RFC (2003) ve jménech lze použít (podmnožinu) UNICODE 3.2 princip ešení: bude to fungovat jako "nadstavba" nad souasným DNS fungování DNS jako takového se nemní!!!! "peklad" z ne-ascii do ASCII tvaru a naopak zajišuje klientská aplikace!!! J.Peterka, MFF UK,

33 v. 2.2 Pedstava fungování name server.cz name server xn--k-qla0j.cz k.cz toascii xn--k-qla0j.cz žluouký.k.cz toascii xn--luouk-uva4it5a4g. xn--k-qla0j.cz peklad se odehrává již na klientském poítai (v rámci aplikace jako je browser, poštovní klient) xn--luouk-uva4it5a4g = J.Peterka, MFF UK,

34 v. 2.2 Peklad musí být definován "peklad" jmen z UNICODE do ASCII a opan nejprve se dlá "nameprep" sjednocují se rzné varianty možného zápisu (nap. velká a malá písmena), vzniká "kanonický tvar" pak se dlá vlastní peklad fakticky: zakódování do istého ASCII tzv. punycode musí existovat i opaný peklad z ASCII do UNICODE dm.cz xn--dm-sua.cz žluouký xn--luouk-uva4it5a4g J.Peterka, MFF UK,

35 v. 2.2 Co se musí stát aby to mohlo fungovat? správce TLD musí zaít registrovat domény typu "xn- - " napíklad pro "k.cz" musí fakticky zaregistrovat doménu xn--k-qla0j.cz již probíhá nap. v.pl,.de,. v asijským zemích v R: (zatím) nebude CZ.NIC poátkem 2005 rozhodl prozatím neimplementovat, kvli malému zájmu uživatel uživatelé musí používat takové aplikace, které podporují IDN browsery, poštovní klienty možnost platí i pro mailové adresy podpora IDN (3/2003): MS IE, MS Outlook a OE: jen s plug-inem nap. i-nav od Verisign Netscape 7.1/Mozilla 1.4, Opera 7.20, Konqueror (Linux with KDE 3.2). ano, nativn J.Peterka, MFF UK,

36 v. 2.2 Píklad když to funguje böhm.de xn--bhm-sna.de (Internet Explorer s instalovaným plug-inem i-nav) J.Peterka, MFF UK,

37 v. 2.2 Píklad když to nefunguje böhm.de (nejde o peklad do punycode) (Internet Explorer (MyIE2) bez podpory IDN) J.Peterka, MFF UK,

38 v. 2.2 Úskalí IDN registrace "ohákovaných" domén ml by si vlastník stávající domény registrovat všechny "další" tvary, které vznikají aplikací diakritiky? vlada.cz vs. vláda.cz,vláa.cz nebo by na to snad ml mít (pednostní) právo? nevzniká tím jen vtší prostor pro spekulativní registrace nejde jen o vtší "kšeft" pro registrátory domén? možnost zadávat "národní" znaky ne všude existuje možnost zadat z klávesnice speciální (národní) znaky jinak musí uživatel psát adresy typu "xn--k-qla0j.cz" absence podpory v SW vždy budou existovat uživatelé používající SW který nepodporuje IDN peklad UNICODE to ASCII J.Peterka, MFF UK,

39 v. 2.2 IRI, Internationalized Resource Indicators koncept IDN se týká pouze doménových jmen nikoli celých URL adres neeší pístupové cesty, jména (a pípony) objekt a další souásti URL "celé URL" bude ešit až koncept IRI Internationalized Resource Indicators IDN bude jeho souástí ješt není hotov!!! pístup firmy Microsoft k IDN: sledujeme a zvažujeme implementaci domnnka: ekají na IRI, až bude mít definitivní podobu: IDN IRI J.Peterka, MFF UK,

40 v. 2.2 Alternativní DNS nahrazují oficiální "DNS root servery" svými vlastními díky tomu si mohou vytváet vlastní TLD podmínka fungování: DNS servery uživatel se nesmí "ptát" oficiálních DNS root server, ale musí být "nastaveny" na alternativní x root alt. root resolver com edu earth europe www= J.Peterka, MFF UK,

41 v. 2.2 Dynamické DNS klasické DNS je statické nepedpokládá, že IP adresa konkrétních uzl se mní moc asto, nap. každý den i hodinu v praxi ovšem hodn uzl dostává IP adresu pidlovanou dynamickým zpsobem nap. na dial-upu, ADSL, kabel.. dsledek: takovéto uzly nemohou mít pidlené (vlastní, stabilní) symbolické doménové jméno DNS by se nestailo pokaždé aktualizovat dynamické DNS takovéešení, kdy dochází k aktualizaci DNS zóny tak asto, jak je poteba princip: na uzlu bží malý "DNS klient", který prbžn informuje (dynamický) DNS server o aktuální IP adrese dynamický DNS server se aktualizuje podle poteby typickéešení: jde o placenou službu J.Peterka, MFF UK,

42 v. 2.2 Reverzní domény peklad z IP do CNAME jaké je CNAME k IP ? in-addr.arpa eší se pes doménu in-addr.arpa další (nižší) subdomény odpovídají pidleným IP adresám, po jednotlivých bytech v obráceném poadí!!! držitel IP adresy má ve správ píslušnou "reverzní doménu" J.Peterka, MFF UK,

43 v. 2.2 ENUM jde o snahu provázat DNS a telefonníísla cíl: umožnit, aby se k telefonním íslm mohly piazovat "další informace", stejn jako k doménovým jménm napíklad o pesmrování hovoru úastník má jedno tel. íslo a skrze DNS si volí, zda chce pijímat na hlasový telefon, nebo na jiné zaízení (na které) napíklad o typu koncového zaízení a jeho schopnostech vhodné zejména pro IP telefonii další cíle: aby se místo WWW adres dala používat telefonníísla aby mobilní terminály nemusely zadávat adresy WWW stránek (WAP stránek atd.), ale staila jen telefonníísla aby se nap. daly posílat maily na telefonníísla obecn: aby tel. íslo mohlo sloužit jako jednotná adresa úastníka jde o projekt "svta spoj", nikoli "svta Internetu" angažuje se hlavn ITU-T J.Peterka, MFF UK,

44 v. 2.2 ENUM pedstava fungování tel. íslo formát uruje direktiva ITU E.164 odstraní se vše kromíslic, obrátí se poadí, oddlí se tekami pidá se "koncovka".e164.arpa e164.arpa již jde o pln kvalifikované jméno, se kterým mohou být spojeny (v rámci DNS) další informace záznamy NAPTR Naming Authority Pointer Resource Record J.Peterka, MFF UK,