Eksperymenty przy pełnym kubku. Praktyczne zastosowanie Split DNS.
Ostatnio zgłębiam tajniki przygotowania perfekcyjnej kawy, która jest znana od ponad 12 wieków. A
zaczęło się najprawdopodobniej od miasta Kaffa znajdującego się w Etiopii nad rzeką Omo.
Postanowiłem napełnić kubek i przygotować dla Was opis jak korzystając z routera Cisco możemy
zbudować użyteczny serwer DNS z funkcją split DNS. Powód był dość prozaiczny ponieważ
przygotowałem nowe środowisko pod VMware vSphere 6.0, który jest dostępny publicznie od zeszłego
czwartku. Wymyślając nową domenę, postanowiłem rozbudować to co aktualnie używam.
Zacznijmy zatem
Od lat używałem domeny Active Directory: fnet.local, która jest bazą dla wszystkich usług jakie mam
swoim domowym labie.
Postanowiłem utworzyć nową, aby była bliższa naszej stronie, czyli popołudniewsieci.local
Przyjąłem założenie, że serwery DNS, które znajdują się w środowisku wirtualnym mogą nie działać, a
zarazem nie chcę konfigurować całego stosu zapasowych serwerów DNS, które będą dostarczać usługę
rozwiązywania nazw do komputerów pracujących w moim labie.
Aby sprostać temu tematowi postanowiłem wykorzystać funkcjonalność split DNS, która jest dostępna
na moim routerze brzegowym jakim jest ISR Cisco 1821.
Na uruchomienie mechanizmu split dns składa się kilka kroków:
Na początek przygotujemy listę domen oraz serwerów jakie będą je obsługiwać:
| Domena | Primary DNS | Secundary DNS |
|---|---|---|
| fnet.local | 172.20.10.2 | 172.20.10.3 |
| popoludniewsieci.local | 10.0.0.2 | 10.0.0.8 |
| Cała reszta | 62.21.99.94 | 8.8.8.8 |
Bazując na tabelce powyżej przygotujemy widoki dns.
Bardzo pomocną opcją jest określenie interfejsu routera, który będzie podawany jako interfejs źródłowy
w komunikacji z serwerem DNS. Wykorzystamy to rozwiązanie w pełni jeżeli interfejs ten bierze udział w
procesie NAT-u źródłowego.
Zacznijmy więc od starej domeny, czyli fnet.local gdzie serwery DNS są osiągalne bezpośrednio z
interfejsu vlan10.Tworzymy widok dns, w którym wskazujemy domenę, serwery DNS dla tej domeny oraz dns forwarder.
ip dns view dns-view-fnet domain list fnet.local domain name-server 172.20.10.2 domain name-server 172.20.10.3 domain resolver source-interface Vlan10 dns forwarder 172.20.10.2 dns forwarder 172.20.10.3
Następnie dodajemy listę na podstawie której będziemy kierować zapytania DNS związane z domeną do
odpowiednich serwerów ją obsługujących
ip dns name-list 1 permit .*.FNET.LOCAL
Czas na przygotowanie konfiguracji dla domeny popoludniewsieci.local:
Serwery DNS dla tej domeny osiągalne są z interfejsu tunnel0
ip dns view dns-view-popoludniewsieci domain list popoludniewsieci.local domain name-server 10.0.0.2 domain name-server 10.0.0.8 domain resolver source-interface Tunnel0 dns forwarder 10.0.0.2 dns forwarder 10.0.0.8 dns forwarding source-interface Tunnel0
Analogicznie jak w przypadku poprzedniej domeny również tworzymy listy na podstawie której zapytania
DNS związane trafiają w odpowiednie miejsce.
ip dns name-list 2 permit .*. popoludniewsieci.local
Pozostały ruch ma być obsłużony przez nasze domyślne serwery DNS zatem ruch do domyślnych
serwerów DNS jest kierowany przez domyślną bramę, czyli interfejs FastEthernet0. Tworzymy dla tego
zachowania odpowiedni widok dns.
ip dns view default logging domain timeout 2 domain resolver source-interface FastEthernet0 dns forwarding timeout 2 dns forwarding retry 3 domain round-robin dns forwarding dns forwarder 62.21.99.94 dns forwarder 8.8.8.8 dns forwarding source-interface FastEthernet0
W ostatnim kroku tworzymy listę, w której określamy kolejność w jakiej mają być przetwarzane
zapytania DNS pochodzące z naszej sieci
ip dns view-list dns-view-list-dns-server view dns-view-fnet 10 restrict name-group 1 view dns-view-popoludniewsieci 20 restrict name-group 2 view default 99
Następnie określamy serwerowi DNS aby korzystał z przygotowanych wcześniej list
ip dns server view-group dns-view-list-dns-server
Uruchamiamy na koniec usługę serwera DNS
ip dns server
Pozostaje wykonanie serii testów:
- Sprawdzenie osiągalności hostów z sieci lokalnej
C:\Users\jarek>ping esxi01.fnet.local Pinging esxi01.fnet.local [172.20.30.201] with 32 bytes of data: Reply from 172.20.30.201: bytes=32 time<1ms TTL=64 Reply from 172.20.30.201: bytes=32 time<1ms TTL=64 Reply from 172.20.30.201: bytes=32 time<1ms TTL=64 Reply from 172.20.30.201: bytes=32 time<1ms TTL=64 Ping statistics for 172.20.30.201: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 0ms, Maximum = 0ms, Average = 0ms
- Sprawdzenie osiągalności hostów z lab-a popoludniewsieci.local
C:\Users\jarek>ping esxi01.popoludniewsieci.local Pinging esxi01.popoludniewsieci.local [10.0.0.51] with 32 bytes of data: Reply from 10.0.0.51: bytes=32 time=4ms TTL=50 Reply from 10.0.0.51: bytes=32 time=5ms TTL=50 Reply from 10.0.0.51: bytes=32 time=4ms TTL=50 Reply from 10.0.0.51: bytes=32 time=5ms TTL=50 Ping statistics for 10.0.0.51: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 4ms, Maximum = 5ms, Average = 4ms
- Sprawdzenie osiągalności hostów z dzieje się w Polsce
C:\Users\jarek>ping wp.pl Pinging wp.pl [212.77.100.101] with 32 bytes of data: Reply from 212.77.100.101: bytes=32 time=30ms TTL=247 Reply from 212.77.100.101: bytes=32 time=28ms TTL=247 Reply from 212.77.100.101: bytes=32 time=26ms TTL=247 Reply from 212.77.100.101: bytes=32 time=25ms TTL=247 Ping statistics for 212.77.100.101: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 25ms, Maximum = 30ms, Average = 27ms
Zastosowanie do jakiego ja wykorzystałem tą funkcjonalność to jedna z możliwości. Możemy na przykład
używać w oddziałach jako domyślny serwer DNS, aby mieć pełną kontrolę nad ruchem DNS.
Pełny opis poleceń znajduje się w dokumentacji Cisco tutaj