Vraag Top-domein / achtervoegsel voor privé-netwerk?


Op ons kantoor hebben we een lokaal netwerk met een puur interne DNS-instelling, waarop klanten allemaal genoemd worden whatever.lan. Ik heb ook een VMware-omgeving en op het virtuele machine-alleen-netwerk noem ik de virtuele machines whatever.vm.

Momenteel is dit netwerk voor de virtuele machines niet bereikbaar via ons LAN, maar we richten een productienetwerk op om deze virtuele machines te migreren naar zullen bereikbaar vanaf het LAN. Dientengevolge proberen we genoegen te nemen met een conventie voor het domeinachtervoegsel / TLD die we toepassen op de gasten op dit nieuwe netwerk dat we aan het opzetten zijn, maar we kunnen geen goede naam bedenken, aangezien .vm, .local en .lan allemaal hebben ze connotaties in onze omgeving.

Wat is de beste werkwijze in deze situatie? Is er een lijst met TLD's of domeinnamen ergens die veilig is om te gebruiken voor een puur intern netwerk?


103
2018-06-01 21:47


oorsprong


Gebruik geen .local. Vooral als je Apple-klanten hebt. - RainyRat
.test wordt om deze reden gereserveerd: secure.wikimedia.org/wikipedia/en/wiki/.test - CWSpear
@CWSpear Dat is niet de echte reden  .test is gereserveerd, maar het maakt het een veilig domein om te gebruiken voor test netwerken die geen verbinding met internet hebben. - voretaq7
@Op de beste praktijken zou dicteren dat u een "echte" domeinnaam (onder een ICANN-erkend TLD) zou verwerven en een subdomein van dat voor uw lokale spullen zou maken (bijv. mydomain.comafgevaardigde internal.mydomain.com naar een interne NS, en correct gesplitste horizon DNS ("views" in BIND) configureren, zodat u geen interne namen / adressen naar het internet lekt. Het is niet zo mooi als een TLD / pseudo-TLD, maar het is minder vatbaar voor breuk omdat het onder uw controle is. - voretaq7
Echter: gebruik geen echte domeinnaam die u al hebt gebruikt voor openbare productieservices. Er zijn verschillende interacties toegestaan ​​tussen www.example.com en *.internal.example.com die zijn niet toegestaan ​​tussen www.example.com en *.example.net, met name cross-site cookie-instellingen. Het uitvoeren van interne en externe services op hetzelfde domein vergroot het risico dat een compromis van een openbare service de interne services binnendringt en omgekeerd dat een onveilige interne service intern misbruik van een externe service kan veroorzaken. - bobince


antwoorden:


Gebruik geen uitgevonden TLD. Als ICANN het zou delegeren, zou u in grote problemen komen. Hetzelfde als je fuseert met een andere organisatie die toevallig dezelfde dummy TLD gebruikt. Dat is de reden waarom globaal unieke domeinnamen de voorkeur hebben.

De standaard, RFC 2606 reserveert namen voor voorbeelden, documentatie, testen, maar niets voor algemeen gebruik en om goede redenen: vandaag is het zo gemakkelijk en goedkoop om een ​​echte en unieke domeinnaam te krijgen dat er geen goede reden is om een ​​dummy te gebruiken.

Dus, koop iamthebest.org en gebruik het om uw apparaten een naam te geven.


85
2018-06-02 07:39



Om volledig veilig te zijn, zou ik alles op een subdomein van de domeinnaam van mijn bedrijf plaatsen, zoals local.company.org, vm.company.org, enzovoort. - drybjed
+1 dit. Vermoedelijk heeft uw bedrijf al een domein. Maak hier eenvoudig een subdomein van. Het hoeft niet zichtbaar / oplosbaar te zijn buiten uw LAN. - Dan Carley
Wel, zelfs met zeer goede advocaten, zult u moeite hebben om ".lan" of ".local" te claimen door een handelsmerk aan te roepen. En het argument "it is internal only" is extreem zwak: organisaties fuseren, zetten virtuele privé-netwerken op met partnerorganisaties en maken eenvoudig fouten waardoor "privé" -namen lekken. - bortzmeyer
Mijn enige nadeel is dat je een domein niet echt kunt 'kopen': je kunt er maar één huren. Sommige bozo vergeet een rekening te betalen (en dit is gebeurd in enkele opvallende gevallen) en een kerndeel van je configuratie gaat naar een willekeurige kraker. Dus u gebruikt het domein van uw bedrijf? Execs besluiten om te rebranden of uit te kopen, en je zit vast met een oude naam. .local werkte altijd goed genoeg, maar het is nu door een bepaald bedrijf op voorhand geblokkeerd op manieren die weigeren aardig te spelen. Ik zou het echt leuk vinden om zoiets als .lan of .interne formeel gereserveerd voor dit doel te zien, maar tot die tijd is dit de beste optie. - Joel Coel
Ben het eens met @Joel Coel, je bent een huurder, en niets meer. Er moeten twee gereserveerde TLD-namen zijn alleen voor intern gebruik dat moet in het openbaar als ongeldig worden beschouwd en is niet bereikbaar via openbare netwerken. Eén naam zou voor intern thuisgebruik zijn, de tweede naam zou voor intern zakelijk gebruik zijn. Beide zouden worden beschouwd als "private TLD's" in dezelfde zin dat we "private subnetten" hebben die niet-routeerbaar zijn (192.168.x.x en ilk). Hiermee kunnen thuisgebruikers iets doen, behalve dat ze gedwongen worden in .local en mDNS. Idem voor kleine bedrijven met een intern LAN achter een NAT zonder domein. - Avery Payne


Gebruik een subdomein van het geregistreerde domein van uw bedrijf voor interne computers waarvan u de namen niet op het internet beschikbaar wilt hebben. (Natuurlijk, host u alleen die namen op uw interne DNS-servers.) Hier zijn enkele voorbeelden voor de fictieve Example Corporation.

Op het internet gerichte servers:
www.example.com
mail.example.com
dns1.example.com

Interne machines:
dc1.corp.example.com
dns1.corp.example.com
client1.corp.example.com

Ik heb 'corp' gebruikt om aan te geven dat dit subdomein machines op het interne bedrijfsnetwerk heeft beschreven, maar u kunt hier alles gebruiken wat u wilt, zoals 'intern': client1.intern.voorbeeld.com.

Onthoud ook dat DNS-zones en subdomeinen niet moeten worden uitgelijnd met uw netwerknummeringsschema. Mijn bedrijf heeft bijvoorbeeld 37 locaties, elk met een eigen subnet, maar op alle locaties wordt dezelfde (interne) domeinnaam gebruikt. Omgekeerd zou u slechts één of enkele subnetten kunnen hebben, maar veel interne domeinen of niveaus van subdomeinen om u te helpen bij het organiseren van uw machines.


46
2018-06-02 13:03





Er is nog een voordeel van het gebruik van een intern subdomein: slim gebruikmakend van zoekachtervoegsels en alleen hostnamen in plaats van FQDN, kunt u configuratiebestanden maken die zowel in ontwikkeling, QA als productie werken.

U gebruikt bijvoorbeeld altijd "database = dbserv1" in uw configuratiebestand.

Op de ontwikkelserver stelt u het zoek-achtervoegsel in op "dev.example.com" => gebruikte databaseserver: dbserv1.dev.example.com

Op de QA-server stelt u het zoek-achtervoegsel in op "qa.example.com" => gebruikte databaseserver: dbserv1.qa.example.com

En op de productieserver stelt u het zoek-achtervoegsel in op "example.com" => gebruikte databaseserver: dbserv1.example.com

Op die manier kunt u dezelfde instellingen in elke omgeving gebruiken.


29
2018-06-04 12:00



Dat is geweldig. - Chris Magnuson
Totdat iemand zijn werkstation verkeerd interpreteert met het suffix voor productiezoekopdrachten om een ​​probleem te testen en later per ongeluk een aantal productierecords bijwerkt. - Joel Coel
Dat is behoorlijk grof, SRV-records zijn heel eenvoudig te ontleden en kunnen in elke zone worden geplaatst, zodat dezelfde db-server meerdere zones bedient. In dit geval zou een beetje code de waarde invullen in uw configuratiebestanden. En u kunt de naam van de database gebruiken als de SRV-sleutel en de waarde die natuurlijk naar de hostnaam verwijst. Ik zou nooit vertrouwen op zoek achtervoegsels. Je kunt ook heel creatief worden met TXT-records en ze volstoppen met aes-256 gecodeerde (dan base64 gecodeerde) waarden, als het geheimen zijn. U kunt TXT-records voor allerlei dingen gebruiken. - figtrap
zie, maar wat ik wil is example.com, example.dev, en example.stg. De laatste twee zijn alleen op een privé-netwerk. Kan ik een lokale DNS-server instellen voor toegang tot zero config? Nog steeds met behulp van een vergelijkbare configuratie hier voor alle sites, alleen het verplaatsen van wijzigingen naar tld. Eenvoudig voor .dev met een hosts-bestand, maar geen configuratie ... - DigitalDesignDj


Zoals gezegd, zou u een niet-geregistreerde TLD niet moeten gebruiken voor uw privé-netwerk. Zeker nu ICANN bijna iedereen toestaat om nieuwe TLD's te registreren. Gebruik dan een echte domeinnaam

Aan de andere kant, de RFC 1918 is helder:

Indirecte verwijzingen naar dergelijke adressen   moet worden opgenomen in de   onderneming. Prominente voorbeelden hiervan   referenties zijn DNS-bronrecords   en andere informatie die verwijst naar   interne privé-adressen.   Uw nameserver moet dus ook weergaven gebruiken om te voorkomen dat de privé-records op internet worden verzonden.


10
2018-06-02 12:41





We hebben de neiging om geen verschil te overwegen in de virtuele naamgeving van hosts van de fysieke - in feite hebben we genomen om de hostconfiguratie (software) van de fysieke laag te abstraheren.

Dus we kopen Hardware-items aan en maken er Host-items bovenop (en gebruiken een eenvoudige relatie om dat in onze documentatie te laten zien).

Het doel is dat wanneer een host bestaat, DNS niet de doorslaggevende factor hoeft te zijn - omdat we machines van de ene naar de andere ruimte laten bewegen - bijvoorbeeld een slecht presterende webapp hoeft geen dure CPU-cycli te verbruiken - het te virtualiseren , en het behoudt zijn naamschema, alles blijft werken.


8
2018-06-01 21:52





Ik weet niet zeker of dit je zal helpen, maar voor interne DNS in mijn AWS-account die ik gebruik .aws als de tld, en het lijkt prima te werken.

Ik weet dat er enkele TLD's zijn die je gewoon niet zou moeten gebruiken, maar behalve die, ik denk niet dat het te streng is.

Ik werkte bij een paar grotere bedrijven, waar ze de authenticatiebron als het TLD zouden gebruiken, wat betekent dat als het een MS / Windows-server was, met behulp van Active Directory als de auth-bron, het zou zijn .ad, en sommige anderen zouden zijn .ldap (Waarom gebruikten ze niet alleen dezelfde bron of servers die repliceerden vanuit dezelfde directoryservice? Ik weet het niet, het was zo toen ik daar aankwam)

Succes


-4
2018-02-29 14:28



Amazon is nu geregistreerd .aws als een TLD, dus u kunt mogelijk op termijn problemen tegenkomen: nic.aws - Mark McKinstry
Ter informatie: de .aws is onlangs geregistreerd "25 maart 2016" => newgtlds.icann.org/en/program-status/delegated-strings - Bruno Adelé
Hoewel ik niet denk dat het gebruik van een valse TLD zo ingewikkeld is, althans niet als het hele systeem is afgesloten en een proxy gebruikt om te communiceren met internet in het algemeen, is ".aws" een echt slechte keuze tenzij je zit NIET in AWS! Er zijn veel te veel denkbare scenario's waarbij je niet meer met AWS kunt communiceren. - figtrap