Flying in the face of convention?
Simon at wretched.demon.co.uk
Sat Jun 1 06:55:44 UTC 2002
Bob Chmara wrote:
> - The current proposition is to use a schema like:
> - Is such a rigid structure the norm for large organizations?
> - If so, what are the benefits?
> - If not, what are the pitfalls of a less rigid approach and how might
> they be mitigated?
> - Are there any suggestions on how to justify a less rigid approach?
Half the big sites I see want to keep bizarre local site
identifiers in the hostname, where they have been because they
didn't have a hierarchical naming structure. So in comparison
this seems fairly reasonable ;)
Often these companies have strict naming policies and the sites
machines would all have the same names if not prefixed with some
obscure local reference. In one case they had tried to prefix
with the local airport designator, but hadn't been able to use
those consistently, so you couldn't guess what a sites
designator would be, or where it was from the designator in many
Most big companies don't manage IT on a site by site basis
beyond basic client issues, but on a project, or business area
basis. DNS will work with almost any scheme, but I suspect
you'll want some easy to type global names. i.e. Common systems
that you won't want at the mercy of dynamic update from Windows
2000 machines, or a local site admin. So just because your
company wide Oracle financials box is in ny, does it really want
to be ora123.newyork.us.company.com, especially if it gets
overwitten when Joe renames his laptop to ora123.
Similarly leaving aside ADS, if it is going to be a strategic
commitment, might be a problem, the trouble with embrace and
extend is it works :( Of course this might be something you can
dump on the ADS admins, but I'd look at how the current Windows
domains are defined for some hints on how things might work in
future. Although whether you think Microsoft ADS will last
longer than any other of Microsoft's software is another
Unwieldy long domain names, or unmanagably large domains, can be
a problem as well. So assuming you decide to group the dynamic
IP addresses in NY in their own zone, you get
joespc.dyn.newyork.us.company.com, and everyone dies of
repetitive strain injury.
If the company already has company.com registered and in use,
reusing that internally should be an explicit decision that
people are happy with, you may have to reimplement this domain
internally to mimic the external domain, and as more facilities
become available via the Internet the scope could grow.
If the company is large enough you eventually discover you have
some Offices that diasgree with what country/region you always
thought they were in at head office, often with a rigor and
enthusiasm that defies understanding. So even if you do go with
a rigorous hierarchical names do check the choice of identifier
with local managers as it saves political embarassment when you
select the wrong side of a raging civil war, international
conflict, or long standing border dispute.
Names are 99% politics, and 1% technical, just make sure the
scheme is implementable. I tend to stick to telling people what
will work, what to avoid, and let them agree on something.
You may find advice against reusing the country codes at layer
3, but as far as I know this dates from when the "uk" (not "gb"
;) was backwards, and it could confuse some email systems that
would reverse the address. Never seen this myself, working from
More information about the bind-users