Architektura DNS w systemie Windows Server

DNS to hierarchiczna rozproszona baza danych i skojarzony zestaw protokołów, które definiują:

• Mechanizm wykonywania zapytań i aktualizowania bazy danych

• Mechanizm replikowania informacji w bazie danych między serwerami

• Schemat bazy danych

Nazwy hostów DNS znajdują się w bazie danych, która może być dystrybuowana między wieloma serwerami, zmniejszając obciążenie jednego serwera i zapewniając możliwość administrowania tym systemem nazewnictwa na podstawie partycji. System DNS obsługuje nazwy hierarchiczne i umożliwia rejestrację różnych typów danych oprócz mapowania nazw na adresy IP używanego przez hosta w plikach HOSTS. Baza danych DNS jest dystrybuowana, co pozwala na skalowanie w górę i w poziomie, co oznacza, że wydajność nie jest obniżona po dodaniu większej liczby serwerów.

Oryginalny system DNS został oparty na żądaniu komentarza (RFC) 1035 (nazwy domen — implementacja i specyfikacja). Inne RFC opisują zabezpieczenia DNS, implementację i problemy administracyjne, które później rozszerzyły oryginalne specyfikacje projektowe.

RFC używane w systemach operacyjnych Windows Server to:

• Nazwy domen — pojęcia i obiekty RFC 1034
• Nazwy domen — implementacja i specyfikacja RFC 1035
• Rozszerzenia DNS do obsługi adresu IP w wersji 6 RFC 1886
• Mechanizm szybkiego powiadamiania o zmianach strefy (DNS NOTIFY) RFC 1996
• Przyrostowy transfer strefy w systemie DNS RFC 1995
• Aktualizacje dynamiczne w systemie nazw domen (DNS UPDATE)RFC 2136
• Negatywne buforowanie zapytań DNS (DNS NCACHE) RFC 2308
• Rekordy zasobów dla rozszerzeń zabezpieczeń DNS RFC 4034
• Modyfikacje protokołu dla rozszerzeń zabezpieczeń DNS RFC 4035
• RR DNS do określania lokalizacji usług (DNS SRV) RFC 2052

Nazwy domen DNS

System DNS jest implementowany jako hierarchiczna i rozproszona baza danych zawierająca różne typy danych, w tym nazwy hostów i nazwy domen. Nazwy w bazie danych DNS tworzą hierarchiczną strukturę drzewa o nazwie przestrzeń nazw domeny. Nazwy domen składają się z pojedynczych etykiet rozdzielonych kropkami, na przykład: mydomain.contoso.com.

W pełni kwalifikowana nazwa domeny (FQDN) jednoznacznie identyfikuje pozycję hosta w drzewie hierarchicznym DNS. FQDN określa listę nazw oddzielonych kropkami w ścieżce od hosta do korzenia. Na poniższej ilustracji przedstawiono przykład drzewa DNS z hostem o nazwie mydomain w domenie contoso.com. Nazwa FQDN hosta będzie mydomain.contoso.com.

Opis przestrzeni nazw domeny DNS

Przestrzeń nazw domeny DNS, jak pokazano na powyższym rysunku, opiera się na koncepcji drzewa nazwanych domen. Każdy poziom drzewa może reprezentować gałąź lub liść. Gałąź to poziom, na którym jest używana więcej niż jedna nazwa do identyfikowania kolekcji nazwanych zasobów. Liść reprezentuje pojedynczą nazwę używaną raz na tym poziomie, aby wskazać określony zasób.

Hierarchia nazw domen DNS

Klienci i serwery DNS używają zapytań jako metody rozpoznawania nazw w drzewie do określonych typów informacji o zasobach. Te informacje są udostępniane przez serwery DNS w odpowiedziach zapytań do klientów DNS, które następnie wyodrębniają informacje i przekazują je do programu żądającego w celu rozpoznawania żądanej nazwy. W procesie rozpoznawania nazwy serwery DNS często działają jako klienci DNS, odpytując inne serwery, aby w pełni rozpoznać nazwę kwerendy.

