Internal DNS setup --- cpu1.domainname

[ttrsux]

I have a network where the domain name is COMPANYNAME. All the computers log into this domain. However, there is no .com or .local on this domain name. Our FQDNs look like this:

cpu1.COMPANYNAME
cpu2.COMPANYNAME
dc1.COMPANYNAME
dc2.COMPANYNAME

Does anyone else find this odd and is there a good reason for it? I can't think of why it would be set up this way and if there are any issues I'll run into in the future by doing it this way. I'm used to setting up corp.companyname.com (not a fan of the .locals).

Everything seems to be working fine so I don't want to reconfigure the whole thing over just so we can log into COMPANYNAME.COM...

thanks,
D

 

[itsp1965]

This is common in companies where they don't employ split brain DNS (ie using the same domain name internally and externally). They can call their internal DNS domain anything they want as long as they are able to navigate internal resources and their company.com is used to house external resources

 

[Noway2]

One advantage the comes to mind with this type of arrangement is that you don't have to have public IP addresses for each system AND you can still reference every device by name.

I personally do this on my own LAN at home. I have one public IP address that is accessable through a .com domain. Internally, the domain is .debian.lan.

 

[ttrsux]

What Noway2? I'm confused with your statement. One could have a .com or whatever on their internal FQDN's and still not need a public IP for each system. It's called NAT.

 

[Noway2]

Yes, on your internal, not publically addressable, LAN you can use whatever you would like for a FQDN; presumably, including .com, though this might cause some conflict (see below).

You do this through the configuration of your local, DNS server which is authoritative for your local domain. As you correctly pointed out, you would map one of your local IPs to the public IP(s) via NAT. For example, in my domain, the public IP maps to 192.168.0.49 and the mapping is handled by the router / gateway.

The DNS gets configured with the local domain. Presumably you would either use static IP addresses for your LAN or you would configure the DHCP and DNS to be linked, which is what I do. Each attached device would query the (local) DNS for lookups, as defined in either the hosts or resolv.conf file. If the lookup is for the domain that your local DNS believes it is responsible for, it will handle the request. Theoretically this should work just fine even if you are using a .com. as part of your local FQDN - the DNS would know that it is responsible for WHATEVER.com. and handle it.

The potential conflict would come into play if you attempt to lookup a device on your LAN and the DNS does not resolve it to a local device and attepts to resolve it via the .COM server. At best you will get an unable to resolve and at worst you will get an unintended host.

 

[theravager]

standard recommended way is to use .internal or .local for ms domain where you aren't using a internet domain name for internal (which isn't recommended).

 

[ttrsux]

i never use anything but legitimate TLD extensions on my domains. for starters, what about when you use Outlook via HTTP? your email client won't know where the heck mail.mycompany.local is (or just MAIL in some cases), and you end up employing VPN for everyone -- more overhead than is necessary.

 

[drummelhart]

do not use .local, or .internal unless need be. The problem is you will carry over all information and the more garbage you put in, the worse the smell when you try to extract it

 

[Titleist]

ttrsux,

Not having a .something in your internal domain won't cause any issues until you need a transitive trust setup (merger or acquisition) with another AD domain. Your domain will be seen as an NT domain and most ADMT tools won't work as expected..

john