1 | Analiza i dostosowanie istniejących standardów dotyczących autoryzacji dostępu oraz uwierzytelniania użytkowników za pomocą usługi katalogowej |
1.1 | Projekt mechanizmów autoryzacji dostępu do informacji o strukturze domenowej |
Przed przystąpieniem do opisu problematyki związanej z autoryzacją dostępu do danych o strukturze domenowej zajmiemy się przedstawieniem ogólnych zasad i technicznych aspektów działania DNS. Poznanie istoty funkcjonowania DNS determinuje możliwość i zasadność wykorzystania baz LDAP jako wsparcia dla tego systemu. Dlatego też zdecydowaliśmy się na zamieszczenie w niniejszym opracowaniu dość szczegółowego opisu wewnętrznych procedur działania systemu.
System DNS jest jednego z najbardziej istotnych, choć może niezbyt spektakularnie działających systemów obsługi sieci Internet. Jego funkcjonowanie ma jednak kluczowe znaczenie dla właściwego działania sieci. Uzyskane dzięki niemu informacje stanowią podstawę i warunek możliwość korzystania ze wszystkich niemal usług Internetu: serwerów WWW, systemów pocztowych, grup dyskusyjnych itd.
DNS jest największą globalną, rozproszoną i hierarchiczną bazą służącą do tłumaczenia nazw nadanym urządzeniom w sieci, na ich liczbowe odpowiedniki w postaci wymaganej przez protokół komunikacyjny IP. Główną, choć nie jedyna przyczyną powstania tego systemu była prozaiczna konieczność zapewnienia mechanizmu eliminującego kłopotliwe zapamiętywanie adresów w postaci cyfr oddzielonych kropkami. System DNS pozwala na znacznie wygodniejszych w użyciu stosowanie nazw odpowiadających adresom, jak również wskazywanie komputerów obsługujących pocztę elektroniczną. System został zbudowany według nazewnictwa opracowane przez P. Mockapetrisa. Domeny na podobieństwo adresów w sieci internet składają się z członów separowanych kropkami. Nazwy domenowe czyta się "od tyłu": najpierw domena główna (ang. root domain) domena pierwszego poziomu, domena drugiego poziomu - typowo w domenie drugiego lub trzeciego poziomu umieszcza się nazwę przyznaną systemowi końcowemu. Stosowanie konkretnej liczby członów dla określenia pełnej nazwy systemu docelowego nie jest obligatoryjne. Takie podejście określa niejako miejsce i charakter systemu. Założenia nazewnictwa zakładają podział na domeny internetowe najwyższego poziomu:
com - organizacje handlowe,
edu - uniwersytety i inne instytucje edukacyjne,
gov - przedstawicielstwa rządowe,
mil - organizacje militarne,
net - ważniejsze centra wspomagające działanie sieci,
int - organizacje międzynarodowe,
org - inne organizacje.
W 2001 roku dołączyły do nich:
aero, biz, coop, info, museum, name, pro
Niezależnie używane są także domeny krajowe (narodowe):
us - Stany Zjednoczone,
uk - Wielka Brytania,
de - Niemcy,
pl - Polska,
ru - Rosja,
fr - Francja itd.
Domeny poziomów dwa, trzy, najczęściej reprezentują miasto lub instytucje.
Technicznie mapowaniem, czyli zamianą nazw domenowych na adresy IP (i vice-versa) zajmują się dla danej domeny określone komputery tzw. serwery DNS (ang. nameservers). Dla właściwej wzajemnej komunikacji i możliwości obsługi zapytań o dowolną nazwę, drzewiasta struktura domen wymaga zarejestrowania domeny niższego rzędu w serwerze DNS odpowiedzialnym za obsługę domeny wyższego poziomu. Równolegle do drzewa domen prostych istnieje struktura domen odwrotnych (IN-ADDR.ARPA). Drzewa domen prostych i odwrotnych uzupełniają się i spotykają jedynie w domenie nadrzędnej dla wszystkich "." (root). Serwery DNS utrzymują częściowe bazy danych DNS wraz z adresami sąsiednich serwerów; korzystają przy tym z pamięci podręcznych, w których przechowują często używane nazwy. System DNS jest skalowalny, zwielokrotniony i stosunkowo szybki.
DNS opiera się na trzech podstawowych składnikach:
Nazwy (adresy symboliczne) tworzą wirtualną przestrzeń o strukturze podobnej do odwróconego drzewa wzorowanego na strukturze systemu plików systemu UNIX.
Nazewnictwo domen jest dowolne, jednak występują tu pewne wyjątki. W nazwie domeny mogą wystąpić wszystkie litery angielskiego alfabetu (bez rozróżnienia małych i wielkich liter oraz znak "-") a także cyfry. Wszystkie znaki uzyskane z klawiatury z klawiszem Shiftem np.: &, *, #, $, _ są niedozwolone.
Każda domena ma swoją strefę(zonę), czyli przestrzeń w której może tworzyć poddomeny.
W hierarchii nazewnictwa domen, nie mogą istnieć dwie takie same nazwy domen lub poddomen na jednym poziomie nazw. Muszą się one różnić co najmniej jednym znakiem.
Najlepiej zobrazuje to rysunek:
Każda wydzielona domena jest unikalna w strukturze drzewa nazw domen. Niepowtarzalność nazw na jednym poziomie ma swoje zalety i wady. Zaletą jest indywidualność nazwy domeny, wadą natomiast, brak możliwości istnienia drugiej domeny o takiej samej nazwie. Każdą domenę powinien obsługiwać co najmniej jeden Name Serwer. Każdy Name Serwer posiada wszystkie dane dotyczące zony (strefy) danej domeny. Jeden Name Serwer może być autorytatywny[1] dla wielu domen jednocześnie. Na pytania o inne domeny, daje odpowiedzi nieautorytatywne (niekompletne lub niepewne).
W domenie nadrzędnej zawsze wpisuje się Serwery autorytatywnie obsługujące daną domenę tj. Primary i Secondary Name Serwer[2]. Secondary Name Serwer posiada kopie danych, które są wpisane w konfiguracji na PNS.
Istnienie co najmniej dwóch Name Serwerów odpowiedzialnych za obsługę domeny zapewnia większą niezawodność oraz poprawia szybkość generowania odpowiedzi na zapytania poprzez możliwość wybrania bliżej zlokalizowanego serwera.
Główne fazy działania systemu DNS, w uproszczeniu przebiegają następująco:
Aplikacja użytkowa w celu uzyskania informacji o systemie o nazwie PC1 znajdującego się w domenie nask.com.pl. (umieszczonej w hierarchii domen zgodnie z powyższym rysunkiem), w pierwszej fazie użyje resolwera[3]. W wyniku tej operacji otrzyma adres IP name serwera[4] który będzie odpowiedzialny za dalsze fazy dialogu zmierzającego do uzyskania szukanego adresu IP systemu docelowego.
Użytkownik wywołał program FTP za pomocą polecenia: ftp pc1.nask.com.pl
służącego do nawiązanie połączenia z serwerem FTP umożliwiającym transfer
plików . Dla zrealizowania połączenie program musi zlokalizować komputer
docelowy, potrzebuje więc uzyskać informacje o adresie
IP komputera PC1 w domenie nask.com.pl.
Zakładamy że w chwili wysłania zapytania żaden Name Serwer nie
ma żadnych danych o szukanym systemie. Pamięci podręczne-cache[5] są puste.
Resolwer kieruje pytanie do pierwszego Name Serwera ze statycznie wpisanej
listy. W systemie Unix używana jest lista znajdująca się w pliku w
/etc/resolv.conf.
W pierwszej kolejności przeszukiwana jest pamięć typu cache tego
Name Serwera, później jego lokalne zasoby. Jeśli pierwszy pytany
serwer nie posiada szukanej informacji to Name Serwer ten zwróci informacje
o adresach Name Serwerów obsługujących domeny najwyższego poziomu
(root domain - czyli ".") Główne serwery obsługujące domenę ".", posiadają
dane o Name Serwerach obsługujących domenę nadrzędną dla Polski
.pl. Informacja ta jest przesyłana do pytającego Name
Serwera, który zapisuje tę informacje w podręcznej pamięci cache - dla
późniejszego wykorzystania. To właśnie pierwszy Name Serwer
będzie prowadził dialog ze wszystkimi Name Serwerami w drzewie
domenowym. W następnym kroku do serwera obsługującego domenę .pl
zostanie skierowane pytanie o adresy name serwerów obsługujących
domenę .com.pl. Procedura ta jest powtarzana do momentu uzyskania
informacji o adresie name serwera odpowiedzialnego za obsługę domeny w
której znajduje się docelowy system - w naszym przykładzie będzie to
domena nask.com.pl.
Dzięki przechowywaniu raz uzyskanych informacji w pamięci podręcznej, name
serwer prowadzący dialog w przypadku otrzymania ponownego zapytania o
system zlokalizowany w domenie nask.com.pl otrzyma odpowiedź
pochodzącą z pamięci cache najbliższego w hierarchii serwera - bez
konieczności powtarzania wszystkich opisanych wyżej faz dialogu.
Pytanie o domenę nask.com.pl ilustruje poniższy rysunek[6]:
1.1.1.2 | Optymalizacja i modele współpracy systemów DNS |
Podobnie jak większość systemów pracujących w środowiskach sieciowych także system DNS może być optymalizowany dla osiągnięcia konkretnych, pożądanych właściwości. Dla wyjaśnienia głównych sposobów optymalizacji pracy DNS poniżej opisujemy kilka niezbędnych pojęć i wykorzystywanych w tym celu mechanizmów:
Rekursywny tryb pracy
Rekursywność to wynikający z konfiguracji tryb pracy Name Serwera pozwalający na wysyłanie zapytań do name serwerów obsługujących kolejne poziomy w adresie domenowym. Zapytania te są częścią dialogu mającego na celu uzyskania adresu serwera odpowiedzialnego za obsługę szukanej domeny.
Caching
Możliwość przechowywania w szybko dostępnej pamięci podręcznej, uzyskanych wcześniej informacji w celu ich późniejszego wykorzystania.
Forwarding
Cecha konfiguracji name serwa pozwalająca na przesyłanie otrzymywanych zapytań do innego, wskazanego name serwera który pokieruje procesem rozwiązywania nazw.
Kombinacje powyższych technik pozwalają na dostosowanie specyfiki pracy systemu DNS do własnych potrzeb.
Dla podniesienia efektywności i zminimalizowania czasu potrzebnego
na znalezienie informacji o szukanym
systemie stosuje się serwery cachujące (caching name servers). Mechanizm
cachowanie typowo używany przez wszystkie serwery DNS, w tym przypadku
jest to jednak ich główna funkcja. Serwery Cachujące nie są odpowiedzialne
za obsługę żadnej strefy nie muszą więc angażować zasobów do obsługi
lokalnych baz danych.
Niekiedy korzystne jest rozdzielenie funkcji realizowanych przez system DNS.
Możemy w tym celu wykorzystać mechanizm
forwardingu. Poprzez odpowiednią
konfigurację lokalnego serwera DNS można wskazać oddzielny name serwer
odpowiedzialny za obsługę zapytań o systemy znajdujące się
poza lokalną strefą, podczas gdy pozostałe zapytania
będą obsługiwane przez lokalny serwer. Zaletą takiego rozwiązania jest to
że lokalny serwer nie musi sam prowadzić dialogu z
innymi serwerami DNS (jego mechanizm pytań rekursywnych jest wyłączony), a
nawet posiadać dostępu do sieci zewnętrznej ponieważ komunikuje się on
wyłącznie z jednym zdefiniowanym wcześniej serwerem. Ten zaś odpowiada
za dalsze etapy dialogu DNS. Dzięki takiej separacji funkcji można uzyskać
znaczną poprawę efektywności pracy systemu DNS jak i zapewnić wyższy
poziom bezpieczeństwa lokalnego serwera DNS.
Przesyłanie każdej informacji w ramach dialogu
odbywa się zgodnie z protokołem TCP lub UDP używanym stosownie
do rodzaju zapytania. W zależności od wykorzystywanego protokółu
transportu używane są również oddzielne porty Name Serwera tj.
53 dla TCP i 42 dla UDP.
Ściśle określony jest także format i standard przesyłania informacji.
Odbywa się to za pomocą ramek[7] o pięciu
polach-sekcjach: Header, Question, Answer, Authority, Additional.
Każde z tych pól niesie inna informację:
Question - pytanie o Name Serwer
Answer - odpowiedź na pytanie
Authority - liczba określająca ilość autorytatywnych name serwerów
Additional - dodatkowe informacje
Oto wygląd zapytania o domenę nask.com.pl (poniżej znajduje się opis tego typu zapytań):
; res_mkquery(0, nask.com.pl.pl, 1, 1) ;; res_send() ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57226 ;; flags: rd; Ques: 1, Ans: 0, Auth: 0, Addit: 0 ;; nask.com.pl, type = A, class = IN ;; Querying server(#1) udp address = 148.81.16.51 ;; got answer, 38 bytes: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57226 ;; flags: qr rd ra; Ques: 1, Ans: 0, Auth: 0, Addit: 0 ;; QUESTIONS: ;; nask.com.pl, type = A, class = IN
a) Header czyli nagłówek występuje zawsze w jednej z tych ramek.
Nagłówek zawiera pola, które z sekcji będą obecnie w wiadomości. Mówi także kiedy wiadomość jest pytaniem, a kiedy odpowiedzią.
| Pola nagłówka dotyczą: | typu zapytania (QTYPE), |
| klasy pytania (QCLASS), | |
| pytania o nazwę domeny (QNAME) |
Answer, Authority i Additional - te trzy sekcje mają taką samą budowę lecz
niosą inne dane.
W zapytaniu DNS-owym musi wystąpić nagłówek. Answer, Authority i
Additional są opcjonalne.
Sekcja nagłówkowa wygląda następująco:
| Id | |||||||
| QR | OPCODE | AA | TC | RD | RA | Z | RCODE |
| QDCOUNT | |||||||
| ANCOUNT | |||||||
| NSCOUNT | |||||||
| ARCOUNT | |||||||
Objaśnienia pól występujących w nagłówku:
id - 16 bitowy identyfikator wyznaczony przez program, który generuje pytanie.
QR - 1 bit oznacza czy wiadomość jest pytaniem (0), czy jest odpowiedzią(1).
OPCODE - 4 bity w których określa się rodzaj wiadomości.
Pole to może przyjąć wartości o następujących znaczeniach :
0 - standardowe pytanie (QUERY)
1 - pytanie odwrotne (IQUERY)
2 - status serwera (STATUS)
3 - 15 - zarezerwowane na przyszłość
AA - autorytatywna odpowiedź pytanego NS
TC - ustawiony kiedy wiadomość zostanie ?ucięta? do długości jaka wymagana jest w kanale transmisji
RD - ten bit może być ustawiony na odpytywanie
RA - ten bit może być ustawiony lub wyzerowany w odpowiedzi, kiedy Name Serwer może odpowiadać rekursywnie
Z - zarezerwowane na przyszłość, obecnie wartość 0
RCODE - to 4 bitowe pole jest ustawione jak część odpowiedzi, zmienne ustawione mogą przybierać formy:
0. - bezbłędna wiadomość
1. - błąd formatu odpowiedzi. Name Serwer nie może zinterpretować pytania.
2. - serwer uszkodzony - Name Serwer nie może odpowiedzieć na pytanie. Problem z odpowiadającym name serwerem.
3. - błąd nazwy - nie istnieje taka nazwa na danym name serwerze
4. - Name Serwer nie jest skonfigurowany; nie potrafi udzielić odpowiedzi
5. - przerwana odpowiedź; nie wszystkie Name Serwery są skonfigurowane tak by udzielały informacji o posiadanych przez siebie danych - mogą one być np.: zablokowane
6-15. - zarezerwowane na przyszłość
QDCOUNT - 16 bitowa liczba wskazująca na ilość elementów w sekcji QUESTION
ANCOUNT - 16 bitowa liczba wskazująca na ilość elementów w sekcji ANSWER
NSCOUNT - 16 bitowa liczba wskazująca na ilość rekordów NS w sekcji AUTORITY
ARCOUNT - 16 bitowa liczba wskazująca na liczbę rekordów w sekcji ADDITIONAL
b) Sekcja QUESTION odpowiada na rodzaj pytania o Name Serwer.
Format tej sekcji jest następujący:
| QNAME |
| QTYPE |
| QCLASS |
QNAME - zapis nazwy domenowej (jest reprezentowany jako sekwencja poziomów, gdzie każdy poziom składa się z oktetów odpowiedniej długości.) Nazwa domeny nie jest odczytywana, kiedy długość oktetu wynosi 0.
QTYPE - wskazuje na typ pytania. Zmienne w tym polu zawiera wszystkie dopuszczalne kody dla pola TYPE, razem z kilkoma innymi ogólnymi kodami, które mogą wyszukać więcej jak jeden typ rekordu.
QCLASS - dwa oktety kodu, które wskazują na klasę pytania, np.: IN wskazujący na INTERNET,
c) ANSWER,AUTORITY i ADDITIONAL - sekwencje mają taki sam format o kształcie:
| NAME |
| TYPE |
| CLASS |
| TTL |
| RDLENGTH |
| RDATA |
NAME - nazwa domeny do której odnosi się rekord
TYPE - dwa oktety w tym polu wskazują na znaczenie zawartości pola RDATA
CLASS - dwa oktety wskazujące na klasę danych w polu RDATA
TTL - 32 bitowe pole oznaczające czas w sekundach określający jak długo rekord ma być przechowywany w cache. Po czasie tym jest on usuwany. 0 oznacza, że informacja nie nie zostanie zapamiętana w pamięci cache.
RDLENGTH - 16 bitowa liczba wskazująca długość oktetu w polu RDATA
RDATA - zmienna długości ciągu znaków oktetów, które opisują rekord. Format tej informacji zmienia się z polami TYPE i CLASS, np.: jeśli TYPE = A i CLASS = IN, odpowiada to na 4 oktety internetowego adresu IP.
Pole TYPE jest używane do przenoszenia wartości rekordów. W tym polu mogą wystąpić następujące rekordy, zawarte w QTYPE:
A - adres hosta NS - autorytatywny Name Serwer MD - gdzie ma być przeznaczona poczta MF - gdzie ma być dostarczona poczta, można użyć MX CNAME - możliwość nadania innej nazwy hosta lub odwołanie się do innego urządzenia SOA - zaznaczenie początku autorytatywnej zony (strefy) HB - skrzynka pocztowa domeny (eksperymentalna) MG - grupowanie poczty wielu użytkowników (eksperymentalna) MR - poczta zmieniająca nazwę domeny (eksperymentalna) NULL - pusta wartość rekordu (eksperymentalna) WKS - wszystkim znany opis protokołu PTR - wskaźnik hosta w domenie HINFO - informacje o hoście MINFO - skrzynka albo informacja o pczcie MX - skrzynka internetowo - pocztowa TXT - ciąg znaków
W QTYPE są zdefiniowane takie następujące typy:
AXFR - prośba o transfer zony MAILB - prośba o rekordy skrzynki pocztowej (MB, MG, MR) MAILA - prośba o wartości rekordów pocztowych (MX) * - prośba o wszystkie (jakiekolwiek) rekordy
Standardowymi, najczęściej używanymi rekordami są: A, NS, SOA, CNAME, PTR, MX. Wszystkie te rekordy występują w sekcji RDATA.
- CNAME: możliwość zakładania przekierowań - aliasów z jednej wartości rekordu na inny np.:
WWW.NASK.COM.PL. CNAME ARTEMOR.NASK.WAW.PL.
- MX: wskazanie adresu systemu odpowiedzialnego za przyjmowanie poczty elektronicznej skierowanej do użytkownika domeny
- NS: rekord w którym zapisane są informacje o autorytatywnych Name serwerach dla danej domeny. Zazwyczaj występuje z klasą IN lub HS.
NASK.COM.PL. IN NS DNS.NASK.COM.PL.
W miejscu wartości rekordu (czyli po prawej stronie zapisu) musi być wpisana pełna nazwa Name Serwera. (Nie mogą być tu wpisane adresy IP).
- PTR: zaznaczenie jednego hosta w obrębie danej domeny, przypisywanie jednego IP dla jednej maszyny- A: przypisanie maszyny do jednego IP. (Można jedną maszynę przypisać do kilku IP).
DNS.NASK.COM.PL. IN A 148.81.90.25- SOA: rekord rozpoczynający zonę; w skład tego rekordu wchodzą następujące sekcje:
MNAME - nazwa kanoniczna PNSRNAME - adres intetnetowy dla operatora - administratora danej domeny
SERIAL - 32 bitowa liczba. Wskazuje ona na czas ostatniego restartu procesu obsługi serwera DNS. Wartość tej liczby jest sygnałem o zmianach dokonanych na serwerze głównym (PNS). Serwery zapasowe (SNS) w przypadku stwierdzenia zmiany pobierają nowe dane dotyczące obsługiwanej strefy.
REFRESH - 32 bitowa liczba przedstawiająca w sekundach co jaki czas zona ma być odświeżona - czyli uaktualniana przez inne name serwery
RETRY - 32 bitowa liczba przedstawiająca w sekundach co jaki czas name serwery mają ponowić próbę ściągnięcia zony
EXPIRE - 32 bitowa liczba przedstawiająca w sekundach czas "życia" na secondary name serwerze, wówczas gdy będzie DNS wyłączony. Po upływie tego czasu wszystkie dane dotyczące domeny są "zapominane"
TTL - czas do życia w podręcznej pamięci cache, wartość liczbowa w sekundach określa jak długo wartości rekordów mogą być eksportowane w komunikacji między Name Serwerami.
Krótką informację opisującą podstawowe konfiguracji systemu DNS dla środowiska
Unix rozpoczniemy od pliku, w którym zawarte są wszystkie wartości niezbędne do działania domeny.
Może on nosić dowolną nazwę wskazaną w głównym pliku konfiguracyjnym
(/etc/named.conf).
Najważniejszym rekordem w takim pliku jest rekord SOA.
;
nazwa.domeny. ttl IN SOA nazwa.primary.name.servera adres.administratora
( 2002071000 ;Serial
10800 ;Refresh
3600 ;Retry
64000 ;Expire
86400 ;TTL )
;
Taki rekord określa jak nazywać się będzie autorytatywny primary Name Serwer dla danej domeny. Wskazuje adres do administratora domeny oraz różne parametry związane z czasem. Dobór poszczególnych parametrów zależy od preferencji administratora, funkcji jak i wielkości całej domeny. Jeżeli domena zawiera znaczną liczbę poddomen, to parametry Refresh, Retry, Expire powinny być krótsze. Inaczej jest z czasem TTL (Time To Live), wpisując większą liczbę zapewniamy dłuższy czas przetrzymywania informacji o domenie w pamięci cache innych Name Serwerów.
Poniżej rekordu SOA występują inne rekordy np: A,NS,MX,PTR,CNAME.
I tak pod SOA należy wpisać:
; nazwa.domeny. IN NS nazwa.primary.name.serwera. nazwa.domeny. IN NS nazwa.secondary.name.serwera. ;
Można w tej sekcji wpisać rekord MX, który będzie kierował pocztę przychodzącą do komputera, którą wskażemy po prawej stronie.
; nazwa.domeny. IN MX 0 nazwa.hosta. ;Taki zapis kieruje pocztę z najwyższym priorytetem "0" do hosta gdzie uruchomiony jest serwis pocztowy. Host ten nie musi być w danej domenie, ale musi on posiadać umiejętność przyjmowania poczty elektronicznej. Jeśli host ten będzie obsługiwanej przez lokalny serwer domenie domenie należy przypisać mu numer IP. Służy do tego rekord A:
; nazwa.hosta. IN A 195.187.16.9 ;
wpis CNAME określa alias dla nazw kanonicznych np:
@ IN SOA www.nask.com.pl.admin.nask.com.pl.
( 2002071000 ;Serial
10800 ;Refresh
3600 ;Retry
64000 ;Expire
86400 ;TTL )
;
IN NS dns.nask.com.pl.
IN NS dns.tpsa.pl.
IN MX 0 poczta.nask.com.pl.
;
poczta.nask.com.pl. IN A 195.187.16.8
;
localhost IN A 127.0.0.1
;
www IN CNAME poczta.nask.com.pl.
* IN CNAME www
;
Powyższe dwie linie zawierające słowo kluczowe CNAME należy interpretować następująco: Pierwsza linia pozwala na odwoływanie się do komputera poczta.nask.com.pl poprzez alias www. Linia rozpoczynająca się od gwiazdki zapewnia domyślne połączenia z serwerem poczta.nask.com.pl w przypadku kiedy serwer DNS nie jest w stanie rozwiązać podanej nazwy.
W przykładzie pojawił się także wpis rozpoczynający się od słowa localhost. W konfiguracji każdego Name Serwera potrzebny jest taki zapis aby była "znana droga do samego siebie". Znaczy to tyle aby serwer mógł trafić prostą drogą do swoich danych w razie otrzymania zapytania o komputer w swojej domenie. Do tego celu należy dodatkowo utworzyć plik loopback.
;
0.0.127.in-addr.arpa. IN SOA www.nask.com.pl. admin.nask.com.pl.
( 2002071000 ;Serial
10800 ;Refresh
3600 ;Retry
64000 ;Expire
86400 ;TTL )
;
0.0.127.in-addr.arpa. IN NS www.nask.com.pl.
;
1.0.0.127.in-addr.arpa. IN PTR localhost.
;
W pliku tym pojawił się rekord PTR (PoinTeR) wskazujący zarezerwowany numer 127.0.0.1, w drzewie in-addr.arpa (domen odwrotnych), na samego siebie.
Plik startowy BINDa w systemie UNIX ma postać następującą:
;
zone "0.0.127.in-addr.arpa" {
type master;
file "127.0.0";
};
zone "nask.com.pl" {
type master;
file "pl.com.nask"
};
;
Jak wspomieliśmy nosi on nazwę named.conf i standardowo umieszczony jest w
katalogu /etc.
Na jednym Name Serwerze może znajdować się większa
liczba podobnych zapisów dotyczących różnych domen. Jeden Name
Serwer nie może jednak jednocześnie pełnić funkcji primary i secondary
name serwera dla tej samej domeny.
Uruchomienie domeny na PNS, oprócz utworzenia wyżej wymienionych
plików wymaga uruchomienia obsługującego je procesu o nazwie named.
Jest to proces udostępniający Name Serwera w sieci. Aby
domena "nask.com.pl" była "widoczna" w globalnej hierarchii domen Internet
należy ją wydelegować- tzn. wpisać do domeny nadrzędnej, w
naszym przykładzie będzie to domena com.pl.
Historia systemu DNS - główne fakty
RFC poświęcone systemowi DNS
Standardy, Propozycje standardów, ścieżki standaryzacyjne
- 0974: Mail routing and the domain system.
- 1034 : Domain names - concepts and facilities.
- 1035 : Domain names - implementation and specification.
- 1101 : DNS encoding of network names and other types.
- 1122: Requirements for Internet hosts - communication layers.
- 1123: Requirements for Internet hosts - application and support.
- 1183: New DNS RR Definitions.
- 1611: DNS Server MIB Extensions.
- 1612: DNS Resolver MIB Extensions.
- 1886: DNS Extensions to support IP version 6.
- 1982: Serial Number Arithmetic.
- 1995: Incremental Zone Transfers in DNS.
- 1996: A Mechanism for Prompt Notification of Zone Changes.
- 2136: Dynamic Updates in the Domain Name System.
- 2163: Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping.
- 2181: Clarifications to the DNS Specification.
- 2247: Using Domains in LDAP/X.500 Distinguished Names.
- 2308: Negative Caching of DNS Queries (DNS NCACHE).
- 2373: IP Version 6 Addressing Architecture.
- 2374: An IPv6 Aggregatable Global Unicast Address Format.
- 2535: Domain Name System Security Extensions. (size: 111k)
- 2536: DSA KEYs and SIGs in the Domain Name System.
- 2537: RSA/MD5 KEYs and SIGs in the Domain Name System.
- 2538: Storing Certificates in the Domain Name System.
- 2539: Storing of Diffie=Hellman Keys in the Domain Name System.
- 2671: Extension Mechanisms for DNS (EDNSO).
- 2672: Non-Terminal DNS Name Redirection.
- 2673: Binary Labels in the Domain Name System.
- 2782: A DNS RR for specifying the location of services (DNS SRV)
- 2845: Secret Key Transaction Authentication for DNS (TSIG)
- 2874: DNS Extensions to Support IPv6 Address Aggregation and Renumbering
- 3007: Secure Domain Name System Dynamic Update.
- 3008: Domain Name System Security (DNSSEC) Signing Authority.
Best Current Practices (BCP)
- 1918: Address Allocation for Private Internets.
- 2870: Root Name Server Operational Requirements
- 2182: Selection and Operation of Secondary DNS Services.
- 2219: Use of DNS Aliases for Network Services.
- 2317: Classless IN-ADDR.ARPA delegation.
- 2606: Reserved Top Level DNS Names.
- 2929: Domain Name System (DNS) IANA Considerations.
Eksperymentalne
- 1464: Using the Domain Name System to store arbitrary string attributes.
- 1876: A Means for Expressing Location Information in the Domain Name System.
- 2168: Resolution of Uniform Resource Identifiers using the Domain Name System.
- 2345: Domain Names and Company Name Retrieval.
- 2540: Detacted Domain Name System Information.
Informacyjne
- 1032: Domain administrators guide.
- 1033: Domain administrators operations guide.
- 1178: Choosing a name for your computer.
- 1480: The US Domain. (size 100k)
- 1535: A Security Problem and Proposed Correction With Widely Deployed DNS Software.
- 1536: Common DNS Implementation Errors and Suggested Fixes.
- 1591: Domain Name System Structure and Delegation.
- 1706: DNS NSAP Resource Records.
- 1713: Tools for DNS debugging.
- 1794: DNS Support for Load Balancing.
- 1912: Common DNS Operational and Configuration Errors.
- 1956: Registration in the MIL Domain.
- 2104: HMAC - Keyed-Hasing for Message Authentication.
- 2146: U.S. Government Internet Domain Names.
- 2230: Key Exchange Delegation Record for the DNS.
- 2352:A Convention For Using Legal Names as Domain Names.
- 2375: IPv6 Multicast Address Assignments.
- 2377: Naming Plan for Internet Directory-Enabled Applications.
- 2517: Building Directories from DNS: Experiences from WWWSeeker.
- 2541: DNS Security Operational Considerations.
- 2553: Basic Socket Interface Extensions for IPv6.
Historyczne
Problemy związane z działaniem systemu DNS mają różnoraki
charakter. Znaczna ich część dotyczy bezpieczeństwa, w szczególności
aspektów związanych z zapewnieniem mechanizmów wzajemnej weryfikacji
systemów obsługi drzewa DNS dla uniknięcia nieuprawnionego
wprowadzania sfałszowanych informacji o parach nazwa ?
adres, propagowanych przez system. Sposoby za rozwiązanie znacznej
części tych problemów zostaną opisane w dziale dotyczącym DNS SEC.
Bezpieczeństwo nie jest to jednak jedyny obszar w którym system ten
powinien zostać udoskonalony. Istotną wadą DNS jest niepodatność na
zmiany w strukturze przestrzeni nazw, a także - przypadku dużej ilość
wpisów, spory nakład pracy związany z jego utrzymaniem i administrowaniem.
Dlatego też jednym z kierunków prac jest wykorzystania zewnętrznych systemów
bazodanowych do przechowywania danych
DNS. Jeden z wariantów zakłada wykorzystanie w tym celu systemu LDAP (ang.
Lightweight Directory Access Protocol).
Opinie co do słuszności pomysłu wykorzystania baz LDAP do współpracy z DNS nie są jednoznaczne. Najbardziej trafne wydaje się zdanie jednego ze współtwórców protokołu LDAP Tima Howes?a. Zgodnie z nim rola baz LDAP w kontekście współpracy z systemem DNS powinna być wyłącznie pomocnicza, nie widzi on konieczności zastąpienia DNS strukturą dedykowanych baz LDAP. W artykule pod tytułem "LDAP: Use as Directed" ( http://www.networkmagazine.com/article/DCM20000502S0039/1) opublikowanym przez ?Network Magazin? autor pisze między innymi:
[...] LDAP is not a stand-in for DNS, which may well be the world's largest distributed database. Although LDAP's abilities are more or less a superset of DNS's-whose biggest job is translating names like home.netscape.com into IP addresses-there's a very good argument for leaving DNS alone: It's working just fine. Also, LDAP can't contend with the connectionless transport that DNS usually runs over. Ultimately, LDAP may have a role in managing and augmenting the information found in DNS. For example, it could link contact information to host information, but it cannot take the place of the DNS database itself.[...]
Wspomnianą rolę pomocniczą można interpretować jako założenie zgodne z kierunkiem prac projektu.
Analizując możliwe zastosowania systemu LDAP do współpracy z DNS jako najbardziej istotne możemy wskazać dwa główne modele takiej współpracy.
model "offline"
LDAP jako baza zewnętrzna do obsługi (utrzymanie, modyfikacja) stref DNS pozwalająca na export struktury bazy (generację plików) w formacie używanym przez DNS.
Główne zalety takiego rozwiązania to:
model "online"
LDAP jako baza przechowująca dane, do której system DNS odwołuje się bezpośrednio, każdorazowo przy otrzymaniu zapytania.
Główne zalety takiego rozwiązania to:
Analizując możliwe zastosowania systemu LDAP do współpracy z DNS warto wymienić zagrożenia na jakie narażone są obydwa systemy oraz porównać możliwe do zastosowania mechanizmy bezpieczeństwa. Jest to szczególnie istotne w kontekście wyboru optymalnej metody udostępniania danych DNS przechowywanych w bazach LDAP przy jednoczesnym zachowaniu właściwych metod i gradacji praw i właściwej ochrony dostępu.
Główne zagrożenia bezpieczeństwa systemu LDAP
Lista podatności na zagrożenia dotyczące różnych implementacji LDAPa jest dostępna pod adresem: http://www.cert.org/advisories/CA-2001-18.html
Mechanizmy bezpieczeństwa stosowane w LDAP
Identyfikacja i uwierzytelnianie
Ochrona transmisji
Zagrożenia bezpieczeństwa dotyczące systemu:
Lista podatności na zagrożenia dotyczące różnych wersji oprogramowania bind jest dostępna pod adresem:
"http://www.isc.org/products/BIND/bind-security.html
Mechanizmy bezpieczeństwa w DNS
Jednym z kluczowych aspektów związanym z wykorzystaniem baz LDAP do współpracy z systemem DNS jest sposób udostępnia danych. Podobnie jak w przypadku modeli współpracy DNS i LDAP teoretycznie możliwe są dwa podstawowe warianty udostępniania informacji o strukturze domenowej i związana z nimi role systemu LDAP.
Warianty te ilustrują poniższe rysunki:
W wariancie pierwszym przechowywana w LDAPie informacja o strukturze DNS udostępniania jest odwołującym się do niej programom za pośrednictwem mechanizmów DNS. Rola LDAPa jest jedynie pomocnicza. Tym samym automatyczne (inicjowane przez programy) wyszukiwanie informacji o DNS przy wykorzystaniu mechanizmów LDAPa jest niemożliwe. Istnieje oczywiście możliwość niezależnego odwołania się do danych o DNS przechowywanych w DIT ((Directory Information Tree) za pośrednictwem protokołu LDAP, pod warunkiem ich udostępnienia - nie jest to jednak odwołanie automatyczne, występujące w typowym procesie rozwiązywania nazw. W kontekście współpracy LDAPa i DNS w wariancie tym wykorzystywany jest opisany wyżej model on-line. Przedstawiony rysunek ilustrujący ten wariant jest uproszczony. Serwery LDAP mogą posiadać swoje repliki pozwalające na różne strategie dublowania informacji.
Wariant drugi ilustruje sytuacje, w której to LDAP w całości przechowuje
dane i obsługuje system DNS. Aplikacje użytkowe zamiast
do resolvera przeszukującego przestrzeń DNS odwołują się
do klienta LDAP, odpowiedzialnego za przeszukanie drzewa LDAPa
przy zachowaniu obecnej topologii i hierarchcznej struktury DNS.
Przeszukiwanie takie odbywa się oczywiście
przy wykorzystaniu mechanizmów LDAPa. Wariant ten jest wariantem
teoretycznym, ponieważ na wstępie analizy możliwych zastosowań
LDAPa, odrzuciliśmy pomysł zastąpienia DNS rozproszonym systemem LDAP jako
niezgodny z przyjętym założeniem pomocniczej roli LDAPa. Nie jest to
oczywiście niemożliwe, jednak nakłady i zakres zmian związanych z migracją
LDAPa do roli systemu obsługi DNS są znaczne i w naszej ocenie czynią taki
kierunek zmian mało realnym.
Aby nasza analiza dotycząca zastosowań LDAPa była
pełna, rozpatrzymy szerzej także taką możliwość.
Opisując warianty komunikacji i współpracy systemów LDAP i DNS warto zwrócić uwagę na pewne cechy obydwu rozwiązań. Dobrym tłem do ich przeanalizowania jest założenie realizacji obsługi DNS przedstawione w wariancie drugim.
Pomimo nieustannej ewolucji technologicznej i pojawiania się nowych zastosowań zmieniających oblicze Internetu, należy zauważyć, że w pewnych obszarach sieć ta jest strukturą niepodatną na zmiany. Dotycz to głównie fundamentalnych założeń jej funkcjonowania i realizujących je składników. Do grupy elementów tego typu można zaliczyć protokół TCP/IP i system DNS. Istotną przeszkodą na drodze zmiany sposobu obsługi DNS jest fakt historycznej obecności i powszechności stosowania systemu w obecnej postaci. Innym powodem dla którego DNS funkcjonuje od początku istnienia sieci globalnej w praktycznie nie zmienionej formie, jest jego relatywnie wysoka sprawność.
Kluczowymi mechanizmami decydującymi o "sukcesie" DNS są:
Przedsięwzięcie przejście na LDAPa jako system obsługi DNS porównać można do prób implementacji na szerszą skalę protokołu IP w wersji szóstej. Słowem - byłaby to prawdziwa rewolucja. Pomimo rewolucyjnego charakteru proces migracji musiałby jednak być procesem powolnym i płynnym. Skala oraz zakres zmian związany z przejściem na "LDAP_DNS" tak jak w przypadku IP v.6 byłaby skalą makro. Konieczność implementacji nowego stosu we wszystkich aplikacjach pracujących w środowisku TCP/IP przekłada się w przypadku DNSu zrealizowanego na drzewie LDAP (LDAP_DNS) na implementację nowego zestawu funkcji dla zastąpienia w nich obsługi resolvera, klientem systemu LDAP. Byłoby to oczywiście rozwiązanie docelowe odzwierciedlające stan końcowy procesu migracji do LDAP_DNS. Należy założyć, że w miarę pojawiania się aplikacji posiadających wbudowany moduł komunikacji z "nowym resolverem" (klientem LDAP) mielibyśmy do czynienia z sytuacją kiedy obywa te systemy musiały by współistnieć. Stan taki ilustruje poniższy rysunek.
Oczywiście migracja taka poza samą skalą, w praktyce nastręczałaby
szereg trudności. Należą do nich np. konieczność zapewnienie mechanizmów
spójność danych, czy ustalenie kryterium według którego przedstawiony na
rysunku "resolver przejściowy" (posiadający funkcjonalność klient LDAP i
tradycyjnego resolvera jednocześnie), podejmowałby decyzje
której struktury należy użyć do zrealizowania zapytania otrzymanego od
aplikacji. Posługując się po raz kolejny
przykładem procesu rozprzestrzeniania się protokółu IPv6 można zauważyć że
ma on swój początek głównie w sieciach kampusowych. Można założyć że
proces wykorzystywania DNS na platformie LDAP mógłby mieć swój
początek także w tego typu zamkniętych środowiskach charakteryzujących się
znaczną liczbą systemów i centralnym zarządzaniem. Można także zauważyć że
przedstawione modele współpracy LDAP i DNS pozwalają na płynny proces
migracji do wariantu II.
Równolegle z procesem przystosowywania aplikacji do współpracy z
DNS_LDAP miałyby miejsce kolejne kroki
migracji które można sobie wyobrazić następująco:
Całość powyższych rozważań wydaje się teoretycznie możliwa do
zrealizowania. Pozostaje jednak wątpliwość czy sam LDAP jako
system rzeczywiście podołałby takiemu zadaniu ? Żeby odpowiedzieć na
to pytanie, porównajmy własności LDAPa z tymi cechami DNS które uznaliśmy
za wpływające w największym stopniu na jego efektywność.
Dwie najbardziej istotne z nich to:
Przeszukiwania DIT w LDAP może odbywać się według dwóch schematów:
Zilustrowany powyżej proces przebiega następująco:
Klient wysyła żądanie przesłania danych do serwera 1 (1). Odpowiedzią serwera jest wysłanie do klienta wskaźnika (referal) do serwera 2 (2). LDAP klient nawiązuje połączenie z serwerem 2 (3). Serwer 2 przesyła do klienta żądaną informacje (4).
Proces "łańcuchowej komunikacji" przebiega następująco:
Klient wysyła żądanie przesłania danych do serwera 1 (1). Serwer jeden znajduje wskaźnik do serwera 2 i przesyła do niego żądanie klienta (2). Serwer 2 przesyła żądane dane do serwera 1 (3)
Serwer 1 zwraca rezultat poszukiwania do klienta (4)
Pierwszy wariant realizacji przeszukiwania drzewa LDAP
jest schematycznie zgodny ze sposobem wykorzystywanym przez system DNS. Ma
on także zalety w stosunku do wyszukiwania typu server chaining, należy do
nich między innymi mniejsze obciążenie serwerów w procesie obsługi
zapytań. Obecność i stosowanie mechanizmu server chaining nie jest
obligatoryjna i zależy od implementacji LDAPa.
Kolejny przyczynek do o istotnym wpływie na sprawności systemu DNS, to mechanizm przechowywania uprzednio uzyskanych odpowiedzi w pamięci podręcznej eliminujący konieczność każdorazowego przeszukiwania drzewa.
Podejmowane są próby zapewnienia mechanizmu cachowania w systemach LDAP.
Przykładem tego typu rozwiązania może być CLDAP (Connection Less LDAP) - RFC 1798, w którym zastosowano caching, zaś jako mechanizm transportu dla zapytań zaproponowano protokoł UDP. Tym samym analogia do systemu DNS jest pełna.
Ogólnie problem cachowania w systemie LDAP pomimo braku technicznych
przeszkód (według Tima Howes'a) w fazie praktycznej implementacji wymaga
rozstrzygnięcia wielu kwestii związanych z implementacją tego mechanizmu.
LDAP pomimo wysokiej efektywności i skutecznej optymalizacji obsługi mechanizmów podstawowych procesów (odczyt, przeglądanie, wyszukiwanie) jak również zaawansowanych mechanizmów konstruowania zapytań nie wydaje się być realną alternatywą dla hierarchicznych mechanizmów DNS. Główną przeszkodą w naszym przekonaniu nie są wyłącznie kwestia technicze - które jak się wydaje mogłyby zostać skutecznie rozwiązane. DNS jest mechanizmem "pierwotnym", głęboko zakorzenionym w środowisku TCP/IP, ponadto jego sprawność dla potrzeb obsługi drzewa DNS jest wystarczająca. Ulepszanie systemu który spełnia stawiane mu wymogi jak również jego rozwój zmierzający w kierunku przejścia na całkowicie inną platformę przy zachowaniu obecnej funkcjonalności, jednocześnie wymagający zmian o zasięgu globalnym - nie znajduje w naszej ocenie wystarczającego uzasadnienia. Przedsięwzięcie takie nie jest również uzasadnione ekonomicznie. Wszystkie te czynniki potwierdzają wcześniejszą opinię o wyłącznie pomocniczej roli LDAPa względem systemu DNS.
2 | Analiza i dostosowanie wymagań stawianych usłudze katalogowej w zakresie wspomagania infrastruktury kluczy publicznych |
O tym że ataki na system DNS mogą mieć bardzo poważne następstwa można się domyślić analizując jego podstawową rolę. Wprowadzenie do systemu nieprawdziwych informacje o mapowaniu nazw na adresy pozwala udostępnić spreparowane usługi czy wręcz całe serwery pod ich legalnymi znanymi użytkownikom nazwami. Inne zagrożenie to blokowanie dostępu to serwisu uniemożliwiające nawiązanie połączenia. Bezpieczeństwo tego serwisu ma więc znaczenie niezwykle istotne.
Z uwagi na powyższe zaproponowano nową wersję DNS - DNSSEC wyposażoną w dodatkowe mechanizmy bezpieczeństwa. Dwie główne cechy które zapewnia DNSSEC to uwierzytelnienie i integralność. W 1994 roku organizacja IETF stworzyła formalną grupę zajmującą się opracowaniem związanego z bezpieczeństwem rozszerzenia dp protokołu DNS. W 1997 roku organizacja IAB (Internet Architecture Board) ustaliła architekturę bezpieczeństwa w DNSSEC. W bezpiecznym DNS zostały wykorzystane dotychczasowe osiągnięcia i standardy takie jak kryptografia klucza publicznego oraz algorytmy kryptograficzne RSA, MD5, Diffie-Hellman itd. Wynikiem tych prac było RFC 2316.
Istotą zmian było dodanie do już istniejących rekordów (np. A, NS, CNAME, MX) nowych, tak aby zapewnić obsługującym je serwerom dodatkowe mechanizmy bezpieczeństwa. Zakres zmian zaproponowanych w ramach DNSSEC dotyczy czterech głównych obszarów: uwierzytelnienia danych i źródła ich pochodzenia (identyfikacja stron transakcji), integralności danych uwierzytelnienie zapytań oraz mechanizmów dystrybucji kluczy.
Uwierzytelnienie stron transakcji oraz zapewnienie integralności przesyłanych danych to kluczowe mechanizm DNSSEC. Zastosowanie podpisu elektronicznego w procesie przesyłanych stref kryptograficznie gwarantuje spełnienie tych wymagań. Podpisy takie są przechowywane w odpowiednich rekordach w postaci skrótów (Hash). Hash jest zaszyfrowaną sumą kontrolną wykonaną dla danych rekordów. W jednym z wariantów jest on podpisywany prywatnym kluczem nadawcy tak aby odbiorca rekordów po rozszyfrowaniu skrótu za pomocą klucza publicznego nadawcy mógł porównać otrzymany skrót z ze skrótem wykonanym lokalnie. Uwierzytelnienie może być stosowane dla zapytań oraz nagłówki wiadomości. Dystrybucja kluczy obsługuje kilka rodzajów kluczy oraz kilka rodzajów algorytmów szyfrujących. Mechanizm dystrybucji nie jest przeznaczony wyłącznie dla kluczy związanych z działaniem DNSSEC, ale służyć może także do innych celów.
Rekordy występujące w DNSSEC to: KEY RR, SIG RR ,NXT RR oraz CERT RR (skrót RR-Resource Records oznacza wartości konkretnych rekordów, w poniższym opisie będzie używany skrót "RR").
Rekord KEY używany jest do przechowywania klucza publicznego, (jeden klucz w jednym KEY RR). Podpis dla grupy rekordów jest przechowywany w grupie rekordów RRSet. KEY RR służy do weryfikacji podpisów. Podpisy lub inaczej sygnatury są przenoszone w wartości rekordu SIG. Rekord ten służy do uwierzytelnienia i kontroli integralności danych zawartych w wartościach grup rekordów. Kolejny rekord NXT wykorzystywany jest w przypadku nie znalezienia wartości dla obsługiwanego zapytania dotyczącego rekordu lub grup rekordów. Rekord CERT służy do wskazania miejsca certyfikacji kluczy publicznych. Poza zastosowaniem dla DNS może on być wykorzystywany przez aplikacje które posiadają mechanizmy pozwalające na weryfikację certyfikatu klucza.
KEY RR
Do przechowywania klucza publicznego w DNS używany jest rekord KEY RR.
Jest on powiązany z nazwą domeny i towarzyszy każdej odpowiedzi o tę
nazwę. Resolwer, który generuje pytanie może sprawdzać ważność
danych używając KEY RR bez tworzenia
następnego pytania o sam KEY RR. Mechanizm taki minimalizuje
liczbę pytań potrzebnych do uzyskania nazwy
domeny znalezionej w bezpiecznej strefie "chronionej" kluczem.
DNSSEC używa KEY RR dla przechowywania klucza publicznego,
jednakże nie certyfikuje go. Służy do tego rekord CERT RR. Klucz
znaleziony w sekcji RDATA rekordu KEY należy do nazwy domeny znalezionej
na pierwszej pozycji z listy dla danego rekordu KEY RR.
KEY RR zawiera informacje określające parametry bezpieczeństwa
charakterystyczne dla klucza publicznego jak również określa kryterium
dozwolonego użycia klucza dla uzyskania informacji o nazwie jego
właściciela.
Informacje te zawierają: sam klucz publiczny, typ
algorytmu, typ protokołu i paramtery (flagi) które specyfikują wymienione
cechy (np. czy domena w ogóle posiada klucz). Klucz publiczny oraz
jego algorytm zapisu wskazuje aktualny ustawiony format
klucza umieszczony w sekcji RDATA rekordu KEY. Jako możliwe do
zastosowania przyjęto algorytmy: RSA/MD5, Diffe-Hellmana, DSA (Digital
Signature Algorithm) oraz krzywe eliptyczne . W DNSSEC obligatoryjne
jest jedynie stosowanie algorytmu DSA. Następne pola to tzw. "protocol
octet" wskazujące dla którego protokołu zawarty klucz publiczny
może być stosowany. Jest już kilka protokołów wykorzystujących
klucze publiczne np.: TLS, e-mail, DNSSEC, IPSec. Jako że zarówno pole
określające algorytm klucza jak i protokół są 8 bitowe,
teoretycznie możliwe jest zadeklarowanie do 255 różnych
protokołów możliwych do użycia wraz z 255 typami kluczy.
Kolejne dwa bity z 16 używanych jest do ustawienia różnych flag znanych jako "type bits".
Wszystkie 4 kombinacje z "type bits" wskazują do czego KEY RR będzie używany:
1) poufność,
2) uwierzytelnienie,
3) poufność i uwierzytelnienie,
4) brak
Następne dwa bity są używane do identyfikacji trzech rodzajów jednostek dla których dany klucz należy np.: użytkownik, strefa (zone) lub cokolwiek co nie jest strefą.
SIG RR
Wygenerowany podpis jest przechowywany w rekordzie SIG RR.
SIG zapewnia uwierzytelnienie dla całej grupy wartości rekordów
(RRSet)
oraz termin ważności podpisu. W bezpiecznej strefie grupa wartości
rekordów (np. NS, PTR, MX, etc) ma jeden rekord lub więcej
rekordów SIG RR. Sytuacja gdy występuje więcej niż jeden rekord
SIG RR dla
danej grupy RRSet zachodzi gdy do jej podpisu został użyty
więcej niż jeden algorytm kryptograficzny.
W sekcji RDATA SIG RR znajdują się także pola. Pole podpisu przechowuje podpis dla RRSet. Dla weryfikacji podpisu resolver lub serwer musi znać identyfikator podpisującego. Jest to wskazywane w polu podpisującego. SIG RR ma pole algorytmu identycznie jak w rekordzie KEY RR. Podpisy mają swój czas ważności (expiration time) jak każdy indywidualny RR, SIG RR ma pól dotyczących czasu.
NXT RR
DNS udostępnia możliwość przechowywania w pamięci podręcznej cache negatywnych odpowiedzi. Negatywna odpowiedź oznacza, że szukany RRSet nie istnieje dla danego pytania. DNSSEC udostępnia podpisy dla nieistniejących RRSet tak, by także odpowiedź dotycząca tego stanu mogła być uwierzytelniona. Można to osiągnąć poprzez użycie NXT RR. NXT RR jest używany do wskazania "zakresu" - zbioru nazw DNS które są niedostępne, lub też zakresu niedostępnych RR dla istniejącej nazwy DNS.
Istnieją dwie możliwości obsłużenia zapytania o nieistniejącą domenę lub rekord. Pierwsza zachodzi w sytuacji, gdy nazwa DNS nie posiada żadnego RR (nazwa nie istnieje). Druga, gdy nazwa DNS istnieje (ma co najmniej jeden RR) lecz zapytanie dotyczy nie istniejącego w niej RR. Dla potwierdzenia faktu nie istnienia domeny wszystkie rekordy w ramach strefy są sortowane w sposób zbliżony do alfabetycznego. Technika używana do tego celu nosi nazwę porządku kanonicznego (canonical order), jej zasady definiuje RFC 2535. Kiedy do systemu trafia pytanie o nieistniejącą nazwę, odsyłany jest rekord NXT RR zawierający następny DNS RRset dla istniejącej domeny wynikający z porządku kanonicznego. Dla obsłużenia zapytania o nieistniejący rekord w istniejącej domenie, odsyłany jest rekord NXT zawierający nazwę DNS i RR w niej zawarte. Za każdym razem gdy SIG RR są generowane dla strefy, rekordy NXT RR także powinny zostać także wygenerowane.
TSIG
Implementacja wszystkich opisanych mechanizmów DNSSEC w praktyce bywa kłopotliwa. Dlatego często wykorzystuje się technikę znaną pod nazwą Transaction Signatures (RFC 2845) której wdrożenie jest przedsięwzięciem prostszym. Mechanizm ten nie jest częścią specyfikacji DNSSEC, z uwagi na jego obecność w powszechnie stosowanym oprogramowaniu BIND oraz wspomnianą łatwość użycia warto wspomnieć o jego głównych cechach. Podstawowe założenie działania TSIG polega na użyciu wspólnego, klucza prywatnego (tzw. Shared Secret) zarówno do generowania jak i weryfikacji podpisu. Jest on stosowany zarówno w procesie transferu stref, obsługi zapytań jak i dynamicznych uaktualnień. W sytuacjach stosowania tego rozwiązania w większych układach sieciowych, należy zapewnić bezpieczną metodę przesłania klucza. Jest to zagadnienie istotne, w RR o nazwie TKEY określa się sposób wymiany oraz późniejszego usuwania takiego klucza (RFC 2930). Dla oprogramowania BIND TKEY implementuje wyłącznie standard Diffie-Helman) Weryfikacja źródła poprzez stosowanie TSIG jest szczególnie ważna dla transakcji typu DNS UPDATE odbywającej się z wykorzystaniem nieodpornego na spoofing protokołu UDP. W czasie takich dynamicznych uaktualnień konieczna jest bowiem zmiana treści udostępnianych przez system DNS.
Należy zauważyć że poza faktem że TSIG nie stanowi części standardu DNSSEC nie jest on rekordem typu RR i nie stanowi części zony. Skutkiem tego nie zdefiniowano dla niego atrybutu w ramach dnsZone schema.
Poniższa lista przedstawia zestaw rekordów w ramach strefy nie wykorzystującej rozszerzeń bezpieczeństwa
example. SOA ...
example. NS ...
a.example. A ...
d.example. A ...
y.example. A ...
Kolejna lista pokazuje dodatkowe rekordy KEY i SIG świadczące o tym że strefa korzysta z DNS SEC
example. SOA ...
example. SIG SOA ...
example. NS ...
example. SIG NS ...
example. KEY ...
example. SIG KEY ...
a.example. A ...
a.example. SIG A ...
d.example. A ...
d.example. SIG A ...
y.example. A ...
y.example. SIG A ...
Domyślnie, dostępna w dystrybucji OpenLDAP cosine schema definiuje następujące atrybuty dla przechowywania rekordów DNS:
Ponadto zdefiniowano tam klasę obiektu dNSDomain (0.9.234.19200300.100.4.15) pełniącą rolę kontenera dla powyższych atrybutów. Atrybuty zdefiniowane w cosine schema pozwalają na przechowywanie jedynie informacji związanych z podstawowymi rekordami DNS (MX, SOA, NS, A oraz CNAME). Dla obsłużenie większej liczby rekordów DNS zdefiniowano dnsZone schema zawierającą dodatkowe klasy:
dNSTTL (1.3.6.1.4.1.2428.20.0.0) dNSClass (1.3.6.1.4.1.2428.20.0.1) zoneName (1.3.6.1.4.1.2428.20.0.2) relativeDomainName (1.3.6.1.4.1.2428.20.0.3)
i atrybuty:
Dla przechowywania w DIT danych DNS konieczne jest załadowanie zarówno cosine schema jak i DnsZone schema. Istotny jest fakt że przyjęty system numeracji umożliwia tworzenie nowych atrybutów niezdefiniowanych w DnsZone schema.
Biorąc pod uwagę wcześniejsze wnioski dotyczące zastosowania LDAPa jako systemu wspomagającego DNS spośród analizowanych narzędzi wybraliśmy oprogramowanie LDAP sdb backend dla BIND. Wybór oprogramowania BIND wynika z faktu jego dużej popularności jak również faktu że od wersji 9 posiada on mechanizm sdb backend pozwalający na wykorzystanie LDAPa jak również innych systemów końcowych do przechowywania danych DNS.
Środowisko wykorzystane do testów składało się z następujących elementów:
Dwa komputery: Sun (SUNU1, SUNU2)
System operacyjny: Solaris 2.6
aplikacje: OpenLDAP 2.0.23
aplikacje pomocnicze: OpenSSL 0.9.6d, libODBC
Dwa komputery PC (PC1, PC2):
System operacyjny : Linux (Debian)
System operacyjny: FreeBSD 4.5
aplikacje: BIND 9.2.1
aplikacje pomocnicze (biblioteki):
OpenLDAP 2.0.23
OpenSSL 0.9.6d
Topologia układu testowego wyglądała następująco:
SUN1 i SUN2 (Komputery z OpenLDAP)
Pecet1, Pecet2 Komputery z Bind
W ramach prac laboratoryjnych doświadczalnie sprawdzono warianty działania modelu on-line dla DNS i DNSSEC. Główny kierunek prowadzonych testów to badanie cech rozwiązania on-line. Model off-line dotyczący generacji plików dla BIND ze strefy przechowywanej w LDAP przy wykorzystaniu narzędzia LDAP2DNS uznaliśmy za mechanizm stosunkowo prosty, dlatego też nie został on włączony do zakresu testów. Innym powodem tej decyzji była konieczność zastosowania starszej wersji BIND (8) nie posiadającej cech wersji 9.
model "online"
W modelu tym LDAP występuje jako baza do której DNS (bind) odwołuje się w trybie online.
Dla ułatwienia procesu migracji wraz z oprogramowaniem BIND jako CONTRIB (podobnie jak moduł współpracy z LDAP) dołączone zostało oprogramowanie zone2ldap pozwalające w oparciu o DNSZone schema na import plików stref w formacie BIND do drzewa LDAP.
Działanie narzędzia sprawdzono na strefie certlab.nask.pl obsługiwanej przez PNS pecet1.certlab.nask.pl
Plik /var/named/P/certlab.nask.pl
@ IN SOA certlab.nask.pl. root.pecet1.certlab.nask.pl. (
2002062000
28800
7200
3600000
86400 )
certlab.nask.pl. IN NS pecet1.certlab.nask.pl.
certlab.nask.pl. IN NS pecet2.certlab.nask.pl.
; MX 10 mail.certlab.nask.pl.
;
localhost A 127.0.0.1
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
bri A 10.20.31.1
commserv A 10.20.31.2
c3640 A 10.20.31.3
c1750 A 10.20.31.4
sunu1 A 10.20.31.5
netra A 10.20.31.6
pecet1 A 10.20.31.7
pecet2 A 10.20.31.8
cat2924 A 10.20.31.9
; konsole
cat2924-c A 10.20.31.201
c3640-c A 10.20.31.202
c1750-c A 10.20.31.203
sunu1-c A 10.20.31.204
netra-c A 10.20.31.205
pecet1-c A 10.20.31.206
pecet2-c A 10.20.31.207
oraz domenie odwrotnej
Plik /var/named/P/10.20.31
@ IN SOA certlab.nask.pl. root.certlab.nask.pl. (
2002062000
28800
7200
604800
86400 )
NS pecet1.certlab.nask.pl.
NS pecet2.certlab.nask.pl.
; VTY
1 PTR bri.certlab.nask.pl.
2 PTR commserv.certlab.nask.pl.
3 PTR c3640.certlab.nask.pl.
4 PTR c1750.certlab.nask.pl.
5 PTR sunu1.certlab.nask.pl.
6 PTR netra.certlab.nask.pl.
7 PTR pecet1.certlab.nask.pl.
8 PTR pecet2.certlab.nask.pl.
9 PTR cat2924.certlab.nask.pl.
; Konsolki
201 PTR cat2924-c.certlab.nask.pl.
202 PTR c3640-c.certlab.nask.pl.
203 PTR c1750-c.certlab.nask.pl.
204 PTR sunu1-c.certlab.nask.pl.
205 PTR netra-c.certlab.nask.pl.
206 PTR pecet1-c.certlab.nask.pl.
207 PTR pecet2-c.certlab.nask.pl.
Dla wykonania importu plików do drzewa LDAP należy wywołać program zone2ldap
Na PNS wydano polecenia:
zone2ldap -D cn=Manager,dc=nask,dc=pl -b dc=nask,dc=pl -w secret -h 10.20.31.5 -z certlab.nask.pl -f certlab.nask.pl -c -d
(import strefy certlab.nask.pl)
zone2ldap -D cn=Manager,dc=nask,dc=pl -b dc=nask,dc=pl -w secret -h 10.20.31.5 -z 10.20.31 -f 10.20.31 -c -d
(import domeny odwrotnej)
Sprawdzenie poprawności przeniesienia danych zostało wykonane za pomocą polecenia listującego zawartość drzewa LDAP.
ldapsearch -u -x -b 'dc=nask,dc=pl' 'objectclass=*'
wynik polecenia:
version: 2 # # filter: objectclass=* # requesting: ALL # # nask, pl dn: dc=nask,dc=pl ufn: nask, pl dc: nask objectClass: dcObject objectClass: organization o: nask # Manager, nask, pl dn: cn=Manager, dc=nask,dc=pl ufn: Manager, nask, pl uid: Manager objectClass: organizationalRole cn: Manager # Bind, nask, pl dn: cn=Bind, dc=nask,dc=pl ufn: Bind, nask, pl userPassword:: e1NIQX01ZW42RzZNZXpScm9UM1hLcWtkUE9tWS9CZlE9 objectClass: top objectClass: person # pl, nask, pl dn: dc=pl,dc=nask,dc=pl ufn: pl, nask, pl objectClass: top # nask, pl, nask, pl dn: dc=nask,dc=pl,dc=nask,dc=pl ufn: nask, pl, nask, pl objectClass: top # certlab, nask, pl, nask, pl dn: dc=certlab,dc=nask,dc=pl,dc=nask,dc=pl ufn: certlab, nask, pl, nask, pl objectClass: top # sunu1-c, certlab, nask, pl, nask, pl dn: relativeDomainName=sunu1-c,dc=certlab,dc=nask,dc=pl,dc=nask,dc=pl ufn: sunu1-c, certlab, nask, pl, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: sunu1-c aRecord: 10.20.31.204 dNSTTL: 86400 zoneName: certlab.nask.pl # sunu1, certlab, nask, pl, nask, pl dn: relativeDomainName=sunu1,dc=certlab,dc=nask,dc=pl,dc=nask,dc=pl ufn: sunu1, certlab, nask, pl, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: sunu1 aRecord: 10.20.31.5 dNSTTL: 86400 zoneName: certlab.nask.pl # pecet2-c, certlab, nask, pl, nask, pl dn: relativeDomainName=pecet2-c,dc=certlab,dc=nask,dc=pl,dc=nask,dc=pl ufn: pecet2-c, certlab, nask, pl, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: pecet2-c aRecord: 10.20.31.207 dNSTTL: 86400 zoneName: certlab.nask.pl # pecet2, certlab, nask, pl, nask, pl dn: relativeDomainName=pecet2,dc=certlab,dc=nask,dc=pl,dc=nask,dc=pl ufn: pecet2, certlab, nask, pl, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: pecet2 aRecord: 10.20.31.8 dNSTTL: 86400 zoneName: certlab.nask.pl # pecet1-c, certlab, nask, pl, nask, pl dn: relativeDomainName=pecet1-c,dc=certlab,dc=nask,dc=pl,dc=nask,dc=pl ufn: pecet1-c, certlab, nask, pl, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: pecet1-c aRecord: 10.20.31.206 dNSTTL: 86400 zoneName: certlab.nask.pl # pecet1, certlab, nask, pl, nask, pl dn: relativeDomainName=pecet1,dc=certlab,dc=nask,dc=pl,dc=nask,dc=pl ufn: pecet1, certlab, nask, pl, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: pecet1 aRecord: 10.20.31.7 dNSTTL: 86400 zoneName: certlab.nask.pl # netra-c, certlab, nask, pl, nask, pl dn: relativeDomainName=netra-c,dc=certlab,dc=nask,dc=pl,dc=nask,dc=pl ufn: netra-c, certlab, nask, pl, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: netra-c aRecord: 10.20.31.205 dNSTTL: 86400 zoneName: certlab.nask.pl # netra, certlab, nask, pl, nask, pl dn: relativeDomainName=netra,dc=certlab,dc=nask,dc=pl,dc=nask,dc=pl ufn: netra, certlab, nask, pl, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: netra aRecord: 10.20.31.6 dNSTTL: 86400 zoneName: certlab.nask.pl # localhost, certlab, nask, pl, nask, pl dn: relativeDomainName=localhost,dc=certlab,dc=nask,dc=pl,dc=nask,dc=pl ufn: localhost, certlab, nask, pl, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: localhost aRecord: 127.0.0.1 dNSTTL: 86400 zoneName: certlab.nask.pl # commserv, certlab, nask, pl, nask, pl dn: relativeDomainName=commserv,dc=certlab,dc=nask,dc=pl,dc=nask,dc=pl ufn: commserv, certlab, nask, pl, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: commserv aRecord: 10.20.31.2 dNSTTL: 86400 zoneName: certlab.nask.pl # cat2924-c, certlab, nask, pl, nask, pl dn: relativeDomainName=cat2924-c,dc=certlab,dc=nask,dc=pl,dc=nask,dc=pl ufn: cat2924-c, certlab, nask, pl, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: cat2924-c aRecord: 10.20.31.201 dNSTTL: 86400 zoneName: certlab.nask.pl # cat2924, certlab, nask, pl, nask, pl dn: relativeDomainName=cat2924,dc=certlab,dc=nask,dc=pl,dc=nask,dc=pl ufn: cat2924, certlab, nask, pl, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: cat2924 aRecord: 10.20.31.9 dNSTTL: 86400 zoneName: certlab.nask.pl # c3640-c, certlab, nask, pl, nask, pl dn: relativeDomainName=c3640-c,dc=certlab,dc=nask,dc=pl,dc=nask,dc=pl ufn: c3640-c, certlab, nask, pl, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: c3640-c aRecord: 10.20.31.202 dNSTTL: 86400 zoneName: certlab.nask.pl # c3640, certlab, nask, pl, nask, pl dn: relativeDomainName=c3640,dc=certlab,dc=nask,dc=pl,dc=nask,dc=pl ufn: c3640, certlab, nask, pl, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: c3640 aRecord: 10.20.31.3 dNSTTL: 86400 zoneName: certlab.nask.pl # c1750-c, certlab, nask, pl, nask, pl dn: relativeDomainName=c1750-c,dc=certlab,dc=nask,dc=pl,dc=nask,dc=pl ufn: c1750-c, certlab, nask, pl, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: c1750-c aRecord: 10.20.31.203 dNSTTL: 86400 zoneName: certlab.nask.pl # c1750, certlab, nask, pl, nask, pl dn: relativeDomainName=c1750,dc=certlab,dc=nask,dc=pl,dc=nask,dc=pl ufn: c1750, certlab, nask, pl, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: c1750 aRecord: 10.20.31.4 dNSTTL: 86400 zoneName: certlab.nask.pl # bri, certlab, nask, pl, nask, pl dn: relativeDomainName=bri,dc=certlab,dc=nask,dc=pl,dc=nask,dc=pl ufn: bri, certlab, nask, pl, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: bri aRecord: 10.20.31.1 dNSTTL: 86400 zoneName: certlab.nask.pl # @ + 86400, certlab, nask, pl, nask, pl dn: relativeDomainName=@ + dNSTTL=86400,dc=certlab,dc=nask,dc=pl,dc=nask,dc=pl ufn: @ + 86400, certlab, nask, pl, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: @ sOARecord: certlab.nask.pl. root.pecet1.certlab.nask.pl. 2002062000 28800 7200 3600000 86400 dNSTTL: 86400 zoneName: certlab.nask.pl nSRecord: pecet1.certlab.nask.pl. nSRecord: pecet2.certlab.nask.pl. # arpa, nask, pl dn: dc=arpa,dc=nask,dc=pl ufn: arpa, nask, pl objectClass: top # in-addr, arpa, nask, pl dn: dc=in-addr,dc=arpa,dc=nask,dc=pl ufn: in-addr, arpa, nask, pl objectClass: top # 10, in-addr, arpa, nask, pl dn: dc=10,dc=in-addr,dc=arpa,dc=nask,dc=pl ufn: 10, in-addr, arpa, nask, pl objectClass: top # 20, 10, in-addr, arpa, nask, pl dn: dc=20,dc=10,dc=in-addr,dc=arpa,dc=nask,dc=pl ufn: 20, 10, in-addr, arpa, nask, pl objectClass: top # 31, 20, 10, in-addr, arpa, nask, pl dn: dc=31,dc=20,dc=10,dc=in-addr,dc=arpa,dc=nask,dc=pl ufn: 31, 20, 10, in-addr, arpa, nask, pl objectClass: top # 9, 31, 20, 10, in-addr, arpa, nask, pl dn: relativeDomainName=9,dc=31,dc=20,dc=10,dc=in-addr,dc=arpa,dc=nask,dc=pl ufn: 9, 31, 20, 10, in-addr, arpa, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: 9 pTRRecord: cat2924.certlab.nask.pl. dNSTTL: 86400 zoneName: 31.20.10.in-addr.arpa # 8, 31, 20, 10, in-addr, arpa, nask, pl dn: relativeDomainName=8,dc=31,dc=20,dc=10,dc=in-addr,dc=arpa,dc=nask,dc=pl ufn: 8, 31, 20, 10, in-addr, arpa, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: 8 pTRRecord: pecet2.certlab.nask.pl. dNSTTL: 86400 zoneName: 31.20.10.in-addr.arpa # 7, 31, 20, 10, in-addr, arpa, nask, pl dn: relativeDomainName=7,dc=31,dc=20,dc=10,dc=in-addr,dc=arpa,dc=nask,dc=pl ufn: 7, 31, 20, 10, in-addr, arpa, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: 7 pTRRecord: pecet1.certlab.nask.pl. dNSTTL: 86400 zoneName: 31.20.10.in-addr.arpa # 6, 31, 20, 10, in-addr, arpa, nask, pl dn: relativeDomainName=6,dc=31,dc=20,dc=10,dc=in-addr,dc=arpa,dc=nask,dc=pl ufn: 6, 31, 20, 10, in-addr, arpa, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: 6 pTRRecord: netra.certlab.nask.pl. dNSTTL: 86400 zoneName: 31.20.10.in-addr.arpa # 5, 31, 20, 10, in-addr, arpa, nask, pl dn: relativeDomainName=5,dc=31,dc=20,dc=10,dc=in-addr,dc=arpa,dc=nask,dc=pl ufn: 5, 31, 20, 10, in-addr, arpa, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: 5 pTRRecord: sunu1.certlab.nask.pl. dNSTTL: 86400 zoneName: 31.20.10.in-addr.arpa # 4, 31, 20, 10, in-addr, arpa, nask, pl dn: relativeDomainName=4,dc=31,dc=20,dc=10,dc=in-addr,dc=arpa,dc=nask,dc=pl ufn: 4, 31, 20, 10, in-addr, arpa, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: 4 pTRRecord: c1750.certlab.nask.pl. dNSTTL: 86400 zoneName: 31.20.10.in-addr.arpa # 3, 31, 20, 10, in-addr, arpa, nask, pl dn: relativeDomainName=3,dc=31,dc=20,dc=10,dc=in-addr,dc=arpa,dc=nask,dc=pl ufn: 3, 31, 20, 10, in-addr, arpa, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: 3 pTRRecord: c3640.certlab.nask.pl. dNSTTL: 86400 zoneName: 31.20.10.in-addr.arpa # 207, 31, 20, 10, in-addr, arpa, nask, pl dn: relativeDomainName=207,dc=31,dc=20,dc=10,dc=in-addr,dc=arpa,dc=nask,dc=pl ufn: 207, 31, 20, 10, in-addr, arpa, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: 207 pTRRecord: pecet2-c.certlab.nask.pl. dNSTTL: 86400 zoneName: 31.20.10.in-addr.arpa # 206, 31, 20, 10, in-addr, arpa, nask, pl dn: relativeDomainName=206,dc=31,dc=20,dc=10,dc=in-addr,dc=arpa,dc=nask,dc=pl ufn: 206, 31, 20, 10, in-addr, arpa, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: 206 pTRRecord: pecet1-c.certlab.nask.pl. dNSTTL: 86400 zoneName: 31.20.10.in-addr.arpa # 205, 31, 20, 10, in-addr, arpa, nask, pl dn: relativeDomainName=205,dc=31,dc=20,dc=10,dc=in-addr,dc=arpa,dc=nask,dc=pl ufn: 205, 31, 20, 10, in-addr, arpa, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: 205 pTRRecord: netra-c.certlab.nask.pl. dNSTTL: 86400 zoneName: 31.20.10.in-addr.arpa # 204, 31, 20, 10, in-addr, arpa, nask, pl dn: relativeDomainName=204,dc=31,dc=20,dc=10,dc=in-addr,dc=arpa,dc=nask,dc=pl ufn: 204, 31, 20, 10, in-addr, arpa, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: 204 pTRRecord: sunu1-c.certlab.nask.pl. dNSTTL: 86400 zoneName: 31.20.10.in-addr.arpa # 203, 31, 20, 10, in-addr, arpa, nask, pl dn: relativeDomainName=203,dc=31,dc=20,dc=10,dc=in-addr,dc=arpa,dc=nask,dc=pl ufn: 203, 31, 20, 10, in-addr, arpa, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: 203 pTRRecord: c1750-c.certlab.nask.pl. dNSTTL: 86400 zoneName: 31.20.10.in-addr.arpa # 202, 31, 20, 10, in-addr, arpa, nask, pl dn: relativeDomainName=202,dc=31,dc=20,dc=10,dc=in-addr,dc=arpa,dc=nask,dc=pl ufn: 202, 31, 20, 10, in-addr, arpa, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: 202 pTRRecord: c3640-c.certlab.nask.pl. dNSTTL: 86400 zoneName: 31.20.10.in-addr.arpa # 201, 31, 20, 10, in-addr, arpa, nask, pl dn: relativeDomainName=201,dc=31,dc=20,dc=10,dc=in-addr,dc=arpa,dc=nask,dc=pl ufn: 201, 31, 20, 10, in-addr, arpa, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: 201 pTRRecord: cat2924-c.certlab.nask.pl. dNSTTL: 86400 zoneName: 31.20.10.in-addr.arpa # 2, 31, 20, 10, in-addr, arpa, nask, pl dn: relativeDomainName=2,dc=31,dc=20,dc=10,dc=in-addr,dc=arpa,dc=nask,dc=pl ufn: 2, 31, 20, 10, in-addr, arpa, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: 2 pTRRecord: commserv.certlab.nask.pl. dNSTTL: 86400 zoneName: 31.20.10.in-addr.arpa # 1, 31, 20, 10, in-addr, arpa, nask, pl dn: relativeDomainName=1,dc=31,dc=20,dc=10,dc=in-addr,dc=arpa,dc=nask,dc=pl ufn: 1, 31, 20, 10, in-addr, arpa, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: 1 pTRRecord: bri.certlab.nask.pl. dNSTTL: 86400 zoneName: 31.20.10.in-addr.arpa # @ + 86400, 31, 20, 10, in-addr, arpa, nask, pl dn: relativeDomainName=@ + dNSTTL=86400,dc=31,dc=20,dc=10,dc=in-addr,dc=arpa,dc=nask,dc=pl ufn: @ + 86400, 31, 20, 10, in-addr, arpa, nask, pl objectClass: top objectClass: dNSZone relativeDomainName: @ sOARecord: certlab.nask.pl. root.certlab.nask.pl. 2002062000 28800 7200 604800 86400 dNSTTL: 86400 zoneName: 31.20.10.in-addr.arpa nSRecord: pecet1.certlab.nask.pl. nSRecord: pecet2.certlab.nask.pl. # search result search: 2 result: 0 Success # numResponses: 47 # numEntries: 46
domena certlab.nask.pl jak i domena odwrotna została prawidłowo zaimportowana do DIT LDAPa na serwerze sun.
Poglądowy schemat przedstawiający przebieg testu
Przebieg zilustrowanego procesu jest następujący. Stacja robocza wysyła do
serwera PNS zapytanie dotyczące RR w strefie certalb.nask.pl
(1). Następnie DNS na podstawie pliku konfiguracyjnego bind?a
wskazuje serwer LDAP jako źródło informacji o szukanej domenie i przesyła
do niego otrzymane zapytanie(2). W wyniku przeszukania DIT
do serwera PNS zwracany jest żądany RR (3). PNS odsyła rekord stacji
roboczej (4)
Wskazanie w pliku konfiguracyjnych binda odwołania do serwera jest
stosunkowo proste. W sekcji pliku konfiguracyjnego bind?a
dotyczącej obsługi strefy certalab.nask.pl należy umieścić
wpis (wyróżniony italic bold) wskazujący serwer LDAP jako źródło
danych o tej domenie.
Fragment pliku /etc/named.conf
zone "certlab.nask.pl" IN {
type master;
database "ldap ldap://10.20.31.5/dc=nask,dc=pl 172800";
// file "P/certlab.nask.pl";
allow-update {
secondary_wew;
};
allow-transfer {
secondary_wew;
};
allow-query {
cert_lan;
};
Linia poniżej wpisu wskazuje plik z którego w typowym procesie obsługi
zapytania (czyli przypadku braku odwołania do serwera LDAP) dane
te zostałyby pobrane.
Przy każdym zapytaniu o domenę kierowanym do DNS, bind przesyła zapytanie
do bazy LDAP przechowującej informacje o strukturze DNS.
Należy zwrócić uwagę że baza LDAP przeszukiwana jest każdorazowo
po odebraniu zapytania, z pominięciem typowego dla bind?a
mechanizmu sięgania do bufora (cache) zawierającego informacje będące
wynikiem poprzednich zapytań kierowanych do systemu. Różnica ta ma
znaczący wpływ na wydajność rozwiązania.
W ramach testów sprawdzono różne warianty współpracy systemów.
Główne wnioski wynikające z przeprowadzonych testów:
Dla sprawdzenia możliwości współpracy DNSSEC z LDAP dołożono do strefy cerlab.nask.pl rozszerzenia bezpieczeństwa i podobnie jak w poprzednim teście wykonano import strefy do systemu LDAP. Działanie powyższych mechanizmów sprawdzono na strefie certlab.nask.pl obsługiwanej przez PNS pecet1.certlab.nask.pl
Przygotowanie strefy wymagało wykonania następujących czynności
1. Generacji kluczy dla domen certlab.nask.pl i nask.pl
dnssec-keygen -a DSA -b 768 -n ZONE certlab.nask.pl.
dnssec-keygen -a DSA -b 768 -n ZONE nask.pl.
Dla zapewnienia mechanizmów zaufania konieczne jest wygenerowanie pary kluczy dla domeny wyższego rzędu (nask.pl). W wyniku powyższych poleceń powstały dwa komplety kluczy - prywatny i publiczny dla każdej ze stref. Powstały więc dwa pliki dla każdej pary:
Kcertlab.nask.pl.+003+12562.key
Kcertlab.nask.pl.+003+12562.private
Knask.pl.+003+31082.key
Knask.pl.+003+31082.private
Klucz publiczny służy weryfikacji podpisów klucz prywatny do ich tworzenia.
2. Następnie do strefy certlab.nask.pl dołączono wygenerowany dla niej klucz publiczny
$INCLUDE "/tmp/Kcertlab.nask.pl.+003+12562.key"
3. Następnie wygenerowano w oparciu o klucz publiczny strefy certlab.nask.pl wygenerowano tzw. Keyset
dnssec-makekeyset Kcertlab.nask.pl.+003+12562
(powstał plik key keyset-certlab.nask.pl.)
4. Keyset został podpisany kluczem domeny wyższego rzędu za pomocą polecenia
dnsec-signkey keyset-certlab.nask.pl.
(powstał plik key signedkey-certlab.nask.pl.)
5. Plik wynikowy został dołączony do strefy certlab.nask.pl
6. Proces podpisywania strefy certlab.nask.pl został zainicjowany poleceniem:
dnssec-signzone -o certlab.nask.pl certlab.nask.pl
(Powstał plik certlab.nask.pl.signed)
Podpisany plik strefy certlab.nask.pl został umieszczony w katalogu binda (/var/named/P/certlab.nask.pl), wygląda on następująco:
dnssec_signzone version 9.2.1
certlab.nask.pl. 86400 IN SOA certlab.nask.pl. root.pecet1.certlab.nask.pl. (
2002062000 ; serial
28800 ; refresh (8 hours)
7200 ; retry (2 hours)
3600000 ; expire (5 weeks 6 days 16 hours)
86400 ; minimum (1 day)
)
86400 SIG SOA 3 3 86400 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BFP8sXKZdWJtv0QZ05jvdw81n3S5I5CozdLm
lg6cvFTlV8uJdVV7kVc= )
3600 NS pecet1.certlab.nask.pl.
3600 NS pecet2.certlab.nask.pl.
3600 SIG NS 3 3 3600 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BK3zgCXGKKWAb3hNg8Jp+LJoBfQYp/oYcyEm
yP3IopuovcBsJwyAvp4= )
3600 KEY 256 3 3 (
BNOPezcH+WxxFwQs+zpEAD9+KWJHn2osssnP
3TgSZHU/q2/r9SrIbM2rDnVZQf6YNLwzOpsc
eGj57EOhznyZ80ZXmC926SnL+wDssvi4AIf3
zODUJTE39XzfvbdIhNB5jmAtsraQF/DXASh6
Pz/3ms4PfPZ5dDQqHQwHXaClP98OYFKhe7a6
fSviSC/Fk8HQZKK0kJKJdqRHJVoS5dMXBvDW
x3ZH4cYTLH1YRvBDVM02to1fKHzkhRLvNbz9
rgefljFv6FGmllj/u39ZnQxsRCQxyraMDSEe
E35Tzg9Ux4J1NYoxtKINnf2HknaVlFt9S5Sc
4VlTAUUASrjnO/wuKNUB/ea6ecsPbZsYHx1l
OV7rWC3F/0nvhBXd+wehnsy2PAyIlGByRV0n
F7d/Eraeo2t33TsU
) ; key id = 12562
3600 SIG KEY 3 3 3600 20021027165850 (
20020927165850 12562 certlab.nask.pl.
BFsjKK5H4qRdRZxmA07L+pABD2ttRdlWmzuK
aqWFHoxYTbGNfS3FQ1Q= )
3600 SIG KEY 3 3 3600 20021027165850 (
20020927165850 31082 nask.pl.
BCYzDAAI7QNlM2I4bK5lKZs5qh4W2p+pC1mv
vzHlyVYyJdDT0vq3RtI= )
86400 NXT bri.certlab.nask.pl. NS SOA SIG KEY NXT
86400 SIG NXT 3 3 86400 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BBmzXMbHAQXr0jAnds5Z4TlgfmL4U/1F/ggC
xuIqRVEEqWAM1E6Oi/A= )
bri.certlab.nask.pl. 3600 IN A 10.20.31.1
3600 SIG A 3 4 3600 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BHj4OyzZUFgDfpVqrtGrR/YUR/mznzlREb3W
5C/sbNO+Zv8LCNcySJk= )
86400 NXT c1750.certlab.nask.pl. A SIG NXT
86400 SIG NXT 3 4 86400 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BMxmpPYRWJnCWxvwIbI/Z55u6yEeSEVr6Ik9
mDFNRDh6BLPb7sMuUgs= )
c1750.certlab.nask.pl. 3600 IN A 10.20.31.4
3600 SIG A 3 4 3600 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BG2y9pvYtqR20lRpOkBK6BI3rK7yboOeK9uI
XvD1xZsbkUhmKYjRIFg= )
86400 NXT c1750-c.certlab.nask.pl. A SIG NXT
86400 SIG NXT 3 4 86400 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BMWUm2LldKbeVsTGlxVuLYzfq/YiNArBHmao
QxEPQ6zEmPj8Hyh2e/g= )
c1750-c.certlab.nask.pl. 3600 IN A 10.20.31.203
3600 SIG A 3 4 3600 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BMsin/JiOMwy0N0rQlDDGD8wr0FQzcrdRTjM
FebUu5DL7bj+S7dQ9Tg= )
86400 NXT c3640.certlab.nask.pl. A SIG NXT
86400 SIG NXT 3 4 86400 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BC//Jsw3N3ti2Amk6wIvRt+Ac41tR6qyGFnY
FR/vPAcK9yNBqXeAkCw= )
c3640.certlab.nask.pl. 3600 IN A 10.20.31.3
3600 SIG A 3 4 3600 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BJn8rVxOlZMnarx3a2VQrbGr9Lh0aYvw97IL
tp9qvBcxm2fQmN8ZMCo= )
86400 NXT c3640-c.certlab.nask.pl. A SIG NXT
86400 SIG NXT 3 4 86400 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BMAZo3UWC+2Q1Tl0ocLLL46UUNWQKZCIusm+
A11NYUduRYnWDX+kAOI= )
c3640-c.certlab.nask.pl. 3600 IN A 10.20.31.202
3600 SIG A 3 4 3600 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BJxYl0ZviNKKwvvLghYNyvLfP8kehgQE4nbp
8rK+Rb7jn4yJ7y6XuB8= )
86400 NXT cat2924.certlab.nask.pl. A SIG NXT
86400 SIG NXT 3 4 86400 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BK7QRvrH4mzGIHslrdCa2ntWbEIioYm1wUJb
y8Z1qrMgonXZX2X0oAI= )
cat2924.certlab.nask.pl. 3600 IN A 10.20.31.9
3600 SIG A 3 4 3600 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BAr4RerKxFX/o3WvG32iz83lIIGed7c5zUON
w/JBB83X2Thj2CoFpY0= )
86400 NXT cat2924-c.certlab.nask.pl. A SIG NXT
86400 SIG NXT 3 4 86400 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BKd+3RLPH+Y2ueHB9eXRjeifjhgrr4XKZSUy
WLUKZrvPVk6Hytu/0Ak= )
cat2924-c.certlab.nask.pl. 3600 IN A 10.20.31.201
3600 SIG A 3 4 3600 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BNOJ7FnYskHla1b8yg95b7IGHg9QvNQMSObc
uO8LjddL0m7oZjH3DjI= )
86400 NXT commserv.certlab.nask.pl. A SIG NXT
86400 SIG NXT 3 4 86400 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BENwetjQ0fe+uyem51w17RHM6ws+fHDKn4lc
nBPIlOmp4Xf9sN3m4X4= )
commserv.certlab.nask.pl. 3600 IN A 10.20.31.2
3600 SIG A 3 4 3600 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BC5jSYJJoHI39GNEew7/+Zzc7iCvEb6kxsN3
STiDXGhWTA5IJQqaFsI= )
86400 NXT localhost.certlab.nask.pl. A SIG NXT
86400 SIG NXT 3 4 86400 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BIJfzr7VWU/3Av2Jknn2z5NqLlKVRdb58zSw
kFFNeH9I28MBGkCMdA0= )
localhost.certlab.nask.pl. 3600 IN A 127.0.0.1
3600 SIG A 3 4 3600 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BH3cq66ug9JlABn9VaMTFB1jus9ZexabRReL
7sdtWl7XB8N3tV1L1xE= )
86400 NXT netra.certlab.nask.pl. A SIG NXT
86400 SIG NXT 3 4 86400 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BItM/30TnKzlZwqVJaJ+/yY+o/T1bhZH7fVT
E41dEf+cLSuDrAHzayQ= )
netra.certlab.nask.pl. 3600 IN A 10.20.31.6
3600 SIG A 3 4 3600 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BNE7DS+FnxbUhbwzOBHp6mUgoXOnYfnAOpDT
j9UNdZcHQWREP6ts5BU= )
86400 NXT netra-c.certlab.nask.pl. A SIG NXT
86400 SIG NXT 3 4 86400 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BAJwzF0ut3LxvYvLTPg/rhZnszPIr46Z520n
+/WOS3UslFx8vKadhMo= )
netra-c.certlab.nask.pl. 3600 IN A 10.20.31.205
3600 SIG A 3 4 3600 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BM/xpOP/2zdxyFsxCu/lpFTeTPZEHzeUHNOd
Nc6KNzR0Dqn8augNicU= )
86400 NXT pecet1.certlab.nask.pl. A SIG NXT
86400 SIG NXT 3 4 86400 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BCzQ2Sb3neDX5xE1E7roRUsdpGwfaMEGkYns
mDySZUGVQ2o3x9u3weQ= )
pecet1.certlab.nask.pl. 3600 IN A 10.20.31.7
3600 SIG A 3 4 3600 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BIK0Cth9i8y0wn18VDZ8dqC7ejLHh96zoaI0
mAi+o8N1lBdL6jmdzGE= )
86400 NXT pecet1-c.certlab.nask.pl. A SIG NXT
86400 SIG NXT 3 4 86400 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BL/YzZL/UOS4HESnZy8fyZ3XJtn1gRW7gszs
GILoGIDmSgm8qF0STJE= )
pecet1-c.certlab.nask.pl. 3600 IN A 10.20.31.206
3600 SIG A 3 4 3600 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BH+tlDXjod12byMC3DDz71g6airwpz2gCq4n
n3kNRp1LW0gQRNCZ19Q= )
86400 NXT pecet2.certlab.nask.pl. A SIG NXT
86400 SIG NXT 3 4 86400 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BA/rAqeX1iCFdZ8GkSa1o7RxalkhtxKXnmRH
X1OoX239+hKff+beL/k= )
pecet2.certlab.nask.pl. 3600 IN A 10.20.31.8
3600 SIG A 3 4 3600 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BI7B9BfQSpgcaPnwFq/qAwfGh90nDTO2+GoO
Rb405A7fCeFomZ4pqA4= )
86400 NXT pecet2-c.certlab.nask.pl. A SIG NXT
86400 SIG NXT 3 4 86400 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BGWyVfzdEDMMKHPmPF7hjbpLaFp3OnGAYn4T
a+1MtU7Z14n2rtsofEY= )
pecet2-c.certlab.nask.pl. 3600 IN A 10.20.31.207
3600 SIG A 3 4 3600 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BAqwx6GV+fy+fn7VXlhTRo4n/sTtg+WBZ9B0
JSX1pxDQ8vIXnXs8rtU= )
86400 NXT sunu1.certlab.nask.pl. A SIG NXT
86400 SIG NXT 3 4 86400 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BM9bqElQk/OZQpmrMsgjA4jrQgXJv10uf3at
hFlVNl9tJKN9KLgPirY= )
sunu1.certlab.nask.pl. 3600 IN A 10.20.31.5
3600 SIG A 3 4 3600 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BBVFThi/0WYtpXqxCzp6yYvrSWDfuxTJT0xo
QvsgFv0isMUqPRUDY64= )
86400 NXT sunu1-c.certlab.nask.pl. A SIG NXT
86400 SIG NXT 3 4 86400 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BHx+DIPk0I8s6Aq7Uyu9ST5yh+buTwOejTjF
Z1/u2WVcq304LDu4rb8= )
sunu1-c.certlab.nask.pl. 3600 IN A 10.20.31.204
3600 SIG A 3 4 3600 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BIb/onqpGGR9cYpJqktDdysENri2v3VsKktR
T4cyrpNn7G8I0dWAUdc= )
86400 NXT certlab.nask.pl. A SIG NXT
86400 SIG NXT 3 4 86400 20021030130453 (
20020930130453 12562 certlab.nask.pl.
BM2EZZp0U6eJZm6Xce/FG6VqEaLXtuOEJi7+
wf9cIZsIgneh3LofcQw= )
Dla uaktywnienia mechanizmów DNSSEC należy w pliku named.conf dodać wpis
trusted-keys {
certlab.nask.pl. 256 3 3"BNOPezcH+WxxFwQs+zpEAD9+KWJHn2osssnP3TgSZHU/q2
/r9SrIbM2r DnVZQf6YNLwzOpsceGj57EOhznyZ80ZXmC926SnL+wDssvi4AIf3zODU
JTE39XzfvbdIhNB5jmAtsraQF/DXASh6Pz/3ms4PfPZ5dDQqHQwHXaCl
P98OYFKhe7a6fSviSC/Fk8HQZKK0kJKJdqRHJVoS5dMXBvDWx3ZH4cYT
LH1YRvBDVM02to1fKHzkhRLvNbz9rgefljFv6FGmllj/u39ZnQxsRCQx y
raMDSEeE35Tzg9Ux4J1NYoxtKINnf2HknaVlFt9S5Sc4VlTAUUASrjn
O/wuKNUB/ea6ecsPbZsYHx1lOV7rWC3F/0nvhBXd+wehnsy2PAyIlGBy RV0nF7d/Eraeo2t33TsU";
};
Dla wykonania importu plików do drzewa LDAP powtórnie użyto programu
zone2ldap.
Na PNS wydano polecenia importujące podpisaną strefę do drzewa LDAP:
zone2ldap -D cn=Manager,dc=nask,dc=pl -b dc=nask,dc=pl -w secret -h 10.20.31.5 -z certlab.nask.pl -f certlab.nask.pl -c -d
Poniższy debugging programu zone2ldap (opcja -d) pokazuje że pomimo umieszczenia w kolejce rekordy DNSSEC (przykładowe linie wyróżnione bold italic) nie zostały umieszczone w strukturze LDAP
Initializing ISC Routines, parsing zone file
Adding relativeDomainName=@ + dNSTTL=86400,dc=certlab,dc=nask,dc=pl (SOA
certlab.nask.pl. root.pecet1.certlab.nask.pl. 2002062000 28800
7200 3600000 86400) to run queue list.
Adding relativeDomainName=@ + dNSTTL=86400,dc=certlab,dc=nask,dc=pl
(SIG SOA 3 3 86400 20021030130453 20020930130453 12562
certlab.nask.pl. BFP8sXKZdWJtv0QZ05jvdw81n3S5I5CozdLmlg6cvFTlV8uJdVV7kVc=)
to run queue list.
Adding relativeDomainName=@ + dNSTTL=3600,dc=certlab,dc=nask,dc=pl (NS
pecet1.certlab.nask.pl.) to run queue list.
Adding relativeDomainName=@ + dNSTTL=3600,dc=certlab,dc=nask,dc=pl (NS
pecet2.certlab.nask.pl.) to run queue list.
Adding relativeDomainName=@ + dNSTTL=3600,dc=certlab,dc=nask,dc=pl (SIG
NS 3 3 3600 20021030130453 20020930130453 12562 certlab.nask.pl.
BK3zgCXGKKWAb3hNg8Jp+LJoBfQYp/oYcyEmyP3IopuovcBsJwyAvp4=) to run queue list.
Adding relativeDomainName=@ + dNSTTL=3600,dc=certlab,dc=nask,dc=pl (KEY 256 3 3
BNOPezcH+WxxFwQs+zpEAD9+KWJHn2osssnP3TgSZHU/q2/r9SrIbM2r
DnVZQf6YNLwzOpsceGj57EOhznyZ80ZXmC926SnL+wDssvi4AIf3zODU
JTE39XzfvbdIhNB5jmAtsraQF/DXASh6Pz/3ms4PfPZ5dDQqHQwHXaCl
P98OYFKhe7a6fSviSC/Fk8HQZKK0kJKJdqRHJVoS5dMXBvDWx3ZH4cYT
LH1YRvBDVM02to1fKHzkhRLvNbz9rgefljFv6FGmllj/u39ZnQxsRCQx
yraMDSEeE35Tzg9Ux4J1NYoxtKINnf2HknaVlFt9S5Sc4VlTAUUASrjn
O/wuKNUB/ea6ecsPbZsYHx1lOV7rWC3F/0nvhBXd+wehnsy2PAyIlGBy RV0nF7d/Eraeo2t33TsU) to run queue list.
Adding relativeDomainName=@ + dNSTTL=3600,dc=certlab,dc=nask,dc=pl (SIG KEY 3 3 3600 20021027165850 20020927165850
12562 certlab.nask.pl. BFsjKK5H4qRdRZxmA07L+pABD2ttRdlWmzuKaqWFHoxYTbGNfS3FQ1Q=) to run queue list.
Adding relativeDomainName=@ + dNSTTL=3600,dc=certlab,dc=nask,dc=pl
(SIG KEY 3 3 3600 20021027165850 20020927165850 31082 nask.pl.
BCYzDAAI7QNlM2I4bK5lKZs5qh4W2p+pC1mvvzHlyVYyJdDT0vq3RtI=) to run queue list.
Adding relativeDomainName=@ + dNSTTL=86400,dc=certlab,dc=nask,dc=pl (NXT
bri.certlab.nask.pl. NS SOA SIG KEY NXT) to run queue list.
Adding relativeDomainName=@ + dNSTTL=86400,dc=certlab,dc=nask,dc=pl
(SIG NXT 3 3 86400 20021030130453 20020930130453 12562
certlab.nask.pl. BBmzXMbHAQXr0jAnds5Z4TlgfmL4U/1F/ggCxuIqRVEEqWAM1E6Oi/A=)
to run queue list.
Adding relativeDomainName=bri,dc=certlab,dc=nask,dc=pl (A 10.20.31.1)
to run queue list.
Adding relativeDomainName=bri,dc=certlab,dc=nask,dc=pl (SIG A 3 4 3600
20021030130453 20020930130453 12562 certlab.nask.pl.
BHj4OyzZUFgDfpVqrtGrR/YUR/mznzlREb3W5C/sbNO+Zv8LCNcySJk=) to run queue list.
Adding relativeDomainName=bri,dc=certlab,dc=nask,dc=pl
(NXT c1750.certlab.nask.pl. A SIG NXT) to run queue list.
Adding relativeDomainName=bri,dc=certlab,dc=nask,dc=pl
(SIG NXT 3 4 86400 20021030130453 20020930130453 12562
certlab.nask.pl. BMxmpPYRWJnCWxvwIbI/Z55u6yEeSEVr6Ik9mDFNRDh6BLPb7sMuUgs=)
to run queue list.
Adding relativeDomainName=c1750,dc=certlab,dc=nask,dc=pl (A 10.20.31.4) to
run queue list.
Adding relativeDomainName=c1750,dc=certlab,dc=nask,dc=pl (SIG A 3 4 3600
20021030130453 20020930130453 12562 certlab.nask.pl.
BG2y9pvYtqR20lRpOkBK6BI3rK7yboOeK9uIXvD1xZsbkUhmKYjRIFg=) to run queue list.
Adding relativeDomainName=c1750,dc=certlab,dc=nask,dc=pl
(NXT c1750-c.certlab.nask.pl. A SIG NXT) to run queue list.
Adding relativeDomainName=c1750,dc=certlab,dc=nask,dc=pl
(SIG NXT 3 4 86400 20021030130453 20020930130453 12562
certlab.nask.pl. BMWUm2LldKbeVsTGlxVuLYzfq/YiNArBHmaoQxEPQ6zEmPj8Hyh2e/g=)
to run queue list.
Adding relativeDomainName=c1750-c,dc=certlab,dc=nask,dc=pl
(A 10.20.31.203) to run queue list.
Adding relativeDomainName=c1750-c,dc=certlab,dc=nask,dc=pl (SIG A 3 4 3600
20021030130453 20020930130453 12562 certlab.nask.pl.
BMsin/JiOMwy0N0rQlDDGD8wr0FQzcrdRTjMFebUu5DL7bj+S7dQ9Tg=) to run queue list.
Adding relativeDomainName=c1750-c,dc=certlab,dc=nask,dc=pl
(NXT c3640.certlab.nask.pl. A SIG NXT) to run queue list.
Adding relativeDomainName=c1750-c,dc=certlab,dc=nask,dc=pl
(SIG NXT 3 4 86400 20021030130453 20020930130453 12562
certlab.nask.pl. BC//Jsw3N3ti2Amk6wIvRt+Ac41tR6qyGFnYFR/vPAcK9yNBqXeAkCw=)
to run queue list.
Adding relativeDomainName=c3640,dc=certlab,dc=nask,dc=pl (A 10.20.31.3) to
run queue list.
Adding relativeDomainName=c3640,dc=certlab,dc=nask,dc=pl (SIG A 3 4 3600
20021030130453 20020930130453 12562 certlab.nask.pl.
BJn8rVxOlZMnarx3a2VQrbGr9Lh0aYvw97ILtp9qvBcxm2fQmN8ZMCo=) to run queue list.
Adding relativeDomainName=c3640,dc=certlab,dc=nask,dc=pl
(NXT c3640-c.certlab.nask.pl. A SIG NXT) to run queue list.
Adding relativeDomainName=c3640,dc=certlab,dc=nask,dc=pl
(SIG NXT 3 4 86400 20021030130453 20020930130453 12562
certlab.nask.pl. BMAZo3UWC+2Q1Tl0ocLLL46UUNWQKZCIusm+A11NYUduRYnWDX+kAOI=)
to run queue list.
Adding relativeDomainName=c3640-c,dc=certlab,dc=nask,dc=pl
(A 10.20.31.202) to run queue list.
Adding relativeDomainName=c3640-c,dc=certlab,dc=nask,dc=pl (SIG A 3 4 3600
20021030130453 20020930130453 12562 certlab.nask.pl.
BJxYl0ZviNKKwvvLghYNyvLfP8kehgQE4nbp8rK+Rb7jn4yJ7y6XuB8=) to run queue list.
Adding relativeDomainName=c3640-c,dc=certlab,dc=nask,dc=pl
(NXT cat2924.certlab.nask.pl. A SIG NXT) to run queue list.
Adding relativeDomainName=c3640-c,dc=certlab,dc=nask,dc=pl
(SIG NXT 3 4 86400 20021030130453 20020930130453 12562
certlab.nask.pl. BK7QRvrH4mzGIHslrdCa2ntWbEIioYm1wUJby8Z1qrMgonXZX2X0oAI=)
to run queue list.
Adding relativeDomainName=cat2924,dc=certlab,dc=nask,dc=pl (A 10.20.31.9)
to run queue list.
Adding relativeDomainName=cat2924,dc=certlab,dc=nask,dc=pl (SIG A 3 4 3600
20021030130453 20020930130453 12562 certlab.nask.pl.
BAr4RerKxFX/o3WvG32iz83lIIGed7c5zUONw/JBB83X2Thj2CoFpY0=) to run queue list.
Adding relativeDomainName=cat2924,dc=certlab,dc=nask,dc=pl
(NXT cat2924-c.certlab.nask.pl. A SIG NXT) to run queue list.
Adding relativeDomainName=cat2924,dc=certlab,dc=nask,dc=pl
(SIG NXT 3 4 86400 20021030130453 20020930130453 12562
certlab.nask.pl. BKd+3RLPH+Y2ueHB9eXRjeifjhgrr4XKZSUyWLUKZrvPVk6Hytu/0Ak=)
to run queue list.
Adding relativeDomainName=cat2924-c,dc=certlab,dc=nask,dc=pl
(A 10.20.31.201) to run queue list.
Adding relativeDomainName=cat2924-c,dc=certlab,dc=nask,dc=pl (SIG A 3 4
3600 20021030130453 20020930130453 12562
certlab.nask.pl. BNOJ7FnYskHla1b8yg95b7IGHg9QvNQMSObcuO8LjddL0m7oZjH3DjI=)
to run queue list.
Adding relativeDomainName=cat2924-c,dc=certlab,dc=nask,dc=pl
(NXT commserv.certlab.nask.pl. A SIG NXT) to run queue list.
Adding relativeDomainName=cat2924-c,dc=certlab,dc=nask,dc=pl
(SIG NXT 3 4 86400 20021030130453 20020930130453 12562
certlab.nask.pl. BENwetjQ0fe+uyem51w17RHM6ws+fHDKn4lcnBPIlOmp4Xf9sN3m4X4=)
to run queue list.
Adding relativeDomainName=commserv,dc=certlab,dc=nask,dc=pl (A 10.20.31.2)
to run queue list.
Adding relativeDomainName=commserv,dc=certlab,dc=nask,dc=pl (SIG A 3 4
3600 20021030130453 20020930130453 12562
certlab.nask.pl. BC5jSYJJoHI39GNEew7/+Zzc7iCvEb6kxsN3STiDXGhWTA5IJQqaFsI=)
to run queue list.
Adding relativeDomainName=commserv,dc=certlab,dc=nask,dc=pl (NXT
localhost.certlab.nask.pl. A SIG NXT) to run queue list.
Adding relativeDomainName=commserv,dc=certlab,dc=nask,dc=pl (SIG NXT 3 4
86400 20021030130453 20020930130453 12562 certlab.nask.pl.
BIJfzr7VWU/3Av2Jknn2z5NqLlKVRdb58zSwkFFNeH9I28MBGkCMdA0=) to run queue list.
Adding relativeDomainName=localhost,dc=certlab,dc=nask,dc=pl (A 127.0.0.1)
to run queue list.
Adding relativeDomainName=localhost,dc=certlab,dc=nask,dc=pl (SIG A 3 4
3600 20021030130453 20020930130453 12562
certlab.nask.pl. BH3cq66ug9JlABn9VaMTFB1jus9ZexabRReL7sdtWl7XB8N3tV1L1xE=)
to run queue list.
Adding relativeDomainName=localhost,dc=certlab,dc=nask,dc=pl
(NXT netra.certlab.nask.pl. A SIG NXT) to run queue list.
Adding relativeDomainName=localhost,dc=certlab,dc=nask,dc=pl
(SIG NXT 3 4 86400 20021030130453 20020930130453 12562
certlab.nask.pl. BItM/30TnKzlZwqVJaJ+/yY+o/T1bhZH7fVTE41dEf+cLSuDrAHzayQ=)
to run queue list.
Adding relativeDomainName=netra,dc=certlab,dc=nask,dc=pl (A 10.20.31.6) to
run queue list.
Adding relativeDomainName=netra,dc=certlab,dc=nask,dc=pl (SIG A 3 4 3600
20021030130453 20020930130453 12562 certlab.nask.pl.
BNE7DS+FnxbUhbwzOBHp6mUgoXOnYfnAOpDTj9UNdZcHQWREP6ts5BU=) to run queue list.
Adding relativeDomainName=netra,dc=certlab,dc=nask,dc=pl
(NXT netra-c.certlab.nask.pl. A SIG NXT) to run queue list.
Adding relativeDomainName=netra,dc=certlab,dc=nask,dc=pl
(SIG NXT 3 4 86400 20021030130453 20020930130453 12562
certlab.nask.pl. BAJwzF0ut3LxvYvLTPg/rhZnszPIr46Z520n+/WOS3UslFx8vKadhMo=)
to run queue list.
Adding relativeDomainName=netra-c,dc=certlab,dc=nask,dc=pl
(A 10.20.31.205) to run queue list.
Adding relativeDomainName=netra-c,dc=certlab,dc=nask,dc=pl (SIG A 3 4 3600
20021030130453 20020930130453 12562 certlab.nask.pl.
BM/xpOP/2zdxyFsxCu/lpFTeTPZEHzeUHNOdNc6KNzR0Dqn8augNicU=) to run queue list.
Adding relativeDomainName=netra-c,dc=certlab,dc=nask,dc=pl
(NXT pecet1.certlab.nask.pl. A SIG NXT) to run queue list.
Adding relativeDomainName=netra-c,dc=certlab,dc=nask,dc=pl
(SIG NXT 3 4 86400 20021030130453 20020930130453 12562
certlab.nask.pl. BCzQ2Sb3neDX5xE1E7roRUsdpGwfaMEGkYnsmDySZUGVQ2o3x9u3weQ=)
to run queue list.
Adding relativeDomainName=pecet1,dc=certlab,dc=nask,dc=pl (A 10.20.31.7)
to run queue list.
Adding relativeDomainName=pecet1,dc=certlab,dc=nask,dc=pl (SIG A 3 4
3600 20021030130453 20020930130453 12562
certlab.nask.pl. BIK0Cth9i8y0wn18VDZ8dqC7ejLHh96zoaI0mAi+o8N1lBdL6jmdzGE=)
to run queue list.
Adding relativeDomainName=pecet1,dc=certlab,dc=nask,dc=pl (NXT
pecet1-c.certlab.nask.pl. A SIG NXT) to run queue list.
Adding relativeDomainName=pecet1,dc=certlab,dc=nask,dc=pl
(SIG NXT 3 4 86400 20021030130453 20020930130453 12562
certlab.nask.pl. BL/YzZL/UOS4HESnZy8fyZ3XJtn1gRW7gszsGILoGIDmSgm8qF0STJE=)
to run queue list.
Adding relativeDomainName=pecet1-c,dc=certlab,dc=nask,dc=pl
(A 10.20.31.206) to run queue list.
Adding relativeDomainName=pecet1-c,dc=certlab,dc=nask,dc=pl (SIG A 3 4
3600 20021030130453 20020930130453 12562
certlab.nask.pl. BH+tlDXjod12byMC3DDz71g6airwpz2gCq4nn3kNRp1LW0gQRNCZ19Q=)
to run queue list.
Adding relativeDomainName=pecet1-c,dc=certlab,dc=nask,dc=pl (NXT
pecet2.certlab.nask.pl. A SIG NXT) to run queue list.
Adding relativeDomainName=pecet1-c,dc=certlab,dc=nask,dc=pl (SIG NXT 3 4
86400 20021030130453 20020930130453 12562 certlab.nask.pl.
BA/rAqeX1iCFdZ8GkSa1o7RxalkhtxKXnmRHX1OoX239+hKff+beL/k=) to run queue list.
Adding relativeDomainName=pecet2,dc=certlab,dc=nask,dc=pl (A 10.20.31.8)
to run queue list.
Adding relativeDomainName=pecet2,dc=certlab,dc=nask,dc=pl (SIG A 3 4
3600 20021030130453 20020930130453 12562
certlab.nask.pl. BI7B9BfQSpgcaPnwFq/qAwfGh90nDTO2+GoORb405A7fCeFomZ4pqA4=)
to run queue list.
Adding relativeDomainName=pecet2,dc=certlab,dc=nask,dc=pl (NXT
pecet2-c.certlab.nask.pl. A SIG NXT) to run queue list.
Adding relativeDomainName=pecet2,dc=certlab,dc=nask,dc=pl
(SIG NXT 3 4 86400 20021030130453 20020930130453 12562
certlab.nask.pl. BGWyVfzdEDMMKHPmPF7hjbpLaFp3OnGAYn4Ta+1MtU7Z14n2rtsofEY=)
to run queue list.
Adding relativeDomainName=pecet2-c,dc=certlab,dc=nask,dc=pl
(A 10.20.31.207) to run queue list.
Adding relativeDomainName=pecet2-c,dc=certlab,dc=nask,dc=pl (SIG A 3 4
3600 20021030130453 20020930130453 12562
certlab.nask.pl. BAqwx6GV+fy+fn7VXlhTRo4n/sTtg+WBZ9B0JSX1pxDQ8vIXnXs8rtU=)
to run queue list.
Adding relativeDomainName=pecet2-c,dc=certlab,dc=nask,dc=pl (NXT
sunu1.certlab.nask.pl. A SIG NXT) to run queue list.
Adding relativeDomainName=pecet2-c,dc=certlab,dc=nask,dc=pl (SIG NXT 3 4
86400 20021030130453 20020930130453 12562 certlab.nask.pl.
BM9bqElQk/OZQpmrMsgjA4jrQgXJv10uf3athFlVNl9tJKN9KLgPirY=) to run queue list.
Adding relativeDomainName=sunu1,dc=certlab,dc=nask,dc=pl (A 10.20.31.5) to
run queue list.
Adding relativeDomainName=sunu1,dc=certlab,dc=nask,dc=pl (SIG A 3 4 3600
20021030130453 20020930130453 12562 certlab.nask.pl.
BBVFThi/0WYtpXqxCzp6yYvrSWDfuxTJT0xoQvsgFv0isMUqPRUDY64=) to run queue list.
Adding relativeDomainName=sunu1,dc=certlab,dc=nask,dc=pl
(NXT sunu1-c.certlab.nask.pl. A SIG NXT) to run queue list.
Adding relativeDomainName=sunu1,dc=certlab,dc=nask,dc=pl
(SIG NXT 3 4 86400 20021030130453 20020930130453 12562
certlab.nask.pl. BHx+DIPk0I8s6Aq7Uyu9ST5yh+buTwOejTjFZ1/u2WVcq304LDu4rb8=)
to run queue list.
Adding relativeDomainName=sunu1-c,dc=certlab,dc=nask,dc=pl
(A 10.20.31.204) to run queue list.
Adding relativeDomainName=sunu1-c,dc=certlab,dc=nask,dc=pl (SIG A 3 4 3600
20021030130453 20020930130453 12562 certlab.nask.pl.
BIb/onqpGGR9cYpJqktDdysENri2v3VsKktRT4cyrpNn7G8I0dWAUdc=) to run queue list.
Adding relativeDomainName=sunu1-c,dc=certlab,dc=nask,dc=pl
(NXT certlab.nask.pl. A SIG NXT) to run queue list.
Adding relativeDomainName=sunu1-c,dc=certlab,dc=nask,dc=pl
(SIG NXT 3 4 86400 20021030130453 20020930130453 12562
certlab.nask.pl. BM2EZZp0U6eJZm6Xce/FG6VqEaLXtuOEJi7+wf9cIZsIgneh3LofcQw=)
to run queue list.
Initializing LDAP Connection to 10.20.31.5 as cn=Manager,dc=nask,dc=pl
Creating base zone DN certlab.nask.pl
Adding DN: relativeDomainName=sunu1-c,dc=certlab,dc=nask,dc=pl
Adding DN: relativeDomainName=sunu1,dc=certlab,dc=nask,dc=pl
Adding DN: relativeDomainName=pecet2-c,dc=certlab,dc=nask,dc=pl
Adding DN: relativeDomainName=pecet2,dc=certlab,dc=nask,dc=pl
Adding DN: relativeDomainName=pecet1-c,dc=certlab,dc=nask,dc=pl
Adding DN: relativeDomainName=pecet1,dc=certlab,dc=nask,dc=pl
Adding DN: relativeDomainName=netra-c,dc=certlab,dc=nask,dc=pl
Adding DN: relativeDomainName=netra,dc=certlab,dc=nask,dc=pl
Adding DN: relativeDomainName=localhost,dc=certlab,dc=nask,dc=pl
Adding DN: relativeDomainName=commserv,dc=certlab,dc=nask,dc=pl
Adding DN: relativeDomainName=cat2924-c,dc=certlab,dc=nask,dc=pl
Adding DN: relativeDomainName=cat2924,dc=certlab,dc=nask,dc=pl
Adding DN: relativeDomainName=c3640-c,dc=certlab,dc=nask,dc=pl
Adding DN: relativeDomainName=c3640,dc=certlab,dc=nask,dc=pl
Adding DN: relativeDomainName=c1750-c,dc=certlab,dc=nask,dc=pl
Adding DN: relativeDomainName=c1750,dc=certlab,dc=nask,dc=pl
Adding DN: relativeDomainName=bri,dc=certlab,dc=nask,dc=pl
Adding DN: relativeDomainName=@ + dNSTTL=3600,dc=certlab,dc=nask,dc=pl
Adding DN: relativeDomainName=@ + dNSTTL=86400,dc=certlab,dc=nask,dc=pl
Operation Complete.
Polecenie którego poprzednio używaliśmy dla potwierdzenia poprawności transferu (ldapsearch -u -x -b 'dc=nask,dc=pl' 'objectclass=*') wykazało jedynie obecność uprzednio importowanych rekordów.
Główne wnioski wynikające z przeprowadzonych testów
Pomimo poprawnie podpisanej strefy oraz obecności w LDAP właściwej struktury dla danych DNS (DNSZone schema) narzędzie zone2ldap dostępne w oprogramowaniu bind w wersji 9.2.1 nie importuje prawidłowo rekordów związanych DNSSEC (NXT, SIG, KEY)[10] dla wszystkich wpisów w domenie. W obecnej chwili rozważamy poszerzenie funkcjonalności oprogramowania zone2ldap o tego typu funkcjonalność.
Wnioski z poszczególnych testów wykazują jak wiele różnych
aspektów i problemów związanych z DNS jak i jego
rozszerzeniami bezpieczeństwa, w kontekście współpracy z systemami
LDAP wymaga rozwiązania. Warto też podkreślić że obecność samego DNSSEC
jako standardu jest marginalna. Najbardziej rokujący wydaje się kierunek
związany z właściwościami DNS, już obecnie pozwalającymi na wskazywania
miejsca przechowywania i transport i kluczy publicznych. W
kontekście coraz śmielej wyłaniających się
pomysłów globalnej struktury klucza publicznego może być to kierunkiem
nowych zastosowań DNS. W takim kontekście LDAP występujący często jako
mechanizm, przechowywania i udostępniania kluczy może zyskać także zyskać
na znaczeniu.
Dlatego też prace mające na celu rozwijanie i badanie możliwości
współpracy tych systemów mogą zaowocować w przyszłości.
[1] Autorytatywny name serwer dla domeny to taki, który jest źródłem danych dotyczących tej domeny.
[2] PNS to skrót dla Primary Name Serwer; SNS to skrót dla Secondary Name Serwer
[3] Resolwer to zestaw programów stanowiący kliencką część systemu DNS, współuczestniczy on w procesie rozwiązywania nazw.
[4] W przypadku systemów Unix, informacja o tych name serwach znajdują się w pliku /etc/resolv.conf . Typowo plik ten jest modyfikowany ręcznie przez administratora systemu.
[5] Podręczną pamięć cache posiada każdy Name serwer i wykorzystuje ją do tymczasowego zapamiętywania informacji o domenach o które był już "pytany". Czas jaki dana domena jest pamiętana określa zmienna TTL. Wartość TTL jest parametrem konfiguracyjnym.
[6] Rysunek zaczerpnięty z książki "DNS and BIND" wyd.O'Reilly
[7] Ramka jest zbiorem pól przenoszących odpowiednie dane.
[8] Computer Emergency Response Team / Coordination Center (www.cert.org) to pierwsza na świecie organizacja powstała w USA dla zapewnienia reakcji na zdarzenia naruszające bezpieczeństwo systemów teleinformatycznych
[9] W Polsce TLD (.pl) jest obsługiwana przez Naukową i Akademicką Sieć Komputerową
[10] Z wyjątkiem rekordu SIG i NXT dla całej strefy certlab.nask.pl