Strefy wyszukiwania wstecznego

W systemach DNS znaczącą rolę odgrywają strefy wstecznego wyszukiwania. DNS jest rolą która nie tylko tłumaczy nazwy domen na adresy IP, ale również adresy IP na nazwy domenowe. Niektóre usługi wymagają tłumaczenia w obie strony. Podobnie jak w przypadku klasycznych stref możliwe jest delegowanie takich stref, jednak zasady ich działania powodują, że proces ten jest trudniejszy szczególnie w przypadku stref w sieciach o wielkości dyktowanej VLSM.

Wyszukiwanie wsteczne jest ściśle powiązane z sieciami a konkretnie z adresacją. Aby to należycie wytłumaczyć musimy posłużyć się przykładem:

W firmie funkcjonuje sieć 172.20.0.0/16 oraz domena lokalna mydomain.local. Oznacza to, że urządzenia będące członkami tej domeny otrzymają stosowny suffix DNS czyli np serwer MYSQL o adresie 172.20.11.10 którego nazwa NETBIOS to MYSQLSRV001 będzie miał FQDN MYSQLSRV001.mydomain.local. Serwer ten będzie próbował zarejestrować zarówno swoją nazwę (rekord A/AAAA) jak i rekord PTR (wyszukiwania wstecznego) w serwerze DNS.

Do tego celu serwer DNS musi posiadać domenę wyszukiwania wstecznego odpowiednią dla tej sieci – w prezentowanym przykładzie będzie to 20.172.in-addr.arpa. Jak łatwo dostrzec notacja takiej strefy jest również wsteczna. Jeżeli serwer będzie miał możliwość odnalezienia takiej strefy i aktualizacje będą dozwolone, wprowadzi on swój adres i nazwę w następującej postaci:

10.11 PTR  MYSQLSRV001.mydomain.local. 

Jeśli teraz połączymy nasze 10.11 z 20.172 (nazwa strefy) i odczytamy od tyłu otrzymamy 172.20.11.20 (adres naszego serwera). Celem oddelegowania fragmentu sieci do innego serwera co do zasady używa się klasowych odniesień. Np w powyższym przykładzie możemy oddelegować sieć 172.20.20.0/24 na inny serwer DNS. W pliku serwera posiadającego strefę delegowaną wprowadzamy następujące odniesienie:

20.20.172 IN NS newdnsserver.local

Natomiast na serwerze docelowym tworzymy właściwą domenę wsteczną przechowującą wymagane rekordy:

20.20.172.in-addr.arpa

Sytuacja jest niestety bardziej skomplikowana w przypadku delegowania stref bezklasowych. I tak to strefy większe od podstawowej np. 23 należy podzielić na strefy /24 i oddelegować jako osobne strefy do serwera delegowanego.

Jeszcze bardziej problematycznym jest obejście stref mniejszych niż /24 np trzymających sieci /26 lub /27. Tu musimy posłużyć się dokumentem RFC2317.

Dzielenie polega na oddelegowaniu na serwerze głównym następującej strefy (przykład dla 172.20.0.0/25):

0/25.0.20.172 IN NS delegatedserver.local

Jest to jednak dopiero początek, ponieważ każdy rekord który będzie w wydelegowanym serwerze również trzeba odnieść do tego serwera ze strefy głównej; co znaczy, że oprócz powyższego wpisu należy także dla KAŻDEGO urządzenia dodać wpisy CNAME:

1  IN CNAME 1.0/25.0.20.172.in-addr.arpa
2  IN CNAME 2.0/25.0.20.172.in-addr.arpa
5  IN CNAME 5.0/25.0.20.172.in-addr.arpa
(...)

Dlatego wyjątkowo istotną rzeczą podczas planowania podsieci i usługi DNS jest umiejętne zaplanowanie stref wstecznych i planu IP.

Mechanizmy zwiększania niezawodności DNS

DNS w kontekście globalnego rozwiązywania nazw spełnia swoją rolę używając wielu różnych mechanizmów – ich znajomość jest kluczowa z punktu widzenia administrowania rozwiązywaniem nazw w kontekście serwisów wysokiej niezawodności.

Rozważymy kilka ze sposobów dostarczania stref do klientów. Ponieważ klient może używać więcej niż jednego serwera nazw jednocześnie konfiguracja serwisów oraz wymiana informacji między nimi jest istotna. Nie można dopuścić do sytuacji w której dwa serwery DNS odpowiedzialne za utrzymywanie jednej strefy różniły się rekordami. Utrzymywanie spójności między serwerami zapewniany jest na różne sposoby – zależnie od stosowanego rozwiązania DNS.

Tu dotykamy tematu różnych rodzajów stref: Primary, Secondary, Stub, Forwarding oraz w przypadku systemów Windows stref Primary AD-Integrated.

