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

Jarosław Zieliński
jestem miłośnikiem dwóch rzeczy – sieci komputerowych i dobrej kawy. Od 12 lat zajmuję się branżą IT, zawsze w towarzystwie dużego kubka czarnego napoju. Posiadam doświadczenie w wirtualizacji, budowaniu rozwiązań integrujących chmurę publiczną z lokalnym DC oraz monitoringu infrastruktury. Pasję do informatyki i kawy przelewam (nie mylić z rozlewaniem) na bloga Popołudnie w Sieci, którego jestem twórcą. Jestem także autorem artykułów do branżowych czasopism oraz prelegentem na konferencjach. Jestem certyfikowanym inżynierem VMware oraz jednym z nielicznym Polaków posiadających tytuł VMware vExpert. Ponadto lideruję grupie AWS User Group Poznań i współtworzę cykl spotkań vBeer Poland.