Na przykład firma Contoso ma przyznaną autoryzację przez główne serwery internetowe dla własnej części drzewa przestrzeni nazw domeny DNS w Internecie, czyli contoso.com. Rozpoznawanie nazwy poza przestrzenią nazw contoso.com wymaga, aby serwery DNS firmy Contoso wysyłały zapytania do innych serwerów DNS, takich jak serwery główne.

Jak jest zorganizowana przestrzeń nazw domeny DNS

Każda nazwa domeny DNS używana w drzewie jest technicznie domeną. Jednak większość dyskusji DNS identyfikuje nazwy na jeden z pięciu sposobów, na podstawie poziomu i sposobu, w jaki nazwa jest często używana. Na przykład nazwa domeny DNS zarejestrowana w firmie Contoso (contoso.com) jest znana jako domena drugiego poziomu. Nazwa składa się z dwóch części (nazywanych etykietami), które wskazują, że jest zlokalizowana dwa poziomy poniżej korzenia lub wierzchołka drzewa. Większość nazw domen DNS ma co najmniej dwie etykiety, z których każda wskazuje nowy poziom w drzewie. Kropki są używane w nazwach do oddzielania etykiet.

W poniższej tabeli opisano pięć kategorii nazw domen DNS według ich funkcji w przestrzeni nazw wraz z przykładem każdego typu nazwy.

Typ nazwy	Opis	Przykład
Domena główna	Wierzchołek drzewa, który reprezentuje nienazwany poziom; czasami jest on przedstawiany jako dwa puste cudzysłowy (""), wskazujące wartość zerową. W przypadku użycia w nazwie domeny DNS jest on określony przez końcowy okres (.), aby wyznaczyć, że nazwa znajduje się na poziomie głównym lub najwyższym w hierarchii domeny. W tym przypadku nazwa domeny DNS jest uważana za ukończoną i wskazuje dokładną lokalizację w drzewie nazw. Nazwy określone w ten sposób są nazwami FQDN. Pojedyncza kropka (.) lub kropka, która jest używana na końcu nazwy, na przykład example.contoso.com..	Pojedyncza kropka (.) lub kropka, która jest używana na końcu nazwy, na przykład example.contoso.com..
Domena najwyższego poziomu (TLD)	Nazwa używana do wskazywania kraju lub regionu lub typu organizacji przy użyciu nazwy.	.com, która wskazuje nazwę zarejestrowaną w firmie do użytku komercyjnego w Internecie.
Domena drugiego poziomu	Nazwy o zmiennej długości zarejestrowane dla osoby fizycznej lub organizacji do użytku w Internecie. Te nazwy są zawsze oparte na odpowiedniej domenie najwyższego poziomu, w zależności od typu organizacji lub lokalizacji geograficznej, w której jest używana nazwa.	contoso.com. jest nazwą domeny drugiego poziomu zarejestrowaną w firmie Contoso przez rejestratora nazw domen DNS w Internecie.
Poddomena	Inne nazwy, które organizacja może utworzyć, pochodzą z zarejestrowanej nazwy domeny drugiego poziomu. Poddomeny obejmują nazwy dodane w celu zwiększenia drzewa DNS nazw w organizacji i podzielenia ich na działy lub lokalizacje geograficzne.	example.contoso.com. jest poddomeną przypisaną przez firmę Contoso do użycia w przykładowych nazwach dokumentacji.
Nazwa hosta lub zasobu	Nazwy reprezentujące liść w drzewie DNS nazw i identyfikujące określony zasób. Zazwyczaj lewa etykieta nazwy domeny DNS identyfikuje określony komputer w sieci. Jeśli na przykład nazwa na tym poziomie jest używana w rekordzie zasobu hosta (A), służy do wyszukiwania adresu IP komputera na podstawie nazwy hosta.	host-a.example.contoso.com. Pierwsza etykieta (host-a) to nazwa hosta DNS dla określonego komputera w sieci.