Primary czyli strefa podstawowa – serwer który jest autorytatywny (przechowuje rekordy strefy i o niego oparte jest rozpoznawanie nazw dla strefy) utrzymuje strefę podstawową. W najprostszej konfiguracji (bez zapewniania mechanizmów replikacji) może istnieć tylko jedna strefa Primary – ponieważ strefa ta jest niezależna i najwyższa w hierarchii.

Celem zapewnienia jakiejś niezawodności w usługach używane są także strefy Secondary – czyli zapasowe strefy które kopiują konfigurację ze stref Primary przy użyciu mechanizmu nazywanego transferem. Transfer jest cechą konfiguracji serwera DNS/Strefy – należy uważać komu (jakim adresom IP / serwerom DNS) pozwala się na dokonywanie transferu naszej strefy. Charakterystyczne dla strefy zapasowej jest to, że nie można zmieniać jej rekordów – są one pobierane i nadpisywane ze strefy podstawowej. Pomimo to – serwer posiadający strefę Secondary posiada wszelkie rekordy (aktualizuje je ze strefy podstawowej w oparciu o numer seryjny rekordu SOA) i obsługuje żądania jak każdy inny serwer DNS.

Istnieją również mechanizmy o charakterze hybrydowym tzn. umożliwiające używanie stref typu multiple Primary. To oznacza, że nie używają one standardów określonych w RFC pomiędzy strefami Primary i Secondary – nie używają mechanizmu transferu. Musi zatem istnieć dedykowany mechanizm transportu informacji o zmianach w tych strefach. Microsoft oparł tego typu rozwiązanie na produkcie który z powodzeniem używany jest w każdej szanującej się korporacji/firmie – Active Directory. To usługa katalogowa posiadająca dane o usługach, użytkownikach i maszynach a także wielu innych elementach definiujących strukturę firmy (atrybuty), kóra od czasu powstania rozrosła się do tego stopnia, że stanowi nośnik wielu innych technologii Microsoft. Umożliwia m.in. tworzenie stref DNS AD-integrated. Oznacza to, że strefa znajduje się w strukturze katalogowej Active Directory i jest replikowania między wszystkimi (lub wybranymi o czym zaraz) kontrolerami DC. Z punktu widzenia administratora jest to wyłącznie kwestia zaznaczenia opcji „Integrate zone with Active Directory”. Co to nam daje? Strefa jest wysoko dostępna (replikowana). Można ją zmieniać na dowolnym kontrolerze domeny a zmiana zostanie zreplikowana do reszty kontrolerów. Strefa jest wszędzie oznaczona jako Primary AD-integrated i posiada własny system uprawnień na rekordach.

Czy to oznacza, że jeśli mamy np. 10 DC to musimy replikować strefę między wszystkimi? Oczywiście nie – istnieje mechanizm nazywany partycjonowaniem Active Directory – który umożliwi stworzenie nam subkontenera w usłudze katalogowej, który będzie zreplikowany na wskazane kontrolery. Kontener taki można stworzyć np. przy użyciu komendy

dnscmd <server> /createdirectorypartition <nazwa partycji>

Dodatkowe serwery które mają trzymać partycję dodajemy

dnscmd <server> /enlistdirectorypartition <nazwa partycji>

Teraz pozostaje tylko w usłudze DNS zmienić zakres replikacji partycji w jej właściwościach na nowo stworzona partycję i tadam!

Oczywiście nie tylko Microsoft wpadł na pomysł replikowania swoich stref. Produkty dedykowane również wykorzystują takie podejście – chociażby Infoblox – całościowy produkt DDI (DHCP/DNS/IPAM) używa struktury którą nazwano GRID (siatka na którą składają się jej maszyny – members, która odpowiada za utrzymywanie i replikowanie bazy wraz z informacjami) . Replikacja w ramach GRID działa na podobnej zasadzie co w AD, umożliwiając propagację stref między skonfigurowanymi memberami.

Niezawodność serwerów – klastry

Klastry – czyli jeden z najpopularniejszych sposobów zwiększania niezawodności lub wydajności gdy pojedyncza jednostka obliczeniowa zawodzi. Poprzednio pisałem o klastrach w kontekście niezawodności i to należy rozszerzyć.

