# Best practice: corporate network naming

## VinzC

Hi all.

I feel I become less certain of what I once knew for sure  :Very Happy:  . Here's my question.

When setting up a corporate network -- when accessing the corporate network remotely is a requirement -- is it best to set the local network name to the same as the public domain (e.g. domain.info) or is it best to remain with a domain.local habit? I'm asking this because in the latter situation, [what I call] an aliased domain.info must be created internally to allow people internal access to the servers that have a public address on the internet -- I never could imagine asking our dearest users to type www.domain.local when working at the office and www.domain.info anywhere else...

Additionally when it comes to setting up mail servers and/or directory servers, what seems logical is that the public domain be used in the configuration. E.g. root="dc=domain,dc=info" with OpenLDAP and mydestination=domain.info in postfix.

So the case with the public domain as the internal network domain name is simpler to handle. IMHO. Right?

I'd like to know your point of view, pros and cons on this.

Thanks in advance.

----------

## Hu

My preference would be to assign .local names to machines which can only be reached through private addresses, and .info names to machines which can be reached via a public address.  This makes it very clear which servers are private-only and which ones are publicly accessible.  I have not received significant feedback from non-technical users on whether they like such a plan, so you may want to float the idea internally before committing to it.  If users frequently use services from both groups of servers, they might be irritated at the seemingly arbitrary variance in names.

You could still use a split brained DNS to serve up the true private addresses when an internal user enters a public name, if the network configuration reacts badly to internal users accessing your public IPs.  This would allow users to always enter www.domain.info, without regard to where they are connected.  The DNS server they hit would give an answer that was reasonable for their current context.

Using a single domain for all hosts is simpler, but can be more confusing.  Consider the case where you have webmail.domain.info publicly reachable so that users can check their e-mail from anywhere, but have sales.domain.info restricted to the private network so that it cannot be attacked by unauthenticated users on the Internet.  Looking at the names, it would not be immediately clear that these two hosts have different properties, so users might wonder why they can use one from anywhere, but the other only when logged in to the VPN.

----------

## darkphader

I highly suggest staying away from using .local (specifically) because of some multicast dns bs. Been bitten by it in the past. Instead use something like .office, .soho, .home or a sub-domain of your public domain, ie: public domain is mydomain.com, use for example city.mydomain.com.

Just wanted to add that although I've used the sub-domain feature much, I actually now prefer the .office type address because Windows boxen default to querying the parent domain if the host isn't found in the current domain. Therefore you will see two lookup's for any not fully qualified or un-found host on the sub-domain.

Chris

----------

## VinzC

Thank you for your lights. Actually the kind of servers that are publicly accessible are also accessible internally (e.g. www, smtp, imap). Currently I've used a split brain DNS to serve known public DNS records as private IP addresses. The internal domain name ends with .local . What do you mean darkphader with “being bitten by it”?

----------

## darkphader

 *VinzC wrote:*   

> The internal domain name ends with .local . What do you mean darkphader with “being bitten by it”?

 

Sorry, I can't remember exactly what the problems were but I had issues on my own subnet right after Gentoo started supporting mDNS, or zeroconf, or something else (this was some time ago). It wrecked havoc on my network. Simply changing my internal tld to .soho resolved them.

http://files.multicastdns.org/draft-cheshire-dnsext-multicastdns.txt

http://blog.scottlowe.org/2006/01/04/mac-os-x-and-local-domains/

http://www.macosxhints.com/article.php?story=20040806232315819

Avoid the problems (or possible problems), don't use .local :)

----------

## VinzC

Thanks.

I'm not sure if this solves the problem but I already have implemented the network in question -- my initial post was to know if I should plan a network change. In fact I already setup the network with .domain.local. The difference is there hasn't been (and probably won't ever be) MacOS computers in the network for the simple reason I am the only net admin (I'm the BOFH  :Very Happy: ) and have no skills with MacOS. So my answer would be: not supported. Given it's a small company, the computers that are worked with are selected and installed, Dell mainly, Mac excluded. That's for the human part of it  :Very Happy:  .

As for the tech' part, DNS is handled by dnsmasq on a Gentoo server, which serves only Windows machines (except one: a Debian machine). I've setup dnsmasq so that the DNS server is referred to as the target machine for any request on the domain that point to non-existing machines. For instance, a query for non-existent.domain.local will serve the IP address of the server that runs dnsmasq.

Basically dnsmasq also serves as a DHCP server and lends the domain and server IP 's to the workstations along with the domain name. So the solution to add the server IP to the resolver file is already what happens. Unless I haven't caught it.

I guess the problem would come as soon as there is a machine is present, that runs mDNS, right? Was your issue about DNS request flooding?

----------

## darkphader

 *VinzC wrote:*   

> In fact I already setup the network with .domain.local. The difference is there hasn't been (and probably won't ever be) MacOS computers in the network

 

Here, on my own network, I have a Gentoo server, a Gentoo desktop, an Ubuntu laptop, and an OpenBSD firewall. Currently use NSD and Unbound, but at the time was using DJBDNS. Thought I may have posted or bugged what my issue was and tried to find it via a search but alas no success. I did, however, make a strong mental note to never use .local :)

Chris

----------

## cach0rr0

 *VinzC wrote:*   

> Currently I've used a split brain DNS to serve known public DNS records as private IP addresses.

 

that was going to be the route I suggested. Use the real domain.tld both places, configure BIND to respond with private IP's for those on the private network, public for those accessing it publicly. 

We do this for one client who needs to access their proxy both internally and externally. Outside, proxy.domain.tld resolves to public IP, inside it resolves to 10.x.x.x

What sort of pitfalls do you see with this approach, aside from having to manage two records for one host?

----------

## VinzC

 *cach0rr0 wrote:*   

> What sort of pitfalls do you see with this approach, aside from having to manage two records for one host?

 

Hence my question  :Very Happy:  . Time and age often lead me to reconsider things periodically in general.

----------