Domeny internetowe i DNS

Internetowe urzędy rejestracji zarządzają systemem nazw domen. Władze rejestracyjne są odpowiedzialne za utrzymywanie domen najwyższego poziomu przypisanych przez organizację i kraj/region. Te nazwy domen są zgodne z Międzynarodowym Standardem dla kodów krajów (ISO 3166). Istnieją setki nazw domen najwyższego poziomu dostępnych do użycia przez opinię publiczną. W poniższej tabeli przedstawiono kilka typowych tlD, a także przykład dwuliterowych skrótów używanych dla krajów i regionów.

Nazwa domeny DNS	Typ organizacji
.Com	Organizacje komercyjne
Domena .edu	Instytucje edukacyjne
.Org	Organizacje non-profit
.sieć	Sieci (szkielet Internetu)
.Gov	Organizacje rządowe nonmilitarne
Domena .mil	Organizacje rządowe wojskowe
.Arpa	Odwrotny system DNS
.Xx	Dwuliterowe kody kraju (na przykład .us, .au, .ca., .fr)

Rekordy zasobów DNS

Rekordy zasobów DNS zawierają informacje, które strefa przechowuje na temat zasobów (takich jak hosty), które zawiera strefa. Typowy rekord zasobu składa się z następujących elementów:

• Nazwa (host) rekordu zasobu.
• Informacje o tym, jak długo rekord zasobu może pozostać w pamięci podręcznej.
• Typ rekordu zasobu, taki jak rekord zasobu hosta (A).
• Dane specyficzne dla typu rekordu, takie jak adres IPv4 hostów.

Rekordy zasobów można dodawać bezpośrednio lub dodawać je automatycznie, gdy klienci z włączoną obsługą dynamicznej konfiguracji hosta (DHCP) z systemem Windows dołączają do sieci przy użyciu aktualizacji dynamicznej.

Typy rekordów zasobów

Typowe rekordy zasobów obejmują:

Typ rekordu zasobu	Opis
Rekordy hosta (A, AAAA)	Mapuje nazwę hosta na adres IP.
Rekordy aliasu (CNAME)	Przekieruj nazwę domeny aliasu lub poddomenę na inną nazwę podstawową lub kanoniczną. Rekordy zasobów aliasu (CNAME) są również nazywane rekordami nazw kanonicznych. Dzięki tym rekordom można użyć więcej niż jednej nazwy DNS, aby wskazać jednego hosta.
Rekordy programu Mail Exchanger (MX)	Określa nazwę komputera, który wymienia lub przekazuje pocztę dalej. Aplikacje poczty e-mail używają rekordu zasobu exchanger (MX), aby zlokalizować serwer poczty na podstawie nazwy domeny DNS w adresie docelowym adresata wiadomości e-mail. Jeśli istnieje wiele rekordów zasobów programu mail exchanger (MX), usługa klienta DNS próbuje skontaktować się z serwerami poczty w kolejności preferencji od najniższej wartości (najwyższy priorytet) do najwyższej wartości (najniższy priorytet).
Rekordy wskaźnika (PTR)	Używane przez wsteczne wyszukiwania DNS do przypisywania domen do adresów IP. Rekordy zasobów wskaźnika (PTR) obsługują proces wyszukiwania wstecznego na podstawie stref utworzonych i zakorzenionych w domenie in-addr.arpa. Musisz mieć odpowiednią strefę wyszukiwania wstecznego na serwerze DNS, aby utworzyć rekord PTR, który mapuje adres IP na określoną nazwę hosta.
Rekordy lokalizacji usługi (SRV)	Określa hosta, port i protokół dla usługi. Rekordy zasobów lokalizacji usługi (SRV) są wymagane, gdy klienci używają systemu DNS do lokalizowania usług lokalizacji, takich jak kontrolery domeny usługi Active Directory.
Rekordy serwera nazw (NS)	Określa autorytatywne serwery nazw dla domeny.
Rekord tekstowy (TXT)	Umożliwia publikację tekstu w rekordzie DNS. Rekordy tekstowe umożliwiają dodawanie informacji tekstowych zwracanych przez wykonywanie zapytań dotyczących systemu DNS. Rekordy TXT są często używane do uwierzytelniania własności stref DNS.
Rekord nazwy delegowania (DNAME)	Udostępnia alias dla domeny, taki jak rekord CNAME, ale zawiera wszystkie poddomeny.
Rekord startowy autorytetu (SOA)	Udostępnia autorytatywne informacje o strefie DNS. Rekord SOA zawiera serwer pierwotny, dane kontaktowe administratora strefy DNS, informacje o odświeżaniu i inne informacje.

