sviluppo-web-qa.it

Dominio di livello superiore / suffisso di dominio per la rete privata?

Nel nostro ufficio disponiamo di una rete locale con una configurazione DNS puramente interna, in cui tutti i client sono denominati whatever.lan. Ho anche un ambiente VMware e, sulla rete solo per macchine virtuali, assegno le macchine virtuali whatever.vm.

Attualmente, questa rete per le macchine virtuali non è raggiungibile dalla nostra rete locale, ma stiamo configurando una rete di produzione per migrare queste macchine virtuali, che sarà sarà raggiungibile dalla LAN. Di conseguenza, stiamo cercando di stabilire una convenzione per il suffisso/TLD di dominio che applichiamo agli ospiti su questa nuova rete che stiamo configurando, ma non possiamo trovarne una valida, dato che .vm, .local e .lan tutti hanno connotazioni esistenti nel nostro ambiente.

Quindi, qual è la migliore pratica in questa situazione? C'è un elenco di TLD o nomi di dominio da qualche parte che è sicuro da usare per una rete puramente interna?

121
Otto

Non utilizzare un TLD inventato. Se l'ICANN lo delegasse, si sarebbe nei guai. Stessa cosa se ti unisci con un'altra organizzazione che utilizza lo stesso TLD fittizio. Ecco perché sono preferiti nomi di dominio univoci a livello globale.

Lo standard RFC 2606 riserva i nomi per esempi, documentazione, test, ma nulla per uso generale e per buoni motivi: oggi è così facile ed economico ottenere un nome di dominio reale e unico che lì non è una buona ragione per usarne uno fittizio.

Quindi, acquista iamthebest.org e usalo per nominare i tuoi dispositivi.

96
bortzmeyer

Utilizzare un sottodominio del dominio registrato della propria azienda per macchine interne i cui nomi non si desidera siano disponibili su Internet. (Quindi, ovviamente, ospita solo quei nomi sui tuoi server DNS interni.) Ecco alcuni esempi per la fittizia Example Corporation.

server con connessione a Internet:
Www.example.com
Mail.example.com
Dns1.example.com

Macchine interne:
Dc1.corp.example.com
Dns1.corp.example.com
Client1.corp.example.com

Ho usato "corp" per indicare che questo sottodominio descriveva macchine sulla rete aziendale interna, ma è possibile utilizzare tutto ciò che si desidera qui, ad esempio "interno": client1.internal.example.com.

Ricorda anche che le zone DNS e i sottodomini non devono allinearsi con lo schema di numerazione della tua rete. La mia azienda, ad esempio, ha 37 sedi, ognuna con la propria sottorete, ma tutte le sedi utilizzano lo stesso nome di dominio (interno). Al contrario, potresti avere solo una o poche sottoreti, ma molti domini interni peer o livelli di sottodomini per aiutarti a organizzare le tue macchine.

52
Jay Michaud

C'è un altro vantaggio dell'utilizzo di un sottodominio interno: usando abilmente suffissi di ricerca e solo nomi host anziché FQDN, è possibile creare file di configurazione che funzionano sia in sviluppo, QA e produzione.

Ad esempio, si utilizza sempre "database = dbserv1" nel file di configurazione.

Sul server di sviluppo, impostare il suffisso di ricerca su "dev.example.com" => server di database utilizzato: dbserv1.dev.example.com

Sul server QA, impostare il suffisso di ricerca su "qa.example.com" => server database utilizzato: dbserv1.qa.example.com

E sul server di produzione, impostare il suffisso di ricerca su "example.com" => server di database utilizzato: dbserv1.example.com

In questo modo, puoi utilizzare le stesse impostazioni in ogni ambiente.

33
geewiz

Da quando sono state scritte le risposte precedenti a questa domanda, ci sono stati un paio di RFC che alterano in qualche modo la guida. RFC 6761 discute i nomi di dominio per uso speciale senza fornire indicazioni specifiche per le reti private. RFC 6762 raccomanda ancora di non utilizzare TLD non registrati, ma riconosce anche che ci sono casi in cui verrà comunque eseguito. Poiché il comunemente usato . Local è in conflitto con il Multicast DNS (l'argomento principale della RFC), Appendice G. Spazi dei nomi DNS privati raccomanda i seguenti TLD:

  • intranet
  • interno
  • privato
  • corp
  • casa
  • lan

IANA sembra riconoscere entrambi gli RFC ma (attualmente) non incorpora i nomi elencati nell'Appendice G.

In altre parole: non dovresti farlo. Ma quando decidi di farlo comunque, usa uno dei nomi sopra.

26
blihp

Come già detto, non dovresti usare un TLD non registrato per la tua rete privata. Soprattutto ora che ICANN consente a quasi tutti di registrare nuovi TLD. Dovresti quindi utilizzare un nome di dominio reale.

Dall'altro lato, RFC 1918 è chiaro:

I riferimenti indiretti a tali indirizzi dovrebbero essere contenuti all'interno dell'azienda. Esempi importanti di tali riferimenti sono i record di risorse DNS e altre informazioni che si riferiscono ad indirizzi privati ​​interni.

Quindi il tuo server dei nomi dovrebbe anche usare le viste per impedire che i record privati ​​vengano trasmessi su Internet.

13
Benoit

Tendiamo a non considerare alcuna differenza nella denominazione virtuale degli host dal fisico - in effetti, abbiamo preso l'astrazione della configurazione dell'host (software) dal livello fisico.

Quindi acquistiamo articoli hardware e creiamo oggetti host sopra di essi (e usiamo una semplice relazione per mostrarlo nella nostra documentazione).

Lo scopo è che quando esiste un host, il DNS non dovrebbe essere il fattore determinante - poiché abbiamo macchine che si spostano da uno spazio al successivo - ad esempio una webapp a basso rendimento non ha bisogno di consumare costosi cicli della CPU - virtualizzarla e mantiene il suo schema di denominazione, tutto continua a funzionare.

10
Mike Fiedler