Nie ma większego sensu generować klastra na sprzęcie który nie będzie wirtualizowany. Innymi słowy klastrowanie pojedynczej usługi w oparciu o zasoby sprzętowe to raczej kiepski pomysł prowadzący do marnowania zasobów. Znacznie częściej stosowanym podejściem jest klastrowanie hostów tzw. Hypervisorów które służą do wirtualizowania oraz konteneryzacji zasobów. Klastrowania dokonuje się w opraciu o mechanizmy wirtualizacyjne w przypadku Microsoft odpowiada za to usługa Microsoft Failover Clustering na której następnie stawiane są role, w przypadku np. vmWare i XenServer mówić będziemy o pulach Pools które gromadzą nody. Skupiając się na klastrach rodziny Microsoft, które są mi najbliższe – każdy klaster składać się może z minimum dwóch maszyn (nodów) i musi współdzielić zasoby (np. musi posiadać wspólny dysk dostępny np. poprzez protokół iSCSI albo SMB). W przypadku klastra opartego o dwie nody warto także rozważyć w kontekście głosowania dodatkowy głos – tzw świadka (może np. być nim share lub dysk). W razie awarii sieci obie maszyny klastra sądzą że są „klastrem” więc decyzja o tym która z nich powinna przejąć jego rolę musi być podyktowana dostępem do świadka (zasobu).

Mamy zatem dwa serwery o jednakowej lub podobnej budowie – posiadają własne mechaniczne zabezpieczenia np. raid, np. redundancje łączy, czy też redundancje zasilania. Zostają włączone do klastra i stają się jego elementami, będą więc dostarczać funkcjonalności. Jedna z maszyn jest aktywna i serwuje serwis, druga jest tzw. hot-standby która przejmie serwisy w razie awarii pierwszej. Istnieją również klastry active-active gdzie obie maszyny są jednocześnie dostępne a ruch jest balansowany – tu jednak dochodzą problemy z zasobami i wielodostępem do dysków – a konkretnie do warstwy systemu plików (operacje I/O) dlatego są stosowane wyłącznie do wysoko skalowalnych rozwiązań – najczęściej bazodanowych np. MSSQL. Dlaczego zasoby na nodach klastra muszą być podobne jak nie jednakowe? Ponieważ np. w przypadku wirtualizacji maszyny wirtualne mają przydzielaną ilość pamięci i vCPU – więc nie może dojść do sytuacji że w przypadku awarii 1 nody, druga nie ma dość pamięci aby uruchomić instancje wirtualne! W przypadku procesorów i ich wirtualizacji sprawa jest o tyle zróżnicowana że można wirtualizować nawet cory procesora, ale zapewnienie wsparcia możliwe jest wyłącznie w ramach jednej architektury – vendora. Jest to spowodowane różnymi procesami konstrukcyjnymi i sposobem oferowania wirtualizacji. Hypervisor jest w stanie użyć więc różnych procesorów tego samego producenta do migracji maszyn używając specjalnej opcji kompatybilności uruchamianej np. powershellem:

Set-VMProcessor -CompatibilityForMigrationEnabled $true

W tak skonstruowanym klastrze można uruchamiać różne usługi – najczęściej są to maszyny wirtualne, jednak mogą to być serwery plików, wysokodostępne serwery DHCP, itp. Co jest więc słabym elementem klastra? Zasoby. Mamy wysokodostępne usługi na np. 3 nodach, ale wszystkie one korzystają z dysku na np. starej macierzy NAS która nie jest replikowana. W przypadku jej awarii, klaster pozostanie bez zasobów – więc chociażby było w nim 10 nod – nie będzie działał. Należy zatem zadbać o zapewnienie wysokiej dostępności zasobów co jest równie ważne jak same nody.

Rzecz o serwerach

Na moment oderwiemy się od tematyki czysto DDI i powiemy sobie kilka słów o systemach serwerowych i sposobach zarządzania nimi w średnich przedsiębiorstwach.

Narzędzi do zarządzania systemami jest wiele. Różnią się one możliwościami, konfiguracją, dostępnością oraz co najważniejsze ceną. Niestety większość mniejszych przedsiębiorstw zmuszona jest do zarządzania serwerami manualnie – bez użycia narzędzi zewnętrznych lub z użyciem narzędzi opartych o darmowe licencje.

Istnieje cała masa oprogramowania darmowego, które doskonale spełnia swoja rolę także w dużych korporacjach. Na szczególną uwagę zasługuje oprogramowanie do wirtualizacji Bare-metal np. Ubuntu MAAS. Swoją rolę odgrywają także systemy monitoringu Nagios, platformy Datalake Hadoop, platformy konteneryzacji docker/hive/kubernetes, Apache spark, czy popularne serwisy Apache WWW, MySQL, Firebird nie mówiąc o całych systemach operacyjnych typu Linux/BSD.

Oprogramowanie to jest z powodzeniem używane i zapewnia wysoki poziom niezawodności. Nie zawiera jednak jednak niezwykle istotnej rzeczy – wsparcia. Niektóre z projektów oczywiście umożliwiają jego wykupienie, jednak co do zasady ideą oprogramowania OpenSource jest dostarczenie funkcjonalności AS-IT-IS. W dużych korporacjach podział na mniejsze teamy odpowiedzialne za swoją działkę jest dużo bardziej granularny. Dlatego duży nacisk kładzie się także na dostarczenie wsparcia do oferowanych produktów/integracji.

