Różne rekordy A domen

Czasami zachodzi konieczność zdefiniowania domeny dla potrzeb sieci lokalnej bądź vpn, np. dla ułatwienia developerom dostępu do repozytorium git. W poniższej notce pokażę jak zrobić do tak, aby uniknąć upubliczniania we wpisie rekordu A DNS klas adresowych wewnętrznej sieci lub nie definiować takiej domeny ręcznie, w pliku hosts każdej z maszyn sieci lokalnej.

Najprostszym rozwiązaniem postawionej wyżej kwestii wydaje się zdefiniowanie jako rekordu A naszej domeny adresu z sieci lokalnej:

git.example.com.      IN      A       192.168.1.1

Metoda ta, choć niezwykle prosta, ma dwie zasadnicze wady: po pierwsze potencjalny atakujący może – poprzez analizę wpisów DNS domeny – poznać adresację naszej sieci wewnętrznej i to bardzo często w tej jej części, która znajduje się już poza DMZ . Po drugie, jeżeli nasza sieć wewnętrzna korzysta z popularnej adresacji (np. podana w przykładzie 192.168.1.0/24 ) może zdarzyć się, że użytkownik próbując wejść na stronę git.example.com spoza firmy lub sieci vpn połączy się z urządzeniem o adresie 192.168.1.1 w swojej sieci lokalnej.

Sposobem rozwiązanie tego problemu jest przygotowanie serwera DNS tak, aby obsługiwał „widoki” i serwował odpowiednie strefy DNS w zależności od tego czy dostęp do serwera wykonywany jest z sieci lokalnej czy też spoza niej. W moim przykładzie pokażę jak skonfigurować serwer bind tak, aby dla dostępu do domeny git.example.com z sieci wewnętrznej zwracał adres lokalny, natomiast dla dostępu spoza sieci wewnętrznej zwracał zewnętrzny adres IP serwera.

Konfigurację bind rozpocząć należy od przygotowania wspomnianych wyżej widoków. Na potrzeby tej implementacji zakładamy dwa:

  1. internal – obsługujący sieć wewnętrzną
  2. external – dla pozostałych zapytań

oczywiście możemy założyć rozbudowę tej koncepcji np. o zapytania z obszaru DMZ jednak idea pozostanie niezmienna.

Widoki w konfiguracji bind definiuje się następująco:

view "[name]" {
    [rules]
};

wewnątrz widoku możemy zdefiniować zmienne serwera DNS oraz strefy poszczególnych domen – mają one charakter lokalny i mogą być różne dla każdego widoku. Rozdzielenia ruchu pomiędzy widoki wykonywać będziemy korzystając z dyrektywy:

match-clients { any; };

która jest jedną z dyrektyw służących do definiowania warunków w konfiguracji bind – w tym przypadku warunków opartych o adresy / klasy adresowe klientów DNS (więcej o składni dyrektywy match-clients możecie przeczytać tutaj). Biorąc pod uwagę to, co napisałem wcześniej konfiguracja naszych widoków będzie wyglądała następująco:

view "internal" {
    match-clients { 127.0.0.0/8; 192.168.1.0/24; };
    zone "git.example.com" {
        type master;
        file "/etc/bind/internals/db.git.example.com";
    };
};
view "external" {
    match-clients { any; };
    zone "git.example.com" {
        type master;
        file "/etc/bind/externals/db.git.example.com";
    };
};

po takim przygotowaniu widoków wystarczy przygotować dwa pliki stref (ja umieściłem je w podkatalogach o nazwach adekwatnych dla widoków, ale nie jest to obligatoryjne) i wpisać konfigurację stref do widoków. Pamiętać należy, że jeżeli korzystamy z widoków, to każda konfiguracja strefy musi znaleźć się w jakimś widoku. Jeżeli posiadamy strefy, których nie chcemy przypisywać do zdefiniowanych widoków możemy wówczas utworzyć w konfiguracji widok domyślny i umieścić je w nim. Widok taki definiujemy następująco:

view default {

};

Strefy DNS definiujemy wg standardowych zasad pamiętając wszelako, że dla strefy internal rekord A naszej domeny powinien przyjmować wartość z puli adresów sieci wewnętrznej, natomiast dla strefy external zewnętrzny adres serwera.

Wdrożenie opisanego przeze mnie rozwiązania wymaga oczywiście posiadania własnego serwera DNS i podania jego adresu komputerom sieci lokalnej (bądź vpn). Jeżeli zależy nam na niezawodności serwerów domenowych i korzystamy z rozwiązań dużych dostawców, możemy na nasz własny serwer domenowy kierować tylko te domeny / sub-domeny, które wykorzystywane będą w sieci wewnętrznej, całą resztę zaś pozostawić w zarządzie dużego dostawcy.

Podziel się:

Mikołaj Niedbała

I'm a Poland based IT administrator, linux administrator and IT engineer creating professional IT infrastructure solutions based on Linux and virtual environments.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *