Domena / sufiks domeny najwyższego poziomu dla sieci prywatnej?

W naszym biurze mamy sieć lokalną z czysto wewnętrzną konfiguracją DNS, na której wszyscy klienci nazywani są jako whatever.lan. Mam także środowisko VMware, aw sieci opartej tylko na maszynach wirtualnych nazywam maszyny wirtualne whatever.vm.

Obecnie ta sieć maszyn wirtualnych jest niedostępna z naszej sieci lokalnej, ale konfigurujemy sieć produkcyjną do migracji tych maszyn wirtualnych, do których będzie można uzyskać dostęp z sieci LAN. W rezultacie staramy się ustalić konwencję dotyczącą przyrostka domeny / TLD, które stosujemy do gości w nowej sieci, którą konfigurujemy, ale nie możemy wymyślić dobrej, biorąc pod uwagę to .vm, .locali .lanwszystkie mają istniejące konotacje w naszym środowisku.

Więc jaka jest najlepsza praktyka w tej sytuacji? Czy istnieje lista TLD lub nazw domen w bezpiecznym miejscu dla sieci o charakterze wyłącznie wewnętrznym?

Nie używaj wymyślonej TLD. Gdyby ICANN ją delegował, miałbyś duże kłopoty. To samo, jeśli połączysz się z inną organizacją, która akurat używa tej samej fikcyjnej TLD. Dlatego preferowane są globalnie unikalne nazwy domen.

Standardowo, RFC 2606 rezerwuje nazwy dla przykładów, dokumentacji, testów, ale nic do ogólnego użytku i z ważnych powodów: dzisiaj tak łatwo i tanio jest uzyskać prawdziwą i unikalną nazwę domeny, że nie ma dobrego powodu, aby używać obojętny.

Więc kup iamthebest.orgi używaj go do nazwania swoich urządzeń.

Użyj poddomeny zarejestrowanej domeny swojej firmy dla wewnętrznych komputerów, których nazwy nie powinny być dostępne w Internecie. (Zatem oczywiście przechowuj tylko te nazwy na wewnętrznych serwerach DNS). Oto kilka przykładów fikcyjnej firmy przykładowej.

Internet skierowaną serwerów:
www.example.com
mail.przykład.com
dns1.example.com

Komputery wewnętrzne: dc1.corp.example.com
dns1.corp.example.com
client1.corp.example.com

Użyłem „corp”, aby wskazać, że ta subdomena opisuje maszyny w wewnętrznej sieci korporacyjnej, ale możesz użyć tutaj wszystkiego, co chcesz, na przykład „wewnętrznego”: client1.internal.example.com.

Pamiętaj też, że strefy DNS i poddomeny nie muszą być zgodne z planem numeracji sieci. Na przykład moja firma ma 37 lokalizacji, każda z własną podsiecią, ale wszystkie lokalizacje używają tej samej (wewnętrznej) nazwy domeny. I odwrotnie, możesz mieć tylko jedną lub kilka podsieci, ale wiele równorzędnych domen wewnętrznych lub poziomów subdomen, które pomogą Ci zorganizować swoje maszyny.

Istnieje jeszcze jedna zaleta korzystania z wewnętrznej subdomeny: sprytnie używając sufiksów wyszukiwania i tylko nazw hostów zamiast FQDN, możesz budować pliki konfiguracyjne, które działają zarówno w fazie programowania, kontroli jakości, jak i produkcji.

Na przykład zawsze używasz „database = dbserv1” w pliku konfiguracyjnym.

Na serwerze programistycznym ustawiłeś sufiks wyszukiwania na „dev.example.com” => użyty serwer bazy danych: dbserv1.dev.example.com

Na serwerze kontroli jakości ustaw sufiks wyszukiwania na „qa.example.com” => użyty serwer bazy danych: dbserv1.qa.example.com

Na serwerze produkcyjnym ustawiłeś przyrostek wyszukiwania na „przyklad.com” => użyty serwer bazy danych: dbserv1.example.com

W ten sposób możesz używać tych samych ustawień w każdym środowisku.

Ponieważ napisano poprzednie odpowiedzi na to pytanie, pojawiło się kilka RFC, które nieco zmieniają wytyczne. RFC 6761 omawia nazwy domen specjalnego zastosowania, nie podając konkretnych wskazówek dla sieci prywatnych. RFC 6762 nadal zaleca nieużywanie niezarejestrowanych TLD, ale przyznaje również, że istnieją przypadki, w których zostanie to zrobione. Ponieważ często używane lokalne konflikty z Multicast DNS (główny temat RFC), dodatek G. Prywatne przestrzenie nazw DNS zalecają następujące domeny TLD:

• intranet
• wewnętrzny
• prywatny
• corp
• Dom
• lan

Wydaje się, że IANA rozpoznaje oba RFC, ale (obecnie) nie zawiera nazw wymienionych w dodatku G.

Innymi słowy: nie powinieneś tego robić. Ale kiedy zdecydujesz się to zrobić, użyj jednej z powyższych nazw.

Jak już powiedziano, nie należy używać niezarejestrowanej domeny TLD w swojej sieci prywatnej. Zwłaszcza teraz, gdy ICANN pozwala prawie każdemu zarejestrować nowe TLD. Następnie powinieneś użyć prawdziwej nazwy domeny

Z drugiej strony RFC 1918 jest jasny:

Pośrednie odniesienia do takich adresów powinny być zawarte w przedsiębiorstwie. Wybitnymi przykładami takich odniesień są rekordy zasobów DNS i inne informacje dotyczące wewnętrznych adresów prywatnych. Twój serwer nazw powinien także używać widoków, aby uniemożliwić przesyłanie prywatnych rekordów przez Internet.

Zwykle nie bierzemy pod uwagę żadnej różnicy w wirtualnym nazewnictwie hostów od fizycznej - w rzeczywistości podjęliśmy się abstrakcji konfiguracji hosta (oprogramowania) od warstwy fizycznej.

Więc kupujemy przedmioty sprzętowe i tworzymy nad nimi przedmioty hosta (i używamy prostej relacji, aby pokazać to w naszej dokumentacji).

Chodzi o to, że gdy host istnieje, DNS nie powinien być czynnikiem decydującym - ponieważ mamy maszyny, które przenoszą się z jednej przestrzeni do drugiej - na przykład nisko wydajna aplikacja internetowa nie musi zużywać drogich cykli procesora - zwirtualizuj ją i zachowuje swój schemat nazewnictwa, wszystko nadal działa.

Nie jestem pewien, czy to ci pomoże, ale w przypadku wewnętrznego DNS na moim koncie AWS używam .awsjako tld i wydaje się, że działa idealnie dobrze.

Wiem, że istnieje kilka TLD, których po prostu nie powinieneś używać, ale poza tymi, nie sądzę, że jest to zbyt surowe.

Pracowałem w kilku większych firmach, w których używałyby źródła uwierzytelniania jako TLD, co oznaczałoby, że byłby to serwer MS / Windows, korzystałby z Active Directory jako źródła uwierzytelniania .ad, a niektóre inne byłyby .ldap(Dlaczego nie były używasz tylko tego samego źródła? lub serwerów replikujących się z tej samej usługi katalogowej? Nie wiem, tak było, kiedy tam dotarłem)

Powodzenia