W odniesieniu do serwerów – małe firmy używają oczywiście słabszego sprzętu. Nie mogą sobie najczęściej pozwolić na zakup rozwiązań z wysokiej półki np. serwerów blade, macierzy duplikowanych np. NetApp. Większość małych firm zadowala się pojedynczym serwerem z którego wykonywane są kopie zapasowe bez redundancji. Oznacza to, że w razie awarii usługa jest niedostępna i należy akceptować fakt Downtime jako ryzyko.

Na poziomie serwera możliwe jest oczywiście zapewnienie pewnej niezawodności np. w postaci macierzy RAID dla dysków. Mamy tu do wyboru różne poziomy niezawodności od 10 (RAID 0 łączenie przestrzeni dysków celem zwiększenia szybkości oraz RAID 1 – mirror), 3-way-mirror (RAID 1 dla 3 dysków) , RAID 5 (wymaga minimum trzech dysków z czego zawsze jeden może ulec awarii) RAID 6 – wymaga minimum 4 dysków i w zależności od ilości dysków awarii może ulec 2 lub więcej dysków). Wybór rozwiązanie RAID podyktowany jest koniecznością zapewnienia kompromisu między bezpieczeństwem a wydajnością. Wydajność jest coraz niższa im wyższe bezpieczeństwo dlatego najczęściej stosowanym rozwiązaniem jest RAID 1 lub RAID 10 gdzie ze względu na brak tzw. informacji o parzystości łatwiejsze jest ewentualne odzyskiwanie danych.

Kolejnym zabezpieczeniem na jakie mogą sobie pozwolić małe firmy jest redundancja na poziomie zasilania wraz z odpowiednim urządzeniem UPS. Serwery umożliwiają instalację zasilaczy redundantnych n+1 co znaczy że nawet gdy ulegnie awarii jeden z modułów drugi zapewnia działanie całego serwera.

W tym miejscu warto także wspomnieć o redundancji rozumianej w kontekście dostępu do samego serwera – redundancji portów sieciowych. Obecnie bardzo często stosowaną techniką jest ich agregacja – najczęściej przy użyciu protokołu LACP (Link Agregation Control Protocol) . Pozwala ona na konfigurację połączenia aktywnego po obu stronach, zwiększenie przepustowości z jednoczesnym zwiększeniem niezawodności – oba linki dokonują transferu danych jako aktywne a jednocześnie w przypadku awarii jednego z nich łączność jest w dalszym ciągu utrzymana. Większość szanującego się sprzętu sieciowego zapewnia obsługę protokołu LACP (Cisco/Juniper, etc). Sprawa z systemami operacyjnymi jest nieco bardziej skomplikowana gdyż agregacja zależy tu np. od sterownika karty w systemie, od architektury rozwiązania (np. wirtualizacja ). Windows Server 2012 i wyżej zapewnia tzw. Network Card Teaming w oparciu o LACP, w przypadku systemów Linuks jest to czasem kwestia instalacji modułu bondingu do kernela i konfiguracji pliku /etc/network/interfaces (tu w zależności od wersji może to wyglądać różnie).

W tej sytuacji nie sposób nie wspomnieć o interfejsach dedykowanych do zarządzania serwerem – BMI (Board Management Interface). Są to dedykowane interfejsy na płycie głównej umożliwiające zarządzanie nawet wyłączonymi serwerami, instalację oprogramowania czy uzyskanie informacji o konfiguracji. W zależności od producenta płyty głównej rozwiązanie może być darmowe lub płatne. Np. IPMI stosowane w płytach Intel/Supermicro jest darmowe i posiada pełną funkcjonalność, natomiast oprogramowanie iDRAC dla serwerów DELL występuje jako Basic i Enterprise i tylko werjsa płatna ma konsolę do zdalnej instalacji systemu oraz zarządzania. HP ma swoje ILO, Lenovo IMM itd.

Niestety redundancja kończy się w tym miejscu. Komponenty takie jak CPU, czy pamięć nawet gdy procesorów jest więcej a pamięć jest dystrybuowana – podłączone są do jednej płyty głównej która w razie awarii odcina wszystko.

W tym miejscu dochodzimy do wyższego poziomu redundancji, który możliwy jest do zapewnienia poprzez instalację klastrów czyli dwóch lub więcej maszyn (najlepiej identycznych lub przynajmniej – z punktu widzenia Hyper-v Clustering – o procesorach tego samego vendora) pełniących jedną funkcję. O klastrach w kolejnym artykule.

Do serca DNS – pliki stref

W poprzednich rozdziałach zapoznaliśmy się ze szczegółami pliku konfiguracyjnego przykładowego serwisu DNS opartego o system Linux i daemon bind. Czas najwyższy zanurkować w głąb stref aby zrozumieć zasady ich zdiałania.

Zakładając, że w głównym pliku konfiguracyjnym wprowadziliśmy definicję strefy:

