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

115

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?

— Otto
źródło

2

Nie używaj .local. Zwłaszcza jeśli masz klientów Apple.

— RainyRat

2

.test został odłożony na bok z tego powodu: secure.wikimedia.org/wikipedia/en/wiki/.test

— CWSpear

1

@CWSpear To nie jest rzeczywisty powód, dla którego .test jest zarezerwowany, ale czyni go bezpieczną domeną dla sieci testowych , które nie będą połączone z Internetem.

— voretaq7

10

@Otto najlepsze praktyki nakazałyby nabycie „prawdziwej” nazwy domeny (pod TLD rozpoznawaną przez ICANN) i utworzenie jej subdomeny dla lokalnych rzeczy (np. Rejestracja mydomain.com, delegowanie internal.mydomain.comdo wewnętrznego NS i prawidłowe skonfigurowanie DNS z podziałem horyzontu ( „widoki” w BIND), abyś nie ujawniał wewnętrznych nazw / adresów do Internetu. Nie jest tak ładny jak TLD / pseudo-TLD, ale jest mniej podatny na pękanie, ponieważ jest pod twoją kontrolą.

— voretaq7

9

Jednak : nie używaj prawdziwej nazwy domeny, której już używałeś do publicznych usług produkcyjnych. Istnieją różne interakcje, które są dozwolone pomiędzy www.example.comi *.internal.example.comktóre nie są dozwolone pomiędzy www.example.comi *.example.net, w szczególności z cookie ustawienie cross-site. Uruchamianie usług wewnętrznych i zewnętrznych w tej samej domenie zwiększa ryzyko, że kompromis z usług publicznych spowoduje pewne wejście do usług wewnętrznych, i odwrotnie, niepewna usługa wewnętrzna może spowodować wewnętrzne niewłaściwe korzystanie z usługi zewnętrznej.

— bobince

94

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ń.

— bortzmeyer
źródło

53

Aby być całkowicie bezpiecznym, umieściłbym wszystko w subdomenie nazwy domeny mojej firmy, takiej jak local.company.org, vm.company.org i tak dalej.

— drybjed

4

+1 to. Prawdopodobnie Twoja firma ma już domenę. Po prostu stwórz z niej subdomenę. Nie musi być widoczny / możliwy do rozwiązania poza siecią LAN.

— Dan Carley

3

Cóż, nawet z bardzo dobrymi prawnikami, będziesz miał problem z roszczeniem znaku „.lan” lub „.local”, powołując się na znak towarowy. A argument „jest tylko wewnętrzny” jest niezwykle słaby: organizacje łączą się, tworzą wirtualne sieci prywatne z organizacjami partnerskimi i po prostu popełniają błędy, powodując wyciek „prywatnych” nazw.

— bortzmeyer

8

Moją jedyną zaletą jest to, że tak naprawdę nie można „kupić” domeny: można ją tylko wynająć. Niektórzy bozo zapominają o zapłaceniu rachunku (a stało się to w kilku głośnych przypadkach), a podstawowa część twojej konfiguracji trafia do przypadkowego lokatora. Więc korzystasz z domeny swojej firmy? Kierownicy decydują się na zmianę marki lub wykupienie, a ty utknąłeś ze starym imieniem. .local działał wystarczająco dobrze, ale teraz został zablokowany przez pewną firmę w sposób, który odmawia przyjemnej gry. Naprawdę chciałbym zobaczyć coś takiego .lan lub .internal formalnie zarezerwowane do tego celu, ale do tego czasu jest to najlepsza opcja.

— Joel Coel,

6

Zgadzam się z @Joel Coel, jesteś najemcą i niczym więcej. Powinny istnieć dwie zastrzeżone nazwy TLD wyłącznie do użytku wewnętrznego, które powinny być uważane za niepoprawne w miejscach publicznych i niedostępne w sieciach publicznych. Jedna nazwa będzie przeznaczona do wewnętrznego użytku domowego, druga nazwa będzie do wewnętrznego użytku służbowego. Oba byłyby uważane za „prywatne TLD” w tym samym sensie, że mamy „prywatne podsieci”, które nie są routowalne (192.168.xx i podobne). Pozwala to użytkownikom domowym na zrobienie czegoś oprócz przymusu do .local i mDNS. To samo dotyczy małych firm z wewnętrzną siecią LAN za NAT bez domeny.

— Avery Payne

49

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.

— Jay Michaud
źródło

32

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.

— geewiz
źródło

2

To jest wspaniałe.

— Chris Magnuson

19

Do czasu, aż ktoś źle skonfiguruje swoją stację roboczą z przyrostkiem wyszukiwania produkcji, aby przetestować problem, a później nieumyślnie zaktualizuje kilka rekordów produkcji.

— Joel Coel,

1

To dość prymitywne, rekordy SRV są bardzo łatwe do przeanalizowania i mogą być umieszczone w dowolnej strefie, tak że ten sam serwer db obsługuje kilka stref. W takim przypadku część kodu wypełniłaby wartość w twoich plikach konfiguracyjnych. I możesz użyć nazwy bazy danych jako klucza SRV i wartości oczywiście wskazującej nazwę hosta. Nigdy nie polegałbym na sufiksach wyszukiwania. Możesz także uzyskać dość kreatywną pracę z rekordami TXT i wypchać je wartościami zakodowanymi w formacie aes-256 (następnie zakodowanym w standardzie base64), jeśli są one tajne. Możesz używać rekordów TXT do różnego rodzaju rzeczy.

— figtrap

widzę, ale to, czego chcę, to example.com, example.dev i example.stg. Ostatnie 2 są tylko w sieci prywatnej, czy mogę skonfigurować lokalny serwer DNS dla zerowego dostępu do konfiguracji? Nadal używam podobnej konfiguracji tutaj dla wszystkich stron, po prostu przenoszę zmiany do tld. Łatwe dla .dev z plikiem hostów, ale bez konfiguracji ...

— DigitalDesignDj

14

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.

— blihp
źródło

W dodatku G znajduje się przed cytowaną przez ciebie listą: „W ogóle nie zalecamy korzystania z niezarejestrowanych domen najwyższego poziomu”. To bardziej kluczowy punkt. Podane nazwy nie są „zalecane” do użycia, są to po prostu obserwowane nazwy, które będą działać lepiej niż .localto, co jest zarezerwowane dla MulticastDNS, co jest dyskusją w załączniku G.

— Patrick Mevzek,

2

Nie zgodziłbym się. Kluczową kwestią jest absurdalność rady: „nie rób tego ... ale kiedy to robisz ...” Oczekiwanie, że sieci domowe / małe firmy / niepubliczne powinny zarejestrować TLD, nie jest realistyczne. Ludzie mają zamiar używać niezarejestrowanych TLD tak daleko lepiej, aby pomóc wszystkim i powiedzieć „OK, oto lista niezarejestrowanych TLD można użyć wewnętrznie”, a nie udawać, każdy ma zamiar podążać dysk porady linii.

— blihp

Pozostaniemy wtedy w sporze. Fakt, że niektórzy ludzie używali TLD tak, jakby byli wewnętrzni (na przykład .MAIL w wielu dokumentacjach), jest dokładnie powodem, dla którego te TLD nie były możliwe do delegowania i są teraz w nieskończoność martwe. Dlatego dalsze zalecanie ludziom korzystania z TLD w ten sposób jest niekorzystne dla globalnej społeczności internetowej. Rada mówi, że skoro niektóre TLD są już tak wykorzystywane, to jeśli ludzie muszą nadużywać, powinni ponownie wykorzystać te zamiast nadużywać nowych. RFC2606 jest jasne, że TLD mogą używać wewnętrznie, które będą działać:.EXAMPLE .TEST .INVALID

— Patrick Mevzek,

12

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.

— Benoit
źródło

10

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.

— Mike Fiedler
źródło

-4

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

— Justin
źródło

2

Amazon zarejestrował się teraz .awsjako TLD, więc w końcu możesz zacząć widzieć problemy: nic.aws

— Mark McKinstry

1

Aby uzyskać informacje, plik .aws został niedawno zarejestrowany „25 marca 2016 r.” => Newgtlds.icann.org/en/program-status/delegated-strings

— Bruno Adelé

Chociaż nie sądzę, aby korzystanie z fałszywej TLD było aż tak wielkim problemem, przynajmniej nie jeśli cały system jest zamknięty i używa proxy do komunikacji z Internetem w ogóle, „.aws” to naprawdę zły wybór, chyba że NIE są w AWS! Istnieje zbyt wiele możliwych scenariuszy, w których nie będziesz już w stanie komunikować się z AWS.

— figtrap