Andrzej Chrząszcz, Witold Mikiciuk
Bogdan Motoszko, Maciej Siciarek
Naukowa i Akademicka Sieć Komputerowa NASK

DNS a usługa LDAP
- analiza funkcjonalności i wymagań instalacyjnych

(opracowanie przygotowane w ramach realizacji zadań projektu KBN)

Spis treści

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

1.1.1 Domain Name Service

1.1.1.1 Przykład działania systemu DNS

1.1.1.2 Optymalizacja i modele współpracy systemów DNS

1.1.1.3 Komunikacja i format wymiany informacji w systemie DNS

1.1.1.4 Konfiguracja systemu DNS

1.1.1.5 Oprogramowanie BIND

1.1.2 Problemy z DNS

1.1.3 Zasadność współpracy systemów DNS i LDAP

1.1.4 Główne modele współpracy systemów DNS i LDAP

1.1.5 Bezpieczeństwo w systemach LDAP i DNS

1.1.5.1 Zagrożenia i mechanizmy bezpieczeństwa w LDAP

1.1.5.2 Zagrożenia i mechanizmy bezpieczeństwa w DNS

1.1.6 Sposób udostępnienia danych DNS przechowywanych w bazach LDAP

1.1.7 LDAP jako system obsługi DNS

1.1.7.1 Mechanizm obsługi zapytań

1.1.7.2 Wykorzystanie pamięci podręcznej

1.1.8 Wnioski dotyczące pozycji i roli LDAPa

2 Analiza i dostosowanie wymagań stawianych usłudze katalogowej w zakresie wspomagania infrastruktury kluczy publicznych

2.1 Określenie wymagań wnoszonych przez usługę "bezpieczny DNS"

2.1.1 Bezpieczny DNS

2.1.1.1 Ataki i zagrożenia

2.1.1.2 Podstawy DNSSEC

2.1.1.3 Opis rekordów DNS SEC

2.1.1.4 Przykłady rekordów

2.1.2 Współpraca DNS i LDAP w praktyce

2.1.2.1 Wsparcie LDAP dla DNS

2.1.3 Analiza i testy narzędzi do współpracy systemów DNS i LDAP

2.1.3.1 Środowiska testowe

2.1.3.2 Przygotowanie systemów do testów

2.1.3.3 Opis testów

2.1.3.4 Model "on-line"

2.1.3.4.1 Testy zone2ldap

2.1.3.4.2 Testy odwołań DNS do danych LDAP

2.1.3.4.3 Testy DNSSEC z LDAP

2.1.3.5 Podsumowanie dotychczasowych testów DNS z LDAP

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

1.1.1 Domain Name Service

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:

hierarchia przestrzeni nazw (drzewo nazw domen)
serwery nazw (Name Serwer to proces odpowiedzialny za rozwiązywanie nazw)
resolwery (element systemu DNS inicjujący komunikację z Name Serwerami)

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.

1.1.1.1 Przykład działania systemu DNS

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.

1.1.1.3 Komunikacja i format wymiany informacji w systemie 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 PNS
RNAME - 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.

1.1.1.4 Konfiguracja systemu DNS

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.

1.1.1.5 Oprogramowanie BIND

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

1972 - pierwsze adresy IP przydzielone przez Department of Defense dla University of Southern California,
1983 - opracowanie dokumentu RFC881 "Domain names Plan and Schedule"
1984 - opracowanie systemu DNS (Paul Mockapetris)
1985 - kontrakt pomiędzy DDN NIC i USC na obsługę "DNS root"
1988 - powstaje IANA (Internet Assigned Numbers Authority, Jon Postel)
Czerwiec 1990 - utworzenie domeny .pl.
1990 - powołanie IANA - "Internet Assigned Numbers Authority"
Czerwiec 1991 - pierwsza rejestracja nazw w domenie .pl
1992 - przekazanie administracji domenami .com, org, .net, .edu, .gov do National Science Foundation, która powierza ich obsługę firmie Network Solutions
1996 - NSI umożliwia rejestrację w domenach .com, .org, .net podmiotom spoza USA
Listopad 1998 - zawiązuje się ICANN (The Internet Corporation for Assigned Names and Numbers), która stopniowo przejmuje funkcje IANA
Grudzień 1999 - NSI rozpoczyna rejestrację domen za pośrednictwem rejestratorów akredytowanych przez ICANN; wprowadzenie przez ICANN "Uniform Domain Name Dispute Resolution Policy"; ustanowienie arbitrażu w sprawach domen administrowanych przez NSI
2000 - pierwsze propozycje nowych gTLD
2001 - wprowadzenie nowych domen najwyższego poziomu

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