Czas wygaśnięcia (TTL) dla rekordów zasobów

Wartość Czas wygaśnięcia (TTL) w rekordzie zasobu wskazuje czas używany przez inne serwery DNS, aby określić, jak długo należy buforować informacje o rekordzie przed wygaśnięciem i odrzuceniem go. Na przykład większość rekordów zasobów utworzonych przez usługę serwera DNS dziedziczy minimalny (domyślny) czas życia (TTL) wynoszący jedną godzinę z rekordu zasobu SOA, co uniemożliwia rozszerzone buforowanie przez inne serwery DNS.

Program rozpoznawania klienta DNS buforuje odpowiedzi odbierane podczas rozpoznawania zapytań DNS. Te buforowane odpowiedzi mogą następnie służyć do odpowiadania na późniejsze zapytania dotyczące tych samych informacji. Buforowane dane mają jednak ograniczony okres istnienia określony w parametrze TTL zwracanym z danymi odpowiedzi. TTL zapewnia, że serwer DNS nie przechowuje informacji tak długo, że staną się one nieaktualne. Czas życia (TTL) pamięci podręcznej można ustawić w bazie danych DNS (dla każdego indywidualnego rekordu zasobu, określając pole TTL rekordu i każdej strefy poprzez minimalne pole TTL rekordu SOA) oraz po stronie klienta rozpoznawania DNS, określając maksymalny TTL, który resolver pozwala przechowywać w pamięci podręcznej rekordy zasobów.

Podczas ustawiania TTL należy wziąć pod uwagę dwa konkurencyjne czynniki. Pierwsza to dokładność buforowanych informacji, a druga to wykorzystanie serwerów DNS i ilość ruchu sieciowego. Jeśli czas TTL jest krótki, prawdopodobieństwo posiadania starych informacji jest znacznie zmniejszone, ale zwiększa to wykorzystanie serwerów DNS i ruch sieciowy, ponieważ klient DNS musi wysyłać zapytania do serwerów DNS o wygasłe dane przy następnym żądaniu. Jeśli czas życia (TTL) jest długi, buforowane odpowiedzi mogą stać się nieaktualne, co oznacza, że resolver może udzielić fałszywych odpowiedzi na zapytania. Jednocześnie długi TTL zmniejsza wykorzystanie serwerów DNS i zmniejsza ruch sieciowy, ponieważ klient DNS, używając buforowanych danych, odpowiada na zapytania.

Jeśli na zapytanie zostanie odpowiedziane przy użyciu wpisu z pamięci podręcznej, czas wygaśnięcia wpisu jest również przekazywany z odpowiedzią. W ten sposób resolvery, które otrzymują odpowiedź, wiedzą, jak długo wpis jest ważny. Resolvery respektują TTL z serwera odpowiadającego; nie resetują go na podstawie własnego TTL. Wpisy naprawdę wygasają, zamiast żyć w nieskończoność, gdy przechodzą z serwera DNS do serwera DNS z aktualizowanym TTL.

Notatka

