[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

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

1454.0. "DNS and domains" by ANOSWS::COMFORT (Spent a little time on the hill) Thu Sep 05 1991 13:05

    
    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.RTitleUserPersonal
Name
DateLines
1454.1Fulnames can be usefull.NSSG::R_SPENCENets don't fail me now...Thu Sep 05 1991 14:5811
    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:3610
    
    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.3TOOK::SWISTJim Swist LKG2-2/T2 DTN 226-7102Fri Sep 06 1991 09:1411
    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.4Reference Entity capabilities tooDELNI::R_PAQUETFri Sep 06 1991 11:266
    
    
    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.