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 14: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 05: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 09: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 11: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. |