EXTRACTS FROM NAMEDROPPERS ARCHIVES '83-'86 ftp://ftp.internic.net/archives/namedroppers 25-Mar-83 20:40:47-PST,1342;000000000000 Received: from USC-ISIF by SRI-NIC at 25-Mar-83 2038-PST Date: 25 Mar 1983 2033-PST From: POSTEL at USC-ISIF Subject: revision delayed To: namedroppers at SRI-NIC I had planned to get a revised draft memo out to you by this time. It is not going to be possible, and i am going to be traveling next week so it won't happen next week either. I have been working with your comments and marking up my draft. The comments have been quite helpful. I am still bothered by the issue of forwarding. I don't think i have really caught all the implications of it. Some how i feel a tension between that notion and main thrust of the grapevine strategy. I would like to have a comment from Ed Taft on the forwarding or relaying idea, and a comment from Chris Kent and Eric Allman on the Grapevine strategy and the ideas Ed has put forward. I think one of the important ideas that has come out is to establish the domain type structure and lookup servers for finding things as a general technique where things can be computers, people, mailboxes, or other things. There seems to be two ways to think about this: (1) there are many conceptually independent domain structures - one for each kind of thing, or (2) there is one domain structure but each node of the structure has many attributes. --jon. ********************* 4-Apr-83 16:37:55-PST,13782;000000000001 Return-path: Received: from PARC-MAXC by SRI-NIC at 4-Apr-83 1630-PST Date: Mon, 4 Apr 83 16:26 PST From: Taft.PA@PARC-MAXC.ARPA Subject: Relaying and related topics To: Postel@ISIF.ARPA cc: NameDroppers@SRI-NIC.ARPA, Taft.PA@PARC-MAXC.ARPA Jon, I've reread your memo and all the correspondence you have distributed and have done a little additional thinking about the issue. I think the main reason we have problems with this issue is that we are all talking about slightly different things. Perhaps I can clarify this somewhat. 1. Mailbox names and locations First of all, let me describe what relaying isn't. There were several messages that discussed scenarios in which a message is delivered other than to its ultimate destination for various reasons, and then "relayed" to that destination. For example, a personal computer isn't prepared to maintain a continuous presence on the internet, so mail is delivered to a "big brother" computer and picked up by the personal computer. Or a machine isn't willing to accept SMTP connections for security reasons, but instead wants to actively pick up mail from some more public place. You responded by saying that such mechanisms lie outside the purview of internet naming, and that if a mailbox is actually located on a particular machine, that is where it should be advertised as being. I agree, but would carry this a step further. By decoupling the host-name and people-name spaces, as I advocated in my previous message, you can make the mailbox's actual location be irrelevant at all but the lowest level. I claim that your mailbox's name should not be either "Postel@Postel'sPC" or "Postel@BigBrother". The binding is much too tight, and could be rendered obsolete at a moment's notice (you acquire a different PC, or BigBrother gets decommissioned). And that level of detail isn't interesting to any of your correspondents anyway (or even to you, if your mail system is like Grapevine). Far better to have your name be "Postel@ISI", and let the binding "Postel@ISI" -> "BigBrother" be done dynamically as part of the transport and delivery process. Doing this makes questions about "where the mailbox actually is" irrelevant at the people-name level. To recap, the name servers should provide two services relating to the delivery of messages: Mailbox location service: person-name -> host-name(s) e.g., "Postel@ISI.ARPA" -> "ISIF.ARPA" (and maybe other information about the person) Host location service host-name -> host-address(es) e.g., "ISIF.ARPA" -> [10.2.0.52] (and maybe other information about the host) Another example that isn't relaying is the provision for mailbox aliases. This arises when a person who receives mail at a particular mailbox also wants to receive mail addressed to other aliases on the same or different hosts. In the present world, this is accomplished by actually establishing "mailboxes" on those hosts which automatically "forward" to the proper mailbox. In the new world, this is properly done at a higher level, as a binding activity rather than as a forwarding activity. This might either be done at the mailbox location service level or be pushed up to the "white pages" level. 2. Multiple internets The reason we need relaying is that we have multiple internets (or, more precisely, multiple incompatible communication environments). Much confusion may be prevented if avoid talking about "the" Internet when what we really mean is the ARPA Internet. For our purposes, we can define the ARPA Internet as consisting of that set of hosts speaking the DOD standard protocols, namely RFC822/SMTP/TCP/IP (in the context of electronic mail). There are other internets: UUCP, CSNET, Xerox Pup, Xerox NS, ... The collection of Arpanet hosts still speaking only NCP are also logically a separate "internet", even though they share much of the same hardware. (Pup and NS are logically separate in the same sense.) Relaying is what you have to do when you cross the boundary between two internets. We are discussing the design of name services operating within the ARPA Internet. In our design, we need to be able to NAME things outside the ARPA Internet, but we can't assume that the same mechanisms will OPERATE outside the ARPA Internet. 3. Structuring multiple name spaces I can think of three approaches to incorporating the names of things outside the ARPA Internet into the name space accessible from within the ARPA Internet. I will call them: a) paths b) encapsulated name spaces c) independently-rooted name spaces a) We all know about paths. They are things like Smith@MIT-OZ@MIT-MC, harpo!zeppo!bilbo!frodo!smith@Berkeley, etc. Paths have a lot of problems, which are the main reason we are engaged in this redesign to begin with. So I won't waste any time talking about them, except to mention that they also appear in the new scheme of things under a slightly different guise: route-addrs (e.g., <@MIT-MC:Smith@MIT-OZ>. It's my understanding that route-addrs are intended as an escape mechanism when nothing else works, and as a means of controlling and monitoring the actual route taken by a message, but NOT as a general scheme for naming. b) Encapsulated name spaces occur when you take one entire internet's name space and dangle it off a single node of another internet's name space. This model most closely approximates the way the ARPA and Xerox internets' name spaces are presently interconnected. For example, my name in the Xerox name space is Taft.PA. But as viewed from the ARPA name space, my name is Taft.PA@PARC-MAXC.ARPA; that is, my name is taken as being locally interpreted by the ARPA domain PARC-MAXC. The essential flavor of this is not changed by decoupling people-names from host-names; thus, I might be Taft.PA@Xerox.ARPA. Name spaces can be "mutually encapsulated" -- each name space thinks of the other as dangling off a single node of its own. For example, in the Xerox name space we have "simple-names" and "registries"; Taft.PA is the simple-name "Taft" in the registry "PA". Your name is Postel@ISIF.ARPA.ArpaGateway, i.e., the simple-name "Postel@ISIF.ARPA" in the registry "ArpaGateway". (This isn't what users actually say, but that's an optimization.) Encapsulated name spaces are much the same as paths when the two name spaces are connected at just one point. Where they differ is in the case of multiple connections. If the ARPA and Xerox name spaces were connected at two places, say X1 and X2, then the names Taft.PA@X1.ARPA and Taft.PA@X2.ARPA would really mean the same thing, whereas with true paths they could be entirely different. Unfortunately, this approach shares most of the problems of the path approach. In order for it to work properly, there must be translation of names when crossing between name spaces. Names that are native to the space being entered must have the (foreign) name of the interconnecting node removed, and names that are foreign must have the (local) name of that node added. Additionally, when there are multiple interconnections, there is a serious "multiple homing" problem that is quite complicated to sort out. c) Independently-rooted name spaces are ones that stand by themselves (i.e., have their own top-level domains) rather than dangling off nodes of other name spaces. Under this scheme, ARPA, CSNET, UUCP, and Xerox are independent top-level domains. The main feature of this approach is that such names do not have to be translated as they cross from one internet to another. You address me as Taft.PA@Xerox and I address you as Postel@ISI.ARPA. Both these names mean the same thing in the ARPA internet as they do in the Xerox internet; no translation is required in the relay host. Named entities in one internet don't have to think of themselves as being descendants of nodes in the other internet -- a decided advantage when you are considering interconnecting two previously independent internets. One other important point is worth mentioning. It is not necessary that all internets agree on what approach is used. While I am advocating that the ARPA internet adopt approach (c), treating itself and all other internets as independently-rooted name spaces, other internets can do what they please. This seems pretty important given today's realities. Approach (c) is really only feasible in an internet that is tree-oriented as opposed to path-oriented; furthermore, the ARPA name syntax has to be compatible with that of the other internet. This happens to be true (for example) in the Xerox internet, where we can just define ARPA as a top-level registry in our own name space. (We have recently tried this; it works fine.) But for a system that has other notions deeply embedded (e.g., UUCP), this is impractical; some form of encapsulation or translation of names seems unavoidable. 4. Implementation What functions do the name servers have to perform in order to support relaying? I think the basic answer is very simple, though various elaborations are doubtless possible. The mailbox location service in an ARPA name server should be able to accept a name in another name space and produce the name of one or more relay hosts. For example: "Taft.PA@Xerox" -> "PARC-MAXC.ARPA" If the ARPA and Xerox internets are connected together in multiple places then this query should give multiple answers. Note that this maps from a non-ARPA person-name to an ARPA host-name. >From the point of view of the user of the name server, this response is syntactically indistinguishable from the response: "Postel@ISI.ARPA" -> "ISIF.ARPA" This is as it should be. From the point of view of an ARPA user, PARC-MAXC.ARPA "is" the logical location of my mailbox, because it is not possible to establish a SMTP/TCP/IP connection to the place where the mailbox really is. Of course, if I ask the same question in my internet, I will get quite a different answer. In my previous message, I suggested a technique for finding the right name server to ask, given that the one you try first doesn't have the information you are looking for. It involves the use of reserved names of the form NameServer.domain. Given this convention, a name server whose name is NameServer.Xerox must exist in the ARPA internet (i.e., be accessible via the IP-based name lookup protocol) in order for ARPA users to be able to name Xerox recipients. A logical place to locate such servers is at the relay hosts themselves, though nothing in the design should constrain this to be so. Note that this name server can know about the domain in question in as little or as much detail as it cares to. It can have a single entry which maps the top-level domain name to the list of relay hosts. Or it can know about the sub-domain structure (and even the local-part substructure) in order to map individual names to a "preferred" relay host. One technical detail remains: if a name lookup request (either of a person-name or of a host-name) results in multiple values, which one do you choose? Clearly you first want to try the "nearest" one (more precisely, the one that is "cheapest" to access, by some criterion). For example, if a host name maps to several addresses, and one of the addresses is on the same network as the one to which you are connected, you try that one first. I don't know enough about the routing protocols in the ARPA internet to be able to suggest how to estimate the relative cost of accessing alternative internet addresses. One observation is worth making, however. The considerations that apply here are very similar to the ones applied for internet routing at the IP level. This suggests that a user program should be able to read the routing information being used at the IP level in its own host or in nearby gateways. (This is actually done in Pup and NS.) 5. One name space or many? You asked whether there should be one name space, in which many different kinds of things can be named, or multiple application-specific name spaces. My response is that, to first order, it really doesn't matter. Considering the name server as implementing a function, the issue really boils down to whether you consider the "kind" of name to be part of the domain (in the mathematical sense) or part of the range. For example, consider the person-name Postel@ISI.ARPA and the host-name ISIF.ARPA. One could define the name service as providing either of the following functions: (F1) [person, "Postel@ISI.ARPA"] -> "ISIF.ARPA" [host, "ISIF.ARPA"] -> [10.2.0.52] (F2) "Postel@ISI.ARPA" -> [person, "ISIF.ARPA"] "ISIF.ARPA" -> [host, [10.2.0.52]] (Note that you can implement case F1 as either a single name space indexed by a two-part key, as shown above, or as separate person and host name spaces; they are logically isomorphic.) The advantage of the first approach is that the name spaces for different kinds of name are entirely independent; so there is no possibility for conflict in name assignment or for confusion about the kind of thing being looked up. The advantage of the second is that it is ultimately more flexible, since you can make additions to the "kinds" of information without restructuring the name space. This is probably more consistent with the "data base" view of the service being provided by the name servers. (By the way, this is the approach taken in the Clearinghouse.) Well, I guess I've rambled on long enough. Hope this is useful. Ed Taft ********************* 6-Apr-83 09:52:31-PST,2420;000000000001 Return-path: Received: from UCB-VAX by SRI-NIC at 6-Apr-83 0951-PST Date: 6 Apr 1983 0951-PST (Wednesday) From: eric%UCBARPA@Berkeley (Eric Allman) Subject: Requested comments regarding Grapevine Message-Id: <883.31.418499478@ucbarpa> Received: by UCBARPA.ARPA (3.332/3.19) id AA01097; 6 Apr 83 09:51:21 PST (Wed) Received: from UCBARPA.ARPA by UCBVAX.ARPA (3.332/3.20) id AA01275; 6 Apr 83 09:51:09 PST (Wed) Phone: (415) 548-3211 To: Postel@ISIF Cc: Taft.ES@PARC-MAXC, namedroppers@SRI-NIC Fcc: mail I do not disagree with anything that Ed Taft has said -- on the contrrry, I think his analysis of the problems was remarkably consise and to the point. I do not think that it does anything to alleviate the basic problem of handling networks where a direct connection cannot be made; these issues seem orthogonal. Grapevine is still postulating the ability to connect directly at any time to fulfill a name server request -- a completely reasonable assumption for the Xerox or Arpanet environments. What I am arguing is that we can easily relax that assumption and thus bring another large class of networks into the fold, such as CSNET. To reiterate, I would like to have a "RELAY" response added to the name server replies. The semantics of this response would be "the named host is willing to collect the mail for this address and any subordinate addresses." For example, the address: user@csnhost.CSNET would do the usual name lookup and would get a response of RELAY: ADDR where ADDR was the address of the CSNET relay host(s). The message would be sent to tiis relay host immediately (as opposed to doing another name server lookup on the specified "csnhost"). Since networks of this sort do exist, and can be expected to exist for some time to come, the choice is basically to admit this now and add the extra reply, or to force people to use the syntax: user.csnhost@CSNET forever (i.e., move the host spec into the local part of the address). The problem with this is that this leaves the door open to a lot of ad hoc hacking on the LHS of the "@", perpetuating problems that we have all come to know and hate. Jon, this may not be what you wanted when you asked me to comment on the Grapevine strategy as regards forwarding -- but after looking at it for several days I cannot seem to see how they relate. eric ********************* 27-Apr-83 14:11:50-PDT,7564;000000000000 Return-path: Received: from MIT-XX by SRI-NIC via ARPANET/MILNET with TCP/SMTP; Wed 27 Apr 83 14:00-PDT Date: Wed, 27 Apr 1983 17:01 EDT From: Karen R. Sollins Message-ID: <[MIT-XX].SOLLINS.27-Apr-83 16:59:29> To: postel@usc-isif, namedroppers@sri-nic Subject: relays and names This set of comments originated with my reactions to Ed Taft's last message although I have gone on from there. They are meant to enhance what Ed said; he took some first steps and I hope I have taken a few more. The ideas here are to a large extent the result of several conversations I have had with Dave Clark. _______ A relay is something that passes things along. Relays may do different sorts of things. Gateways are relays, because they pass things from one network to another. Nodes in a store and forward network are relays, because they pass things from one wire to another. Of particular interest here are mail relays. Before we continue with relays, let us briefly consider the names for mailboxes. One way to look at them is to consider them to be two part names. The two parts are separated by the "@". For clarity I will call the parts of a name the "internal name" to the left of the "@" and the "external name" to the right of the "@". >From a mailer's point of view, the external name names a relay. The relay will interpret the internal name. This interpretation may involve translating the internal name into another pair of names involving another relay or may simply involve a receiving mail server that will dispose of the mail item. It is possible that a relay will also translate from one protocol family to another, but not necessary. In any case, given these assumptions about names and relays, relaying is a separate function from the functions provided by a name service. It has nothing to do with name translation from domain style name to internet address. Now let me turn to some more reactions to some Ed Taft's recent comments. (1) The question of "ISI.ARPA" vs. "ISIF.ARPA" vs. "BigBrother" vs. "PostelsPC": From the perspective taken above, all of these are relays. They are listed here in increasing degree of refinement, each encompassing a smaller group of people. From the human sender's point of view, the first (ISI.ARPA) is probably the easiest to remember and therefore has an advantage. The reason that it is the easiest to remember is that the human only has to remember one such name for many recipients, whereas for the other aprroaches the human has to remember an ever increasing number of additional names, reaching the limit when there is a unique relay name for each recipient (of the form of PostelsPC). Otherwise, the human's model of them can be identical, something that will deliver a message to Jon Postel. Consider "TAFT@PARC-MAXC" (which, by the way, is the address the NIC whois service tells me to use). When my message reaches MAXC, both name and protocol are changed. The name becomes TAFT.PA and the protocols probably become the NS family. Whether I said TAFT@PARC-MAXC or TAFT@XEROX.ARPA or even TAFT@PARC.XEROX really would make no difference to me. I view PARC-MAXC, XEROX.ARPA and PARC.XEROX as mail delivery service (or relay) that will know about someone named TAFT and deliver my mail to him. (2) Apparently there may be confusion about the relationship between domains and internets that speak different protocol families. There is no inherent reason that either has to map onto the other. I can imagine a situation in which an organization develops its own family of protocols because they have a different set of requirements from those for IP/TCP, but they decide for convenience to use the same naming and addressing scheme. In this case, an external name in one internet could name a relay in the other. Protocol translation would have to occur somewhere along the way (in gateways), but the point at which that occurs would not necessarily be the same place at which the internal name was interpreted. In this case, one internet could certainly be a subdomain of the other, if this seemed desirable. Of course, I assume that in many cases internets and domains will coincide. (3) I have two concerns about Ed's discussion on structuring multiple name spaces. First, I was under the impression that there always were plans for more than one top level domain. The only reasons for only one top level domain were that no one could handle more than one (and many people couldn't handle even one), and that it wasn't clear what the others should be or who should decide. My assumptions was that there was general agreement only on the ARPA domain. Second, I do not believe that multiple top level domains solve the problems that Ed outlined for his other approaches. There doesn't seem to be a significant difference between having a single giant domain labelled ARPA with secondary domains (such as ARPARESEARCH and XEROX) under it, and a collection of top level domains (such as ARPARESEARCH and XEROX) under an unnamed but implicit top level domain. I can't believe that the problems are different in these two cases. I like Ed's idea of "mutual encapsulation" because it recongnizes that different domains may do their naming independently and need name translation at the relays, as well as whatever else may be done at the relays. I'm not sure it solves any technical problems, but it may solve political ones. (4) There is one final point that I would like to make about relays and name translation. It is certainly imaginable (and in fact happens) that I, on my machine (in this case a TOPS-20), cannot actually create the name of a recipient of my mail in a form that the recipient's machine can understand. Return, for example, to Ed Taft. The machine where he reads his mail probably only knows about 96 bit destination addresses (or 48 bit host addresses). My mail program and its supporting transport mechanisms only know about 32 bit internet addresses. My mail system must generate them, and his mail system cannot understand them. Therefore, it seems apparent to me that translation must occur, and the place that this happens is by definition the relay. Now, in fact, translation ought to happen on both the source and destination and ought to be done on mail travelling in both directions. BBN-UNIX provides a good example. When I send mail to my husband, MSOLLINS@BBN-UNIX, he receives it at MSOLLINS@BBNX. When he sends me mail from MSOLLINS@BBNX, the reply-to field says MSOLLINS@BBN-UNIX. I don't know and don't really care to know which machine does which part of the translation. What matters me is that I address him as MSOLLINS@BBN-UNIX and he responds to me as the same person. This doesn't quite work at PARC because those names with the registries (TAFT.PA) escape from PARC. If I send mail to TAFT@PARC-MAXC, I may get a response from TAFT.PA@PARC-MAXC. This gets into a question of equality - is the recipient of my message the same person as the sender of the message I just received? One way to answer this question is on the basis of names, but that obviously doesn't always work. I will not go further with this particular can of worms here. Just let it suffice to say that there is a large can of worms lurking here. I apologize for having gone on so long, but I hope this helps clarify some ideas or at least provokes more thought. Karen ************ 30-Apr-84 21:23:41-PDT,14553;000000000001 Return-Path: Received: from USC-ISIF by SRI-NIC.ARPA with TCP; Mon 30 Apr 84 21:22:42-PDT Date: 30 Apr 1984 21:20:39 PDT From: POSTEL@USC-ISIF Subject: Draft RFC on Requirements to be a Domain To: namedroppers@SRI-NIC Hello: The enclosed memo is a DRAFT RFC on the requirements to be met to become a domain. Please take a look at it. Please send any comments, suggestions for improvement, or other remarks either to the namedroppers list (if you want to share your statement) or to JKReynolds@USC-ISIF.ARPA (if you want to make a private statement). Thank You. -- jon & joyce. Network Working Group J. Postel J. Reynolds Request for Comments: DRAFT ISI April 1984 Domain Requirements Status of this Memo This is a draft memo. When the review is complete this memo will be issued as an RFC with the following statement: This memo is a policy statement on the requirements of establishing a new domain in the ARPA-Internet and the DARPA research community. This is an official policy statement of the ICCB and the DARPA. Introduction This memo restates and refines the requirements on establishing a Domain first described in RFC-881 [1]. The Purpose of Domains Domains are administrative entities. The purpose and expected use of domains is to divide the name management required of a central administration and assign it to sub-administrations. There are no geographical, topological, or technological constraints on a domain. The hosts in a domain need not have common hardware or software, nor even common protocols. Most of the requirements and limitations on domains are designed to ensure responsible administration. Possible Examples of Domains The following examples are fictions of the authors' creation, any similarity to the real world is coincidental. The UC Domain It might be that a large state wide university with, say, nine campuses and several laboratories may want to form a domain. Each campus or major off-campus laboratory might then be a subdomain, and within each subdomain, each department could be further distinguished. One might see domain style names for hosts in this domain like these: LOCUS.CS.LA.UC CCN.OAC.LA.UC Postel & Reynolds [Page 1] RFC DRAFT April 1984 Domain Requirements ERNIE.CS.CAL.UC A.S1.LLNL.UC A.LAND.LANL.UC NMM.LBL.CAL.UC The MIT Domain Another large university may have many hosts using a variety of machine types, some even using several families of protocols. However, the administrators at this university may see no need for the outside world to be aware of these internal differences. One might see domain style names for hosts in this domain like these: APIARY-1.MIT BABY-BLUE.MIT CEZANNE.MIT DASH.MIT MULTICS.MIT TAC.MIT XX.MIT The CSNET Domain There may be a consortium of universities and industry research laboratories called, say, "CSNET". This CSNET is not a network per se, but rather a computer mail exchange using a variety of protocols and network systems. Therefore, CSNET is not a network in the sense of the ARPANET, or an Ethernet, or even the Internet, but rather a community. Yet it does, in fact, have the key property needed to form a domain; it has a responsible administration. One might see domain style names for hosts in this domain like these: CIC.CSNET EMORY.CSNET GATECH.CSNET HP-LABS.CSNET IBM-SJ.CSNET UDEL.CSNET UWISC.CSNET Postel & Reynolds [Page 2] RFC DRAFT April 1984 Domain Requirements Requirements on a Domain There are several requirements that must be met to establish a domain. In general, it must be responsibly managed. There must be a responsible person to serve as an authoritative coordinator for domain related questions. It must be a person with authority that can give orders. There must be a robust name service, it must be of at least a minimum size, and the domain must be registered with the central domain administrator (the Network Information Center (NIC) Domain Registrar). Responsible Person: An individual must be identified who has authority for the administration of the names within the domain, and who seriously takes on the responsibility for the behavior of the hosts in the domain, plus their interactions with hosts outside the domain. This person must have some technical expertise and the authority within the domain to fix problems. If some host in a domain somehow misbehaves in the interactions with hosts outside the domain (e.g., consistently violates protocols), the responsible person for the domain must be competent and available to receive reports of problems, take action on the reported problems, and follow through to eliminate the problems. Domain Servers: A robust and reliable domain name service must be provided. One way of meeting this requirement is to provide at least two independent domain name servers for the domain. The database can, of course, be the same. The database can be prepared and copied to each domain name server. But, the servers should be in separate machines on independent power supplies, et cetera; basically as physically independent as can be. They should have no common point of failure. One of the difficult problems in operating a domain name server is the acquisition and maintenance of the data. In this case, the data is the host names and addresses. In some environments this information changes fairly rapidly and keeping up-to-date data may be difficult. This is one motivation for sub-domains. One may wish to create sub-domains until the rate of change of the data in a sub-domain domain name server database is easily managed. Postel & Reynolds [Page 3] RFC DRAFT April 1984 Domain Requirements The responsible person or an identified technical assistant must understand in detail the procedures for operating a domain name server, including the management of master files and zones. The operation of a domain name server should not be taken on lightly. There are some difficult problems in providing an adequate service, primarily the problems in keeping the database up to date, and keeping the service operating. The concepts and implementation details of the domain name server are given in RFC-882 [2] and RFC-883 [3]. Minimum Size: The domain must be of at least a minimum size. Several measures of size may be used in combination with making this test. Measures may include: (a) the number of host computers in the domain, (b) the number of people with primary mailboxes in the domain, (c) the amount of traffic that crosses the boundary of the domain [packets/day or mail items/week]. Specific threshold values for these measurements will be established before new domains are authorized. There is no requirement to form a domain because some set of hosts is above the minimum size. Registration: The administrator must register the domain with the central authority (the NIC Domain Registrar). This central authority must be satisfied that the requirements are met before authorization for the domain is granted. The registration procedure involves answering some questions about the prospective domain. A prototype of what the NIC Domain Registrar may ask is shown below. These questions may change from time to time. The administrator of a domain is required to make sure that host and sub-domain names within that jurisdiction conform to the standard name conventions and are unique within that domain. If sub-domains are set up, the administrator may wish to pass along some of his authority and responsibility to a sub-domain administrator. Even if sub-domains are established, the responsible person for the top-level domain is ultimately responsible for the whole tree of sub-domains and hosts. Postel & Reynolds [Page 4] RFC DRAFT April 1984 Domain Requirements Prototype Questions To establish a DOMAIN, the following information must be provided to the NIC Domain Registrar (???***): 1) The name of the sponsoring organization, and the name, title, mailing address, phone number, net mailbox, and NIC-Ident (if any) of the contact person at that organization. This is the contact point for administrative and policy questions about the authorization for this DOMAIN to join the the Domain Naming System. For example: Sponsor Organization DARPA Name Dr. Robert E. Kahn Title Director, IPTO Mail Address DARPA 1400 Wilson Blvd. Arlington, VA. 22209 Phone Number (202) 694-5922 Net Mailbox Kahn@USC-ISI.ARPA NIC-Ident REK2 2) The name, title, mailing address, phone number, and organization of the administrative head of the organization. This is the contact point for administrative and policy questions about the DOMAIN. In the case of a research project, this should be the Principal Investigator. The online mailbox and NIC-Ident (if any) of this person should also be included. For example: Administrator Organization USC/Information Sciences Institute Name Keith Uncapher Title Executive Director Mail Address USC/ISI 4676 Admiralty Way, Suite 1001 Marina del Rey, CA. 90292 Phone Number (213) 822-1511 Net Mailbox Uncapher@USC-ISIB.ARPA NIC-Ident KU 3) The name, title, mailing address, phone number, and organization Postel & Reynolds [Page 5] RFC DRAFT April 1984 Domain Requirements of the technical contact. The online mailbox and NIC-Ident (if any) of the technical contact should also be included. This is the contact point for problems with the DOMAIN and for updating information about the DOMAIN. Also, the technical contact may be responsible for hosts in this DOMAIN. For example: Technical Contact Organization USC/Information Sciences Institute Name Craig Milo Rogers Title Researcher Mail Address USC/ISI 4676 Admiralty Way, Suite 1001 Marina del Rey, CA. 90292 Phone Number (213) 822-1511 Net Mailbox Rogers@USC-ISIB.ARPA NIC-Ident CMR 4) The name of the DOMAIN (up to 12 characters). This is the name that will be used in tables and lists associating the DOMAIN and the domain name server addresses. For example: ALPHA-BETA 5) A description of the server that provides the domain name service for translating name to address for hosts in this DOMAIN, and the date it will be operational. A good way to answer this question is to say "Our server is supplied by person or company X and does whatever their standard issue server does". For example: Our server is a copy of the server operated by the NIC, and will be installed and made operational on 1-June-84. 6) A description of the server machine, including: (a) hardware and software (b) addresses (what host on what net for each connected net) For example: (a) hardware Postel & Reynolds [Page 6] RFC DRAFT April 1984 Domain Requirements VAX Berkeley Unix or IBM-PC MDOS, or DEC-1090 TOPS20 (b) address 10.9.0.193 on ARPANET 7) An estimate of the number of hosts that will be in the DOMAIN (a) initially, (b) within one year, (c) two years, and (d) five years. For example: (a) initially = 25 (b) one year = 50 (c) two years = 100 (d) five years = 500 References [1] Postel, J., "The Domain Names Plan and Schedule", RFC-881, USC Information Sciences Institute, November 1983. [2] Mockapetris, P., "Domain Names - Concepts and Facilities", RFC-882, USC Information Sciences Institute, November 1983. [3] Mockapetris, P., "Domain Names - Implementation and Specification", RFC-883, USC Information Sciences Institute, November 1983. [4] Postel, J., "Domain Name System Implementation Schedule", RFC-897, USC Information Sciences Institute, February 1984. Postel & Reynolds [Page 7] ************** 31-Jan-85 22:22:26-PST,1699;000000000001 Return-Path: Received: from UCB-VAX.ARPA by SRI-NIC.ARPA with TCP; Thu 31 Jan 85 22:22:07-PST Received: by UCB-VAX.ARPA (4.24/4.41) id AA16853; Thu, 31 Jan 85 22:21:21 pst Received: from cbpavo.cbosgd.ATT.UUCP (cbpavo.ARPA) by cbosgd.ATT.UUCP (4.12/3.7) id AA08029; Thu, 31 Jan 85 23:52:53 est Received: by cbpavo.cbosgd.ATT.UUCP (4.24/3.14) id AA21015; Thu, 31 Jan 85 23:47:36 est Date: Thu, 31 Jan 85 23:47:36 est From: cbosgd!mark@Berkeley (Mark Horton) Message-Id: <8502010447.AA21015@cbpavo.cbosgd.ATT.UUCP> To: namedroppers@sri-nic.ARPA Subject: domain naming conventions How do people feel about the characters allowed in domain names? We're considering subdomains of UUCP representing areas like "New England", "MidWest", "South Eastern USA", "Northern California", and the like, and right now these are proposed as N-ENG.UUCP, M-WEST.UUCP, S-EAST.UUCP, N-CA.UUCP. Ignoring the confusion that might occur because the N in New England doesn't stand for North, how do you feel about the dash in the name? Would it be less confusing for people to use NENG, MWEST, SEAST, and NCA? What about name length? We're trying to keep the names as short as possible, so people don't have to type ugly things like mark@D.OSG.CB.BTL.ATT.UUCP but there are some situations that are hard to keep short. I expect to see user@CSVAX.KAIST.KOREA.ASIA.UUCP and that one's hard to shrink. We've adopted a soft guideline that the RHS should be 16 characters or less, if possible. Does anyone have a better way of dealing with this? Are we being too concerned about name length - should we not discourage 32 or 64 character domain names? Mark ************** 1-Feb-85 11:19:57-PST,907;000000000000 Return-Path: Received: from merlin.ARPA by SRI-NIC.ARPA with TCP; Fri 1 Feb 85 11:19:45-PST From: Christopher A Kent Message-Id: <8502011918.AA18003@merlin.ARPA> Received: by merlin.ARPA; Fri, 1 Feb 85 14:18:58 est Date: 1 Feb 1985 1418-EST (Friday) To: cbosgd!mark@Berkeley.ARPA (Mark Horton) Cc: namedroppers@sri-nic.ARPA Subject: Re: domain naming conventions In-Reply-To: Your message of Thu, 31 Jan 85 23:47:36 est. <8502010447.AA21015@cbpavo.cbosgd.ATT.UUCP> Mutter. I'm still trying to understand why people want a top-level domain named .UUCP -- it describes a transport protocol, not an administrative entity. There will probably be several gateways into the uucp network; by making the top level domain the same for all parts of the country, it makes it more difficult to determine the best gateway to use. chris ************** 8-Feb-85 16:42:10-PST,5692;000000000001 Received: from USC-ISIF.ARPA by SRI-NIC.ARPA with TCP; Fri 8 Feb 85 16:41:34-PST Date: 8 Feb 1985 16:41:24 PST From: POSTEL@USC-ISIF.ARPA Subject: re: naming and routing To: namedroppers@SRI-NIC.ARPA Mark Horton describes in gory detail how attempting to use a name server approach via mail over dial up lines is totally crazy. I never suggested otherwise, and i don't think anyone else did. I don't know how the people in uucp land plan to convert domain style names to route information, but i don't expect them to try to use domain name servers via computer mail sent over dial up lines! I expect that each host has some information about the names and routes to other hosts it talks to frequently. I don't expect any host to have total knowledge of all the other hosts in the world. Mark makes an assumption about what a host should do with mail it does not know what to do with (i.e., the name is not in the local table), he says the host should give it to its "domain parent". To me, this is not at all obvious. (I am not sure that every node of the domain name tree necessarily has a host associated with it.) Certainly, if a host has some mail that it does not know what to do with it should give it to some smarter host. The lines of communication, especially within a protocol family or communication scheme need not have anything to do with the domain name structure. I can imagine a host connected to the world only via the uucp communication scheme that for perverse reasons known only to its owners is called "NO-TECH.EDU". This host may know about some other uucp capable hosts in its neighborhood and be able to directly exchange mail with them using uucp. But, this host may not have much knowledge of the wider world and when asked to send mail to some host it never heard of (say "F.ISI.USC.EDU", or "Q.CC.BBN.COM", or even "CBOSGD.ATT.UUCP"), it punts by sending the mail to one of the hosts it does know that is smarter about the wider world. These other neighborhood hosts may be known by any kind of domain style names, for example, they may be in the EDU domain, or the COM domain, or even the UUCP domain. This assumes that at some point this messages gets forwarded to a host that does know the destination host and has it its tables a routing procedure for that destination. This does not require that there be some smartest host that knows everything. The knowledge can be subdivided and portions stored in a number of hosts. It may help to divide the knowledge according to the naming structure. For example, some host in the uucp communication scheme may take responsibility for knowing all the uucp capable hosts in the EDU domain. If some message for a host in the EDU domain is forwarded to this host it can either route it to the destination via uucp, possibly route it to the destination via some other communcation scheme, or may not know of the destination at all. In the last case, this host may forward the message to a relay that interconnects the uucp communcation scheme with other communication schemes (e.g., BITNET, MAILNET, CSNET, ARPA-Internet), the relay must attempt to find a way to route to the destination host in the other communication schemes. I think it is possible that if the source host and the destination host are in the same communication scheme (e.g., uucp), that even though their names have no obvious relationship (e.g., NO-TECH.EDU and HI-TEK.COM) a message can be delivered from one to the other without leaving that comminication scheme. I don't think there is any evidence that "two disjoint TCP/IP networks just don't work well". The ARPA world (ARPANET and connected nets) and the DDN world (MILNET and connected nets) are interconnected because the users in the two worlds have a strong need to share information, not because there is any flaw in the protocols that makes separation difficult. I really like the idea that the users of the uucp communication scheme are going to join together to have some coherent management. I think it is great that this management is exploring the various possible ways to set up additional internal structure, based on various criteria. I would like to point out that i think it is not likely that this management can force every host that has the uucp capability to use a name that ends in ".UUCP". If a host, X, at ISI, is uucp capable, its name is going to be X.ISI.USC.EDU. If some other uucp capable host has message to send to this host X there had better be a way of doing the message routing entirely within the uucp communication scheme. The conceptual problem i see is that some people still can't separate the arbitrary administrative domain style names from communication schemes. Where this causes real problems is at the edges, where the different communication schemes overlap. I think it is really important that a host have exactly one official name that is used consistently on all messages originated at that host. There are lots of reasons for this. I think the main point i'd like to make to the designers of naming and routing mechanisms for communication schemes (e.g., uucp, bitnet, mailnet, csnet (phone net), whatever) is: If your "name to route" procedure includes the assumption that every host in your communication scheme has a name ending in a constant string (e.g., UUCP, BITNET, MAILNET, CSNET, WHATEVER), then you should go back to the drawing boards -- the names you have to deal with are completely arbitrary. --jon. ************** 18-Oct-85 01:22:22-PDT,7272;000000000001 Received: from LOCUS.UCLA.EDU by SRI-NIC.ARPA with TCP; Fri 18 Oct 85 01:20:02-PDT Date: Thu, 17 Oct 85 16:42:24 PDT From: Rich Wales To: NAMEDROPPERS@SRI-NIC.ARPA Subject: Re: Mail forwarding (MF) info in domain data base References: Message of Wed, 16 Oct 85 21:11:54 pdt from "netinfo@jade (Postmaster + BITINFO)" <8510170411.AA16956@ucbjade.Berkeley.Edu> Message of 17 Oct 85 10:25:29 EDT (Thu) from "Dennis Rockwell " Message-ID: <498440544-12749-wales@DIANA.LOCUS.UCLA.EDU> Background: I recently stated the opinion that every host name used in a "From:" line of an ARPA Internet message should appear in the NIC host name table (not just in the domain data base) -- in order that hosts still using the NIC table can figure out where to send the mail. Bill Wells pointed out that Berkeley has lots of entities in its BERKELEY.EDU domain which are not on packet networks and which therefore cannot be listed in the NIC table (since they don't have Internet addresses). Dennis Rockwell then reminded us that the "MF" (mail forwarder) resource record exists for this very purpose -- and urged the designers and maintainers of mail systems to issue QTYPE=MAILA queries on destination domain names (and issue QTYPE=A queries only if QTYPE=MAILA returns no information). I decided to post this follow-up to NAMEDROPPERS because I felt it was a more appropriate forum for the technical issues involved than HEADER-PEOPLE. Since most NAMEDROPPERS recipients are supposedly on HEADER-PEOPLE as well, I assume that everyone reading this saw the previous messages as well. I wholeheartedly agree with Dennis's comments. Mail systems should unquestionably look first for mail-related domain information (MD and MF RR's; eventually, MB and MR RR's as well). A-type RR's should be used only as a last resort if no specifically mail-realted RR's are found for the destination domain. >From a realistic standpoint, however, we need to keep in mind the way that many (I won't necessarily say "most", since I don't know for sure) hosts are going to be handling the conversion to the data base system, at least initially. The easiest method for converting to the new system is for one to simply replace the old "name-to-address" library routine (which consulted the NIC table, or a hashed version of same) with a new library routine which uses a resolver to consult the domain data base. Such a routine would typically have exactly the same parameters as the routine it replaced, so that the actual program -- TELNET, FTP, mailer, server daemon, or whatever -- would not have to be modified at all. The "-lresolv" library (included as part of the 4.2BSD UNIX name server, BIND) is a typical example of this approach to conversion. This method, however, has two serious drawbacks: (1) I would guess that the vast majority of existing network-related programs use a very simple library routine which maps a given host name into one or more addresses, without regard to what kind of service is to be sought on the remote host. (This is only natural, considering that the "available services" information in the NIC table never indicates that different services are to be requested from different addresses. Rather than see whether a given host advertises a given service, it was always much easier simply to try to connect to the well-known port and see what happened.) As a result, I would predict that 99%+ of all queries to name servers will be for A-type RR's only. After all (so the simple substitute library routine would think -- if it could think :-}), if all I am trying to do is map a name into an address, why should I care about any type of RR other than A? (2) The domain data base system introduces a new kind of error condition -- namely, "temporary failure". Unfortunately, I suspect that many of the "quick-and-dirty" drop-in substitutes for the old NIC-table library routines are simply going to map this condition into the single, catch-all error category -- which the application program will undoubtedly interpret as meaning "no such host". As a result, I would predict that a temporary unavailability of part or all of the domain data base will result in mail to valid hosts being rejected with the claim that the requested host doesn't exist. Since a fair proportion of the net is probably going to use this method of conversion, at least initially -- whether we like it or not -- I would be reluctant to rely on MF-type RR's in the domain data base in order to accomplish anything interesting in the near future. And, of course, there's still the question of what the MILNET people are going to do if they want to send mail to CSNET's new domain -- or to one of Berkeley's myriad hosts -- with only the NIC table as a guide. So, for the time being, I continue to hold my original opinion that all domain names used in mail addresses should be listed in the NIC table. If an organization cannot (or chooses not to) list some name in the NIC table, for whatever reason, then I don't think that name should be used as the domain in a return address. Rather, the unlisted name should be "hidden" in the local-part (via the "%" hack), and some other domain name which is in the NIC table should be used to the right of the "@" in the address. A reasonable timetable should be set for remedying this problem -- taking into account the MILNET's actions relating to the domain data base, as well as the issue of making better name->address mapping rou- tines available to those organizations which haven't the time or exper- tise to write such routines themselves. Whether we like it or not, I think it is clear by now that the RFC921 timetable has slipped badly and is in need of revision. In retrospect, maybe it might have been better not to put A-type RR's in the domain data base at all -- but instead to make people find addresses from WKS RR's. This would have forced everyone, right from the start, to think about exactly what service they planned to seek when asking questions about a given domain name. The idea of looking for MD and MF RR's when looking for mail service for a domain would then have been a logical extension to the general procedure. Doing things this way would admittedly have forced people to go to some extra trouble in converting existing software (since a direct replacement for the simple name-to- address query would not be possible) -- but since it's now obvious that they'll have to go to this extra trouble anyway, this approach would probably have paid off in the long run. Ah well, so much for 20-20 hindsight. -- Rich Wales // UCLA Computer Science Department // +1 213-825-5683 3531 Boelter Hall // Los Angeles, California 90024 // USA ARPA: wales@LOCUS.UCLA.EDU -or- wales@UCLA-LOCUS.ARPA UUCP: ...!(ucbvax,ihnp4)!ucla-cs!wales ************** 29-Oct-85 09:10:49-PST,1108;000000000001 Received: from LOKI.ARPA by SRI-NIC.ARPA with TCP; Tue 29 Oct 85 09:10:28-PST To: wales@locus.ucla.edu cc: namedroppers@sri-nic Subject: MF in domain database Date: 29 Oct 85 12:00:06 EST (Tue) From: Craig Partridge Rich, I'm a little behind in reading namedroppers so this message may be superfluous. I'd like to suggest that the MF stuff is actually pretty trivial to handle. I actually managed to diddle Sendmail trivially to try using MF and MD records before A records. Now it wasn't absolutely perfect, but it did handle transient errors (and requeue messages for later delivery). Took about a 5 line change to sendmail which called a new mail handling routine which will be coming out with the next release of the Berkeley BIND software. I suspect many other systems can be changed almost as easily and we should encourage people to move towards using MD and MF, and be a little hard on people who resist. Craig Partridge CSNET Technical Staff craig@csnet-sh (CSNET) craig@loki (ARPA) {decvax,ihnp4,wjh12}!bbncca!craig (USENET) 29-Oct-85 11:38:41-PST,2304;000000000001 Received: from LOKI.ARPA by SRI-NIC.ARPA with TCP; Tue 29 Oct 85 11:38:09-PST To: namedroppers@sri-nic.arpa Subject: Wildcarding and Domains Date: 29 Oct 85 14:32:05 EST (Tue) From: Craig Partridge We have recently received a request from Israel (domain IL) to be one of their nameservers. In addition they have asked us to provide a somewhat special service, which has caused some mild debate here, and we thought we would consult the interested parties on the net for your views. The domain IL is expect to eventually contain several hundred hosts (it currently has between 50 and 100), which are accessible only for mail. Most of those hosts are accessed via RELAY.CS.NET, which forwards their mail via phone lines. The rest can be reached via EARN. As a result, the domain information for IL will only contain MAIL information (no Internet addresses), and every entry will simply be an MF RR, indicating that any mail to the given IL domain name is to be forwarded via RELAY.CS.NET. or some EARN gateway. The folks behind IL have expressed interest in just having us do a wildcard match -- i.e. any mailer asking about any name ending in IL will just be told to pass it on to RELAY.CS.NET for forwarding to Israel. For hosts on EARN we might keep a list of those hosts to forward specially. In other words, we would not keep a list of the hundreds of hosts in IL but would recognize any name ending in .IL as valid The major advantage is that we don't have to worry about coordinating the host information for an entire country. (Is this name valid this week?). The one disadvantage is that we would be creating a section of the domain space which is unverifiable. You will never be able to establish (without mailing to it) that a given IL name is actually valid. Since you can't reach the host except through mail anyway, it isn't clear this is a serious concern. Is it better to have "user%site@IL" (verifiable) or "user@site.IL" (unverifiable)? We'd be interesting in hearing views on both sides of the issue. Craig Partridge CSNET Technical Staff craig@sh.cs.net or craig@csnet-sh (CSNET) craig@loki.bbn.com or craig@bbn-loki (ARPA) {decvax,ihnp4,wjh12}!bbncca!craig (USENET) 29-Oct-85 13:04:44-PST,1370;000000000001 ************* 29-Oct-85 16:41:38-PST,1252;000000000001 Received: from A.CS.CMU.EDU by SRI-NIC.ARPA with TCP; Tue 29 Oct 85 16:37:40-PST Date: 29 Oct 85 19:37 EST From: Rudy.Nedved@A.CS.CMU.EDU To: NameDroppers@SRI-NIC.ARPA Subject: domain names Message-Id: <29Oct85.193715.EN0C@A.CS.CMU.EDU> What is the "name policy" behind CSNET going to domain names like .CS.NET? Wasn't the plan to have names like UMASS.EDU registered at NIC which pointed to some domain server at CSNET which had MF records for the phonenet site "umass"? Does this first attempt at using domains for another transport/administration network means that we will have domain names like: network domain names ------- --------------------- BITNET BIT.NET MAILNET MAIL.NET or EDUCOM.NET UUCP UCB-UUCP.NET, SEISMO-UUCP.NET, etc. or is this some transition mechanism to get thru the short term? One of the driving arguments around CMU for domain names were they provided a flat name space independent of networks and that each host would have ONE name. With hosts part of CSNET, MAILNET, UMich net, etc. and this unwritten new naming policy, the driving flat name space argument has been undermined. So what is the deal? Some feedback from the domain gurus would be nice for a change. -Rudy 29-Oct-85 18:16:22-PST,5167;000000000001 Received: from USC-ISIC.ARPA by SRI-NIC.ARPA with TCP; Tue 29 Oct 85 18:15:45-PST Date: 29 Oct 1985 18:16:51 PST From: MOCKAPETRIS@USC-ISIC.ARPA Subject: My ten favorite domain server lossages To: namedroppers@SRI-NIC.ARPA In the course of debugging my resolver, I have found that a number of servers are responding in ways that range from mildly distasteful to downright antisocial. I realize that the organizations running the servers may be mere accesories and not directly to blame, but rather the server writers or those who compose vague domain specs. Hence, I appologize to the named ones, particularly those who have fixed the problems already. The top ten: 1) The serial field of the SOA RR for a domain is supposed to be a continuously increasing (mod 2**32) value which denotes the version of the database. The idea is that you can tell that a zone has changed by comparing serial numbers. Suspects: I haven't found any values greater than 1, which either means that we have seen remarkable stability, or else that nobody is playing the game by the rules. 2) If a node has a CNAME RR, it isn't supposed to have any other RRs. This makes reasonable caching possible. Suspects: Too numerous to mention. 3) If you send a query to a host with multiple addresses, it is supposed to respond from the address receiving the query. Suspects: Several, but RICE.EDU is the most interesting. If you ask the NIC for RICE.EDU, it says that servers are RICE.EDU at 192.5.58.6 and PENDRAGON.PURDUE.EDU at 192.5.48.5. Fine. Ask RICE.EDU, using 192.5.58.6, for all information for RICE.EDU, and you get a message back from 128.42.3.2. This address doesn't correspond to either data at RICE.EDU or the delegation from the root servers such as the NIC. 4) If you use the IN-ADDR tree to get a host name corresponding to a Internet address, you are supposed to get a pointer (PTR) RR to the primary name of the host, not a list of aliases or whatever. Suspects: Several, for example the mysterious 128.42.3.2 from the previous item. 5) Making up data. For example, there are lots of servers who return RRs for the root servers with 99999999 in the TTL. Some return RRs that suggest that ISIF is a root server. (It was months ago, but is no longer. I use it for testing. I haven't updated its database since I started using it for testing.) One of the main ideas of the domain system is that everybody can get a chunk of the name space to manage as they choose. However, you aren't supposed to lie about other parts of the name space. Its OK to remember about other parts of the name space for caching or other purposes, but you are supposed to follow the TTL rules. Now it may be that you put such records in your server or whatever to ensure a server of last resort etc. I suppose that's fine. But if you export these in answers to queries, you should be shot. These entries get put in caches and never die. Suspects: all BINDs. Suggested domain meta-rule: If you must lie, lie to yourself. 6) Backup servers which don't backup. The rules say that your database should be available from redundant servers. If you only have one computer, you can find a buddy, and back each other up. But you don't just find the name of a buddy, you are also supposed to actually back each other up. 7) All RRs with the same name, class, and type should have the same TTL. The logic here is that all of them will timeout simultaneously if cached and hence the cache can be reliably used for QTYPES which don't match multiple types. Suspects: DECWRL.DEC.COM, GODOT.THINK.COM, LABREA.STANFORD.EDU for type=a Many others. 8) Delegation information should be consistent at all of the delegator and delegatee zones. For example, XXX delegates to ZZZ.XXX, the XXX and ZZZ.XXX servers should have identical lists of NS RRs for ZZZ.XX. Ideally, they should have the same TTLs. Suspects: RICE.EDU, BERKELEY.EDU and many others 9) The domain system is supposed to preserve case, but be case insensitive. However, it does nobody any good to put both RRs for domain name xxx and XXX in the data base - It merely makes caching ambiguous and decreases the efficiency of compression. This consistency should also exist in the duplicate RRs that mark delegation in the delegator and delegatee. For example, if you ask the NIC to delegate UZOO.EDU to you, your database shouldn't say uzoo.edu. Suspects: ucbvax.berkeley.edu, UCBVAX.BERKELEY.EDU 10) Don't use aliases where they only can cause trouble. For example, if you use a NS RR to mark delegation, use the primary name of the server in the RR rather than the alias - all you are doing is slowing resolvers down. Similarly, don't use both the alias and the primary name. Suspects: If you ask ucbarpa.berkeley.edu about the BERKELEY.EDU zone, it will tell you that there are authoritative servers known as ucb-vax.berkeley.edu, ucbvax.berkeley.edu and ucbarpa.berkeley.edu itself. The first two appear to be the same host ( or should be if they aren't.) paul ************* 30-Oct-85 11:35:14-PST,3254;000000000001 Received: from LOKI.ARPA by SRI-NIC.ARPA with TCP; Wed 30 Oct 85 11:34:00-PST To: namedroppers@sri-nic.arpa Subject: Domain Names and CSNET Date: 30 Oct 85 14:26:37 EST (Wed) From: Craig Partridge After reading some of the recent messages on this mailing list we at CSNET thought it might be appropriate to tell people what we have adopted as our policy on domain names, and how we are planning to advise our sites. In essence we have decided that CSNET sites should NOT include service related information in their domain name (like .CSNET or CS.NET) but should instead register in the domain which seems most appropriate (like EDU or COM). So a CSNET site which you now mail to as STATEU.CSNET, will become STATEU.EDU or some such. We are looking at ways of making this registration easy on our members, many of whom have only nodding acquaintance with the realities of the Internet. We chose to encourage sites to register in the descriptive domain because it seemed unreasonable to expect the average mail user to remember that an educational institition should have a name that ends in .EDU, unless they get their mail thru CSNET (or UUCP, etc.) in which case you must use .CSNET or .UUCP, etc. It seemed that the whole point of domains was to get rid of this confusion. There is a domain CS.NET. which is only used by the CSNET support hosts like RELAY.CS.NET (aka CSNET-RELAY.ARPA) and SH.CS.NET (where most of the CSNET staff actually works and keeps their mailboxes). This domain is now registered with the NIC and we are in the process of getting rid of most of the old .ARPA names (we are keeping CSNET-RELAY.ARPA and CSNET-SH.ARPA around as CNAMES during the transition). One should note that there are some interesting consequences of this decision. First is that many if not most CSNET sites can only be reached via RELAY.CS.NET. They do not have Internet addresses and the only way they participate in the Internet is that mail can be sent to and from them via the relay. As a result their entries in the domain databases are simply going to be an MF record saying send anything addressed to (for example) STATEU.EDU to RELAY.CS.NET. As the conversion goes into effect, people with mailers that don't know how to cope with MF records are going to discover that they can't reach CSNET sites. We may try to make this problem easier by rewriting addresses as they go thru the RELAY to read JOE%STATEU.EDU@RELAY.CS.NET, but that seems distasteful. The second problem is one I've already broached with regard to domain IL. We've got a lot of sites out there which are gateways into large local mailsystems. We (and this is probably the Internet community collectively) are going to have figure out how we want to deal with registering all these hosts, which can only be reached via mail. The domain servers could be innundated with mail related RR's and we should at least begin to think about whether there are better solutions (like wildcarding and deferred authentication?). Craig Partridge CSNET Technical Staff craig@SH.CS.NET (csnet-sh.arpa) craig@LOKI.BBN.COM (bbn-loki.arpa) {decvax,ihnp4,wjh12}!bbncca!craig ************* 30-Oct-85 17:13:56-PST,1357;000000000001 Received: from SU-SCORE.ARPA by SRI-NIC.ARPA with TCP; Wed 30 Oct 85 17:13:16-PST Date: Wed 30 Oct 85 17:08:23-PST From: David Roode Subject: Re: domain names To: zsu@SRI-TSC.ARPA, NameDroppers@SRI-NIC.ARPA In-Reply-To: <8510302159.AA04861@sri-tsc> Message-ID: <12155367584.25.G.ROODE@SU-SCORE.ARPA> I think the suggestion for a .OTHER domain is the best change that would be compatible with the current classification scheme of top level domains. This would subsume .NET. However, the current top level domain names seem useless. What about merging all the current top level domains into a nationwide domain ".US"? As Rudy Nedved pointed out, it is pretty self-centered of the US to assume that other countries will want to participate in its naming scheme. There is little advantage of breaking up toplevel domains along the lines of EDU and COM. The real benefit comes in having one organizational naming domain, where previously we had 300 individual host candidates for the NIC host table. That the US domain should have 2000 entries versus each of COM and EDU having 1000 is unimportant. The COM and EDU is an artificial split for the sake of splitting. Domains are needed, and there are plenty of natural splits without creating them for the sake of getting the domain system started. ************* 2-Nov-85 19:22:56-PST,3596;000000000001 Received: from seismo.CSS.GOV by SRI-NIC.ARPA with TCP; Sat 2 Nov 85 19:22:28-PST Return-Path: Received: from somewhere.UUCP by seismo.CSS.GOV with UUCP; Sat, 2 Nov 85 22:17:21 EST Received: from cbpavo.cbosgd.ATT.UUCP (cbpavo.ARPA) by cbosgd.ATT.UUCP (4.12/0.98.UUCP-CS.beta.4-27-85) id AA17327; Sat, 2 Nov 85 22:13:20 est Received: by cbpavo.cbosgd.ATT.UUCP (4.24/3.14) id AA22639; Sat, 2 Nov 85 22:11:00 est Date: Sat, 2 Nov 85 22:11:00 est From: cbpavo.cbosgd.ATT.UUCP!mark@seismo.CSS.GOV (Mark Horton) Message-Id: <8511030311.AA22639@cbpavo.cbosgd.ATT.UUCP> To: namedroppers@sri-nic.arpa Subject: Re: domain names What about merging all the current top level domains into a nationwide domain ".US"? As Rudy Nedved pointed out, it is pretty self-centered of the US to assume that other countries will want to participate in its naming scheme. Exactly. From the surveys I've taken of the international electronic mail community, I have yet to run into ANYONE outside the United States who is interested in the EDU/COM/GOV domains. Without exception, they all want the top level domains to be based on geography and international boundaries. All the people interested in EDU/COM/GOV, and all those who feel that geography is inappropriate for domains, are within the USA. Regions that I've talked to include Europe, Israel, Korea, Japan, Australia, and Canada. I've heard nothing from South America, Central America, Africa, or Central Asia, presumably because these are less developed regions. There is a lot of interest in X.400 in the international community. There seems to be a strong sentiment that future electronic mail will be exchanged using the X.400 standard, and that all domains should be formed along the X.400 lines. (This interest is not universal, there are many people who would prefer to continue to use ARPA or UUCP or BITNET or DECNET or Greybook or whatever their local system is.) They have the telcos behind them, with the weight of law, saying that all data communication had better use the telco facilities and standards, which are essentially X.25 and OSI. These requirements are especially strict for international traffic. As I understand X.400, it's moving in the general direction of having the top level domain be the country and the second level domain be the name of the organization. (It's not quite that simple, but that's the idea. In the short term, the second level is the "administration management domain" (the common carrier or X.25 network they buy service from.) This is very similar to the ARPANET, except for the presence of some top level domains like EDU which are not countries. I'm told that the other countries (especially the UK) consider the EDU, COM, and like domains to have a .US on top of them. I think it would be a very good idea for us to do the same. Doing something about the second level is harder, since the US is so big and there are many organizations. The X.400 solution to this is to include "extra information" to resolve ambiguities. This information can be a "locality" (e.g. city, state, region), a Zip code, a Telephone number, or a Telex address. I think it may be fair to make up other types of attributes for this, e.g. a "type of org" attribute which might be EDU, COM, or GOV. How to handle this isn't all that clear-cut. But for the time being the problem isn't all that bad. Even on UUCP (which is huge) a name count shows only about 400 orgs in the COM domain, and 125 in EDU. Mark ************* 4-Nov-85 13:35:33-PST,780;000000000001 Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Mon 4 Nov 85 13:31:52-PST Date: 4 Nov 1985 13:28:27 PST From: POSTEL@USC-ISIB.ARPA Subject: politics of names - not on this list -- please ! To: namedroppers@SRI-NIC.ARPA Hi. The namedroppers list is for the discussion of the technical issues in the DARPA domain name system. The actual spelling of the name strings, and especially the semantics that people attach to those strings are not part of these technical issues. So please, no messages in this mailing list about the merits of EDU vs US (etc.,) as a top level domain name. Clearly, the choices of top-level names is a highly-charged political issue. Please discuss it in the appropriate forum (msggroup ?, poli-sci ??). --jon. ************* 11-Nov-85 06:38:34-PST,2588;000000000001 Received: from LOKI.ARPA by SRI-NIC.ARPA with TCP; Mon 11 Nov 85 06:38:13-PST To: namedroppers@sri-nic Subject: MD and MF for one host Date: 11 Nov 85 09:30:04 EST (Mon) From: Craig Partridge I've been re-reading the RFC's and noticed that it is apparently legal for a host to have both an MF and an MD record. I find this a bit confusing. If a mailer gets both an MD and an MF for a single host which one is it supposed to use? If it always prefers one over the other, then listing both an MD and an MF is clearly wrong or at least a bad idea (since one or the other gets ignored). But if the mailer is supposed to make some intelligent choice between the two choices, can anyone tell me how that choice should be made? I've been trying to think of why one would want both an MD and an MF and have come up with two examples. They are: 1. Just to describe the true mail situation. For example, anyone at BBN.COM can be reached by mailing to them at UNIX.BBN.COM (or indeed to almost any host in BBN.COM). Thus one might list a host as accepting mail itself (MD) or as reachable thru some of the BBN.COM. hosts (MF). I think this practice should be discouraged, since it is not clear that the MF record is useful. 2. To deal with intermittent links. Imagine, for example, a host (A) which is only reachable during certain hours from the Internet (or only reachable thru a single gateway, or experimental link) but which also has a direct link to another Internet host (B). Here one might list A as being its own MD, but also list B as an MF. Here one would want a mailer to try to reach A, and failing that, immediately send the mail on to B for forwarding, so B can promptly pass the mail to A. Note that a mailer's behaviour in the two situations is likely to be different. In case 1, the MF is simply another way to reach a host you can always reach directly. As such, the mailer should probably ignore the MF as not useful (if you can't reach the host it is because the host is probably down, and passing the mail on to the MF isn't going to change this situation). In case 2, the MF record is very useful -- it allows mail to reach the desired host faster. Other examples may produce other results. Anybody got any idea what a poor mailer is supposed to do about this? Craig Partridge CSNET Technical Staff craig@csnet-sh or craig@sh.cs.net (CSNET) craig@loki.bbn.com (ARPA) {decvax,ihnp4,wjh12}!bbncca!craig (USENET) ************* 11-Nov-85 08:36:30-PST,2145;000000000001 Received: from rice.ARPA (CALIPSO.RICE.EDU) by SRI-NIC.ARPA with TCP; Mon 11 Nov 85 08:35:33-PST Received: by rice.ARPA (AA03739); Mon, 11 Nov 85 10:27:27 CST Date: Mon, 11 Nov 85 09:57:05 CST From: Paul Milazzo Subject: Re: MD and MF for one host To: Craig Partridge Cc: NAMEDROPPERS@SRI-NIC.ARPA Message-Id: <1985.11.11.09.57.06.150.03079@Dione.rice> In-Reply-To: A message from Craig Partridge dated 11 Nov 85 09:30:04 EST (Mon) Craig: The RICE.EDU nameserver lists both MD and MF records for all the hosts that can accept SMTP mail, and MF records alone for those that cannot. I have arranged for the MD record to preceed the MF record in the answer, under the assumption that many clients will use the first one they encounter (Besides, that way it matches the example in RFC 883 :-). In my opinion, an "Intelligent" mailer, upon encountering both an MD and one or more MF records, should try first the MD. If that host does not answer or is unreachable, it should try the MFs in order of reception. A "Really Intelligent" mailer would avoid trying an MF pointing to a host on a network for which it had just received a Network Unreachable. I justify this approach as follows: in the RICE.EDU domain, all the MF records point to a host which is electrically closer to the main body of the Internet than the intended recipient host, and thus more likely to be reachable. We would prefer the mail be delivered directly to the recipient host *if it is available*. If not, we would prefer that the mail be delivered to a forwarding host at Rice rather than retried every m minutes for n days. For one thing, all those retries represent PDN packets, which cost us money. For another, if the mail is now physically at Rice, it can be redirected by the Postmaster should the original recipient host suffer extended downtime. Paul G. Milazzo Dept. of Computer Science Rice University, Houston, TX Domain: milazzo@rice.EDU ARPA: milazzo@rice.ARPA BITNET: milazzo@ricecsvm UUCP: {cbosgd,convex,hp-pcd,shell,sun,ut-sally,waltz}!rice!milazzo ************* 12-Nov-85 10:26:33-PST,1925;000000000001 Received: from LOKI.ARPA by SRI-NIC.ARPA with TCP; Tue 12 Nov 85 10:25:56-PST To: namedroppers@sri-nic Subject: Mailers use MD and MF Date: 12 Nov 85 13:20:39 EST (Tue) From: Craig Partridge The unanimous opinion of the notes (all but one of which also went to namedroppers) I've gotten in response to my last letter is that it makes sense to have both MD and MF records for a single host. If people are willing, I'd like to take this discussion one step further and nail down what we expect a mailer to do with with MD and MF records. The notes I got seemed to have pretty similar ideas, and we might as well canonize it, before all the mail systems come out with their own (different) rules. Here is the set of rules I think comes closest to what people want (heavily borrowing from Paul Milazzo's message). The two key points are that the MFs are tried immediately, if the MD host isn't reachable (no fancy delays, etc.) and that if a host doesn't list any mail records, it is assumed to be its own MD, while simply listing an MF says "always forward". Here the rules I think people are headed towards: Given a host name a mailer should do a MAILA query on that domain name. If the MAILA query returns nothing look up the Internet address of HOST. If this lookup fails, reject the message, otherwise try to deliver the message to the Internet address. If the MAILA query succeeded, first try to deliver to the MD host (if any). If you cannot reach the MD host, try any MF hosts listed. Try to contact each MF until either there are no MFs remaining, or one of them has accepted or rejected the message. (Paul's idea of not trying MFs on unreachable networks is a nice touch here). Craig Partridge CSNET Technical Staff craig@csnet-sh or craig@sh.cs.net (CSNET) craig@loki.bbn.com (ARPA) {decvax,ihnp4,wjh12}!bbncca!craig (USENET) ************* 15-Nov-85 14:32:04-PST,2903;000000000001 Received: from USC-ISIB.ARPA by SRI-NIC.ARPA with TCP; Fri 15 Nov 85 14:31:38-PST Date: 15 Nov 1985 14:30:31 PST From: MOCKAPETRIS@USC-ISIB.ARPA Subject: MD, MF, and larger issues To: namedroppers@SRI-NIC.ARPA As the recent discussion of MD and MF types has illustrated, the domain system has created a need to refine the semantics of information available from the domain system. Mail isn't the only issue; for example, the address RRs now make multiple host addresses available to many applications which didn't have them before, and we start wondering if order is important, how we select an address to use, etc. As a general principle, I believe that we should start thinking about the domain system as a general mechanism for distributing data and work on defining modular specs or guidelines for applications. Mail is a good example. In any case, a couple of additional thoughts on MF and MD: The original idea was that MD was the destination and MF was something willing to eventually get it to the destination. Some group of organizations connected via a bad (intermittent, low bandwidth, or some such) link to the rest of the world might use MD/MF combinations to try to get mail over the bad link even when the destination was down. Similarly, an organization might choose to make a number of alternates available via MF partners to remove queueing requirements from senders on small hosts. A personal computer might access mail by calling up a big brother mail drop via POP or some other system to download mail. In this case, the PC host might be represented as MFs exclusively. A sending host might prefer, given a destination that returns both MF and MDs, to believe that it would be faster/more reliable/more secure to wait for a MD to be available than to use the MFs. Perhaps we should deconceive MD and MF, and create a new RR called say, MX. The data section for MX would carry multiple data items: a domain name for a mail agent (i.e. the contents of present MD and MFs), AND a integer "distance" value. The distance value would be zero if the agent was the destination, and a number representing "closeness" to the destination otherwise. The idea here is that smaller distance values should be selected in preference to larger ones, all other things being equal. (It might be possible to figure out some good unit for "distance" but I'm not going to try and defend one.) The advantages of this scheme are: Caching would be easier because we use a single data type. Mail senders don't have to worry about two types. Selecting between different MFs might be more rational. However, I'm not sure we want to replace our existing system with MX, even though its clearly better than the MD & MF RRs we have now. I do suggest that we use these experiences when we design new RR types. paul ************* 9-Jan-86 12:11:44-PST,2406;000000000001 Received: from LOKI.ARPA by SRI-NIC.ARPA with TCP; Thu 9 Jan 86 12:11:15-PST To: namedroppers@sri-nic.arpa Subject: Draft RFC on Mailers and Domains Date: 09 Jan 86 15:04:59 EST (Thu) From: Craig Partridge A draft of an RFC on how Internet mailers should interact with the domain system for the purposes of routing mail is now available by anonymous FTP from SH.CS.NET (or CSNET-SH.ARPA) in "rfc/rfcXXX.txt". I'll be interested in any comments that readers have. People should be aware that there is an anticipated change in how the domain system stores mail routing. MD and MF RRs are going to be replaced by a single RR, called MX. An MX RR matches a domain name with two pieces of data: a domain name of a host and a 32-bit preference number. The preference number is used to allow mailers to prioritize MXs. (I.e. to answer the question, to which host should I try to deliver this message to first?). The preference value is purely for purposes of prioritization and has nothing to do with distances, hop counts, etc. There are several reasons for the change. Here are a few: (1) It vastly simplifies what mailers have to do to route messages. The decision making process turns out to be messy using two types of RRs. (2) It is more flexible than a simple two class (MD and MF) system. (3) Using one RR type instead of two dramatically reduces the chances for mail looping and other unpleasantness due to differing timeout periods for the two RR types. The draft RFC is written in terms of using MX RRs. I believe that an RFC explaining this change and incorporating the updates in DOMAIN-CHANGES.2 is planned. Craig Partridge CSNET Technical Staff craig@csnet-sh or craig@sh.cs.net (CSNET) craig@loki.bbn.com (ARPA) ---------- P.S. For users of the BIND software, I have diffs to BIND to support MX RRs. It assumes that the type for MX is 15 (which was the first free type) and that the format in the nameserver files and RRs is: # domain class etc. type host preference LOKI.BBN.COM. IN MX UNIX.BBN.COM 10 this may well turn out to be backwards (preference could just as well come before the host name) and the type number could prove wrong, but at least this allows you to try things out. Diffs are being posted to the bind list.