0819: Domain naming convention for Internet user applications.

0881: Domain names plan and schedule.

0897: Domain name system implementation schedule.

0920: Domain requirements.

0921: Domain name system implementation schedule - revised.

0952: DoD Internet host table specification.

1.1.2 Problemy z DNS

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).

1.1.3 Zasadność współpracy systemów DNS i LDAP

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.

1.1.4 Główne modele współpracy systemów DNS i LDAP

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:

brak potrzeby kłopotliwej "ręcznej" edycji i modyfikacji plików tekstowych
łatwość wykonywania repliki primary DNS (po zmianach generowany jest zestaw plików, które mogą być dystrybuowane )
centralizacja obróbki i gwarancja spójności wygenerowanych dla systemu DNS plików

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:

łatwe modyfikacje poszczególnych rekordów zony
możliwość zrealizowania większej liczby kombinacji np. 2 serwery LDAP, 2 DNS
możliwość łatwego tworzenia większej ilość serwerów przy jednoczesnym zachowaniu spójności danych

1.1.5 Bezpieczeństwo w systemach LDAP i DNS

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.

1.1.5.1 Zagrożenia i mechanizmy bezpieczeństwa w LDAP

Główne zagrożenia bezpieczeństwa systemu LDAP

Nieautoryzowany dostęp do danych poprzez operację "data fetching"
Nieautoryzowany dostęp do danych w wyniku uzycia danych uwierzytelniających pozyskanych poprzez monitorowanie uprawnionych użytkowników
Nieautoryzowana użytkownie lub/i modyfikacja danych
ieautoryzowana modyfikacja konfiguracji systemu
Spoofing jako technika pozyskania przez oporgramowanie klienta danych z serwera (serwer jest przekonany że komunikuje się z uprawnionym klientem)
Ataki na system operacyjny obsługujący bazę 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

Zwykłe uwierzytelnianie uzytkownika oparte o hasło
Uwierzytelnienie strony klienta w dialogu z serwerem
Aurtoryzacja ( w oparciu o ACL)
Zastosowanie SASL (Simple Authentication and Security Layer)

Ochrona transmisji

protokół SSL (Secure Socket Layer)na porcie 636 ( tzw. "LDAPS")
TLS (Transport Layer Security) na porcie 389

1.1.5.2 Zagrożenia i mechanizmy bezpieczeństwa w DNS

Zagrożenia bezpieczeństwa dotyczące systemu:

Ataki na kod name serwera
Ataki na system operacyjny serwera
Ataki typu "odmowa serwisu" (Denial of Service)
Ataki typu DNS spoofing
Ataki typu cache poisoning (wprowadzania do pamięci podręcznej nieprawdziwych informacji)

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

Restrykcje w zakresie uprawnień do transferu zon
Restrykcje w zakresie obsługi zapytań o rekordy w ramach zony
Możliwość ustawienia różnych trybów obsługi zapytań (rekursywność)
Zastosowanie mechanizmów dostępnych w DNSSEC (dodatkowe rekordy pozawalające na kryptograficznę weryfikację źródła i integralności danych)

1.1.6 Sposób udostępnienia danych DNS przechowywanych w bazach LDAP

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ą:

prostota konstrukcji drzewa i ogólnych zasad działania systemu
efektywny mechanizm cachowania
konstrukcja mechanizmu zapytań i wykorzystanie protokołu UDP
sprawność i wystarczająca szybkość działania wyszukiwań

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:

Do typowej postaci DNS dodawane są serwery LDAP jako system pomocniczy przechowujący dane DNS - wariant I (model on-line)
Powstaje nowe oprogramowania resolvera posiadające alternatywną funkcjonalność bezpośredniego przeszukiwania drzewa LDAP
Stopniowo w miarę dostosowywania aplikacji funkcję resolvera przejmuję klient LDAP. Dane o DNS wpisywane są na wprost do serwerów LDAP. Stosowany jest mechanizm replikacji pomiędzy serwerami LDAP
Całkowite przejście na wariant II

1.1.7 LDAP jako system obsługi DNS

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:

mechanizm obsługi zapytań
cachowanie

1.1.7.1 Mechanizm obsługi zapytań

Przeszukiwania DIT w LDAP może odbywać się według dwóch schematów:

Referal search obsługiwany przez klienta

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).

Dialog łańcuchowy serwerów (Serwer Chaining)

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.

1.1.7.2 Wykorzystanie pamięci podręcznej

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.

1.1.8 Wnioski dotyczące pozycji i roli LDAPa

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

2.1 Określenie wymagań wnoszonych przez usługę "bezpieczny DNS"

2.1.1 Bezpieczny DNS

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.