Ogólnie rzecz biorąc, nigdy nie ustawiaj wartości TTL na zero. Różnica między ustawieniem wartości 0 lub 60 jest minimalna, jeśli chodzi o dokładność rekordu, ale gdy TTL jest ustawiony na 0, istnieje znaczący wpływ na wydajność serwera DNS, ponieważ serwer DNS stale wykonuje zapytania z powodu wygaśnięcia danych.

Strefy i delegowanie

Bazę danych DNS można podzielić na wiele stref. Strefa jest częścią bazy danych DNS, która zawiera rekordy zasobów z nazwami właścicieli należącymi do ciągłej części przestrzeni nazw DNS. Pliki strefy są przechowywane na serwerach DNS. Pojedynczy serwer DNS można skonfigurować tak, aby hostować zero, jedną lub wiele stref.

Każda strefa jest zakotwiczona pod określoną nazwą domeny, nazywaną domeną główną strefy. Strefa zawiera informacje o wszystkich nazwach, które kończą się nazwą domeny głównej strefy. Serwer DNS jest uznawany za autorytatywny dla nazwy, jeśli ładuje strefę zawierającą tę nazwę. Pierwszym rekordem w dowolnym pliku strefy jest rekord zasobu typu Start of Authority (SOA). Rekord zasobu SOA identyfikuje podstawowy serwer nazw DNS dla strefy jako najlepsze źródło informacji dla danych w tej strefie. SOA działa również jako jednostka przetwarzająca aktualizacje strefy.

Nazwę w strefie można również delegować do innej strefy hostowanej na innym serwerze DNS. Delegowanie to proces przypisywania odpowiedzialności za część przestrzeni nazw DNS do serwera DNS należącego do oddzielnej jednostki. Ta oddzielna jednostka może być inną organizacją, działem lub grupą roboczą w firmie. Takie delegowanie jest reprezentowane przez rekord zasobu NS, który określa strefę delegowana i nazwę DNS serwera autorytatywne dla tej strefy. Delegowanie w wielu strefach było częścią oryginalnego projektu DNS.

Aby dowiedzieć się więcej o typach i replikacji stref DNS, zobacz Strefy DNS.

Powody delegowania przestrzeni nazw DNS obejmują:

• Należy delegować zarządzanie domeną DNS do wielu organizacji lub działów w organizacji.

• Aby zwiększyć wydajność rozpoznawania nazw, należy rozłożyć obciążenie obsługi jednej dużej bazy danych DNS między wiele serwerów DNS i utworzyć środowisko odporne na błędy DNS.

• Trzeba umożliwić przynależność hosta do organizacji poprzez uwzględnienie go w odpowiednich domenach. Rekordy zasobów serwera nazw (NS) ułatwiają delegowanie, identyfikując serwery DNS dla każdej strefy, a rekordy zasobów NS są wyświetlane we wszystkich strefach. Za każdym razem, gdy serwer DNS musi przejść przez delegację, aby rozpoznać nazwę, odwołuje się do rekordów zasobów NS serwerów DNS w strefie docelowej.

Na poniższej ilustracji przedstawiono sposób delegowania zarządzania domeną contoso.com w dwóch strefach, contoso.com i mydomain.contoso.com.

Notatka

Jeśli istnieje wiele rekordów NS dla strefy delegowanej identyfikującej wiele serwerów DNS dostępnych do wykonywania zapytań, usługa serwera DNS systemu Windows Server będzie mogła wybrać najbliższy serwer DNS na podstawie interwałów dwukierunkowych mierzonych w czasie dla każdego serwera DNS.

Architektura usługi DNS

Na poniższym diagramie przedstawiono architekturę usługi klienta DNS w operacjach rozpoznawania nazw i aktualizacji w kliencie systemu Windows i systemie Windows Server. Architektura rozpoznawania nazw jest przedstawiana przy użyciu aplikacji klienckiej, a aktualizacje są reprezentowane przez klienta DHCP.