zone "fafik.com" {
type master;
file "fafik.com.zone";
};

w pliku fafik.com.zone musimy zdefiniować szczegóły:

$ORIGIN fafik.com.
$TTL 86400

@ IN SOA dns1.fafik.com. hostmaster.fafik.com. (
2001062501 ; serial
21600 ; refresh after 6 hours
3600 ; retry after 1 hour
604800 ; expire after 1 week
86400 ) ; minimum TTL of 1 day

IN NS dns1.fafik.com.
IN NS dns2.fafik.com.
IN MX 10 mail.fafik.com.
IN MX 20 mail2.fafik.com.
dns1 IN A 10.0.1.1
dns2 IN A 10.0.1.2
server1 IN A 10.0.1.5
server2 IN A 10.0.1.6
ftp IN A 10.0.1.3
IN A 10.0.1.4
mail IN CNAME server1
mail2 IN CNAME server2
www IN CNAME server1

Zatem – co to właściwie wszystko jest? Znakami dolara opatrzone są tzw. zmienne globalne – TTL czyli Time To Live to czas życia strefy w pamięci cache poszczególnych serwerów DNS oraz ORIGIN czyli tzw. namespace w którym pracuje zona, który będzie uzupełniał skrócone rekordy w dalszej części pliku. Np. weźmy pojedynczą linię:

server1 IN A 10.0.1.5

Mówi on o tym, że rekord server1 będzie rozwiązywany na adres 10.0.1.5. Parametr ORIGIN umożliwia zastosowanie takiej skróconej nazwy server1 zamiast serverv1.fafik.com ponieważ sam dołoży na końcu odpowiedni suffix domenowy.

Dalej mamy definicję @ czyli w to miejsce wstawiany jest parametr $ORIGIN i rekord SOA (start of authority w którym określamy czasy życia), główny serwer dns dla strefy, hostmastera i numer seryjny.

W ty miejscu wspomnieć należy, że są różne rodzaje rekordów np.

  • A – rekord mapowania adresu na nazwe
  • PTR – odwrotny rekord mapuje nazwe na adres w strefach reverse lookup
  • AAAA – podobny jak A tylko dla Ipv6
  • MX – master exchanger czyli serwer mailowy
  • CNAME – alias do innego rekordu
  • NS – name server – czyli serwer DNS jaki odpowiada za rekord
  • TXT – rekord tekstowy o wielorakim zastosowaniu – często stosuje się go do weryfikacji SSL, do ustanawiania polityki SPF lub po prostu do opatrywania czegoś komentarzem
  • SRV – rekord usługi – szczególnie używany w odniesieniu do systemów Windows i domeny Active Directory do identyfikacji usług np. kerberos, ldap, itp. Posiad a inną składnię:

 <usługa> TTL <klasa> SRV <priorytet><waga><port><cel>

Istnieje także wiele innych mnie popularnych rekordów np.

  • DNAME – mapujący domenę
  • RRSIG,NSEC,DS,SIG – rekordy związane z bezpieczeństwem serwisu DNS w oparciu o DNSSEC. (o tym popiszemy osobno)
  • ISDN – przestarzały dot. usługi ISDN
  • HINFO – host info – niosący informację o hoście (CPU/OS)

Generalnie konstrukcja rekordu jest następująca

<nazwa rekordu > IN <typ rekordu> <wartość>

I tak w naszym przykładzie

@ IN NS dns1.fafik.com.

Oznacza, że strefa @ (fafik.com) przechowywana jest na serwerze dns1, a z kolei:

dns1 IN A 10.0.1.1

mówi, że ów dns1 znajduje się pod adresem 10.0.1.1. Czyli jeżeli używamy testowego klienta ustawionego na serwer DNS zawierający strefę to po przeprowadzeniu próby ping dns1.fafik.com, powinniśmy otrzymywać odpowiedzi z 10.0.1.1 (nazwa rozwiązana na adres).

I tak dalej, i tym podobne. Pliki stref mogą zawierać tysiące rekordów, nie powinny jednak zawierać adresów IP mieszanych lokalnych z publicznymi. Posiadamy np. domenę wewnętrzną fafik.local, która ma swój serwer DNS zawierający mapowania do lokalnych usług (lokalnych adresów) np.

service01 IN A 10.0.0.1
privatecloud IN A 10.0.2.2

Zwykle taki serwer DNS nazywa się internalowym i odpowiada on za rozwiązywanie nazw dla maszyn z wewnątrz przedsiębiorstwa. Z zewnątrz z kolei maszyna nikt nie powinien znać i móc rozwiązać takich nazw jak privatecloud, czy service01. Zamiast tego powinien z kolei rozwiązywać IP dla strony internetowej i rekordu WWW. Serwer, który za to odpowiada nazywamy externalowym i zawiear on mapowania publicznych rekordów na publiczne adresy IP np:

