IP, verze 2.2. ást 4: Systém DNS

Rodina protokol

TCP/IP v. 2.2

Katedra softwarového inženýrství, Matematicko-fyzikální fakulta, Univerzita Karlova, Praha

Rodina protokol TCP/IP, verze 2.2

ást 4: Systém DNS Ji í Peterka, 2005

Rodina protokol

TCP/IP v. 2.2

Pro DNS?

• k jednozna né identifikaci uzl a pro fungování p enosových mechanism sta í IP adresy

• DNS je ešení, které umož uje používat symbolická jména místo íselných adres

– ale jsou málo mnemonické – v n kterých speciálních situacích a pro • n které ú ely neposta ují • aliasy • dynamicky p id lované IP adresy

– pro n které ú ely nejsou vhodné • když je pot eba "oslovit" poskytovatele ur ité služby, ne konkrétní uzel • pro flexibilní doru ování elektronické pošty ("na doménu") • ….. když hrozí p e íslování …

– nevypovídají nic o povaze/ur ení/umíst ní uzlu • 195.113.19.213 vs. ksi.ms.mff.cuni.cz  J.Peterka, MFF UK, 2005

– 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

– p evodní mechanismy • pro p evod mezi symbolickými a doménovými jmény

– ….. 2

Rodina protokol

TCP/IP v. 2.2

P vodní ešení (p ed DNS)

• Symbolická jména pro uzly se používala již v zárode ném ARPANETu – a zastupovala jejich íselné adresy

•

ešení: – existovala centrální autorita, která vedla evidenci symbolických jmen a p evodní tabulku • ve stylu: UCLA=193.34.56.78

– zajiš ovala všechny aktualizace – distribuovala tuto tabulku všem zájemc m • ve form souboru HOSTS

1981-1985  J.Peterka, MFF UK, 2005

• symbolická jména mohla být "jednorozm rná" – nemusela být len na na ásti/složky

• celé to mohlo fungovat pouze p i velmi malém po tu uzl a malé frekvenci zm n. • v tší po et uzl a v tší frekvence zm n vyžadují jiné ešení – nikoli centralizované – nikoli "jednorozm rné"

– dostate n škálovatelné !!! • DNS za alo vznikat po átkem 80. let – postupn za alo plnit i další funkce (nap . v oblasti el. pošty) 3

Rodina protokol

TCP/IP

Koncepce DNS

v. 2.2

• musí to být distribuované ešení – distribuované co do umíst ní dat • objemy dat budou velké • data by m la být uchovávána co nejblíže místu kde vznikají a kde "žijí" (m ní se)

– distribuované co do pravomocí • aby r zné subjekty mohly p ijímat ur itá rozhodnutí a vykonávat úkony bez nutnosti koordinace s jinými subjekty – aby bylo možné p id lovat nová jména bez nutnosti ptát se, zda jsou již použita jinde – ….  J.Peterka, MFF UK, 2005

– distribuované co do fungování • kv li spolehlivosti i kv li vytížení to nesmí mít jeden centrální prvek • dotazy týkající se ur itých dat se budou zodpovídat tam, kde se tato data nachází

• musí to fungovat efektivn – týká se to hlavn p evodních mechanism mezi symbolickými jmény a íselnými IP adresami – m že to využívat "princip lokality" • dotazy nej ast ji sm ují na "místní" uzly, nebo na stále stejná jména "cizích" uzl – má smysl optimalizovat fungování pomocí vyrovnávacích pam tí (cache)

4

Rodina protokol

TCP/IP

Plochý vs. hierarchický prostor jmen

v. 2.2

• Plochý jmenný prostor – všechna jména jsou "jednorozm rná" • nap . ALPHA, Sun, PC1 • je omezený po et "smysluplných" jmen

– jména se p id lují z jedné "množiny" • musí to být centráln koordinováno – ten kdo chce n jaké jméno se musí ptát zda ješt nebylo použito

• nevýhody: – je to nepružné, neškálovatelné, organiza n náro né  J.Peterka, MFF UK, 2005

• Hierarchický jmenný prostor – existuje hierarchie (strom) díl ích jmenných prostor , • t mto díl ím jmenným

prostor m se íká domény

– "výsledná" jména budou mít více složek – organiza n 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 v tších celk 5