Na poniższym diagramie przedstawiono architekturę usługi serwera DNS za pomocą narzędzi administracyjnych i interfejsu Instrumentacja zarządzania Windows (WMI) w systemie Windows Server.

W poniższych sekcjach opisano proces zapytań DNS i sposób obsługi aktualizacji DNS.

Zapytania DNS

Zapytania DNS można wysyłać z klienta DNS (resolvera) do serwera DNS lub między dwoma serwerami DNS.

Zapytanie DNS jest tylko żądaniem rekordów zasobów DNS określonego typu rekordu zasobu o określonej nazwie DNS. Na przykład zapytanie DNS może zażądać wszystkich rekordów zasobów typu A (hosta) o określonej nazwie DNS.

Istnieją dwa typy zapytań DNS, które można wysyłać do serwera DNS:

• Rekursywne: Rekursywne zapytanie wymusza, aby serwer DNS odpowiedział na żądanie odpowiedzią negatywną lub pozytywną. Klienci DNS (rozpoznawanie nazw) zwykle tworzą zapytania rekursywne. W przypadku zapytania cyklicznego serwer DNS musi skontaktować się z innymi serwerami DNS, które muszą rozwiązać ten problem. Gdy otrzyma pomyślną odpowiedź z innego serwera DNS (lub serwerów), wysyła odpowiedź na klienta DNS. Kwerenda rekurencyjna jest typowym typem zapytania, używanym przez resolver do zapytań względem serwera DNS oraz przez serwer DNS wysyłający zapytanie do jego forwardera, czyli innego serwera DNS skonfigurowanego do obsługi przekazywanych do niego żądań.

  Gdy serwer DNS przetwarza zapytanie cykliczne i nie można rozpoznać zapytania z danych lokalnych (plików strefy lokalnej lub pamięci podręcznej poprzednich zapytań), kwerenda cykliczna musi być eskalowana do głównego serwera DNS. Każda implementacja systemu DNS oparta na standardach zawiera plik pamięci podręcznej (lub wskazówki serwera głównego), który zawiera wpisy dla głównych serwerów DNS domen internetowych. (Jeśli serwer DNS jest skonfigurowany z usługą przesyłania dalej, usługa przesyłania dalej jest używana przed użyciem serwera głównego).

• Iteracyjne: zapytanie iteracyjne to zapytanie, w którym serwer DNS powinien odpowiadać używając najlepszych dostępnych informacji lokalnych, na podstawie tego, co serwer DNS wie z plików strefy lokalnej lub danych z buforowania. Ta odpowiedź jest również znana jako odwołanie, jeśli serwer DNS nie jest autorytatywny dla nazwy. Jeśli serwer DNS nie ma żadnych informacji lokalnych, które mogą odpowiedzieć na zapytanie, po prostu wysyła negatywną odpowiedź. Serwer DNS tworzy tego typu zapytanie, gdy próbuje znaleźć nazwy poza domeną lokalną (lub domenami) (jeśli nie jest skonfigurowany z usługą przesyłania dalej). Może być konieczne wykonywanie zapytań poza serwerami DNS w celu rozpoznania nazwy.

Na poniższej ilustracji przedstawiono przykład obu typów zapytań.

Na diagramie pokazano, jak wiele zapytań zostało użytych do określenia adresu IP dla www.contoso.com. Sekwencja zapytań jest opisana w następujący sposób:

1. Rekursywne zapytanie dla www.contoso.com (rekord zasobu A).

2. Zapytanie iteracyjne dla www.contoso.com (rekord zasobu A).

3. Odwołanie do serwera nazw .com (rekordy zasobów NS dla .com); dla uproszczenia pominięto iteracyjne zapytania typu A wykonywane przez serwer DNS w celu rozpoznania adresów IP nazw hostów, które zostały zwrócone przez inne serwery DNS.

4. Zapytanie iteracyjne dla www.contoso.com (rekord zasobu A).

