Rozwój Systemu Nazw Domenowych

Rozwój Systemu Nazw Domenowych
Wprowadzenie
System nazw domen (DNS) dostarcza usługę nazewniczą dla DARPA Internet. Jest jedną z największych
usług nazewniczych stosowanych dzisiaj, służy wysoce różnorodnym środowiskom hostów, użytkowników,
sieciom i używa unikalnego połączenia hierarchii, cach-owania i dostępu datagramowego.
W tym dokumencie analizowane są pomysły sprzed początkowego projektowaniem DNS w 1983.
Omówiona została ewolucja tych pomysłów do aktualnych implementacji oraz jej użycie, przedstawiono
zauważalne niespodzianki, zalety i wady jak również próbę przewidzenia jego przyszłego rozwoju.
1. Wstęp
Przyczyną powstania DNS było zaobserwowanie, około 1982 roku, że system HOSTS.TXT publikujący
odwzorowania między nazwami host-ów i adresami napotykał na wiele problemów. HOSTS.TXT jest nazwą
prostego pliku tekstowego, który znajduje się na centralnym hoście w SRI Network Information Center –
sieciowym centrum informacyjnym (SRI-NIC) i rozprowadzony jest do wszystkich hostów w Internecie przez
bezpośredni i pośredni transfer pliku.
Problemy polegały na tym, że plik i związany z nim koszt dystrybucji, stawały się zbyt duże, jak również to,
że scentralizowana kontrola aktualizowania nie pasowała do trendu rozproszonego zarządzania Internetem.
Prosty wzrost był jedną z przyczyn tych problemów; inną był rozwój społeczności używającej HOSTS.TXT
począwszy od ARPANET opartego na oryginalnym NCP do Internetu opartego na IP/TCP. W wyniku badań
rola ARPANET-u zmieniła się - z pojedynczej sieci łączącej duże systemy z podziałem czasu (timesharing)
ARPANET stał się jedną z kilku sieci szkieletowych dalekiego zasięgu łączącej sieci lokalne, które jedna po
drugiej zapełniały się stacjami roboczymi. Liczba host-ów zmieniła się od ilości systemów z podziałem czasu timesharing (w przybliżeniu organizacji) do liczby stacji roboczych (użytkowników). Ten wzrost bezpośrednio
odbił się na wielkości HOSTS.TXT, szybkości zmian dokonywanych w HOSTS.TXT i liczbie transferów pliku.
Doprowadziło to do dużo większego niż liniowy wzrostu użycia zasobów do rozprowadzania pliku. Ponieważ
zmusiło to organizacje do zarządzania lokalnymi adresami sieciowymi, bramami, etc., przy wykorzystaniu
jakiejkolwiek technologii, całkiem logiczną okazała się chęć, by podzielić bazę danych i pozwolić na lokalną
kontrolę lokalnych nazw i przestrzeni adresowej. Rozdzielony system nazywania wydawał się na miejscu.
W skład istniejących systemów nazywania wchodziły: DARPA Internetowy IEN116 [IEN 116] i XEROX
Grapevine [Birrell 82] i systemy Clearinghouse [Oppen 83]. Usługi IEN116 wydawały się nadmiernie
ograniczone, z konkretnym hostem, IEN116 nie dostarczył na tyle dużo korzyści, by usprawiedliwić koszty
renowacji. System XEROX był wtedy i nadal jest najbardziej wyszukaną usługą nazewniczą w dziejach, ale to
nie było oczywiste, że jego intensywne użycie replikacji, małe użycie buforowania podręcznego i niezmienna
liczba poziomów hierarchii były odpowiednie dla różnorodnego i często chaotycznego stylu Internetu DARPA.
Importowanie projektu XEROX-a oznaczałoby konieczność importowania wspierających elementów
architektury protokołu. Z tych powodów zapoczątkowano nowy projekt.
Początkowy projekt DNS został wyszczególniony w [RFC 882, RFC 883]. Jest on zbudowany jako
hierarchiczna przestrzeń nazw z zapisanymi danymi w punktach węzłowych. Kontrola baz danych została
również rozdzielona w sposób hierarchiczny. W zamiarze było, że typy danych będą rozszerzalne, a z dodaniem
nowych typów danych będzie związane dodawaniem nowych aplikacji. Chociaż system został zmodyfikowany i
upiększony w kilku obszarach [RFC 973, RFC 974], aktualne specyfikacje [RFC 1034, RFC 1035] i sposób
użycia są całkiem podobne do oryginalnych definicji.
Rozróżnienie pomiędzy doświadczalnym użyciem i stanem produkcji jest trudne, ale w roku 1985 cześć
host-ów używała DNS jako podstawowy i jedyny sposób uzyskiwania dostępu do informacji poprzez
nazewnictwo. Chociaż DNS nie zastąpił mechanizmu HOSTS.TXT w wielu starszych host-ach, stał się on
standardowym mechanizmem dla host-ów, szczególnie dla opartych na Berkeley UNIX, które śledziły postęp w
sieci i w projektowaniu systemów operacyjnych.
2. DNS Design
Podstawowe założenia projektowe dla DNS były takie, że musi on:
• Dostarczać przynajmniej tyle informacji co HOSTS.TXT
• Baza danych musi być przechowywana w sposób rozproszony
• Być wolny od ograniczeń odnośnie nazw, ich komponentów oraz danych
związanych z nazwą itd.
• Współpracować z DARPA Internet i możliwie dużą ilością środowisk
• Zapewniać odpowiednie osiągi.
Kolejne ograniczenia były następujące:
• Koszt implementacji systemu mógł być uzasadniony jedynie dostarczaniem
rozszerzalnych usług. W szczególności system powinien być niezależny od
topologii sieci, zdolny do enkapsulacji innych przestrzeni nazw.
• Aby system mógł być ogólnie dostępny i używany, powinien unikać
wymuszania na użytkowniku korzystania tylko z jednego systemu
operacyjnego, architektury, czy stylu organizacji. Ta idea ogarniająca
problemy począwszy od obaw dotyczących wrażliwości na wielkość liter aż do
tego, że system powinien być użyteczny zarówno dla dużych hostów
dzielących czas jak i dla zwykłych PC. Ogólnie dążono do uniknięcia
wszelkich ograniczeń systemu w związku z zewnętrznymi wpływami i
zezwolić na możliwie dużą ilość różnych struktur implementacyjnych.
Wymagania dla emulacji HOSTS.TXT nie były szczególnie surowe, ale to spowodowały wczesne
sprawdzanie schematów gromadzenia danych innych niż odwzorowania nazwy w adres. Hierarchiczna
przestrzeń nazw wydawała się oczywistym i minimalnym rozwiązaniem dla wymagań ilościowych
i dystrybucyjnych. Ograniczenia współdziałania i osiągów sugerowały, że system będzie musiał pozwolić na
buforowanie informacji z bazy danych pomiędzy klientem i źródłem danych, ponieważ dostęp do źródła nie
mógłby być możliwy albo odpowiedni w czasie.
Początkowy projekt DNS zakładał konieczność zapewnienia równowagi między bardzo wąską usługą i
zupełnie ogólną rozproszoną bazą danych. Wąska usługa była pożądana, ponieważ powodowała więcej prób
implementacyjnych i wcześniejszą możliwość wykorzystania. Ogólny projekt amortyzowałby koszty
wprowadzenia w większej ilości aplikacji, zapewniałby większą funkcjonalność i zwiększałby liczbę środowisk,
w których DNS mógłby być ostatecznie użyty. Kryterium „wąskości” doprowadziło do świadomej decyzji, by
pominąć większość funkcji, których można by się spodziewać w bardziej zaawansowanych bazach danych.
Szczególnie dynamiczna aktualizacja bazy danych z odpowiednią atomowością, głosowaniem i kopiami
zapasowymi została pominięta. Ostatecznie zamierzano dodać te opcje, ale stwierdzono, że system, który
zawierałby te cechy mógłby być postrzegany jako zbyt złożony, by zostać zaakceptowany przez społeczność.
2.1. Architektura
Wyróżnić można dwa główne typy aktywnych komponentów DNS : serwery nazw i klienci DNS
(resolver). Serwery nazw są składnicą informacji i odpowiadają na zapytania używając wszelkich posiadanych
informacji. Klienci DNS to interfejs dla programów klienta, zawierający w sobie algorytmy konieczne, by
znaleźć serwer nazw, który zawiera informację poszukiwaną przez klienta.
Te funkcje mogą zostać połączone albo rozdzielone, by dostosować się do potrzeb środowiska. W wielu
przypadkach przydatnym jest, by scentralizować funkcję klienta DNS w jednym albo w większej liczbie
specjalnych serwerów nazw dla danej organizacji. Taka struktura dzieli się użyciem skeszowanej informacji, jak
również pozwala słabszym hostom, takim jak PC, polegać na rozwiązujących nazwy usługach specjalnych
serwerów bez potrzeby posiadania klienta DNS w PC.
2.2. Przestrzeń nazw
Wewnętrzna przestrzeń nazw DNS jest drzewem o zmiennej głębokości, przy czym każdy punkt
węzłowy w drzewie ma przypisaną etykietę. Nazwa domeny punktu węzłowego jest połączeniem wszystkich
etykiet na ścieżce z punktu węzłowego do korzenia drzewa. Etykiety są zmiennej - długość stringami oktetów i
każdy oktet w etykiecie może przyjmować dowolną 8-bitową wartość. Etykieta zerowej długości jest
zarezerwowana dla korzenia. Operacje przeszukujące przestrzeń nazw są realizowana w sposób, który nie
uwzględnia wielkości liter (stosuje się kod ASCII). W ten sposób etykiety „Paul”, „paul” i „PAUL”, oznaczają
ten sam węzeł. Ta reguła dopasowywania skutecznie przeciwdziała tworzeniu wierzchołków drzewa o etykietach
mających identyczną pisownię, ale różniących się wielkością liter. Racjonalny dla tego systemu jest fakt, że
pozwala on źródłom informacji wyszczególnić ich kanoniczną wielkość liter, ale uwalnia użytkowników od
konieczności pamiętania o wielkości liter w etykietach. Etykiety są ograniczone do 63 oktetów, a nazwy
całkowicie do 256 oktetów. Pomaga to przy implementacji, choć ograniczenie mogłoby łatwo zostać zmienione,
jeśli pojawiłaby się taka potrzeba.
Specyfikacja DNS unika definiowania standardowej reguły druku dla wewnętrznego formatu nazw, aby
pozwolić na użycie DNS do zakodowania istniejącej strukturalnej nazwy. Pliki konfiguracyjne w systemie
domen reprezentują nazwy jako łańcuchy znaków rozdzielone kropkami, ale aplikacje mogą je przedstawiać
inaczej. Na przykład, nazwy hostów używają wewnętrznych reguł DNS, więc przykładowo VENERA.ISI.EDU
jest nazwą z czterema etykietami (pusta nazw korzenia zwykle jest pominięta). Nazwy skrzynek pocztowych,
podawane są jako USER@DOMAIN (albo ogólniej jako lokalna_cześć@oraganizacja) kodują tekst z lewej
strony znaku „@” w pojedynczą etykietę (być może zawierającą „.”) i używają ustalania zakresu kropki zgodnie
regułami pliku konfiguracyjnego DNS dla części po znaku „@”. Podobne kodowanie można by zastosować dla
nazw plików, etc.
DNS również oddziela strukturę drzewa od ukrytych semantyk. Nie wykonano tego aby przechowywać
nazwy wolne od ukrytych semantyk, ale po to, by pozostawić aplikacji wybór semantyki. W ten sposób nazwa
hosta mogłaby mieć więcej albo mniej etykiet niż nazwa użytkownika i drzewo nie byłoby zorganizowane przez
sieć albo inne grupowanie. Szczególne sekcje przestrzeni nazw mają bardzo silną (ukrytą) semantykę łączoną z
nazwą, szczególnie kiedy DNS zawiera istniejącą przestrzeń nazw albo gdy jest użyty, by dostarczyć
odwrotnych odwzorowań (np. INADDR. ARPA, adresy IP do sekcji nazwy hosta w przestrzeni domeny), ale
domyślnym założeniem jest, że jedynym sposobem, by zdecydowanie powiedzieć co nazwa reprezentuje jest
spojrzenie na dane skojarzone z tą nazwą.
Zalecana struktura przestrzeni nazw dla hostów, użytkowników i innych typowych aplikacji
odzwierciedla strukturę organizacji kontrolującej domenę lokalną. Jest to wygodne, ponieważ cechy DNS
dotyczące (dystrybucji) kontroli nad bazą danych jest najskuteczniejsze kiedy odpowiada strukturze drzewa.
Administracyjnie wprowadzono [RFC 920], że najwyższe poziomy odpowiadają kodom krajów albo ogólnie
typom organizacji (na przykład EDU dla edukacyjnego, MIL dla wojskowego, UK dla Wielkiej Brytanii).
2.3. Powiązanie danych z nazwami
Ponieważ DNS nie powinien ograniczać danych, które aplikacje mogą dołączać do nazwy, to nie może
przygotować całkowicie formatu danych. DNS potrzebował też wyszczególnić pewne podstawy dla
strukturyzacji danych, tak żeby odpowiedzi na zapytania mogły zostać ograniczone do istotnych informacji oraz
by DNS mógł użyć swych własnych usług, by śledzić serwery, adresy serwerów, etc. Dane dla każdej nazwy w
DNS są zorganizowane jako zestaw rekordów zasobów (RRs); każdy RR zawiera dobrze znany typ i pole klasy,
po których następują dane aplikacji. Wielokrotne wartości tego samego typu są reprezentowane jako oddzielny
RRs.
Typy mają reprezentować abstrakcyjne zasoby albo funkcje, na przykład adresy hostów i skrzynki
pocztowe. Około 15 jest aktualnie zdefiniowanych. Pole klasowe jest przeznaczone do podzielenia bazy danych
ortogonalnie ze względu na typ i do określenia rodziny protokołów albo instancji. Internet DARPA zawiera
klasę i można sobie wyobrazić, że klasy mogłyby zostać przydzielone do CHAOS, ISO, XNS albo podobnych
rodzin protokołów. Próbowano również konfigurowania funkcji określonej klasy, która byłaby niezależna od
protokołu (np.: uniwersalne archiwum pocztowe). Trzy klasy zostały obecnie wydzielone: Internet DARPA,
CHAOS i Hessiod.
Decyzja, by użyć wielokrotnych RRs pojedynczego typu zamiast włączania wielokrotnych wartości do
pojedynczego RR, różniła się od użytej w systemie XEROX i wybór nie był oczywisty. Wydajność przestrzeni
pojedynczego RR z wielokrotnymi wartościami była atrakcyjna, ale opcja wielokrotnych RR ograniczyła
maksymalną wielkość RR. To wydawało się obiecywać protokoły o prostszej dynamicznej aktualizacji, jak
również wydawało się dostosowane do użycia w środowisku datagramowym o ograniczonej wielkość (np.:
odpowiedź mogłaby zawierać tylko te elementy, które pasowałyby do maksymalnego rozmiaru pakietu bez
uwagi na część transportową RR).
2.4. Dystrybucja bazy danych
DNS dostarcza dwóch głównych mechanizmów dla przesyłania danych z końcowego źródła do
końcowego celu. Są to strefy oraz buforowanie. Strefy to sekcje systemowej bazy danych, które są kontrolowane
przez określoną organizację. Organizacja kontrolująca strefę jest odpowiedzialna za rozprowadzanie aktualnych
kopii stref do wielu różnych serwerów, które udostępniają strefy dla klientów przez Internet. Transfery strefy
typowo są inicjowane przez zmiany danych w strefie. Buforowanie jest mechanizmem, dzięki któremu dane
uzyskane w odpowiedzi na prośbę klienta mogą być lokalnie przechowywane na wypadek przyszłego zapytania
przez tego samego albo innego klienta.
Należy zauważyć, że zamiarem jest, aby oba mechanizmy były niewidoczne dla użytkownika, który
powinien widzieć pojedynczą bazę danych bez oczywistych ograniczeń.
Strefy
Strefa jest to kompletny opis sąsiedniej sekcji całkowitego drzewa przestrzeni nazw, razem
z informacjami „wskazującymi” na inne sąsiednie strefy. Ponieważ podziały stref mogą zostać wykonane
pomiędzy dowolnymi dwoma połączonymi punktami węzłowymi w całkowitej przestrzeni nazw, strefa mogłaby
być pojedynczym punktem węzłowym albo całym drzewem, ale typowo jest prostym drzewem podrzędnym.
Organizacja przejmuje kontrolę nad strefą przestrzeni nazw przez przekonanie rodzicielskiej
organizacji, by udzieliła pełnomocnictwa nad podstrefą składającą się z pojedynczego punktu węzłowego.
Rodzicielska organizacja dokonuje tego poprzez wstawianie RRs we własnej strefie, który zaznacza podział
strefy. Nowa strefa może wtedy rozrosnąć się do arbitralnej wielkości i dalej udzielać pełnomocnictwa bez
angażowania rodzica, chociaż rodzic zawsze zachowuje kontrolę nad początkowym udzieleniem
pełnomocnictwa. Na przykład, strefa ISI.EDU została utworzona przez przekonanie właściciela domeny EDU do
oznaczenia granicy strefy pomiędzy EDU i ISI.EDU.
Odpowiedzialność spoczywająca nad organizacją dotyczy utrzymania danych strefy i dostarczenia
nadmiarowych serwerów dla strefy. Typowa strefa jest utrzymana przez pewnego administratora systemu w
formie tekstowej zwanej plikiem głównym i jest ładowana do serwera głównego. Nadmiarowe serwery są albo
przeładowane ręcznie, albo używają automatycznego algorytmu odświeżania strefy, który jest częścią protokołu
DNS. Odświeżający algorytm pyta o numer seryjny w strefie danych serwera głównego, kopiuje strefę tylko
wtedy, jeśli wzrósł jej numer seryjny. Transfery strefy wymagają protokołu TCP dla zapewnienia
niezawodności.
Szczególny serwer nazw może utrzymywać dowolną ilość stref, które mogą być sąsiednie, ale nie
muszą. Serwer nazw dla strefy nie musi być częścią tej strefy. Ten plan (schemat) pozwala na prawie arbitralną
dystrybucję, ale jest najskuteczniejszy, kiedy baza danych jest rozprowadzona równolegle z hierarchią nazw.
Kiedy serwer odpowiada z danej strefy, a nie z pamięci podręcznej, oznacza on odpowiedź jako autorytatywną.
Celem takiego postępowania jest zapewnienie organizacji możliwości posiadania domen nawet, jeśli
brakuje jej możliwości komunikacji albo zasobów hosta wymaganych do usługi nazewniczej domeny. Jedna
metoda polega na tym, że organizacje posiadające zasoby dla pojedynczego serwera mogą tworzyć systemy
z innymi organizacjami podobnego typu. Może być to pożądane przez klientów, gdy ich organizacje znajdują się
z dala od siebie (w kategoriach sieciowych). Powoduje to, że dane są dostępne z różnych miejsc (lokalizacji w
sieci,stron etc). Inna metod polega na tym, że serwery zgadzają się na dostarczenie usługi nazewniczej dla
dużych społeczności takich jak CSNET i UUCP i otrzymują plik główny poprzez pocztę elektroniczną albo FTP
od ich abonentów.
Buforowanie (pamięć podręczna)
Oprócz zaplanowanej dystrybucji danych poprzez transfery strefy, resolvery DNS i połączone programy
serwera nazw/klienta DNS również buforują odpowiedzi dla użycia przez późniejsze zapytania. Mechanizmem
kontrolowania pamięci podręcznej jest czas życia (TTL), pole znajdujące się w każdym RR. Określa ono, przez
jaki czas (w ułamkach sekund) odpowiedź może zostać użyta ponownie. Zerowy TTL zakazuje buforowania.
Administrator określa wartości TTL dla każdego RR podczas definicji strefy; niski TTL jest wskazany, by
zmniejszać okresy przejściowej niekonsekwencji, podczas gdy wysoki TTL zmniejsza ruch i pozwala na
buforowanie w celu zamaskowania okresów nieosiągalności (niedostępności) serwera z powodu problemów z
siecią, bądź z hostem. Komponenty oprogramowania powinny się zachowywać tak, jak gdyby ciągle
zmniejszały TTL danych w buforach. Zalecaną wartością TTL dla nazw hosta są dwa dni.
W zamierzeniu buforowane odpowiedzi powinny być tak dobre jak uzyskiwane od autorytatywnego
serwera, z wyjątkiem zmian wprowadzonych w okresie TTL. Jednakże, wszystkie komponenty DNS preferują
wiarygodną informacje kiedy obie są udostępnione lokalnie.
3. Aktualny stan implementacji
DNS jest używany w całym Internecie DARPA. Katalogi [RFC 1031] opisują tuzin implementacji bądź
portów, obejmując zagadnienia począwszy od wszechobecnego wsparcia (pomocy) dostarczonego jako część
Berkeley UNIX, aż do implementacji dla IBM - PCety, Macintosh’e, maszyny LISP i fuzzball [Mills 88].
Chociaż mechanizm HOSTS.TXT nadal jest używany przez starsze hosty, zalecanym mechanizmem jest DNS.
Hosty dostępne przez HOSTS.TXT tworzą stale zmniejszający się podzbiór wszystkich hostów; ostatni pomiar,
[Stahl 87] pokazał, że w przybliżeniu 5,500 nazw hostów znajdowało się w obecnym HOSTS.TXT, podczas gdy
przeszło 20,000 nazw hostów było dostępnych poprzez DNS.
Aktualna przestrzeń nazw domen jest dzielona na około 30 domen najwyższego poziomu. Chociaż te
domeny są zarezerwowana dla każdego kraju (w przybliżeniu 25 w użyciu, np.: US, UK), większość hostów
oraz poddomeny nazywane są zgodnie z sześcioma najważniejszymi domenami najwyższego poziomu
określonymi dla różnych typów organizacji (e.g. edukacyjny - EDU, handlowy - COM). Niektóre hosty żądają
wielokrotnej nazwy w różnych domenach, chociaż zwykle jedna nazwa jest najważniejsze a inne są nazwami
umownymi (lub aliasami). SRI - NIC zarządza strefami dla wszystkich nie-krajowych domen najwyższego
poziomu i deleguje niższe domeny do indywidualnych uniwersytetów, przedsiębiorstw i innych organizacji,
które życzą sobie zarządzać własną przestrzeń nazw.
Delegacja poddomenami przez SRI-NIC stale rosła. W lutym 1987, około 300 domen zostało
wydelegowanych. Począwszy od marca 1988, ponad 650 domen zostało wydelegowanych. W przybliżeniu 400
reprezentuje normalne przestrzenie nazw kontrolowane przez organizacje inne niż SRI - NIC, podczas gdy 250 z
wydelegowanych domen reprezentuje przestrzenie adresu sieciowego (np. części IN-ADDR.ARPA) już nie są
kontrolowane przez NIC.
Dwoma dobrymi przykładami współczesnego użycia DNS są tak zwane "serwery korzenia”, które są
nadmiarowymi serwerami nazw wspierającymi najważniejsze poziomy przestrzeni nazw domen i poddomen
Berkeley, która jest jedną z domen wydelegowanych przez SRI - NIC w domenie EDU.
3.1. Serwery korzenia
Podstawowy algorytm poszukiwania dla DNS pozwala klientom DNS na decyzje przeszukiwania „w
dół” z domen, do których mogą już uzyskać dostęp. Klienci DNS typowo są skonfigurowani z
„podpowiedziami” wskazującymi na serwery wierzchołka roota (korzenia głównego) i wierzchołka domeny
lokalnej. W ten sposób, jeśli klient może uzyskać dostęp do jakiegoś serwera korzenia to może uzyskać dostęp
do wszystkich przestrzeni domen, i jeśli klient DNS jest w sieci oddzielonej od reszty Internetu, to może
przynajmniej uzyskać dostęp do lokalnych nazw.
Chociaż klient DNS ma dostęp do serwerów korzenia w mniejszym stopniu niż gromadzi buforowane
informacje o serwerach dla niższych domen, to dostępność serwerów korzenia jest ważnym elementem
odporności na błędy, a monitorowanie działania serwera korzenia dostarcza wglądu w użycie DNS.
Ponieważ dostęp do korzenia i innych stref najwyższego poziomu jest tak ważny, domena korzenia,
razem z innymi domenami najwyższego poziomu zarządzonymi przez SRI-NIC, jest utrzymywana przez siedem
nadmiarowych serwerów nazw. Te serwery korzenia rozproszone są wśród głównych rozległych sieci
szkieletowych Internetu. Są również nadmiarowane, z tym, że trzy są systemami TOPS-20 używającymi
JEEVES a cztery to systemy UNIX używające BIND.
Typowy ruch na każdym serwerze korzenia odbywa się w kolejności pytań na sekundę, z odpowiednio
wyższymi współczynnikami, kiedy inne serwery korzenia są niedostępne. Kiedy szeroki trend dotyczący tempa
zapytań jest generalnie rosnący, codzienne i miesięczne porównania ładunku są powodowane bardziej przez
zmiany w algorytmach implementacji i przerwy w nastawianiu odbiornika, niż przez wzrost w populacji
klientów. Na przykład, jedna zła wersja popularnego oprogramowania domeny doprowadziła średnio do ponad
pięciokrotnego wzrostu ładunku dla rozszerzonych okresów. Obecnie, ocenia się, że 50% całego ruchu na
serwerach korzenia mogłoby zostać wyeliminowane przez poprawy w różnych implementacjach klientów DNS
tak, aby używać mniej agresywnej retransmisji i lepszego buforowania podręcznego.
Liczba klientów, którzy uzyskują dostęp do serwerów korzenia może być oszacowana bazując na
narzędziach pomiarowych wersji TOPS-20. Te serwery korzenia przechowują ścieżkę pierwszych 200 klientów
po inicjalizacji serwera korzenia i pierwszych 200 klientów typowo realizujących 90% albo więcej wszystkich
pytań w jakimś pojedynczym serwerze. Skoordynowane pomiary w trzech serwerach korzenia TOPS-20 typowo
wykazują w przybliżeniu 350 różnych klientów przy 600 wejściach. Liczba klientów spada, gdy więcej
organizacji przyjmie strategie, które koncentrują zapytania i buforowanie podręczne dla dostępu na zewnątrz
lokalnej organizacji.
Klienci wydają się używać statycznych priorytetów w celu wybierania z którego serwera korzenia
korzystać. Niepowodzenie w wyborze danego serwera powoduje natychmiastowy wzrost ruchu na innych
serwerach. Ogromną większość zapytań stanowią cztery typy: wszystkie informacje (25 do 40%), odwzorowanie
nazw hostów na adresy (30 – 40%), odwzorowanie adresów na nazwy hosta (10 do 15%) i nowy styl informacji
poczty elektronicznej zwany MX (mniej niż 10%). Liczby te różnią się znacznie, gdy nowe dystrybucje
oprogramowania są rozpowszechniane. Serwery korzenia odsyłają 10 – 15% z wszelkich pytań do serwerów na
niższych poziomach domen.
3.2. Berkeley
Wsparcie UNIX dla DNS zostało dostarczone przez Uniwersytet Kalifornijski, Berkeley, częściowo
jako badania w systemach rozproszonych, a częściowo z konieczności w związku z rozbudową sieci
kampusowej [Dunlap 86a, Dunlap 86b]. Skutkiem jest serwer Berkeley Internet Domain Name (BIND).
Berkeley służy jako przykład dużej wydelegowanej domeny, chociaż jest na pewno bardziej wyrafinowany i ma
więcej doświadczenia niż większość.
Z BIND-em, Berkeley stał się pierwszą organizacją Internetu DARPA, przynoszącą komputery z
wszystkimi ich aplikacjami sieciowymi wyłącznie zależnymi od DNS dla rozwiązywania nazw hostów sieci
adresów. Berkeley zaczął instalować komputery zależne od serwera nazw na miasteczku studenckim wiosną
1985. Jesienią 1985, dwie pocztowe bramy do Internetu DARPA zostały skonwertowane do zależnych od DNS,
to oznaczało, że całe miasteczko uniwersyteckie musiało przyjąć domenowy styl adresów poczty.
Kształcenie wyrafinowanej społeczności użytkowników Berkeley w nowej formie adresowania okazało
się głównym zadaniem. Największy sprzeciw ze strony społeczności użytkowników był spowodowany przez
adresy poczty e-mail, które stały się przestarzałe. Dodatkowo brakowało skrótów i zasad przeszukiwania w
początkowej implementacji.
Chociaż przejście na system DNS było żmudne, zapotrzebowanie było oczywiste, jak pokazano w
tabeli, która podaje liczbę hostów, podsieci i ostatecznie poddomen będących w użyciu w Berkeley przez
ostatnie trzy lata. Na przykład od stycznia 1986 do lutego 1987 Berkeley dodał 735 hostów w 250 dni
roboczych, średno trzy nowe hosty każdego dnia roboczego.
Data
Hosty
Podsieci
Poddomeny
Styczeń 1986
267
14
Luty 1987
1002
44
Marzec 1988
1991
86
5
Należy zauważyć, że Berkeley ostatnio podzielił swą domenę na wielokrotne strefy w celu
wygodniejszej administracji.
4. Niespodzianki
Działanie DNS ujawniło kilka spraw, które wydały się początkowo zaskoczeniem dla inwestorów, ale po
zastanowieniu nie wydają się aż tak zaskakujące.
4.1. Udoskonalenie semantyki
Główną rolą DNS jest występowanie jako składnicy informacji a początkowym założeniem było to,
żeby forma i zawartość tej informacji były dobrze zrozumiane. To okazało się złym założeniem. Nawet
istniejące powszechne pojęcia takie jak adres IP hosta były źródłem problemów; było oczywiste, że trzeba
będzie utrzymać wielokrotne adresowania dla pojedynczego hosta, ale wywiązały się długotrwałe dyskusje, czy
adresy przydzielone dla nazwy hosta powinny zostać uporządkowane i jeśli tak, to w jaki sposób.
4.2. Osiągi
Osiągi podstawowych sieci były gorsze niż projekt oryginalnie zakładał. Wzrost liczby sieci nadwerężał
mechanizmy bramy służace do podtrzymywania łączności, doprowadzając do gubienia ścieżek dostępu i
jednokierunkowych ścieżek dostępu. Równocześnie, wzrost obciążenia oraz dodanie wielu wolniejszych
połączeń doprowadziło do dłuższych opóźnień. Te problemy były widoczne w serwerach korzenia, gdzie
dzienniki (pliki log, pliki przedstawiające historie połączeń) ujawniają w wielu wypadkach powtórzenie kopii
tego samego zapytania z tego samego źródła. Chociaż serwery korzenia TOPS-20 potrzebują mniej niż 100
milisekund, by przetworzyć zdecydowaną większość pytań, klienci typowo widzą czasy odpowiedzi od 500
milisekund do 5 sekund, nawet dla bliższego serwera korzenia, w zależności od ich położenia w Internecie.
Sytuacja dla zapytań do wydelegowanych domen jest często dużo gorsza, zarówno z powodu kłopotów w sieci,
jak również ponieważ serwery nazw dla tych domen są często w dużym stopniu obciążone przez hosty na mniej
scentralizowanych sieciach. Zapytania od ARPANET do domen delegowanych typowo zajmują od 3 do 10
sekund podczas czasu największego obciążenia sieci oraz sporadycznie od 30 do 60 sekund w najgorszych
przypadkach. Interesującym spostrzeżeniem, jest to, że czasy dostępu do odległego serwera nazw są podobne do
tych zaobserwowanych dla jednorodnej usługi nazewniczej XEROX-a [Larson 85].
Dodatkowym zaskoczeniem okazały się trudności w robieniu rozsądnych pomiarów osiągów DNS.
Zaplanowaliśmy zmierzyć osiągi kolejnych elementów DNS, by ocenić koszty przyszłych poprawek i aby
kierować nastawianiem istniejących przedziałów retransmisji, ale pomiary często były zaburzone przez
niezwiązane zjawiska z powodu zmiany bramy, nowej wersji oprogramowania DNS itp. Dużo serwerów wypada
lepiej, gdy ich obciążenie wzrasta z powodu rzadszych błędów strony, ale wyraźnie nie jest to trwała sytuacja
przez dłuższy okres czasu, prowadząca do obaw o poprawę osiągów sieci i istnienie możliwości zwiększenia
obciążenia dla serwerów.
Osiągi wyszukiwania odpowiedzi dla zapytań, które nie potrzebowały dostępu do sieci był miłym
zaskoczeniem. Zastępowaliśmy dość prostą tabelę wyszukiwania hostów bardziej skomplikowaną bazą danych,
więc nawet, jeżeli pamięć podręczna pracowała bardzo dobrze, to mogliśmy znacznie spowalniać istniejące
aplikacje. Jednakże nowe mechanizmy typowo są tak dobre albo nawet lepsze od starych, niezależnie od
implementacji. Powodem tego jest to, że stare mechanizmy zostały utworzone dla dużo mniejszej bazy danych i
nie były dostosowywane do rozmiaru gwałtownie powiększającej się bazy danych, podczas gdy nowe
oprogramowanie zostało oparte na założeniu bardzo dużej bazy danych.
4.3. Buforowanie negatywnych odpowiedzi
DNS dostarcza dwóch typów przeczących odpowiedzi na pytania. Jedno określa, że nazwa z zapytania
nie istnieje. Drugie natomiast oznacza, że mimo że nazwa w zapytaniu istnieje, to wymagane dane nie są
dostępne. Pierwszy typ może wystąpić, gdy nazwa została błędnie napisana, natomiast drugi może być
rezultatem tego, że zapytanie dotyczyło rodzaju skrzynki poczty elektronicznej hosta albo członów listy
adresowej hosta. Takie odpowiedzi występują rzadko.
Początkowe monitorowanie aktywności serwera korzenia pokazało bardzo wysoki udział (20 do 60%)
takich odpowiedzi. Pliki dzienników ujawniły, że wiele z tych pytań zostało wygenerowanych przez programy
używające nazwy hosta w starym stylu, albo nazw innej poczty internetowej (np.: UUCP). W drugim przypadku,
oprogramowanie obsługujące przesyłanie poczty często użyłoby wywołania konwersji nazwy na adresy, aby
przetestować, czy adres obowiązywał w Internecie DARPA, chociaż można było to łatwo określić w inny
sposób. Skutkiem tego, że mało adresów pocztowych UUCP jest ważnymi nazwami domeny, była przecząca
odpowiedź od serwera korzenia, połączona z opóźnieniem dla nie-lokalnego zapytania.
Oczekiwaliśmy, że ilość przeczących odpowiedzi będzie się zmniejszać i że być może znikną,
ponieważ hosty skonwertowały ich nazwy do formatu nazwy domeny oraz gdyż poprosiliśmy osoby
odpowiedzialne za programy pocztowe, aby je zmodyfikowały. Mimo że kroki te zostały podjęte, negatywne
odpowiedzi pozostały w zakresie 10 – 50% wszystkich, a typowo 25%.
Powodem jest to, że środki poprawy zostały wyrównane przez rozpowszechnianie się programów, które
dostarczyły skrótowych nazw przez mechanizm przeszukiwania listy. Przeszukiwane listy produkują pewną
serię złych nazw przy sprawdzaniu różnych wariantów; błędnie wpisana nazwa może teraz doprowadzić do kilku
błędnych nazw zamiast jednej. Naszym zdaniem jakikolwiek system nazw, który polega na buforowaniu, dla
osiągów mógłby potrzebować także buforowania dla negatywnych odpowiedzi. Taki mechanizm został dodany
do DNS jako opcja, z imponującym wzrostem osiągów w przypadkach, gdy opcja ta to jest wspierana zarówno
w wymagających serwerach nazw jak i klientach DNS. Ta opcja prawdopodobnie stanie się standardem w
przyszłości.
5. Sukcesy
5.1. Zmienna hierarchia głębokości
Hierarchia o zmiennej głębokości jest często używana z kilku powodów:
• Rozprzestrzenianie się stacji roboczych i technologii sieci lokalnych oznaczało, że organizacje
uczestniczące w Internecie potrzebowały się wewnętrznie zorganizować.
• Organizacje znacznie różniły się rozmiarem i stąd potrzebowały różnej liczby poziomów
organizacyjnych. Na przykład, zarówno duże międzynarodowe przedsiębiorstwa jak i małe
początkujące rejestrowane są w systemie domeny.
• Zmienna hierarchia głębokości daje możliwość, aby enkapsułować jakiś stały, bądź zmienny
poziom systemu. Na przykład, własna usługa nazewnicza w Wielkiej Brytanii (NRS) i DNS
nawzajem kapsułują przestrzeń nazw. Ten schemat może też zostać użyty w przyszłości, by
współdziałać z usługą zgodną z rozwojem ISO i CCITT.
Wiele sieci, które nie używają protokołów DNS i typów danych standaryzowało adresowanie poczty
elektronicznej na DNS-owej hierarchicznej składni nazw [Quarterman 86].
5.2. Organizacyjne budowanie nazw
Chociaż szczególna organizacyjna struktura najwyższego poziomu używana przez obecny system DNS
jest dość kontrowersyjna, zasada, że nazwy są niezależne od sieci, topologii, etc. jest całkiem popularna.
Przyszła struktura najwyższych poziomów prawdopodobnie, będzie podlegać debacie. Większość propozycji
przynosi równowagę pomiędzy poparciem i sprzeciwem. W opinii autorów, jedyną prawdziwą możliwość dla
masowej zmiany stwarza polityczna decyzja, by zmienić strukturę przestrzeni nazwy domeny, tak by była
podobna do przestrzeni nazw proponowanej przez katalogową usługę ISO / CCITT. To nie jest techniczna
kwestia ponieważ DNS jest wystarczająco elastyczny, by przystosować się do prawie każdego politycznego
wyboru.
5.3. Dostęp datagramowy
Użycie datagramów jako preferowanej metody uzyskiwania dostępu do serwerów nazw było pomyślne
i prawdopodobnie istotne, zważywszy na niespodziewane złe osiągi Internetu DARPA. Ograniczenie do około
512 bajtów danych okazuje się nie być problemem, szybkość jest o wiele lepsza niż osiągnięta przez obwody
TCP, poza tym zasoby OS nie są zajęte.
Jedyną oczywistą wadą dostępu datagramowego jest potrzeba, by rozwinąć i udoskonalić strategie
retransmisji, które są już bardzo dobrze rozwinięte dla TCP. Dużo zbędnego ruchu jest generowane przez
klientów, którzy zostali rozwinięci do punktu roboczego, ale których autorzy stracili zainteresowanie przed
dostrojeniem, albo przez systemy, które importowały dobrze znane wersje kodu programu, ale nie śledziły
aktualizacji dostrajania.
5.4. Dodatkowe przetwarzanie segmentu
Kiedy serwer nazw odpowiada na zapytanie, dodatkowo do dowolnej informacji użytej, by
odpowiedzieć na pytanie, może dołączyć do odpowiedzi dowolną informację, która według niego pasuje, o ile
dane mieszczą się w pojedynczym datagramie. Ideą było pozwolić odpowiadającym serwerom przewidzieć
następną logiczną prośbę i odpowiedzieć na nią, zanim zostało zadane pytanie, bez znaczącego wzrostu kosztu
transmisji. Na przykład, kiedykolwiek serwery korzenia zwracają nazwę hosta, dołączają jego adres (jeśli jest
dostępny), zakładając, że adres hosta będzie potrzebny, do uzyskania innej informacji. Eksperymenty pokazują,
że ta cecha zmniejszy ruch zapytań o połowę.
5.5. Buforowanie
Dziedzina buforowania DNS pracuje dobrze i zważywszy na niespodziewane złe osiągi Internetu, była
niezbędna dla sukcesu systemu.
Jedyne problemy z buforowaniem wiążą się z bazami danych i strategiami zapytań, które powodują, że
jest ono mniej wiarygodne lub użyteczne. Na przykład, RR-y tego samego typu w danym (konkretnym) węźle
powinny mieć ten sam TTL, żeby przerwy były równoczesne, ale administratorzy czasami przydzielają TTL
popełniając błąd. Uważają, że wyznaczają jakiś rodzaj priorytetu. Administratorzy również bardzo często
wybierają krótkie TTLs, żeby ich zmiany odnosiły skutek szybko, nawet, jeśli są bardzo rzadkie i nie potrzebują
punktualności.
Podobnym zmartwieniem jest bezpieczeństwo i problem niezawodności spowodowany przez nie dające
się rozróżnić buforowanie. Kilka istniejących klientów DNS nierozsądnie buforuje całą informację odpowiedzi.
To skończyło się licznymi przypadkami, kiedy błędna informacja krążyła i powodowała problemy. Podobne
trudności napotykano, kiedy jeden administrator odwrócił TTL i wartości danych, wskutek czego
rozpowszechniano złe dane z kilkuletnim TTL. Pomimo że, zredukowano podatność na błędy różnymi środkami,
bezpieczeństwo aktualnego systemu zależy od integralności mechanizmów adresowania sieci, co i tak jest
niepewne w erze PC-ów i sieci lokalnych.
5.6. Współdziałanie
z adresem pocztowym
Porozumienie pomiędzy reprezentantami CSNET, BITNET, UUCP i społecznością Internetu DARPA
doprowadziła do porozumienia, by użyć organizacyjnie ukształtowanych nazw domeny do adresowania poczty
elektronicznej i routingu. Mimo że, przejście od nieeleganckiego, wielokrotnie kodowanego adresowania poczty
w przeszłości, jest dalekie od ukończenia, możliwość porządkowania adresów pocztowych wyraźnie została
zademonstrowana.
6. Mankamenty
6.1. Typ i wzrost klasy
Kiedy szkic specyfikacji DNS został udostępniony w 1983, prawie jednomyślnie skrytykowano to, że
typ i elementy opisujące dane klasy, które były 8 bitowe w projekcie, powinny zostać rozwinięty do 16, albo
nawet 32 bitów, by pozwolić na nowe definicje. Przez pierwsze pięć lat użycia DNS, dwa nowe typy zostały
zaadoptowane, dwa typy zostały odrzucone i przydzielono dwie nowe klasy. Wyraźnie albo wymagania dla
nowych typów i klas zostały zupełnie źle zrozumiane, albo bieżący DNS powoduje, że nowe definicje są zbyt
trudne.
Podczas gdy jednym problemem jest to, że prawie całe istniejące oprogramowanie traktuje typy i klasy
jako stałe uzyskiwane podczas kompilacji, dlatego wymaga ponownej kompilacja by uwzględnić zmiany.
Trudniejszym problemem jest to, że nowe typy danych i klas są bezużyteczne dopóki ich semantyki nie zostaną
starannie zaprojektowane i opublikowane, aplikacje nie zostaną stworzone do ich użycia i konsensus nie będzie
osiągnięty, by użyć nowego systemu w Internecie. To oznacza, że nowe typy stają przed szeregiem technicznych
i politycznych przeszkód.
Potrzebne są wskazówki oraz metodologia, które mogą pomóc w projektowaniu nowych typów
informacji. Jest to bardziej skomplikowane niż tylko uzyskanie wartości potrzebnych aplikacji, ponieważ często
wymagało to projektowania specjalnych segmentów przestrzeni nazw, operacji wyboru TTL, by uzyskać
zadowalające osiągi i semantykę, i decyzji, czy wyprodukować pożądane powiązanie przez jedno odszukanie
albo ciąg mniejszych powiązań. Metoda pojedyncza odszukania często wydaje się niezwykle atrakcyjna dla
projektanta danej aplikacji pomijając fakt, że to może spowodować nakładanie się albo kolidować z danymi
innej aplikacji. Innym czynnikiem jest to, że członkowie Internetu mają różniące się spojrzenie na odpowiednie
założenia albo podejście do poszczególnych problemów. Przykładem jest poczta elektroniczna. Po długiej
debacie, typ danych MX i system [RFC 974] zdefiniowały znormalizowaną metodę dla routingu poczty, opartej
na części DOMENY albo LOCAL-PART@DOMAIN adresie pocztowym. MX reprezentował proste
uzupełnienie do samego DNS-u, ale wymagał zmian we wszystkich serwerach poczty i jego korzyści wymagały
definitywnej zmiany oprogramowania obsługującego przesyłanie poczty. Pojawiły się liczne sugestie, by
rozszerzyć DNS w celu dostarczenia rejestru przeznaczenia poczty do poziomu indywidualnego użytkownika.
Podstawy takiej usługi są w zakresie naszego zrozumienia, ale konsensus dla pojedynczego planu pozostaje
nieosiągnięty. Część zainteresowanych wymaga, by powiązanie na poziomie poczty użytkownika było opcją
ponad MX, podczas gdy inni popierają świeże uruchomienie, z dużymi możliwościami przesyłania poczty,
utrzymania listy, itp. Najlepszym wyborem wydaje się być ten, w którym powiązanie agenta jest zawsze opcją
do wyboru, oprogramowanie obsługujące przesyłanie poczty, które decyduje się dostosować do poziomu
skrzynki pocztowej może tak postąpić, jeśli dane skrzynki pocztowej są również dostępne.
6.2. Łatwe ulepszanie aplikacji
Konwersja aplikacji sieciowych do użycia DNS-u nie jest prostym zadaniem. Idealnie byłoby, gdyby
wszystkie aplikacje konwertowane z HOSTS.TXT mogły zostać przekompilowane ponownie do użycia DNS i
zachowały wszystkie uprawnienia, ale jest to rzadkim przypadkiem.
Część problemu stanowią chwilowe uszkodzenia. Rozproszony system nazywania, z natury rzeczy ma
okresy, w których nie może uzyskać dostępu do szczególnej informacji. Aplikacje muszą odpowiednio
rozwiązywać ten problem. Oprogramowanie obsługujące przesyłanie poczty sprawdzające (wyszukujące) punkty
przeznaczenia poczty nie powinny odrzucać poczty z powodu tych chwilowych uszkodzeń, ale nie mogą też
pozwolić sobie na czekanie bez końca. Nawet, jeśli takie uszkodzenia są przewidziane jako całkiem rzadkie,
kiedy DNS się ustabilizuje, stajemy wobec problemu „kury i jajka” w konwersji oprogramowania obsługującego
przesyłania poczty, by użyć nowego oprogramowania.
Inną częścią problemu jest to, że dostęp do systemu nazywającego powinien być włączony do systemu
operacyjnego w znacznie większym stopniu, niż dostarczanie wywołania systemowego dla klienta DNS.
Użytkownicy potrzebują mieć możliwość uzyskania dostępu do tej usługi na z poziomu konsoli i określić listy
przeszukiwania i wartości domyślne w sposobie zgodnym z innymi systemami operacyjnymi.
6.3. Rozpowszechnienie kontroli w przeciwieństwie do
rozpowszechnienia wiedzy specjalistycznej albo odpowiedzialności
Grupa odpowiedzialna za administracje domen DNS udostępniająca bazy danych nie rozprowadza
odpowiadającej ilości wiedzy specjalistycznej. Serwisanci naprawiają urządzenia dopóki te działają, a nie póki
działają dobrze. Chcą używać dostarczonych im systemów nie rozumiejąc ich działania. Projektanci systemów
powinni przewidzieć to i spróbować skompensować w sposób techniczny. DNS dostarcza kilka przykładowych
zasady:
• Początkowa polityka polegała na autoryzacji domeny każdej organizacji, która wypełniła
formularz przedstawiający jej nadmiarowe serwery i inne niezbędne urządzenia. Zamiast
tego należy wymagać, żeby organizacja zademonstrowała nadmiarowe serwery z
prawdziwymi danymi w nich zawartymi zanim domena zostanie wydelegowana
i prawdopodobnie należy nalegać, aby serwery te były w różnych sieciach i nie ufać
zapewnieniom, że serwery nie ulegały żadnym uszkodzeniom.
• Dokumentacja dla systemu używała przykładów, które łatwo zostały wyjaśnione w
narracji. Przykładowe wartości TTL, które odpowiadały godzinie zawsze były kopiowane;
tekst, który mówił, że wartości te powinny być kilkudniowe został zignorowany.
Dokumentacja zawsze powinna być pisana z założeniem, że tylko przykłady będą czytane.
• Debugowanie systemu zostało utrudnione przez pytania o wersje oprogramowania i
parametry. Te wartości powinny być dostępne przez protokół.
_
7. Wnioski
Pytanie brzmiące: „Czy DNS był dobrym pomysłem?” może być przedmiotem dyskusji opartej na
poglądach czytelnika, podobnie jak klasyfikacja wielu poprzednich kwestii na punkty: „sukcesy”, „zaskoczenia ”
i „wady ”.
Modyfikacje schematu HOST.TXT mogłyby odłożyć potrzebę nowego systemu i zmniejszyły ilościowe
argumenty dla DNS. DNS prawdopodobnie nie zmniejszyło jeszcze szerokiej społecznie, administracyjnej
komunikacji czy też ładunku informacji. Jednakże potrzeba, by rozdzielić funkcjonalność, była według nas
nieuchronna. Ta potrzeba, razem z nową funkcjonalnością i możliwościami dla przyszłych usług muszą być
kluczowym kryterium oceny, z perspektywy autorów, którzy uzasadniają DNS.
Jest wiele decyzji, które moglibyśmy podjąć w odmienny sposób, gdybyśmy zaczynali od początku.
Głównymi radami, jakie byłyby wartościowe gdybyśmy zaczynali są:
• Buforowanie może działać w różnorodnym środowisku, ale powinno także zawierać
możliwość przechowywania (cachowania) przeczących odpowiedzi.
• Często trudniej jest usuwać funkcje z systemów niż dodawać nowe. Cała społeczność nie
przystosowałaby się do nowej usługi; zamiast tego część pozostałaby przy starej usłudze, część
zmieniła ją na nową, a pozostała część korzystałaby z obu rozwiązań. To ma niefortunny efekt
komplikowania wszystkich funkcji w czasie dodawania nowych możliwości do systemu.
• Najzdolniejsi programiści tracą zainteresowanie, gdy tylko nowy system dostarcza osiągów na
poziomie, którego oni oczekują; nie łatwo ich zmotywować, by zoptymalizowali użycie innych
zasobów albo dostarczyli łatwych w użyciu wskazówek dla administratorów, którzy używają
tych systemów. Rozprowadzone oprogramowanie powinno zawierać numer wersji i tabele
parametrów, które mogą zostać odczytane. Jeśli jest to możliwe, systemy powinny zawierać
techniczny sposób dla przekazania parametrów dostrajania, albo przynajmniej wartości
domyślne dla wszystkich instalacji bez ingerencji administratorów systemu.
• Zezwolenie na zmiany w strukturze implementacji użyte w celu dostarczenia usługi okazały się
bardzo dobrym pomysłem; Natomiast zezwolenie na zmiany w dostarczanej usłudze powoduj
problemy.
_
_"
_
8. Kierunki dalszych prac
Chociaż DNS jest w produkcyjnym użyciu i w związku z tym trudno w nim wprowadzić zmiany, inne
badania nad systemami nazywania, szczególnie pojawiający się ISO X. 500 usług katalogowych, może
dostarczyć dodatkowych bodźców.
Obsługa stylu adresów poczty dla X. 500, itp. mogłaby zostać zbudowana jako dodatkowa
warstwa nad DNS, aczkolwiek bez skomplikowanej ochrony, aktualizacji, i reguł budowania X. 500.
Użycie technik opisu danych ze standardów ISO mogłoby dostarczyć lepszego mechanizmu dodawania
typów danych niż aktualne reguły konstrukcji danych, podczas gdy udowodniona infrastruktura DNS
mogłaby przyspieszać modelowanie aplikacji ISO.
Wartość wszechobecnej usługi nazewniczej i zwartej przestrzeni nazw na wszystkich
poziomach protokołu i systemu operacyjnego wydaje się oczywista, ale jest jednakowo oczywiste, że
kompromis pomiędzy osiągami, powszechnością i rozpowszechnieniem wymaga przynajmniej
różniących się stylów użycia na różnych poziomach. Na przykład, system odpowiedni dla zarządzania
nazwami plików na miejscowym dysku różniłby się znacznie od systemu utrzymującego szeroką listę emailową w Internecie. Wyzwaniem jest rozwinięcie podejścia, które, przynajmniej pojęciowo, rozbije
całkowite zadania na warstwy albo przedstawi je w innej spójnej organizacji. Badania w systemach
nazywania typowo zakończyły się propozycjami dla systemów, które mogłyby zastąpić albo zawierać w
sobie wszystkie inne systemy, albo systemy, które pozwalają na tłumaczenie pomiędzy rozłącznymi
przestrzeniami nazw, a formatami danych, itp. Obie propozycje mają zarówno zalety jak i wady.
Aktualny DNS i próby, by ujednolicić jego przestrzeń nazw bez specjalnych domen dla
sprecyzowanych sieci, etc. umieszcza DNS w pierwszej kategorii. Jednakże, jego sukces jest
wystarczająco uniwersalny, by być zachęcającym, podczas gdy nie jest wystarczający by rozwiązać
trudności użytkownika związane z niejasnym kodowaniem innych systemów. Techniczne i/lub
polityczne rozwiązania dla wzrastającej złożoności nazewnictwa będą coraz bardziej potrzebne.
Wprowadzenie............................................................................................................................ 1
1. Wstęp.................................................................................................................................. 1
2. DNS Design........................................................................................................................ 2
2.1. Architektura..................................................................................................................... 2
2.2. Przestrzeń nazw............................................................................................................... 2
2.3. Powiązanie danych z nazwami........................................................................................ 3
2.4. Dystrybucja bazy danych ................................................................................................ 4
3. Aktualny stan implementacji.............................................................................................. 5
3.1. Serwery korzenia............................................................................................................. 5
3.2. Berkeley .......................................................................................................................... 6
4. Niespodzianki..................................................................................................................... 6
4.1. Udoskonalenie semantyki ............................................................................................... 6
4.2. Osiągi .............................................................................................................................. 6
4.3. Buforowanie negatywnych odpowiedzi .......................................................................... 7
5. Sukcesy............................................................................................................................... 7
5.1. Zmienna hierarchia głębokości................................................................................................ 7
5.2. Organizacyjne budowanie nazw...................................................................................... 8
5.3. Dostęp datagramowy....................................................................................................... 8
5.4. Dodatkowe przetwarzanie segmentu............................................................................... 8
5.5. Buforowanie .................................................................................................................... 8
5.6. Współdziałanie z adresem pocztowym ..................................................................................... 8
6. Mankamenty....................................................................................................................... 9
6.2. Łatwe ulepszanie aplikacji .............................................................................................. 9
6.3. Rozpowszechnienie kontroli w przeciwieństwie do rozpowszechnienia wiedzy
specjalistycznej albo odpowiedzialności................................................................................ 9
7. Wnioski ................................................................................................................................ 10
8. Kierunki dalszych prac......................................................................................................... 10