# Planuj adresy i DNS jako części wdrożenia | SwissOctet Insights https://swissoctet.com/pl/insights/plan-addresses-and-dns-for-deployment/ SwissOctet / Spostrzeżenia / Inżynieria sieci Inżynieria sieci Podstawy · 4 min czytania Zaplanuj adresy i DNS jako części swojego wdrożenia Oddziel adresy publiczne, prywatne, statyczne i dedykowane, a następnie zmapuj przekierowanie DNS, odwrotne DNS i TLS do stron, które mogą je konfigurować. Autor: SwissOctet Editorial Zapisz przewodnik Kopiuj link NA TEJ STRONIE 01 Właściwości adresu odpowiadają na różne pytania 02 Adresacja prywatna nadal wymaga routingu i kontroli dostępu 03 Stałe nazwy i stałe adresy są ze sobą powiązane 04 Forward DNS i reverse DNS mają różnych właścicieli 05 Dedykowany adres nie jest wymagany dla każdej witryny HTTPS 06 Przed zmianą rekordów użyj mapy wdrożenia Twoja praktyczna lista kontrolna Źródła i dalsza lektura Powrót do biblioteki BEZPOŚREDNIA ODPOWIEDŹ Publiczny, prywatny, statyczny i dedykowany to niezależne właściwości adresu. Zbuduj mapę wdrożenia, która obejmuje również routing, zapory, forward DNS, reverse DNS i TLS, i zweryfikuj każde ustawienie u strony, która je kontroluje. 01 Właściwości adresu odpowiadają na różne pytania Publiczny i prywatny opisują, gdzie adres ma być routowany. Statyczny i dynamiczny opisują, jak przypisanie zachowuje się w czasie. Dedykowany i współdzielony opisują, jak adres jest używany lub przydzielany w ramach usługi. To odrębne właściwości: stabilny adres publiczny może obsługiwać wiele witryn, a adres prywatny może być przypisywany dynamicznie w kontrolowanej sieci. Opisz rolę każdego adresu we wdrożeniu: publiczny punkt wejścia, wewnętrzna baza danych, trasa zarządzania lub połączenie wychodzące. Następnie ustal, kto go przypisuje i co może się zmienić. Zapobiega to uzależnieniu prac konfiguracyjnych od założenia, że dedykowany oznacza trwale przypisany, a publiczny oznacza, że usługa jest osiągalna. Osiągalność zależy również od routingu, zapór i nasłuchu aplikacji. 02 Adresacja prywatna nadal wymaga routingu i kontroli dostępu RFC 1918 rezerwuje zakresy IPv4 10.0.0.0/8, 172.16.0.0/12 i 192.168.0.0/16 dla sieci prywatnych. Ich adresy nie są globalnie unikalnymi celami publicznymi. Sieć może tłumaczyć adresy prywatne dla połączeń wychodzących lub łączyć sieci prywatne przez jawne trasy. Usługa przychodząca za translacją wymaga celowej metody publikacji; sama zmiana rekordu DNS nie tworzy tej trasy. IPv6 ma własne typy i zakresy adresów, w tym adresowanie lokalne łącza i globalnie routowalne adresy unicast. Przejrzyj je osobno, zamiast zakładać, że reguła zapory lub translacji IPv4 obejmuje IPv6. Adres prywatny nie jest mechanizmem uwierzytelniania, a publiczny adres IPv6 nie jest powodem, by ujawniać każdą usługę. Testuj dostęp z każdej istotnej sieci i ogranicz administrację na odpowiedniej granicy. 03 Stałe nazwy i stałe adresy są ze sobą powiązane DHCP przydziela konfigurację adresu za pomocą protokołu i może używać dzierżaw. Dynamicznie przypisany adres może przez jakiś czas pozostać niezmieniony; nie czyni to jego trwałości gwarancją umowną. Gdy aplikacja zależy od stabilnego adresu, zweryfikuj politykę przypisywania i zmian u dostawcy, zamiast wnioskować o niej na podstawie wczorajszego połączenia. Dynamiczny DNS może zaktualizować nazwę po zmianie adresu, ale klienci mogą nadal buforować poprzednią odpowiedź. Nie może też pokonać nieosiągalnego nasłuchu, brakującej trasy przychodzącej ani translacji adresów klasy operatorskiej. Używaj go, gdy sieć pozwala na połączenie, a aplikacja toleruje opóźnienia aktualizacji. W przypadku wdrożenia hostowanego udokumentuj zamierzony cykl życia adresu przed zbudowaniem list dozwolonych lub integracji zewnętrznych wokół niego. Właściwość Co potwierdzić Częste błędne założenie Publiczny lub prywatny Zakres routingu i ścieżka dostępu Sam adres czyni usługę osiągalną Statyczny lub dynamiczny Polityka przypisywania i zmian Niezmieniona dzierżawa jest trwała Dedykowany lub współdzielony Przydział i dozwolone użycie Dedykowany adres zapewnia anonimową tożsamość IPv4 lub IPv6 Zarówno konfiguracja routingu, jak i zapory Ustawienia jednego protokołu obejmują drugi 04 Forward DNS i reverse DNS mają różnych właścicieli Forward DNS mapuje nazwy na dane, takie jak rekordy adresów A i AAAA. Reverse DNS używa przestrzeni nazw powiązanej z adresem i rekordów PTR, aby powiązać adres z nazwą. Organizacja kontrolująca strefę forward DNS niekoniecznie jest organizacją kontrolującą reverse DNS dla zakresu adresów. Uzyskaj właściwą ścieżkę konfiguracji, zanim obiecasz nazwę odwrotną. Sprawdź rekord przez odpowiedni resolver i zapisz wynik. W przypadku PTR mającego identyfikować host sprawdź także, czy odpowiadający mu rekord forward wskazuje oczekiwany adres. Reverse DNS może wspierać identyfikację operacyjną i niektóre kontrole systemów pocztowych, ale nie uwierzytelnia aplikacji ani nie gwarantuje dostarczenia wiadomości. Wysyłanie poczty wymaga również własnego przeglądu domeny, reputacji i uwierzytelniania. 05 Dedykowany adres nie jest wymagany dla każdej witryny HTTPS Routing hostów HTTP i rozszerzenie TLS Server Name Indication pozwalają obsługiwanym klientom i serwerom wybrać witrynę lub certyfikat po nazwie. Kilka witryn HTTPS może zatem używać jednego adresu bez potrzeby osobnego adresu publicznego dla każdej domeny. Rzeczywista konfiguracja hostingu i wymagani klienci decydują, czy takie rozwiązanie jest odpowiednie. Wybierz dodatkowy adres tylko wtedy, gdy udokumentowane wymaganie tego wymaga, na przykład w przypadku obsługiwanego rozdzielenia sieci lub systemu zewnętrznego oczekującego odrębnego punktu końcowego. Adres nie zapewnia odporności na problemy z reputacją ani nie identyfikuje osoby obsługującej usługę. Prowadź osobne kontrole certyfikatów, routingu nazw hostów i przydziału adresów. Zweryfikuj certyfikat obsługiwany przez nazwę hosta, którą użytkownicy faktycznie odwiedzą. 06 Przed zmianą rekordów użyj mapy wdrożenia Utwórz niewielką mapę zawierającą każdą nazwę hosta, rekord adresu, nasłuch, ścieżkę zapory i stronę odpowiedzialną. Uwzględnij administrację, kopie zapasowe i wszelkie wychodzące listy dozwolonych. Sprawdź, czy konfiguracja SwissOctet wymienia potrzebną opcję adresu, i zapytaj o kontrolę reverse DNS, zanim zaczniesz na niej polegać. Nie przedstawiaj opcji katalogowych jako aktywnego przypisania, które zostało już udostępnione. Podczas przenoszenia przygotuj aplikację docelową i ustawienia TLS, zanim skierujesz tam użytkowników. Uwzględnij pamięci podręczne DNS i utrzymuj wykonalną ścieżkę odzyskiwania. Zweryfikuj osobno rozwiązywanie nazw forward, rzeczywistą osiągalność aplikacji i oczekiwaną nazwę odwrotną. Mapa ułatwia zlokalizowanie awarii, ponieważ błędny rekord, zamknięty port i niedopasowany certyfikat to różne problemy z różnymi właścicielami. ZAMIEŃ TO W DZIAŁANIE Twoja praktyczna lista kontrolna. ✓ Zmapuj rolę adresu, przypisanie i własność. ✓ Sprawdź IPv4 i IPv6 osobno. ✓ Zweryfikuj routing przychodzący, zanim zaczniesz polegać na DNS. ✓ Ustal, kto kontroluje rekordy PTR. ✓ Testuj nazwę hosta, certyfikat i aplikację razem. Pobierz listę kontrolną CZĘSTE PYTANIA Szczegóły, które mają znaczenie. Czy dedykowany adres IP czyni usługę anonimową? + Nie. Opisuje on przydział lub sposób użycia, a nie tożsamość ani gwarancję prywatności. Konta, ruch i dane aplikacji mają odrębne konsekwencje. Czy mogę ustawić rekordy PTR z panelu DNS mojej domeny? + Tylko jeśli kontroluje on również odpowiednią strefę odwrotną. Dostawca adresu zwykle kontroluje tę strefę lub udostępnia osobny proces żądania. Czy każda domena HTTPS potrzebuje własnego adresu? + Niekoniecznie. Obsługiwani klienci i serwery mogą używać routingu opartego na nazwach i TLS SNI. Zweryfikuj rzeczywiste wymagania hostingu i klientów. GŁÓWNE ŹRÓDŁA Przejdź do źródła. Te źródła wspierają koncepcje techniczne w tym przewodniku. Przed zmianą systemu produkcyjnego zapoznaj się z aktualną dokumentacją. RFC 1918: przydział adresów dla sieci prywatnych www.rfc-editor.org RFC 2131: Dynamic Host Configuration Protocol www.rfc-editor.org RFC 1035: implementacja i specyfikacja DNS www.rfc-editor.org RFC 4291: architektura adresowania IPv6 www.rfc-editor.org RFC 6066: rozszerzenia TLS, w tym Server Name Indication www.rfc-editor.org Wskazówki redakcyjne SwissOctet. Przykłady są ilustracyjne. Specyfikacje usług, dostępne opcje i warunki umowne należy zweryfikować osobno. POŁĄCZ WIEDZĘ Powiązana infrastruktura. Vector VPS Szwajcaria Canvas Web Szwajcaria Metal Origin Szwajcaria Shield VPN Szwajcaria ZACHOWAJ WĄTEK Twoje następne notatki z terenu. Poznaj wszystkie przewodniki NOTATKA Z TERENU / 01 + Inżynieria sieci Podstawy Przepustowość, prędkość portu i transfer: poznaj pełny obraz Oszacuj ilość danych przesyłanych przez Twój projekt i zrozum, dlaczego większy port to tylko jedna część wydajności sieci. 4 min czytania Przeczytaj przewodnik NOTATKA Z TERENU / 02 + Operacje dnia drugiego Praktyczne Bezpieczne administrowanie Windows RDP bez utraty dostępu Oddziel osiągalność sieciową, uwierzytelnianie i uprawnienia, a następnie zweryfikuj ścieżkę odzyskiwania, zanim ograniczysz dostęp zdalny. 6 min czytania Przeczytaj przewodnik NOTATKA Z TERENU / 03 + Inżynieria sieci Zaawansowane Oszacuj transfer z uwzględnieniem opóźnienia, współbieżności i pomiarów przepustowości Zbuduj powtarzalny model transferu na podstawie wolumenu danych, okien dostarczania i czasu rundy, a następnie przetestuj go, nie myląc etykiety portu z użyteczną przepustowością. 4 min czytania Przeczytaj przewodnik