www IN A 89.123.23.1

Wgłąb DNS – named.conf

Skoro wiemy już czym jest usługa DNS i w jaki sposób odbywa się rozpoznawanie nazw przez resolver – warto zastanowić się nad możliwościami i szczegółami budowy tego serwisu.

Wspomnieliśmy, że DNS jest usługą która może zostać oparta o różne systemy operacyjne – najpopularniejszymi z nich są darmowy DNS bind oraz zintegrowana z systemem Windows rola DNS server. Dziś przyjrzymy się demonowi bind.

Jego konfigurację najogólniej rzecz biorąc rozbić można na konfigurację pliku stref named.conf wraz z opcjami domyślnymi oraz konfigurację samych zon określonych w powyższym pliku.

Plik named.conf pozwala na określenie tzw ACLek czyli list kontroli dostępu, które mogą następnie zostać użyte do ograniczenia użycia poszczególnych elementów skłądowych w dalszej części pliku np. transferów stref, aktualizacji sterf czy samych odpytań o rekordy.

Ponieważ plik named.conf podobnie jak inne pliki konfiguracyjne w systemie Linux ma konstrukcję opartą o opcje, nawiasy klamrowe oraz średniki kończące linie kodu lista kontroli dostępu może wyglądać w sposób następujący:

acl ACL_transfer_allowed {
10.0.1.0/24;
};

ACLek można używać, chociaż nie jest to wymagany element konfiguracji. Mają one jednak bardzo duże możliwości i pozwalają na dowolne kształtowanie ruchu DNS między klientami a serwerem oraz między serwerami DNS.

Kluczowym elementem konfiguracji jest sekcja options. To tutaj konfigurowane są kluczowe opcje globalne systemu. W tym momencie zaczyna się prawdziwa konfiguracja pliku DNS i jednocześnie pierwsza próba rozumienia zasad jego działania. Przykładowe dostępne opcje:

  • allow-query – pozwala na określenie kto może odpytywać nasz serwer. Można w tym miejscu użyć właśnie ACLek lub wprowadzać adresy sieci wprost. Dopuszczalne jest także używanie słów kluczowych np. any, localnets, none, localhost
  • allow-recursion – określa jacy klienci serwisu DNS mogą dokonywać odpytań rekursywnych czyli żądań zajęcia się rozpoznaniem rekordu DNS od A do Z i zwróceniu ostatecznego wyniku. Zazwyczaj lokalne serwery DNS w naszych sieciach są rekursywne, natomiast serwery wysokiego szczebla nie pozwalają na tego typu zapytania. Co zrozumiałe zapytania rekursywne wymagają znacznie więcej czasu i zasobów, a serwery root czy domen głównych .com, .net, itd. nie mogą pozostawać obciążone (DNS jest hierarchiczny). W tej opcji także możemy używać ACLek.
  • blackhole – tu określamy kto nie może odpytywać serwera – zapytania z tych ACLek lub adresów zostaną wysłane do ciemnej * i pozostaną bez echa.
  • directory – miejsce w którym demon DNS pracuje – najczęściej /var/named
  • forwarders – ponieważ nasz serwer nie ma wiedzy odnośnie całego świata, musi jakoś przesyłać zapytania odnośnie nieznanych domen dalej – temu służy opcja forwarders – czyli adresy IP serwerów do których przekierowane są zapytania jesli nasz serwer nie zna rekordu (nie jest cache’owany lub nasz serwer nie jest autorytatywny – czyli sam nie posiada strefy dla odpytywanej domeny).
  • forward – tu potrzebujemy trochę teorii. Nasz serwer DNS może być autorytatywnym (tzn. posiada jakieś strefy dla domen i rekordy wewnątrz jeśli np. obsługuje naszą firmową domenę) lub może być wyłącznie serwerem cache – czyli nie ma nic swojego tylko przechowuje rozwiązywane nazwy aby zwiększyć szybkość rozwiązywania w naszej sieci. Opcja forward może przyjąć dwie wartości – only oraz first. Pierwsza oznacza, że po otrzymaniu jakiegoś zapytania serwer DNS nie będzie nawet zaglądał do swoich stref tylko od razu przekaże zapytanie dalej. Opcja first oznacza, że serwer DNS przekaże co prawda zapytanie dalej ale w przypadku braku rozpoznania nazwy sprawdzi jeszcze swoje rekordy przed zwróceniem wyniku do klienta .
  • listen-on – tu zwyczajnie podajemy na jakich interfejsach usługa będzie nasłuchiwała na zapytania. Nie mamy możliwości konfiguracji portu, gdyż DNS zawsze prowadzi nasłuch na portach 53 tcp/udp
  • notify – tu ponownie potrzebujemy odrobinę więcej wiedzy odnośnie rodzajów stref jakie mogą występować, ponieważ ta opcja określa czy i jak nasz serwer ma informować o zmianach w swoich strefach serwery podrzędne. DNS posiadać może następujące strefy: Primary (strefa podstawowa autorytatywna); Secondary (strefa zapasowa autorytatywna – stanowiąca kopię ze strefy podstawowej – jest to swoisty mechanizm zwiększający dostępność usługi); Delegation – strefa delegowana na inny serwer DNS; Stub – strefa zawierająca wyłącznie informacje o rekordach NS/A typu glue – czyli najbardziej istotnych z punktu widzenia istnienia strefy. Ponieważ brak w niej informacji odnośnie innych rekordów celem ich uzyskania trzeba odpytywać zewnętrznych (wskazany w rekordach glue) serwer nazw; Strefa wyszukiwania wstecznego – przekształcająca adresy na nazwy. Rodzajom stref i ich działaniu poświęcimy osobny rozdział historii o DNS.
  • pid-file –określa gdzie znajduje się plik procesu named (tzw. process ID).