5. Przekierowanie do serwera nazw contoso.com (rekord zasobu NS dla contoso.com).

6. Zapytanie iteracyjne dla www.contoso.com (rekord zasobu A).

7. Odpowiedz na zapytanie iteracyjne z serwera contoso.com (adres IP www.contoso.com).

8. Odpowiedź na oryginalne zapytanie rekursywne z lokalnego serwera DNS do resolvera (adres IP www.contoso.com).

Aktualizowanie systemu DNS

Rekordy zasobów często zmieniają się w miarę dodawania lub usuwania komputerów, serwerów i urządzeń z sieci. Implementacja systemu DNS w systemie Windows Server obsługuje zarówno statyczne, jak i dynamiczne aktualizacje bazy danych DNS.

Rekordy zasobów można dodać do istniejącej strefy przy użyciu polecenia Add-DNSServerResourceRecord programu PowerShell. Niektóre typowe typy rekordów zasobów mają inne polecenia programu PowerShell, w których nie trzeba określać typu rekordu zasobu. Rekordy zasobów można również dodać przy użyciu konsoli Menedżera DNS. Aby uzyskać wskazówki dotyczące pracy z rekordami zasobów, w tym tworzenia i modyfikowania istniejących rekordów zasobów wszystkich typów, zobacz Zarządzanie rekordami zasobów DNS .

Obsługa znaków Unicode

Po wprowadzeniu systemu DNS w ramach RFC 1035 nazwy były ograniczone do używania wielkich i małych liter (A-Z, a-z), cyfr (0–9) i łączników (-). Ponadto pierwszy znak nazwy DNS może być liczbą, a nazwy muszą być kodowane i reprezentowane przy użyciu znaków opartych na us-ASCII. W przypadku korzystania z systemu DNS w ustawieniach międzynarodowych to wymaganie powoduje znaczne ograniczenia, w których rozszerzone zestawy znaków są używane do lokalnych standardów nazewnictwa. Usługa DNS systemu Windows Server zapewnia rozszerzoną obsługę dla znaków UTF-8, wykraczającą poza specyfikację RFC 1035 .

Co to jest UTF-8?

UTF-8 jest zalecanym zestawem znaków dla protokołów zmieniających się poza użyciem ASCII. Protokół UTF-8 zapewnia obsługę rozszerzonych znaków ASCII i tłumaczenia UCS-2, 16-bitowego zestawu znaków Unicode, który obejmuje większość systemów pisania na świecie. UtF-8 umożliwia znacznie większy zakres nazw niż można osiągnąć przy użyciu kodowania ASCII lub rozszerzonego ASCII dla danych znaków.

Komputery z systemem Windows Server 2008 mają świadomość UTF-8. Oznacza to, że gdy znaki zakodowane w formacie UTF-8 są odbierane lub używane jako dane przez serwer, serwer może ładować i przechowywać te dane w swoich strefach. Mimo że serwery DNS oparte na systemie Windows są oparte na protokole UTF-8, pozostają zgodne z innymi serwerami DNS, które używają tradycyjnego kodowania danych US-ASCII i bieżących standardów DNS.

Jak usługa DNS implementuje utF-8

Aby zapewnić zgodność standardów i współdziałanie z innymi implementacjami DNS, usługa DNS używa zamiany wszystkich odebranych danych znakowych na małe litery. W tym procesie usługa DNS konwertuje wszystkie wielkie litery używane w standardowych US-ASCII danych na małe, równoważne dane z następujących powodów:

• Aby zachować zgodność z bieżącymi i istniejącymi standardami DNS.
• Aby zapewnić współdziałanie z implementacjami serwera DNS, które nie rozpoznają ani nie obsługują kodowania UTF-8.

Aby zrozumieć, dlaczego wybrano jednolite litery, należy najpierw rozważyć kilka powiązanych punktów z aktualnych zmienionych standardów internetowych dla systemu DNS. Kilka kluczowych punktów w standardach bezpośrednio dotyczy sposobu obsługi danych znakowych między serwerami DNS a innymi serwerami i klientami. Kluczowe kwestie obejmują:

