your domain naming convention

Django x2 · 1 Feb 2010 at 13:25

Hi guys, what do you do for internal domains normally?

I'm seeing some companies with massive domains like:

1234.ourinternaldomain.outexternal-domain.com

I just normally do:

internaldomain.com

and build around it.

What kind of stuff do you do?

Sp00n · 1 Feb 2010 at 13:31

companyname.local usually

and then site.companyname.local

bigredshark · 1 Feb 2010 at 13:38

the root domain is ad.[company].com, from there it's fairly obvious.

office.ad.company.com for desktops etc
mail.ad.company.com for the exchange infrastructure
backoffice.ad.company.com is the generic home of servers
prod.ad.... for customer facing systems
dev.ad.... speaks for itself

there are a few other ones which are fairly esoteric and stem from not wanting them to be part of any of the existing domains. Advantages are it's high structured and the DNS namespace is consistent and unified (ad.company.com is delegated to the root DCs etc.)

Downside is we have at last count about 50 domain controllers in the wild...and that's down from it's peak. Before people question, we have about 8,000 servers in our AD these days (again, down from peak) and a worldwide user base which means we have to distribute DCs around the world to keep auth requests reasonably snappy.

rz30 · 1 Feb 2010 at 13:39

There is a glitch using .local internal domains as macs use this by default and can cause dns problems if you add a mac to a windows based domain. Usually .lan is recommended.

bigredshark · 1 Feb 2010 at 13:40

Sp00n said:
companyname.local usually

and then site.companyname.local

That's usually the accepted form for small installs.

Sp00n · 1 Feb 2010 at 13:41

Yup

I deal with SME's.

bigredshark · 1 Feb 2010 at 13:47

I'm curious about site.company.local actually - does anybody still do that? Once upon a time the idea of site/country/area specific domains was sensible but these days I don't see the point myself, our country specific forests died a few years back.

paradigm · 1 Feb 2010 at 15:04

externaldomain.com
subdomain.externaldomain.com

And the DNS is built around it.

bigredshark · 1 Feb 2010 at 15:13

paradigm said:
externaldomain.com
subdomain.externaldomain.com

And the DNS is built around it.

really - so your AD is doing DNS for your website for example? Braver than me I have to say...

paradigm · 1 Feb 2010 at 15:36

bigredshark said:
really - so your AD is doing DNS for your website for example? Braver than me I have to say...

It's hosted by us anyway, but yes it does do the DNS for our site, but only to internal clients, not external.

York · 1 Feb 2010 at 16:26

paradigm said:
externaldomain.com
subdomain.externaldomain.com

And the DNS is built around it.

Same for us here. If a site is hosted within our network all DNS requests stay within the network and are handled by our AD DNS setup. External DNS is handled by a different set of servers.

We've also got a separate AD domain (the .net version of our .com) that's used for sites that are only internally operated.

Sin_Chase · 1 Feb 2010 at 16:57

company.local

Screw macs.

bigredshark · 1 Feb 2010 at 17:53

York said:
Same for us here. If a site is hosted within our network all DNS requests stay within the network and are handled by our AD DNS setup. External DNS is handled by a different set of servers.

We've also got a separate AD domain (the .net version of our .com) that's used for sites that are only internally operated.

So what's authoritative?

RSR · 1 Feb 2010 at 18:57

I've personally always used .com

bods · 1 Feb 2010 at 20:53

York said:
Same for us here. If a site is hosted within our network all DNS requests stay within the network and are handled by our AD DNS setup. External DNS is handled by a different set of servers.

We've also got a separate AD domain (the .net version of our .com) that's used for sites that are only internally operated.

Exactly what we do... Never allow AD DNS to handle external queries..... shudder....

bigredshark · 1 Feb 2010 at 22:37

bods said:
Exactly what we do... Never allow AD DNS to handle external queries..... shudder....

So if you use .com, unless you delegate a sub domain to your AD DNS, you have two versions of the zone...

Either use .local (or I've seen .adr used effectively) and forget about consistent DNS or make sure you delegate the sub domain to AD. The greatest problem with AD is the abuse of DNS is causes...

unclepablo · 1 Feb 2010 at 23:03

I'm curious, I thought company.com for the AD was a no-no due to exposing your internal DNS structure externally (as detailed above by a few posters advocating company.local) - although it seems stupid when [email protected] is logically an ideal setup!

So the question is: If you use a .com, how to do stop exposing the internal DNS structure - via the firewall? Oh, and what about remote users resolving to a different IP?

Are you referring to this when you state "delegate the sub domain to AD"?

Sin_Chase · 2 Feb 2010 at 01:06

Most places can workaround resolving the external (when using a company.com domain name) website by adding a www. entry in their DNS forcing resolution to the external address.

Why would anyone's AD DNS be visible from outside of the corporate network?

RSR · 2 Feb 2010 at 08:52

Sin_Chase said:
Most places can workaround resolving the external (when using a company.com domain name) website by adding a www. entry in their DNS forcing resolution to the external address.

Why would anyone's AD DNS be visible from outside of the corporate network?

That's the way I have always set mine up.

Exposing the AD DNS to the outside world is a bit of a big security risk is it not?

bigredshark · 2 Feb 2010 at 09:09

andyd said:
That's the way I have always set mine up.

Exposing the AD DNS to the outside world is a bit of a big security risk is it not?

Indeed, which is why using company.com is really dumb because it basically requires you to have both internal and external (with different information) authoritative name servers for the company.com zone.

Using ad.company.com you can delegate the sub domain to the AD DNS infrastructure and the zone remains consistent everywhere (ie. you're not breaking DNS).

Of course the fact it's wrong, bad practice and a random abuse of DNS doesn't stop people doing it....