Rodina protokol

TCP/IP v. 2.2

cz cz cuni cuni

P edstava hierarchického jmenného prostoru hierarchie jmenných prostor / domén každá doména má své jméno (label)

mff mff

www (jméno p id lené v domén "cuni.cz", pln kvalifikované jméno je www.cuni.cz

ms ms

www (jméno p id lené v domén "mff.cuni.cz", pln kvalifikované jméno je www.mff.cuni.cz

www kocour  J.Peterka, MFF UK, 2005

ksi (jméno p id lené v domén "ms.mff.cuni.cz", pln kvalifikované jméno je ksi.ms.mff.cuni.cz 6

Rodina protokol

TCP/IP v. 2.2

Symbolická doménová jména obecn nemusí být uvedeny všechny složky (všechna díl í jména)

cz cz cuni cuni

www

mff mff

www

ms ms

ksi kocour

www.mff.cuni

www

 J.Peterka, MFF UK, 2005

jednotlivá díl í jména se zapisují za sebou a odd lují te kami po adí: nejvíce vlevo je "nejnižší" jméno ve smyslu hierarchie domén

7

Rodina protokol

Pln kvalifikovaná symbolická doménová jména

TCP/IP v. 2.2

teprve teprve pln pln kvalifikovaná kvalifikovaná jména jména jsou jsou jednozna jednozna ná ná

cz cz cuni cuni

www

mff mff

www

ms ms

ksi kocour

www.mff.cuni.cz

www


obsahuje celou posloupnost díl ích jmen až po nejvyšší doménu (ve smyslu jejich hierarchie) 8

Rodina protokol

TCP/IP v. 2.2

Syntaxe doménových jmen

• každá složka (díl í jméno, • v praxi lze používat i doménová jména, která nejsou pln kvalifikovaná label) smí mít nejvýše 63 – chybí jim n co "zprava" znak – m že se doplnit automaticky • mohou se používat pouze • nap . mailto:peterka@ksi se doplní na písmena, íslice a poml ka [email protected] – ne há ky a árky!! – poml ka 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

– ale jen v "p sobnosti" domény ms.mff.cuni.cz

– p esný mechanismus "dopl ování" je v kompetenci místní sít • nemusí být p esn známo jak to dopadne

– d sledek: nepoužívat 2-písmenná jména shodná se jmény TLD • nebylo by z ejmé, zda jde i nejde o pln kvalifikované jméno • nap . [email protected] ????? – .ms je TLD Montserratu


9

Rodina protokol

TCP/IP v. 2.2

Princip delegace pravomoci cz cz

v každé domén mohli p id lit jméno www, aniž se museli kohokoli ptát !!!!

cuni cuni

Pravidlo: v jedné domén nesmí být stejné jméno použito dvakrát !!!

mff mff ms ms

troja troja

karlin karlin

www

www

www

www www.mff.cuni.cz

www.ms.mff.cuni.cz  J.Peterka, MFF UK, 2005

www.troja.mff.cuni.cz

www.karlin.mff.cuni.cz

10

Rodina protokol

TCP/IP v. 2.2

Co je doména?

• prvek v rámci hierarchického • výjimka: je p edepsán charakter domén nejvyšší úrovn len ní jmenného prostoru – není apriorn stanovena ani hloubka, ani košatost hierarchie (stromu)!!

• "okruh p sobnosti" n koho, kdo má právo p id lovat symbolická jména • emu má doména odpovídat? – – – –

organiza nímu len ní? teritoriálnímu len ní? jinému len ní? NENÍ TO P EDEPSÁNO !!! • je to ponecháno na uvážení správce nad azené domény


– tzv. TLD domén (Top Level Domén)

– existují ccTLD (country code TLD), odpovídající státním útvar m, tvar dle normy ISO-3166 • • • •

.cz pro R .sk pro Slovesko .us pro USA .ru pro Rusko

p id luje IANA/ICANN

– existují gTLD (generic TLD), vyjad ující charakter subjektu • .edu pro školské instituce • .com pro komer ní organizace • .int, .net, .gov, .mil, .org, .arpa

11

Rodina protokol

TCP/IP v. 2.2

Jak má být doména "velká"?

• není apriorn stanoveno – to co komu vyhovuje, co do velikosti i logice len ní

• "p íliš velká" doména – není smysluplné, aby se p ímo v této domén p id lovala jména uzl m spadajícím do domény • nap . z organiza ních d vod

– eší se "delegováním pravomoci" (parcelací "okruhu p sobnosti") • vytvá í se dce inné domény


• "vhodn velká" doména – s takovým po tem uzl , aby se nevy erpala 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 vhodn jší víceúrov ové len ní • nap . UK (cuni.cz)

12

Rodina protokol

TCP/IP v. 2.2

Autorita nad doménou

• autorita = právo provád t zm ny

zóna

cz cz

– p id lovat nová jména, m nit je …. – z izovat dce inné domény

• obecn : ten kdo má autoritu nad doménou, má autoritu i nad jejími dce innými doménami

ISP1 ISP1

ISP2 ISP2

– získává ji p i vytvo ení dce inné domény

• ale m že se jí vzdát, resp. delegovat ji na jiný subjekt !!! – p íklad: • provider má autoritu nad doménami n kterých svých zákazník (kterým spravuje jejich domény), • nemá autoritu nad doménami jiných svých zákazník  J.Peterka, MFF UK, 2005

Z1 Z1

Z2 Z2 X1 X1 Y1 Y1

X2 X2

X3 X3

Y2 Y2 13

Rodina protokol

TCP/IP

Zóny

v. 2.2

• zóna – oblast tvo ená skupinou domén, nad kterou má n kdo konkrétní (jeden subjekt) autoritu • zóny se "zv tšují" vytvá ením dce inných domén • zóny se "zmenšují" delegováním pravomoci (autority) nad dce inný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á n kdo 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

14

Rodina protokol

TCP/IP v. 2.2

Name servery vs. domény

• v rámci každé domény se "pamatují" ur ité informace – nap .: • po íta se jménem X má IP adresu 193.194.195.196 • poštu pro doménu doru uj na uzel X.domena.cz

• Name server – vždy p ísluší k n jaké 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í

– slouží jako podklad k zodpovídání • p edstava: dotaz – každá doména má sv j name • typu" jako IP adresu má po íta server X?

• tyto informace nejsou uchovávány centráln , ale jsou distribuovány – a také se s nimi pracuje tam, kde se nachází  J.Peterka, MFF UK, 2005

• poskytuje službu spo ívající v p evodu jmen na IP adresy

– 1 po íta m že plnit roli name serveru pro více domén • 1 zóna = 1 uzel který d lá name server pro všechny domény v zón 15

Rodina protokol

TCP/IP

Struktura name server

v. 2.2

root root cz cz

cz cz

cuni cuni cuni cuni mff mff mff mff ms ms

ms ms

troja karlin troja karlin troja karlin troja karlin


• struktura name server logicky odpovídá struktu e domén – každá doména má sv j name server – existuje tzv. ko enový (root) name server, který "zná" name servery všech TLD (domén nejvyšší úrovn )

• fyzicky jsou name servery len ny jinak – 1 zóna má 1 name server – kv li dostupnosti jsou name servery nejmén zdvojeny name server

doména

16

Rodina protokol

TCP/IP

Princip p ekladu

v. 2.2

tazatel se nejprve ptá ko enového name serveru, jehož adresa je všeobecn známa

root root 2 cz cz

až se dostane k takovému name serveru, který mu dokáže odpov d t

tazatel

ptá se na IP adresu uzlu ksi.ms.mff.cuni.cz

5

tazatel je postupn odkazován na další name servery

mff mff mff mff

5 ms ms


3

cuni cuni cuni cuni 4

195.113.19.213

4 3 2 1

cz cz

1

ms ms

uzel ksi.ms.mff.cuni.cz

troja karlin troja karlin troja karlin troja karlin 17

Skute ný pr b h p ekladu (rekurzivní dotaz)

Rodina protokol

TCP/IP v. 2.2

root root

oslovený name server sám zprost edkuje zodpov zení dotazu

cz cz ksi.ms.mff.cuni.cz?

cuni cuni cuni cuni

name server 195.113.19.213

mff mff mff mff

tazatel se ptá "nejbližšího" name serveru nejbližší je ten, jehož existenci má zanesenu ve své konfiguraci  J.Peterka, MFF UK, 2005

cz cz

ms ms

ms ms


Skute ný pr b h p ekladu (iterativní dotaz)

Rodina protokol

TCP/IP v. 2.2

ksi.ms.mff.cuni.cz?

oslovený name server pouze doporu í jiný name server

zeptej se .cz

2 cz cz ksi.ms.mff.cuni.cz?

1

ksi.ms.mff.cuni.cz? 195.113.19.213


ms ms

cz cz

cuni cuni cuni cuni

name server

zeptej se root-a

tazatel se nejprve ptá "nejbližšího" name serveru

root root

ms ms

mff mff mff mff

• p vodní tazatel se

postupn obrací na jednotlivé name servery • žádný mu nedá odpov • každý jej pouze nasm ruje jinam


Rodina protokol

TCP/IP v. 2.2

Primární a sekundární name servery • každá doména musí mít (hlavní) name server, který je tzv. primární

z pohledu tazatel jsou ekvivalentní

primární name server


• sv j zone file získává z místního disku

• krom toho by m la mít nejmén jeden (záložní) name server, tzv. sekundární sekundární name server

získává data z primárního name serveru zone file je na místním disku

– primární name server má p ímo k dispozici relevantní data o domén

– sekundární name server by m l být umíst n v jiné síti • nej ast ji u (nad azeného) providera

– sekundární name server "se izuje sv j obsah" sám a automaticky podle obsahu primárního name serveru • vyžádá si tzv. zone transfer 20

Rodina protokol

TCP/IP

DNS servery a resolvery

v. 2.2

aplikace

dotazy

resolver

odpov di

• DNS má architekturu klient/server – name server odpovídá na dotazy • plní roli serveru

– resolver pokládá dotazy name server m

dotazy

resolver

odpov di

cache dotazy

data

name server


odpov di

• 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 pot ebuje resolver

• na ostatních uzlech sta í jen resolver 21

Rodina protokol

TCP/IP v. 2.2

Optimalizace fungování DNS

• replikace – name servery domén jsou replikovány

• cache-ování – odpov di autoritativních name server si ostatní servery ukládají do svých cache pam tí

• 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 ko enové name servery • všechny jsou primární • slouží i k rozložení zát že

• a pak je používají pro p ímou (neautoritativní) odpov )

• cacheování p ináší nejv tší optimalizaci!!

• forwarding name server – p ijímá rekurzivní dotazy, ale ne eší je, nýbrž pouze p edává (forwarduje) jinému name serveru • obvykle kv li snazší konfiguraci klient  J.Peterka, MFF UK, 2005

22

Rodina protokol

TCP/IP

Neautoritativní odpov di

v. 2.2

resolver cache cache data

name server

autoritativní autoritativnípro pro konkrétní konkrétnídoménu doménujsou jsou její jejíprimární primárníaa sekundární sekundárníserver server  J.Peterka, MFF UK, 2005

• kv li optimalizaci fungování jsou získané odpov di ukládány do vyrovnávací pam ti (cache pam ti) – pouze po ur itou dobu • TTL je atributem odpov di

– další odpov di na stejné dotazy jsou pak zodpovídány z vyrovnávací pam ti

• odpov odpov

z cache pam ti má jiný statut než od autoritativního name serveru – je tzv. neautoritativní, nebo pochází od

n koho kdo nemá autoritu hovo it za p íslušnou doménu – tazatel to z odpov di 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í 23

Rodina protokol

TCP/IP

Ko enové name servery

v. 2.2

name a b c d e f g h i j k l m

org InterNIC ISI PSInet UMD NASA ISC DISA ARL NORDUnet (TBD) RIPE ICANN WIDE


city Herndon,VA, US Marina del Rey,CA, US Herndon,VA, US College Park,MD, US Mt View, CA, US Palo Alto, CA, US Vienna, VA, US Aberdeen, MD, US Stockholm, SE (colo w/ A) London, UK Marina del Rey,CA, US Tokyo, JP

• celkem 13 po celém sv t – na 7 r zných HW platformách – na 8 r zných variantách OS (Unix) 24

Rodina protokol

TCP/IP v. 2.2


Ko enové name servery

25

Rodina protokol

TCP/IP v. 2.2

RR - Resource Records

• DNS je distribuovaná databáze – logicky len ná podle domén

• data jsou v ní uložena ve form v t – tzv. RR – Resource Records – nap . údaj o IP adrese uzlu s konkrétním jménem NAME

TYPE

CLASS

TTL

2B

2B

4B

1 = Internet

jméno položky typ položky  J.Peterka, MFF UK, 2005

RDLENGTH

2B

RDATA

samotná data

skute ná velikost dat doba, po kterou smí být data (jako odpov ) uložena v cache pam ti, v sekundách 26

Rodina protokol

RR – Resource Records (p íklady)

TCP/IP v. 2.2

Typ

anglický název

význam pole RDATA

A

A host address

IP adresa uzlu

NS

Authoritative name server

doménové jméno name serveru, který je autoritativní pro danou doménu

CNAME

Cannonical name

kanonické synonymum k NAME

HINFO

Host INFO

popis HW s SW

MX

Mail eXchange

kam má být doru ována el. pošta pro doménu

AAA

IPv6 address

128-bitová adresa dle IP verze 6

….

….

….


27

Rodina protokol

TCP/IP v. 2.2

P íklady

• Name=ksi.ms.mff.cuni.cz

RDATA

Type=A, Class=1, TTL=86400 (1 Day), RDLENGTH=4 IP Address=195.113.19.213

• 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, 2005

28

Rodina protokol

TCP/IP v. 2.2

DNS protokol

• DNS klient a server spolu komunikují pomocí jednoduchého aplika ního protokolu – protokolu DNS

• pro transport je nej ast ji využíván protokol UDP – ale m že být použit i TCP – pro dotazy na p eklad jména je preferován protokol UDP

• DNS server "poslouchá" na portu 53 – p es TCP i UDP  J.Peterka, MFF UK, 2005

• DNS protokol používá stejný formát paketu (DNS QUERY) pro dotaz i odpov HEADER QUESTION ANSWER AUTHORITY ADDITIONAL 29

Rodina protokol

TCP/IP 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, 2005

30

Rodina protokol

TCP/IP 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=194.213.224.6 - Name=ns.czech.net Type=A, Class=1, TTL=86400 (1 Day), RDLENGTH=4 IP Address=194.213.224.1 - Name=scretchy.czech.net Type=A, Class=1, TTL=86400 (1 Day), RDLENGTH=4 IP Address=194.213.224.2


31

Rodina protokol

TCP/IP

Domény a diakritika

v. 2.2

• standardn : – diakritika není p ípustná, jen isté ASCII

• snaha: – p ipustit také použití znak národních abeced ve jménech domén • v R: s há ky& árkami, nap . žlu ou ký.k .cz

– motivace: • rozší ení jmenného prostoru, více možných registrací • možnost registrovat takové domény, jaké dnes neexistují  J.Peterka, MFF UK, 2005

IDN (Internationalized Domain Names) – ešení dle RFC 3490-2 (2003) – ve jménech lze použít (podmnožinu) UNICODE 3.2

• princip ešení: – bude to fungovat jako "nadstavba" nad sou asným DNS • fungování DNS jako takového se nem ní !!!!

• "p eklad" z ne-ASCII do ASCII tvaru a naopak zajiš uje klientská aplikace!!! 32

Rodina protokol

TCP/IP

P edstava fungování

v. 2.2

name server .cz

name server xn--k-qla0j.cz k .cz

toASCII

žlu ou ký.k .cz

xn--k-qla0j.cz toASCII

xn--luouk-uva4it5a4g. xn--k-qla0j.cz

p eklad se odehrává již na klientském po íta i (v rámci aplikace jako je browser, poštovní klient)


xn--luouk-uva4it5a4g = 123.456.789.100 33

Rodina protokol

TCP/IP v. 2.2

P eklad

• musí být definován "p eklad" jmen z UNICODE do ASCII a opa n

d m.cz

– nejprve se d lá "nameprep" • sjednocují se r zné varianty možného zápisu (nap . velká a malá písmena), vzniká "kanonický tvar"

xn--dm-sua.cz

– pak se d lá vlastní p eklad • fakticky: zakódování do istého ASCII • tzv. punycode

– musí existovat i opa ný p eklad • z ASCII do UNICODE  J.Peterka, MFF UK, 2005

žlu ou ký xn--luouk-uva4it5a4g 34

Rodina protokol

TCP/IP 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, kv li malému zájmu uživatel  J.Peterka, MFF UK, 2005

• 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

35

Rodina protokol

TCP/IP v. 2.2

P íklad – když to funguje

böhm.de

xn--bhm-sna.de (Internet Explorer s instalovaným plug-inem i-NAV)


36

Rodina protokol

TCP/IP v. 2.2

P íklad – když to nefunguje

böhm.de

www.b%C3%B6hm.de/ (nejde o p eklad do punycode) (Internet Explorer (MyIE2) bez podpory IDN)


37

Rodina protokol

TCP/IP

Úskalí IDN

v. 2.2

• registrace "ohá kovaných" domén – m l 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 m l mít (p ednostní) právo? – nevzniká tím jen v tší prostor pro spekulativní registrace – nejde jen o v tší "kšeft" pro registrátory domén?  J.Peterka, MFF UK, 2005

• 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 • p eklad UNICODE to ASCII

38

Rodina protokol

IRI,

TCP/IP v. 2.2

Internationalized Resource Indicators

• koncept IDN se týká pouze doménových jmen

• p ístup firmy Microsoft k IDN:

– nikoli celých URL adres – ne eší 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

– sledujeme a zvažujeme implementaci

• domn nka: –

ekají na IRI, až bude mít definitivní podobu:

• IDN bude jeho sou ástí

– ješt není hotov !!!

http://žlu ou ký.k .cz/stáj/podestýlka/seno.htm IDN  J.Peterka, MFF UK, 2005

IRI

39

Rodina protokol

TCP/IP

Alternativní DNS

v. 2.2

• 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í  J.Peterka, MFF UK, 2005

root

alt. root

x resolver com

edu

earth europe

www.europe.earth

www=… 40

Rodina protokol

TCP/IP

Dynamické DNS

v. 2.2

• klasické DNS je statické – nep edpokládá, že IP adresa konkrétních uzl se m ní • moc asto, nap . každý den i hodinu

– v praxi ovšem hodn uzl dostává IP adresu p id lovanou dynamickým zp sobem • nap . na dial-upu, ADSL, kabel …..

• dynamické DNS – takové ešení, kdy dochází k aktualizaci DNS zóny tak asto, jak je pot eba – princip: na uzlu b ží malý "DNS klient", který pr b žn informuje (dynamický) DNS server o aktuální IP adrese • dynamický DNS server se aktualizuje podle pot eby

– d sledek: takovéto uzly nemohou • typické ešení: mít p id lené (vlastní, stabilní) – jde o placenou službu symbolické doménové jméno • DNS by se nesta ilo pokaždé aktualizovat  J.Peterka, MFF UK, 2005

41

Rodina protokol

TCP/IP v. 2.2

Reverzní domény – p eklad z IP do CNAME jaké je CNAME k IP 169.254.16.200?

16.254.169.in-addr.arpa 16.254.169.in-addr.arpa

• eší se p es doménu in-addr.arpa – další (nižší) subdomény odpovídají p id leným IP adresám, po jednotlivých bytech • v obráceném po adí!!!

– držitel IP adresy má ve správ p íslušnou "reverzní doménu"  J.Peterka, MFF UK, 2005

42

Rodina protokol

TCP/IP

ENUM

v. 2.2

• jde o snahu provázat DNS a telefonní ísla • cíl: umožnit, aby se k telefonním ísl m mohly p i azovat "další informace", stejn jako k doménovým jmén m – nap íklad o p esm rování hovoru • ú astník má jedno tel. íslo a skrze DNS si volí, zda chce p ijí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 sta ila 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 "sv ta spoj ", nikoli "sv ta Internetu" – angažuje se hlavn ITU-T


43

Rodina protokol

TCP/IP

ENUM – p edstava fungování

v. 2.2

• tel. íslo +420 123 456 789 – formát ur uje direktiva ITU E.164

• odstraní se vše krom te kami

íslic, obrátí se po adí, odd lí se

– 9.8.7.6.5.4.3.2.1.0.2.4

• p idá se "koncovka" .e164.arpa – 9.8.7.6.5.4.3.2.1.0.2.4.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, 2005

44

IP, verze 2.2. ást 4: Systém DNS

Recommend Documents