Poza opcjami kluczowym elementem pliku konfiguracyjnego jest definiowanie stref. Przykładowo strefa może być definiowana w następujący sposób:

zone "fafik.com" {
type master;
file "fafik.com.zone";
};

Wewnątrz strefy możliwe jest również konfigurowanie parametrów które nadpiszą wartości globalne np.: notify, allow-query, allow-update czy allow-transfer. Z punktu widzenia strefy kluczowym jest parametr type określający typ strefy. Może przybierać wartości delegation-only, master, slave, forward, in-view, redirect, static-stub i stub. Master i slave to strefy podstawowa i zapasowa. Stub to tłumaczona wcześniej strefa zawierająca tylko rekordy glue, Static-stub to strefa podobna do stub z tą różnicą, że możliwe jest skonfigurowanie adresów NS. Hint to strefa definiująca podstawowe serwery (root). Forward to strefa przekierowująca, a delegation-only to strefa umożliwiająca przeciwdziałanie wildcardom dla stref.

Wildcard to specjalne definiowanie stref przy użyciu * np dla strefy fafik.com możliwe jest zdefiniowanie wildcardu *.fafik.com rozwijającego wszystkie nazwy w domenie na konkretny adres IP.

Z punktu widzenia istnienia strefy musi istnieć także wskaźnik do pliku z zasobami strefy definiowany poprzez parametr file oraz w przypadku stref typu slave definiowane są także serwery z których pobiera się dane dyrektywą masters { x.x.x.x; };

W następnej części zapoznamy się z plikami stref i resourcami DNS.

Słowem wstępu o serwisie DNS

Nikogo nie trzeba przekonywać jak kluczową rolę w życiu internetu pełnią serwisy DNS. Cisi bohaterowie wykonują swoje funkcje bezszelestnie pozostając w cieniu i zapewniając poprawne rozwiązywanie nazw oraz adresów.

Pozornie rola i konfiguracja serwisów jest prosta, jednak przed wnikliwymi administratorami otwiera się znacznie więcej możliwości w zakresie konfiguracji i zarządzania usługą.

W tym miejscu warto wspomnieć, że usługa DNS jest jedną z kilku kluczowych ról w sieciach komputerowych wraz z usługą adresacji automatycznej DHCP oraz że usługi te są ze sobą blisko powiązane.

Czym jest DNS – najprościej rzecz biorąc jest to usługa która tłumaczy adresy IP v4 oraz IPv6 na nazwy zrozumiałe dla Kowalskiego. Gdyby nie ona wchodząc na stronę google.com  w przeglądarkę wpisywalibyśmy http://216.58.215.110, ewentualnie http://[2a00:1450:401b:803::200e]:80 zamiast poczciwego http://google.com. Warto pamiętać, że DNS działa także w drugą stronę – przy użyciu tzw. stref zwrotnych potrafi rozpoznać adres IP i zwrócić nazwę domenową.

Ponieważ zapamiętywanie stron internetowych w postaci adresów IP byłoby raczej mozolną sprawą warto przyjrzeć się serwerom DNS ciut bliżej. Sam serwis może zostać postawiony w oparciu  o dowolny system. Może być to np. Linuksowy demon bind9 nazywany named; może być to usługa DNS Server systemu Windows Server, bądź też zupełnie osobny produkt (!) stawiany jako virtual appliance lub nawet urządzenie fizyczne!

Z punktu widzenia przeciętnego zjadacza chleba rola DNSów kończy się na powyższej formułce; administratorzy serwerów/DDI mają jednak znacznie więcej na głowie i nie chodzi tu bynajmniej o konfigurowanie prostej usługi DNS.

