Czy router domowy może obsługiwać Split DNS zarówno dla IPv4, jak i IPv6?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Can a Home Router Resolve Split DNS for Both IPv4 and IPv6? - Zima Store Online

Tak, jeśli router lub delegowany resolver dostarcza właściwe odpowiedzi A i AAAA odpowiednim sieciom klientów, a klienci faktycznie używają tego resolvera dla obu rodzin adresów.

Staje się to rzeczywistą kwestią zgodności, gdy wewnętrzne nazwy hostów muszą być rozwiązywane do prywatnych adresów IPv4 i IPv6, podczas gdy klienci publiczni otrzymują publiczne odpowiedzi. Zacznij od jednorazowej ścieżki testowej lub konta, zachowaj poprzedni działający stan i oceniaj projekt na podstawie pierwotnego obciążenia, a nie jednorazowego testu połączenia.

Oddziel obsługiwaną architekturę od ryzykownej

Obsługiwana gałąź to zależne od klienta odpowiedzi A i AAAA z jednej autorytatywnej polityki. Alternatywna gałąź to klienci IPv6 omijający lokalny resolver lub otrzymujący nieosiągalny adres globalny albo ULA. Zapisz wersje, tożsamości, adresy, ścieżki montowania, uprawnienia i bieżący obserwowalny stan przed zmianą którejkolwiek z tych gałęzi.

Odpowiednie widoki podzielonego DNS wyznaczają pierwszą granicę zgodności. Użyj ich do ograniczenia zakresu twierdzenia, a następnie zweryfikuj to samo zachowanie na tym konkretnym serwerze domowym, zamiast traktować udokumentowaną funkcję jako dowód, że cały projekt działa.

Zapisz regułę decyzyjną przed testowaniem: powodzenie musi oznaczać, że każda sieć otrzymuje właściwą rodzinę adresów i dociera do tej samej usługi z certyfikatem bez publicznego hairpinningu; niepowodzenie obejmuje wyciek publicznego lub nieaktualnego adresu AAAA, korzystanie przez klientów z szyfrowanego zewnętrznego DNS albo niezgodność routingu IPv6 i polityki zapory z otrzymaną odpowiedzią. Zapobiega to błędnej interpretacji częściowego połączenia lub poprawnego zakończenia polecenia jako zgodności kompleksowej.

Odtwórz dokładną ścieżkę pamięci masowej i sieci

Użyj jednego kontrolowanego wyróżnika: odpytywania A i AAAA z każdej sieci VLAN, sprawdź faktycznie używany resolver, a następnie połącz się przez obie rodziny przy wyłączonym publicznym fallbacku na czas testu. Nie zmieniaj klienta, obciążenia, zestawu plików, konta ani czasu testu, aby zmieniony komponent był jedynym prawdopodobnym wyjaśnieniem.

Użyj reguł adresów dnsmasq, aby wybrać drugą obserwację istotną dla tej ścieżki. Zarejestruj obie strony transakcji: resolver lub trasę, wynegocjowany protokół, tożsamość procesu, kod zakończenia, opóźnienie, przesłane bajty oraz każde zdarzenie odzyskiwania.

Powtórz test po zdarzeniu cyklu życia wymienionym w tytule - odtworzeniu, ponownym połączeniu, ponownym zamontowaniu, restarcie, przełączeniu awaryjnym lub zmianie klienta. Projekt, który działa tylko tak długo, jak długo stare gniazda, pamięci podręczne lub dane uwierzytelniające pozostają aktywne, nie przeszedł testu.

dig A app.home @router
dig AAAA app.home @router
curl -4 https://app.home
curl -6 https://app.home

Interpretuj wyniki trwałości, limitu czasu i odzyskiwania

PASS: każda sieć otrzymuje właściwą rodzinę adresów i dociera do tej samej usługi z certyfikatem bez publicznego hairpinningu. Zapisz dokładne wersje i topologię, które doprowadziły do tego stanu, ponieważ wniosek dotyczy tych warunków, a nie każdej implementacji protokołu.

FAIL: wyciek AAAA ujawnia publiczny lub nieaktualny adres, klienci korzystają z szyfrowanego zewnętrznego DNS albo routing IPv6 i polityka zapory nie odpowiadają otrzymanej odpowiedzi. Sprawdź współdzielone zależności, takie jak DNS, MTU, tożsamość, stan zapory, opóźnienia pamięci masowej i buforowane sesje, zanim uznasz którąkolwiek z głównych gałęzi za odpowiedzialną.

EXCEPTION: usuń nieprawidłowe nadpisanie AAAA, przywróć osiągalny zestaw odpowiedzi i napraw rozgłaszanie resolvera oraz routing IPv6 przed ponownym włączeniem tej funkcji. Nie rozszerzaj uprawnień, nie usuwaj danych źródłowych, nie osłabiaj bezpieczeństwa transportu ani nie wymieniaj działającej pamięci masowej, dopóki powtarzalna obserwacja nie wskaże, która granica zawiodła.

-15% OFF

ZimaBoard 2 – Mini serwer domowy dla Twojego wielkiego pomysłu

Single board computer zimaboard2

Zachowaj projekt dopiero po kontroli na poziomie odtwarzania

Zastosuj wyłącznie działanie odpowiadające zaobserwowanej gałęzi, a następnie ponownie uruchom pierwotne obciążenie. Zachowaj projekt tylko wtedy, gdy każda sieć otrzymuje właściwą rodzinę adresów i dociera do tej samej usługi z certyfikatem bez publicznego hairpinningu przez dwa istotne cykle życia i przy oczekiwanym obciążeniu współbieżnym.

Użyj DNS z podzielonym horyzontem, aby zweryfikować najbliższy zależny proces. Jego zachowanie w zakresie dostępu, czasu i odzyskiwania musi pozostać niezmienione podczas aktywności nowego projektu.

Zatrzymaj się i wróć do zapisanego stanu, jeśli AAAA ujawnia publiczny lub nieaktualny adres, klienci korzystają z szyfrowanego zewnętrznego DNS albo routing IPv6 i polityka zapory nie odpowiadają otrzymanej odpowiedzi. Eskaluj problem, podając znaczniki czasu, dokładne wersje, dowody dotyczące tras lub montowania oraz najmniejszy przypadek reprodukcji, zamiast dodawać kolejne obejście.

Zweryfikuj wynik względem reguł zapory IPv6, aby ryzyko nie zostało jedynie przeniesione do innej warstwy sieci, tożsamości, kopii zapasowych lub pamięci masowej.

W przypadku podzielonego DNS dla stosu dual-stack właściwa odpowiedź brzmi zatem tak jak początkowa ocena - nie jest to bezwarunkowe „tak”. Obserwowalny stan powodzenia jest linią akceptacji; stan niepowodzenia jest linią wycofania zmian.