| Title: | DECmcc user notes file. Does not replace IPMT. |
| Notice: | Use IPMT for problems. Newsletter location in note 6187 |
| Moderator: | TAEC::BEROUD |
| Created: | Mon Aug 21 1989 |
| Last Modified: | Wed Jun 04 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 6497 |
| Total number of notes: | 27359 |
Hi,
I am currently delving into the DNS heirarchy and attempting to
understand the ramifications of varied structuring of the namespace. In
looking at my MCC private namespace, I find that I have many top level
directories being created. This is mainly due to domain entries, not
only the ones I specifically create, but those that are created by
default when a DELNI or DEMPR or other "domained" network device is
entered on the iconic map. I already have 60 some-odd entries and I
have not even begun to enter all domains necessary for this network.
When I look at the corporate namespace, currently supporting DFS abd
RSM, I find on the order of 20 top level directories, all access points
to various disks and directories. When I "roll" my private namespace
into to the corporate namespace, I believe an immediate performance hit
will be taken. I realize (and will be suggesting) that re-structuring
of the current DFS naming conventions is needed and will help the
situation, however it seems that the domains in MCC can quickly evolve
into a rampant DNS nightmare. Here at SmithKline, we probably will not
use these devices (DELNI's, etc.) as domain entities, as it does not
necessarily provide the best solution to their network entity
"grouping" needs. I am trying to come up with a structure for DNS
that will work within the current (DNS v1.2) guidelines of no more
than 100 top level directories. Does this change in v2.0?
Can I put domains in a sub-directory and what problems would this
present to MCC?
Does anyone know how the LATTISNET implementation will work in this
regard (the local lan here is 98% LATTISNET)?
I would appreciate any general feedback on my concerns.
Thanks,
Dave Comfort
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 1454.1 | Fulnames can be usefull. | NSSG::R_SPENCE | Nets don't fail me now... | Thu Sep 05 1991 13:58 | 11 |
Subdirectories for domains are not a problem. In fact, remember that
the domain "name" is only a DNS Fullname so there is nothing wrong with
the name being something like .5.delni or 5.dempr where the "5" in
this case might mean "building 5" to the customer. In fact, you can
name a lot of things like that with a combination of dots and dashes
and underscores resulting in names that convey much more than a simple
name would.
Does this help?
s/rob
| |||||
| 1454.2 | with or without DNS ? | WOTVAX::PURNELLR | Life, it's not what I thought it was ! | Fri Sep 06 1991 04:36 | 10 |
With the option in DECmcc V1.2 of NOT using DNS and holding all
registration information within the MIR, does this mean we will
eventually negate the need for DNS altogether ?
&:*)
Rex
| |||||
| 1454.3 | TOOK::SWIST | Jim Swist LKG2-2/T2 DTN 226-7102 | Fri Sep 06 1991 08:14 | 11 | |
You will need it if you need what it does - i.e., if you want a
network-wide view of your registration and configuration info, you'll
need a name service.
If you don't mind private (potentially asynchronous) copies of this
stuff per system, then the local MIR version saves you the use of DNS,
but I would guess if you have a distributed management environment
(i.e., the managers sit in multiple places), then this may be
inadequate.
The whole idea is to give you a choice based on your setup.
| |||||
| 1454.4 | Reference Entity capabilities too | DELNI::R_PAQUET | Fri Sep 06 1991 10:26 | 6 | |
Additionally, in V1.2 you will have "reference entity" capabilities,
that is you will be able to put DELNIs and DEMPRs on the map as
entities (as opposed to domains today in V1.1) and associate reference
information with those entities.
| |||||