Te bowiem polega na konfigurowaniu np. w przypadku BINDa pliku named.conf i kreowaniu w nim stref/zon np. google.com oraz stref zwrotnych o zawrotnej nazwie <pisany-od-tyłu-adres-sieci>.in-addr.arpa, by następnie kreować właściwe pliki stref zawierające rekordy.  Posłużmy się przykładem. Nasza firma posiada własną domenę lubieplacki.corp. Posiada także własny serwer DNS na który po zakupie domeny oddelegowano zarządzenie <zaparkowano domenę>.  Na serwerze DNS musi więc istnieć skonfigurowana strefa oraz konfiguracja rekordów domeny.  Ale tym w szczegółach zajmiemy się w kolejnej odsłonie boju DNS.

Na początek warto wiedzieć, że każda strefa posiada swój rekord identyfikacyjny stanowiący swoistą nalepkę na domenę (rekord SOA). W rekordzie SOA znajdują się różne tajemnicze wartości czasów (TTL) które mówią po jakim czasie rekordy domeny mają się przeterminować i powinny zostać zapomniane przez klientów a następnie pobrane od nowa. Trzeba bowiem wiedzieć, że z uwagi na dynamikę zmian w nazewnictwie DNS nie jest usługa statyczną jak pomnik z czasów epoki słusznie minionej.  Z drugiej strony nie może być także w pełni dynamiczna bo ilość zapytań o np. google.com w ciągu sekundy na całym świecie zapchałaby nawet serwery DNS firmy G.

Skorzystano więc z mechanizmu cache’owania nazw gdzie się tylko da. Tak oto rekordy cacheowane sa zarówno po stronie naszego klienta który odpala przeglądarkę (resolver),  jak również wszelkich serwerów DNS pośredniczących w rozwiązywaniu nazwy.  Owe czasy w rekordzie SOA mają więc pomóc w wyczyszczeniu danych o nazwie z wszystkich cache’ów co jest niezbędne bo strony www (szczególnie takie które są osadzone na balansowanych serwerach WWW i zwracane użytkownikowi algorytmem roundrobin / ew randomowo) często zmieniają adres IP. Gdyby nie istniał cache raz zapamiętana referencja strona www <–> adres IP istniałaby wiecznie, nawet jak strona umrze, domena wygaśnie albo zostanie relokowana pod inny adres.

No dobrze, ale zanim wrócimy do naszego SOA musimy sobie odpowiedzieć na pytanie:  jak odbywa się rozpoznawanie nazwy np. przez przeglądarkę? Prosta sprawa. Nasz komputer posiada skonfigurowany adres serwera DNS – w domu będzie to najczęściej serwer DNS ISP (dostawcy), a w firmie – firmowy DNS.  Odpalamy przeglądarkę, wpisujemy www.kubraczekdlapsa.net  i przeglądarka, zwana resolverem, kontaktuje się z najbliższym lub skonfigurowanym wprost w ustawieniach karty sieciowej serwerem DNS w poszukiwaniu upragnionej strony. Nasz serwer DNS ma za zadanie przeprowadzić cały proces rozpoznania nazwy i wrócić z tarczą albo na tarczy – proces ten zwany jest zapytaniem rekursywnym. Niestety nasz serwer DNS nic nie wie o tej stronie – nikt inny z naszej sieci nie próbował się na nią dostać więc nie ma jej w cache serwera. Serwer musi się więc skontaktować z innymi serwerami DNS żeby zdobyć więcej informacji. W tej sytuacji odpytywane są serwery tzw. root (czyli po prostu najwyższe główne serwery DN na świecie). Rozbijają naszą nazwę na części i mówią coś w stylu: nie mam pojęcia co to jest www.kubraczekdlapsa.net, ale wiem jaki serwer DNS odpowiada za część „.net” – oto jego adres. Nasz serwer kontaktuje się z serwerem który odpowiada za część .net z kolejnym pytaniem o całą nazwę. Podobnie jak root DNS serwer odpowiada, że nie wie jaki jest adres dla naszej requestowanej nazwy, ale ma w swoich rekordach „.net” zarejestrowaną nawę serwera dla kubraczekdlapsa. Nasz lokalny DNS zwraca się więc z zapytaniem do serwera odpowiedniego dla kubraczekdlapsa.net i tym razem uzyskuje adres IP dla rekordu www znajdującego się w kubraczekdlapsa.net i ten oto adres zostaje zapisany w cache wszystkiego po drodze i zwracany jest do resolvera – przeglądarki, która otwiera upragnioną stronę.

Tu warto dodać, że o ile nasz pierwszy serwer DNS odpowiada za rozwiązanie nazwy od A do Z i zwrócenie gotowego wyniku, o tyle serwery pośredniczące zwracają tylko wynik częściowy (iteratywny).  Wynika to z konieczności optymalizacji i hierarchizacji DNS – inaczej serwery wysokiego szczebla byłyby najbardziej obciążone.

W kolejnej odsłonie przedstawię DNS w szczegółach.