2.1.1.1 Ataki i zagrożenia

Do najbardziej istotnych zagrożeń i ataków na system DNS można zaliczyć:

Cache poisoning

W przypadku doprowadzenia do umieszczenia w pamięci podręcznej (cache) sfałszowanych informacji o parach nazwa-adres, atakujący może kontrolować (np. przekierować) ruch kierowany do prawdziwego serwisu. Według ankiety CERT/CC[8] aż 80 % serwerów obsługujących domeny najwyższego poziomu (tzw. Top Level Domain[9]) jest podatna na tego typu ataki.

Compromised data

Atakujący poprzez uzyskanie nieautoryzowanego dostępu do systemu modyfikuje zawartość serwera DNS. Znaczna część operatorów obsługujących TLD używa oprogramowania bind, w którym pomimo jego rozbudowanej funkcjonalności wykrywane są luki bezpieczeństwa. Według CERT/CC przynajmniej 20 % operatorów TLD używa wersji oprogramowania podatnej na ataki.

Denial of service

W przypadku szeroko zakrojonego ataku mającego na celu wykorzystanie zasobów obliczeniowych systemów obsługujących DNS atakujący może spowodować znaczne opóźnienia lub przerwy w jego działaniu.

Domain hijacking

Poprzez wpływanie lub nieuprawniony udział w procesie aktualizacji i obsługi systemu rejestracji domen, atakujący może przejąć prawa do kontroli tych domen.

2.1.1.2 Podstawy DNSSEC

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.

2.1.1.3 Opis rekordów DNSSEC

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.

2.1.1.4 Przykłady rekordów

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 ...

2.1.2 Współpraca DNS i LDAP w praktyce

2.1.2.1 Wsparcie LDAP dla DNS

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.

2.1.3 Analiza i testy narzędzi do współpracy systemów DNS i LDAP

2.1.3.1 Środowiska testowe

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:

2.1.3.2 Przygotowanie systemów do testów

SUN1 i SUN2 (Komputery z OpenLDAP)

openssl 0.9.6d
(config; make; make test; make install, przeniesienie bibliotek z .a do .so i przekopiowanie do katalogu /usr/local/lib)

unixodbc (pakiet - polecenie pkgadd)

Berkeley DB 3.2.9 (pakiet)

openldap
./configure --with-tls --enable-modules --enable-aci --enable-dynamic --enable-dnssrv --enable-ldap --enable-passwd --enable-shell --enable-sql

Pecet1, Pecet2 Komputery z Bind

openssl 0.9.6d
(config; make; make test; make install; przeniesienie bibliotek z .a do .so i wrzucenie do katalogu /usr/local/lib)

openldap
./configure --with-tls --enable-modules --enable-aci --enable-dynamic --enable-dnssrv --enable-ldap --enable-passwd --enable-shell

bind 9.1.2
(./configure --with-openssl=/usr/local/ssl --enable-libbind )

2.1.3.3 Opis testów

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.

2.1.3.4 Model "on-line"

model "online"

W modelu tym LDAP występuje jako baza do której DNS (bind) odwołuje się w trybie online.

2.1.3.4.1 Testy zone2ldap

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.

2.1.3.4.2 Testy odwołań DNS do danych LDAP

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:

prostsza modyfikacja poszczególnych rekordów strefy, brak jednak wygodnego mechanizmu do ich kompleksowej modyfikacji
możliwość realizowania większej ilości kombinacji (np. 2 serwery LDAP, 2 serwery DNS)
możliwość wzajemnej replikacji LDAP'ów dla uzyskania duplikacji danych DNS
nie można skonfigurować w BIND'zie odwołania do dwóch LDAP'ów obsługujących jedną zonę
każdorazowe odwołanie do LDAP'a - nie ma możliwości korzystania rekordów, które znalazły się w cachu
brak możliwości automatycznego uaktualniania pustej bazy z pełnej (mechanizm różnicowy replikacji)

2.1.3.4.3 Testy DNSSEC z LDAP

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ść.

2.1.3.5 Podsumowanie dotychczasowych testów DNS z LDAP

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

Pola nagłówka dotyczą:	typu zapytania (QTYPE),
	klasy pytania (QCLASS),
	pytania o nazwę domeny (QNAME)

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

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

DNS a usługa LDAP - analiza funkcjonalności i wymagań instalacyjnych

Spis treści

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

1.1.1.2

Optymalizacja i modele współpracy systemów DNS

2

Analiza i dostosowanie wymagań stawianych usłudze katalogowej w zakresie wspomagania infrastruktury kluczy publicznych

DNS a usługa LDAP
- analiza funkcjonalności i wymagań instalacyjnych