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

115

Nel nostro ufficio disponiamo di una rete locale con una configurazione DNS puramente interna, su cui tutti i client hanno il nome whatever.lan. Ho anche un ambiente VMware e, sulla rete solo per macchine virtuali, nomina 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 la migrazione di queste macchine virtuali, che sarà raggiungibile dalla LAN. Di conseguenza, stiamo cercando di accordarci su una convenzione per il suffisso / TLD di dominio che applichiamo agli ospiti su questa nuova rete che stiamo configurando, ma non possiamo trovare una buona, dato che .vm, .locale .lantutti 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?

— Otto
fonte

2

Non usare .local. Soprattutto se hai clienti Apple.

— RainyRat,

2

.test viene accantonato per questo motivo: secure.wikimedia.org/wikipedia/en/wiki/.test

— CWSpear

1

@CWSpear Non è questo il vero motivo .test riservato, anche se lo rende un dominio sicuro da utilizzare per le reti di test che non saranno connesse a Internet.

— voretaq7,

10

@Otto migliori pratiche vorrebbe che si acquista un "vero" nome del dominio (in virtù di un TLD ICANN riconosciuto) e di creare un sottodominio di quello per la vostra roba locale (ad esempio registro mydomain.com, delegato internal.mydomain.coma un NS interne, e configurare correttamente spaccato DNS horizon ( "view" in BIND) in modo da non far trapelare nomi / indirizzi interni a Internet. Non è bello come un TLD / pseudo-TLD, ma è meno soggetto a rotture come è sotto il tuo controllo.

— voretaq7

9

Tuttavia : non utilizzare un nome di dominio reale che hai già utilizzato per i servizi di produzione rivolti al pubblico. Esistono varie interazioni consentite tra www.example.come *.internal.example.comche non sono consentite tra www.example.come *.example.net, in particolare l'impostazione dei cookie tra siti. L'esecuzione di servizi interni ed esterni nello stesso dominio aumenta il rischio che un compromesso di un servizio pubblico dia accesso ai servizi interni e, al contrario, un servizio interno non sicuro potrebbe provocare un uso interno non corretto di un servizio esterno.

— bobince

94

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 niente per uso generale e per buoni motivi: oggi è così facile ed economico ottenere un nome di dominio reale e unico che non ci sono buoni motivi per usare un uno fittizio.

Quindi, acquistalo iamthebest.orge usalo per nominare i tuoi dispositivi.

— Bortzmeyer
fonte

53

Per essere totalmente sicuro, metterei tutto su un sottodominio del nome di dominio della mia azienda, come local.company.org, vm.company.org e così via.

— drybjed

4

+1 questo. Presumibilmente la tua azienda ha già un dominio. Basta creare un sottodominio da questo. Non deve essere visibile / risolvibile al di fuori della LAN.

— Dan Carley,

3

Bene, anche con ottimi avvocati, avrai difficoltà a rivendicare ".lan" o ".local" invocando un marchio. E l'argomento "è solo interno" è estremamente debole: le organizzazioni si fondono, creano reti private virtuali con organizzazioni partner e fanno semplicemente errori tali da far trapelare nomi "privati".

— Bortzmeyer,

8

Il mio unico vantaggio è che non puoi davvero "comprare" un dominio: puoi solo noleggiarne uno. Alcuni bozo dimenticano di pagare un conto (e questo è successo in alcuni casi di alto profilo) e una parte fondamentale della configurazione va ad alcuni squatter casuali. Quindi usi il dominio della tua azienda? Execs decide di rinominare o essere acquistato, e sei bloccato con un vecchio nome. .local funzionava abbastanza bene, ma ora è stato anticipato da una certa compagnia in modi che si rifiutano di giocare bene. Mi piacerebbe davvero vedere qualcosa come .lan o .internal formalmente riservato a questo scopo, ma fino ad allora questa è l'opzione migliore.

— Joel Coel,

6

Concordo con @Joel Coel, sei un affittuario e niente di più. Dovrebbero esserci due nomi TLD riservati solo per uso interno che devono essere considerati non validi in pubblico e non raggiungibili dalle reti pubbliche. Un nome sarebbe per uso domestico interno, il secondo nome sarebbe per uso aziendale interno. Entrambi sarebbero considerati "TLD privati" nello stesso senso in cui abbiamo "sottoreti private" che non sono instradabili (192.168.xx e ilk). Ciò consente agli utenti domestici di fare qualcosa oltre a essere forzati in .local e mDNS. Idem per le piccole imprese che gestiscono una LAN interna dietro un NAT senza dominio.

— Avery Payne,

49

Utilizza un sottodominio del dominio registrato della tua azienda per macchine interne i cui nomi non desideri 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 accesso 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 subnet, ma molti domini interni peer o livelli di sottodomini per aiutarti a organizzare i tuoi computer.

— Jay Michaud
fonte

32

C'è un altro vantaggio dell'utilizzo di un sottodominio interno: utilizzando abilmente i suffissi di ricerca e solo i nomi host anziché il nome di dominio completo, è 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 di 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.

— geewiz
fonte

2

Questo è geniale.

— Chris Magnuson,

19

Fino a quando qualcuno configura erroneamente la propria workstation con il suffisso di ricerca della produzione per testare un problema e successivamente aggiorna inavvertitamente un mucchio di record di produzione.

— Joel Coel,

1

È piuttosto rozzo, i record SRV sono molto semplici da analizzare e possono essere inseriti in qualsiasi zona, in modo che lo stesso server db serva diverse zone. In questo caso un po 'di codice riempirebbe il valore all'interno dei file di configurazione. E puoi usare il nome del database come chiave SRV e il valore ovviamente che punta al nome host. Non farei mai affidamento sui suffissi di ricerca. Puoi anche diventare abbastanza creativo con i record TXT e riempirli di valori crittografati con aes-256 (quindi codificati in base64), se sono segreti. Puoi usare i record TXT per ogni sorta di cose.

— figtrap,

vedi, ma quello che voglio è example.com, example.dev e example.stg. Gli ultimi 2 sono solo su una rete privata, posso impostare un server DNS locale per l'accesso senza configurazione? Usando ancora una configurazione simile qui per tutti i siti, spostando le modifiche su tld. Facile per .dev con un file hosts, ma zero config ...

— DigitalDesignDj

15

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 .local comunemente usato è in conflitto con il DNS multicast (l'argomento principale dell'RFC), l' Appendice G. Gli spazi dei nomi DNS privati raccomandano i seguenti TLD:

intranet
interno
privato
corp
casa
lan

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

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

— blihp
fonte

L'appendice G ha prima dell'elenco che citi: "Non raccomandiamo affatto l'uso di domini di primo livello non registrati". Questo è più il punto chiave. I nomi forniti non sono "raccomandati" da usare, sono solo i nomi osservati che funzionano meglio di quelli .localche sono un po 'riservati a MulticastDNS, che è la discussione nell'Appendice G.

— Patrick Mevzek,

2

Non sarei d'accordo. Il punto chiave è l'assurdità del consiglio: "non farlo ... ma quando lo fai ..." L'aspettativa che le reti domestiche / di piccole imprese / non pubbliche debbano registrare un TLD non è realistica. Le persone stanno andando a utilizzare TLD non registrati in modo di gran lunga migliore di aiutare tutti fuori e dire 'OK, ecco una lista di domini di primo livello non registrati è possibile utilizzare internamente', piuttosto che fingere tutti sta per seguire il consiglio linea dura.

— blihp,

Rimarremo in disaccordo allora. Il fatto che alcune persone abbiano usato il TLD come se fossero interne (ad esempio, .MAIL trovato in molte documentazioni) è esattamente il motivo per cui questi TLD non potevano delegare e ora sono indefinitamente morti. Quindi continuare a raccomandare alle persone di usare i TLD in questo modo è un disservizio per la comunità globale di Internet. Il consiglio dice che poiché alcuni TLD sono già stati abusati in questo modo, se le persone devono abusare dovrebbero riutilizzare quelle invece di abusarne di nuove. RFC2606 è chiaro per i TLD da usare internamente che funzionerà:.EXAMPLE .TEST .INVALID

— Patrick Mevzek il

12

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, l' 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.

— Benoit
fonte

10

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

Quindi acquistiamo articoli hardware e creiamo sopra degli articoli host (e usiamo una semplice relazione per dimostrarlo 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.

— Mike Fiedler
fonte

-4

Non sono sicuro che questo ti aiuterà, ma per il DNS interno all'interno del mio account AWS, utilizzo .awscome tld e sembra funzionare perfettamente.

So che ci sono alcuni TLD che dovresti semplicemente non usare, ma a parte quelli, non penso che sia troppo severo.

Ho lavorato in alcune grandi aziende, dove avrebbero usato l'origine di autenticazione come TLD, il che significa che se fosse un server MS / Windows, usando Active Directory come fonte di autenticazione, sarebbe .ad, e alcuni altri sarebbero .ldap(Perché erano stai usando la stessa fonte o server che si replicano dallo stesso servizio di directory? Non lo so, era così quando sono arrivato lì)

In bocca al lupo

— Justin
fonte

2

Amazon è ora registrato .awscome TLD, quindi potresti iniziare a vedere i problemi alla fine: nic.aws

— Mark McKinstry

1

Per informazione, il .aws è stato recentemente registrato "25 marzo 2016" => newgtlds.icann.org/en/program-status/delegated-strings

— Bruno Adelé

Anche se non credo che usare un TLD fasullo sia un grosso problema, almeno non se l'intero sistema è chiuso e utilizza un proxy per comunicare con Internet in generale, ".aws" è una scelta davvero sbagliata a meno che tu NON sei in AWS! Ci sono troppi scenari immaginabili in cui non sarai più in grado di comunicare con AWS.

— figtrap,