• Dowolny ciąg binarny może być używany w nazwie DNS. (Specyfikacja RFC 2181)
• Serwery DNS muszą mieć możliwość porównywania nazw w sposób bez uwzględniania wielkości liter. (Specyfikacja RFC 1035)
• Oryginalna wielkość liter danych znakowych powinna być zachowywana, kiedy tylko jest to możliwe, gdy dane są wprowadzane do systemu. (Specyfikacja RFC 1035)

Ze względu na to, że niewrażliwość na wielkość liter jest wymaganą częścią podstawowego standardu DNS, a zachowanie wielkości liter jest opcjonalną rekomendacją, ujednolicone przekształcenie na małe litery zostało wybrane w celu zapewnienia skutecznego rozwiązania zgodnego ze standardami. Poprzez zmniejszenie wielkości liter nazw zakodowanych w UTF-8 przed transmisją, inne serwery DNS (które nie są świadome UTF-8) są w stanie odbierać dane, wykonywać pomyślne porównania binarne i uzyskać żądane wyniki.

Zagadnienia dotyczące współdziałania z programem UTF-8

Usługę serwera DNS można ustawić tak, aby zezwalać na używanie znaków UTF-8 dla każdego serwera lub blokować go. Niektóre serwery DNS, które nie obsługują protokołu UTF-8, mogą akceptować strefy z nazwami UTF-8, ale mogą mieć problemy z zapisaniem lub ponownym załadowaniem tych nazw. Należy zachować ostrożność podczas przesyłania stref z nazwami UTF-8 do serwerów, które nie obsługują protokołu UTF-8.

Niektóre protokoły nakładają ograniczenia dotyczące znaków dozwolonych w nazwie. Ponadto nazwy, które mają być widoczne globalnie (RFC 1958) powinny zawierać znaki tylko ASCII, zgodnie z zaleceniami w dokumencie RFC 1123.

Przekształcanie znaków Unicode przy użyciu formatu UTF-8 jest niewidoczne dla użytkowników. Można jednak zobaczyć znaki zakodowane w formacie UTF-8, jeśli używasz monitora sieciowego lub podobnego narzędzia do analizowania ruchu DNS.

Oprócz obsługi serwera DNS dla formatu kodowania UTF-8 program rozpoznawania klienta domyślnie używa formatu kodowania znaków UTF-8.

Nazwy zakodowane w formacie UTF-8 nie mogą przekraczać limitów rozmiaru wyjaśnionych w dokumencie RFC 2181, który określa maksymalnie 63 oktety na etykietę i 255 oktetów na nazwę. Liczba znaków jest niewystarczająca do określenia rozmiaru, ponieważ niektóre znaki UTF-8 przekraczają jedną oktet długości.

Protokół kodowania UTF-8 dostosowuje się do użycia z istniejącymi implementacjami protokołu DNS, które oczekują US-ASCII znaków, ponieważ reprezentacja znaków US-ASCII w formacie UTF-8 jest identyczna, bajt dla bajtów, do reprezentacji US-ASCII. Implementacje klienta lub serwera DNS, które nie rozpoznają znaków UTF-8, zawsze kodują nazwy w formacie US-ASCII. Usługa serwera DNS jest w stanie poprawnie interpretować te nazwy.

Usługa DNS może skonfigurować sprawdzanie nazw, aby zezwolić lub ograniczyć użycie znaków UTF-8 w danych DNS.

Domyślnie jest używane wielobajtowe sprawdzanie nazw UTF-8, co pozwala na największą tolerancję, gdy usługa DNS przetwarza znaki. Wielobajtowe sprawdzanie nazw UTF-8 jest preferowaną metodą sprawdzania nazw dla większości prywatnych serwerów DNS, które nie udostępniają usługi nazw dla hostów internetowych.