Stef@NRTC.NORTHROP.COM (Einar Stefferud) (07/17/90)
It may just be my inability to read these things with ease, but I did not see a clear cut distinction between the records used to identify (route to) gateways vs the records used to map TO-822 and TO-X400 in the RFC822 and P2 envelopes. It is not clear to me how an X400 MTA would use these records for P1 routing to a gateway. (Not that I think they should not! I absolutely think that we should find a way to do this, without resorting to source-routing hacks!) Could you clarify this in the text? Also, why do you want to orient the X400 addresses least significant element to the left, and most significant to the right, when most X400 texts tend to show them the other way around? (Or am I wrong in this perception?) Is there any non-arbitrary logic here? Next, is it reasonable to deal with the excess of DNS domain names in a mapping TO-X400 by just arbitrarily concatenating the excess into the lowest level OU on the X400 side? u@a.b.c.d.e.f.g => S$u.OU$a\.b\.c.OU$d.OU$e.OU$f.O$g.PRMD$NREN.ADMD$ .C$US And last, what is wrong with allowing mapping all the way down to the User Name (S$last.G$first)? Cheers...\Stef
Christian.Huitema@MIRSA.INRIA.FR (Christian Huitema) (07/17/90)
Rob, I read your note, and think that we should work towards its fast finalisation, perhaps clarifying a few points. My first remark concern the mapping ``towards X.400''. You follow-up the mechanism which was first introduced in RFC-987, to build up a hierarchical name as a sequence of ``typed'' tokens, e.g. a top level "C$FR", a second level "ADMD$ATLAS", etc. This has the advantage of precision, but it has also one serious disadvantage, i.e. requiring the setting up of a complete new tree. I feel that this kind of mapping is in fact contradictory with the whole philosophy of RFC-987/1048, where after some specific top levels (C, ADMD, PRMD) the next hierarchical tokens are mapped directly to DNS name parts. A specific start of the tree is certainly necessary, as the subdomains of e.g. "C=FR" bear few relations with those of ".FR". This could easily be provided by setting up a pseudo top domain for "x400", in much the same way as "in-addr". But then, there is no need to insist on the presence of the "C$" or "OU$" prefixes; one should rather try to use the aliasing mechanism already present in the DNS, in order to discover that e.g. "cea.cea.atlas.fr.x400" is in fact the same domain as "cea.fr". This has two advantages: * the same tree can be used at the lower levels, * there is no need for a specific "to-rfc" record. This can also introduce my second remark, regarding routing and the choice of gateways. If the naming heirarchies are in the same tree, there is no need of inventing new routing mechanisms; you can as well use the MX records! Indeed, there is at that point the need to support X.400, hence the need to define a PSAP record associated to the MX host, but this may be another matter... My other remarks are much in the same line as Steve. I don't see much need for a preference counter in the "to-x400" records, and I don't see why the wildcarding mechanism should be different from the one used for the MX records... Christian Huitema
hagens@CS.WISC.EDU (07/18/90)
> 5.0 "This implies that there will be two separate copies of the > mapping database, one in table form, and the other within the internet > DNS Namespace". I agree that this is the case. If we go down this > path, it is imperative that we have solid mechanisms to keep these > two views consistent. I don't think that you have really addressed this. No, your right. We did not discuss the specifics for keeping the authoritative data for a specific DNS server and the table form consistent. At one level, it is simply a program that produces one form from the other. At a higher level, there are issues concerning the way in which the US collects its tables and disseminates them to the rest of the world (and vice versa). Another issue is how to deal with inconsistencies that may result if a site changes their DNS server configuration file before the change has been propagated to those gateways which do not have DNS access. In general tho, do you think the coordination of the tables and server config files is feasible? > > I think that the preference value is an interesting idea, however I > don't see why it is really needed. Then 987 mappings are global. There > should be no need to have alternate/preferred mappings. A preference > mapping would be more appopriate when choosing a 987 gateway, but not > for the base 987 mapping. In retrospect, I think the preference field is not going to work, for reasons you site above. I think that in the 822->X.400 direction, the preference field of MX records can be used to find the gateway. In the other direction, it is a matter for X.400 routing to solve. > > You may use 987 mappings to reformat a header containing a large number of > addresses. It would seem reasonable to reformat the header in a single > process. There might be problems with DNS timeouts for headers > with a very large number of addresses. Yes, this is a problem with the DNS today with RFC 822 mail! We need to make sure that back-up servers are distributed correctly. Of course, running the DNS over the OSI connection-less network will drastically improve connectivity and dependability! :^) > Overall, I have a lot of sympathy with the approach you propose. The format > of Appendix F of 987 was not a co-incidence. However, I have a lot of > concern that it is not the correct operational choice. Could you elaborate here? Thanks, Rob
hagens@CS.WISC.EDU (07/18/90)
> > > Rob, > > I read your note, and think that we should work towards its fast > finalisation, perhaps clarifying a few points. > > My first remark concern the mapping ``towards X.400''. You follow-up > the mechanism which was first introduced in RFC-987, to build up a > hierarchical name as a sequence of ``typed'' tokens, e.g. a top > level "C$FR", a second level "ADMD$ATLAS", etc. This has the > advantage of precision, but it has also one serious disadvantage, > i.e. requiring the setting up of a complete new tree. I feel that > this kind of mapping is in fact contradictory with the whole > philosophy of RFC-987/1048, where after some specific top levels (C, > ADMD, PRMD) the next hierarchical tokens are mapped directly to DNS > name parts. Christian, Our basic assumption for this work is that we will need many specific mapping entries because the OR Address tree will not be directly derivable from the DNS tree. For example, in the pilot project here, my X.400 address has an Org of "uw-madison". The components "wisc" and "edu" do not appear in my address. Thus, I need a more specific mapping entry than just C and PRMD. If you assume that a few general mappings will work, then obviously you don't need our proposal... Lets discuss this more in Wisconsin! Have a good flight Rob
harald.alvestrand@elab-runit.sintef.no (Harald Tveit Alvestrand) (07/19/90)
Rob et al:
Your proposal requires (as far as I can see)
the registration of new toplevel domains C$no, C$us and so on.
Maybe we should follow Christian's proposal (I recognize the idea from
the MAILWAY code....), and put a single toplevel domain with name "X400"
or even "RFC987TABLE"?????
The administrative authority for the subdomains of this descends naturally
on the RARE MHS managers, since most of the national X.400 authorities
(whatever that is) will probably not even know what a DNS is.
Otherwise, I like your proposal.
One note: You should perhaps include a statement that "when mapping
information is not available due to DNS server downtime, the 987 gateway
should WAIT until the mapping is available, or a LONG timeout, before
non-delivering the message".
Second note: I have never seen a DNS name with a space in it.
The proposal (and RFC987 tables!) depend on $ and . being absent from
the attributes (or escaped, see the troubles with uk.ac!). With
X.400/88 we get every character under the sun into the addresses.
Is this problem generally solved by using (numeric)?
Does DNS handle a name of the form
dom(number)dom.gurba .
correctly? (parentheses and space!)
I ask from ignorance of DNS....
Haraldcole@CS.WISC.EDU (Bruce Cole) (07/20/90)
> Rob et al: > Your proposal requires (as far as I can see) > the registration of new toplevel domains C$no, C$us and so on. > Maybe we should follow Christian's proposal (I recognize the idea from > the MAILWAY code....), and put a single toplevel domain with name "X400" > or even "RFC987TABLE"????? If a new address class is used for the RFC987 mapping data, then adding an extra level to the DNS tree seems unnecessary. In this case, root nameservers would be registered as authoritative for the new address class. These root nameservers do not need to be the same as the root nameservers for the internet address class. If the internet address class is used for the RFC987 mapping data, then storing the new domains within a dummy top level domain seems desirable from an administrative point of view. > The administrative authority for the subdomains of this descends naturally > on the RARE MHS managers, since most of the national X.400 authorities > (whatever that is) will probably not even know what a DNS is. And if a new address class is used, then the RARE MHS managers could also be authoritative for the root nameservers of the new address class. > Second note: I have never seen a DNS name with a space in it. > The proposal (and RFC987 tables!) depend on $ and . being absent from > the attributes (or escaped, see the troubles with uk.ac!). With > X.400/88 we get every character under the sun into the addresses. > Is this problem generally solved by using (numeric)? Section 3.3.3 of RFC987 defines how special characters within O/R addresses can be represented as (DNS safe) ascii characters for X.400/84. RFC1138 has a similar section which applies to X.400/88. In both, parenthesized numbers representing ascii codes are used to encode special characters. > Does DNS handle a name of the form > > dom(number)dom.gurba . > > correctly? (parentheses and space!) Yes, for example I can add a resource record to my BIND nameserver that looks like: example in mx 0 dom(number)dom.gur\ ba. or example in mx 0 "dom(number)dom.gur ba." and when I query my nameserver I get: dip(cole): host -a example Trying domain "cs.wisc.edu" rcode = 0 (Success), ancount=1 example.cs.wisc.edu 86400 IN MX 0 dom(number)dom.gur ba dip(cole): Bruce Cole Computer Sciences Dept. U. of Wisconsin - Madison
Eppenberger@verw.switch.ch ("Urs Eppenberger") (07/20/90)
Dear Rob,
It was important to start some thoughts on how the coordination problem
for the RFC987 tables could be solved. Your porposal is a very valid input
to that discussion, thanks a lot. (I'm the MHS coordinator for the Swiss
X.400 academic network SWITCHmail, which includes several RFC987 gateways
and I know personally the problems of keeping the tables up to date :-| .)
Just let me do two comments:
a) RARE WG1 does not coordinate the RFC987 tables. Actually it is done by
the RARE MHS project team at Sintef in Norway. In the near future this
job will be handed over to COSINE S2.1 or S2.2.
I suggest therefore to delete the corresponding parts in your proposal
und replace it with a 'neutral' term, i.e. RFC987 gateway table
coordination group, ...
Perhaps your proposal will getthe status of a standard and then it is
important not to fix who will collect the tables.
b) As we actually suffer from recource intensive gatewaying software
(in terms of CPU power and maintenance) I'm very concerned about how
performant an implementation following your proposal will be.
I suggest you to add a small chapter which studies the performance
issue.
(The WG1 distribution list contains 60 addresses from ca 40 different
domains which forces the gateway to collect 60 MX records from 40
different name servers. How long will it need to translate the
message? A table driven mechanism will surely be faster.)
(But clever implementation of your proposal could easily be faster
than the software we use actually :-) :-( .)
Kind regards,
Urs.harald.alvestrand@elab-runit.sintef.no (Harald Tveit Alvestrand) (07/20/90)
ad performance and nameserver queries: does it take modification of my local nameserver to cache the new-address- class/new-type records? if YES: who will take responsibility for updating NS SW & distributing fixed sources?
hagens@CS.WISC.EDU (07/25/90)
> > > Your point (and Steve's) about synch between RFC987/1148 mappings in DNS > and in the necessary TABLES around rthe world for those who do not have > DNS access is indeed a well foudned problem and worthy of serious > discussion. > > Question: Is it possible to devise some way to build the TABLES from > the DNS records on some regular basis, rather than to just not really > try (as seems to be the way we arrived at the current DNS vs NIC-TABLES > situation). The zone transfer operation was designed for just such a purpose. It allows one to snarf a piece of the DNS tree from a server. It is possible (although resource intensive) to have a single site snarf ALL the 987 mappings from the entire DNS system. Once this data was in hand, the mapping table could be built. If this site was the one responsible for the worldwide tables, I think table/DNS coordination would be minimized. Rob ps. obviously, such a resource intensive operation would run infrequently.
poole@chx400.switch.ch (Simon Poole) (07/26/90)
In article <9007251452.AA09940@janeb.cs.wisc.edu> hagens@CS.WISC.EDU writes: ..... >The zone transfer operation was designed for just such a purpose. It allows >one to snarf a piece of the DNS tree from a server. It is possible (although >resource intensive) to have a single site snarf ALL the 987 mappings from >the entire DNS system. Once this data was in hand, the mapping table could >be built. If this site was the one responsible for the worldwide tables, >I think table/DNS coordination would be minimized. .... >ps. obviously, such a resource intensive operation would run infrequently. Ah, but that's exactly the problem. The anlogue with DNS - host table just doesn't work: if your host table is out of date, your site just looses connectivity, if your RFC987 tables are out of date, you start injecting messages with bad addresses into the mail system (on both sides of the gateway) with all the problems that can cause (loops, unreplyable messages and so on...). In my opinion, implementing this scheme would simply mean: no RFC987 gateways for sites without full Internet connectivity. -- ------------------------------------------------------------------------ Simon Poole poole@verw.switch.ch / poole@chx400.switch.ch / mcsun!chx400!poole ------------------------------------------------------------------------
postel@VENERA.ISI.EDU (07/27/90)
Hi. Say, i think something has gone off the track here. I thought that RFC-987 was for mapping between the Internet mail protocol as defined in RFCs 821 and 822, and the X.400 mail system. If that is the case then wouldn't any gateway that did RFC-987 be between the Internet and some part of the X.400 world? That is, won't any gateway that needs to do the RFC-987 mappings have one foot in the Internet, and therefore have access to the DNS? So why are we talking about hand crafted tables and all their problems? Why can't we use a distributes system like the DNS ??? [One could argue that we should use X.500 services to keep the mapping data since presumably the X.500 world is coextensive with the X.400 world, and all these gateways also have one foot in those worlds; but i won't make that arguement.] --jon.
pvm@VENERA.ISI.EDU (Paul Mockapetris) (07/27/90)
I must admit that I am very surprised at the direction this discussion has taken. For other applications, several of the participants have argued that the DNS lacks the power for various high-powered schemes and X.500 (or something else) was required. But now we seem to be hearing that the future belongs to fixed tables? Perhaps the tables should have line numbers in columns 73-80 as well? The main argument for fixed tables seems to be that they are required for some gateways without DNS access, hence they are always required, so why keep the data in two forms which can get out of synch and cause problems? [Extracting data for periodic table construction via DNS is possible at acceptable cost, modulo some transient inconsistencies, and these transient inconsistencies are the issue.] The main reason that the DNS is better than host tables is that it distributes the control of configuration data; if you lose a host, you can reconfigure your domain around it. The NIC delegates control of about 3000 domains today. The curve points up. The future is with distributed control. Any scheme that distributes control at an acceptable cost isn't atomic; it doesn't matter whether we are looking at X.500, DNS, or mail of update forms to a central table building organization. We should build robust mechanisms and learn to live with this now, rather than retreating. Some lower level comments: I would separate the function of translating between domain names and X.400 addresses from the function of binding a X.400 address to a list of MTAs or gateways. The preference field has proved useful in the Internet; I wouldn't discard it lightly. I would not muck with the DNS view of wildcards or add the level counting function to nameservers; the same function can be implemented using the existing system. One way to deal with the issue of component order is to just create a new syntax, using say "/" as a separator. Thus A.B would be just another way of saying B/A. The argument that says "MX shows that you cannot construct tables from the DNS" is not strictly correct. There were two things that happened: some hosts were listed in the DNS and not in HOSTS.TXT, and we added new functionality in MX. For the purposes of host name to address conversion, anyone could (or can) build scripts to make up a table of hosts, given the host names. The real problem is that we added new functionality which could not be expressed in HOSTS.TXT. Similarly, we could repeat the same backward compatibility problem here, but only if we add new bells an whistles. paul
Stef@NRTC.NORTHROP.COM (Einar Stefferud) (07/27/90)
Paul and Jon (One Msg to reply to you both) -- We have to recognize that we cannot build a system that requires full network connectivity for every gateway, cause we know full well that there will always be some significant set of hosts that will not have full network connectivity, hence we must provide for ways to provide the appropriate tables for the non-fully-network-connected hosts. Full Stop! Now that we have settled that point, what can or should we do to live with reality and keep our sanity too? One thing is to invent a table form of the information in the DNS that will carry its functionality (remember the MX problem that cannot be represented in HOSTS.TXT because HOSTS.TXT is not extensible). What is the problem with defining a table representation that has record types, ala DNS, so we can have one-for-one representation of the same information, and be as extensible in the tables as in the DNS? And, another thing to do is define a mapping of DNS information in an appropriate X.500 schema, which must likewise be just as extensible and facilitate one-for-one mapping of the same information in X.500 forms. Now, having said these relatively simple things, what am I missing here? What is wrong with my picture? (Aside from the fact that a little work must be done?) Best...\Stef;-)
Eppenberger@verw.switch.ch ("Urs Eppenberger") (07/27/90)
Dear --jon. the use of RFC822 is not restriced to the Internet, there are SMTP networks without connection to Internet and they also need to have gateways between RFC822 and X.400. Urs.
poole@chx400.switch.ch (Simon Poole) (07/27/90)
In article <9007270026.AA16028@bel.isi.edu> postel@VENERA.ISI.EDU writes: ..... >Say, i think something has gone off the track here. I thought that RFC-987 >was for mapping between the Internet mail protocol as defined in RFCs 821 >and 822, and the X.400 mail system. If that is the case then wouldn't any >gateway that did RFC-987 be between the Internet and some part of the X.400 >world? That is, won't any gateway that needs to do the RFC-987 mappings have >one foot in the Internet, and therefore have access to the DNS? No. Two reasons: a) Internet <-> X.400 mail system <-> local RFC822 mail system (without DNS connectivity) is reasonably common (matter of fact the swiss universities were and are in exactly this situation). b) RFC822 addresses (and running them thru a RFC987 gateway) are the defacto short hand notation for X.400 addresses (purists will hate me for saying that) at least in our academic environment. -- ------------------------------------------------------------------------ Simon Poole poole@verw.switch.ch / poole@chx400.switch.ch / mcsun!chx400!poole ------------------------------------------------------------------------
piet@cwi.nl (Piet Beertema) (07/27/90)
I thought that RFC-987 was for mapping between the Internet mail protocol as defined in RFCs 821 and 822, and the X.400 mail system. Correct. If that is the case then wouldn't any gateway that did RFC-987 be between the Internet and some part of the X.400 world? Definitely not: mapping between a protocol and some other world does not necessarily imply gatewaying between one particular network and some other world, even when that network happens to be the originator and largest user of that particular protocol. That is, won't any gateway that needs to do the RFC-987 mappings have one foot in the Internet, and therefore have access to the DNS? No. Gateways following RFC-987 may well operate between parts of the X.400 world and networks that are using the "Internet mail protocol as defined...." but that do not necessarily have access to the Internet and thus to the Internet-wide DNS. Piet
postel@VENERA.ISI.EDU (07/28/90)
Stef,Piet: I am sorry, but i really don't get it yet. Could some one tell me about these networks that use RFC-822 and are not part of the Internet, and don't have access to the DNS? I could imagine such a situation, but i don't know of any actually existing. I really don't understand at all what Stef is getting at by "we cannot build a system that requires full network connectivity for every gateway". It seems crazy to me to imagine that we can have a gateways that are not connected to the network. And if "there will always be some significant set of hosts that will not have full network connectivity", lets be sure not to use them as gateways, and lets be sure that while we provide for them we do not limit the connected hosts to the lowest common denominator of mechanisms and procedures. --jon.
hagens@CS.WISC.EDU (07/28/90)
> > > I really don't understand at all what Stef is getting at by "we cannot > build a system that requires full network connectivity for every gateway". > It seems crazy to me to imagine that we can have a gateways that are not > connected to the network. Jon, I also found this hard to accept at first. But may I suggest the following scenario: There may be RFC 822 users on a "small internet" somewhere in the world, whose only email path into the Internet we know is via an X.400 mail system. In this scenerio, the isolated RFC 822 users would require an RFC 987/... gateway to operate, but that gateway would not have DNS access. I really can't say how contrived this scenerio truly is. > And if "there will always be some significant > set of hosts that will not have full network connectivity", lets be sure > not to use them as gateways, and lets be sure that while we provide for > them we do not limit the connected hosts to the lowest common denominator > of mechanisms and procedures. I agree with your last sentence; I believe that the DNS can greatly assist the 987 gateways that are connected to it. It seems that this benefit outweighs the hassel of producing a "hosts.txt" on a periodic basis for those non-connected sites. This *will* be a discussion item for the IETF-OSI-OR WG at the Vancouver IETF. (Thursday AM). Rob
Makey@Logicon.COM (Jeff Makey) (07/28/90)
In article <1990Jul27.145802.19330@chx400.switch.ch> poole@chx400.switch.ch (Simon Poole) writes: >Internet <-> X.400 mail system <-> local RFC822 mail system > (without DNS connectivity) I have recently been thinking about a similar problem, which I suspect is much more common: Internet <-> UUCP mail system <-> isolated internet This problem is somewhat easier than the X.400 version because UUCP uses RFC 822, but the isolated internet still has no direct access to the Internet DNS (although it might run an isolated DNS for its local domain). The solution to both problems is conceptually simple: provide a protocol that allows non-Internet sites to indirectly query the Internet DNS. Discussion thus far has concerned a proposed implementation of such a protocol in which the entire Internet DNS would be transmitted to the isolated network on a periodic basis. Some other ideas I haven't seen are: 1) Regularly transmit different portions of the Internet DNS to the isolated network on a rotating schedule. This is comparable to periodic transmission of the entire DNS, but spreads the transmission load more evenly over time. The model for this is the use of USENET's comp.mail.maps newsgroup to distribute the UUCP Map. 2) Transmit changes in the Internet DNS database to the isolated network as they occur. Combined with the ability for new isolated networks to fetch the entire DNS, this seems to be a more efficient method than the above. Perhaps one of the biggest problems with all of these ideas so far is that there will be a copy of the *entire* Internet DNS per isolated network, plus a copy maintained at each Internet site that provides the DNS to an isolated network. I realize that gigabyte storage is pretty cheap these days, but who wants to do backups of all that data? 3) Probably the best long-term solution -- particularly for resource-poor isolated sites -- would be a query/response protocol that allows an isolated resolver to obtain DNS information on an as-needed basis over the intermediate non-internet network. Something analogous to UDP/X.400 (or UDP/UUCP when appropriate) would do the trick. The performance of the intermediate network would affect latency, but that's why timeout values are configurable. The nifty side effect of this approach is that the protocol would be symmetrical, which means that Internet sites would able to query the isolated DNS, giving the the effect of the single global DNS envisioned in RFC 1034. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: All opinions are strictly those of the author. Internet: Makey@Logicon.COM UUCP: {nosc,ucsd}!logicon.com!Makey
he@idt.unit.no (Haavard Eidnes) (07/28/90)
There's one thing I've wanted to bring up for a while, which is becoming more relevant as this discussion surfaced. The issue is with the RFC987 mapping tables, and with the inability to distinguish between "wildcard" mappings for a domain name and mapping only for the domain name itself. Stated in DNS RR terms, it seems that the mapping tables has no way to distinguish between the two following RR entries: $origin some.domain.no. @ WHATEVER TO-X400 something * WHATEVER TO-X400 something-else Instead, it would seem that an entry like the first automatically would be interpreted as a wildcard specification expressed by the second. The corresponding RFC 987 mapping table (domain->X.400) would only contain a single entry, covering the mapping expressed by *both* of the above RR's: some.domain.no#something# This deficiency is inconvenient for several reasons. First, it runs a bit counter to the use of wildcard matching in the DNS. Second, it increases the size of the RFC 987 mapping tables in specific cases, illustrated by the following example: Say that you wished to use the address some.domain.no as the domain name of a X.400 mail system, and host.some.domain.no as domain names for your SMTP-speaking hosts. Furthermore, you wish to use a different X.400 mapping for your SMTP-speaking hosts than for the X.400-speaking hosts. If you do this, the above mentioned deficiency forces you to register all RFC822/SMTP-speaking hosts with their own TO-X400 mapping! This is obviously not desirable if you start conversion to X.400 (without throwing out all SMTP/RFC822 mail systems all at once) and want to use a "natural" addresses for your (central?) X.400 service. This should perhaps be amended, at least before we start storing the data in the DNS? (Not that it's not a problem for the table based approach...) I checked (quickly) with the RFCs 1026 and 1148 (all concerned with mapping between X.400 and RFC 822), and they seem to have the same problem. I should perhaps mention that my exposure to this problem is only second-hand, and I have yet to fully grasp all of RFC 987 and its companions, so please excuse any inaccuracies or wrong terminology above. Regards, Havard Eidnes, Postmaster &c @idt.unit.no, Uninett employee, ... Division of Computer Systems and Telematics, Norwegian Institute of Technology
Makey@Logicon.COM (Jeff Makey) (07/31/90)
In article <9007271704.AA19586@bel.isi.edu> postel@VENERA.ISI.EDU writes: >Could some one tell me about >these networks that use RFC-822 and are not part of the Internet, and don't >have access to the DNS? Just for example, there are hundreds -- if not thousands -- of LANs with Sun workstations on them that are connected to the Internet only via UUCP, or not at all. These LANs all use RFC822/SMTP/TCP/IP for exchanging mail among their hosts. Most of these LANs have virtually no support for the DNS, but instead use Sun's NIS (nee Yellow Pages) to distribute host information. :: Jeff Makey Department of Tautological Pleonasms and Superfluous Redundancies Department Disclaimer: All opinions are strictly those of the author. Internet: Makey@Logicon.COM UUCP: {nosc,ucsd}!logicon.com!Makey
rick@UUNET.UU.NET (Rick Adams) (07/31/90)
There are even networks that use RFC822 *AND* SMTP *AND* DNS that are not connected to the internet (they are blocked for "political" reasons at the gateways. "Political" could be as simple as not meeting the aceptable use policies of NSF). Requiring connected status for domains listed in the root servers makes no sense and cuases a fair amount of problems. (Sure require the nameservers to have conmnected status, but there's nothing gained by requiring the addresses they serve to be connected) The current policies on what gets into a root server etc needs to be reworked in a major way --rick
vcerf@NRI.RESTON.VA.US (08/04/90)
The scenario is real. I have learned that a number of private TCP/IP local area networks use RFC822 email but then need to get out via X.400 public services to the commercial email worls. These nets at NOT on the Internet! Vint
pcg@cs.aber.ac.uk (Piercarlo Grandi) (08/05/90)
"postel" == postel writes:
postel> I am sorry, but i really don't get it yet. Could some one tell me about
postel> these networks that use RFC-822 and are not part of the Internet, and don't
postel> have access to the DNS? I could imagine such a situation, but i don't
postel> know of any actually existing.
Essentially any site running any version of BSD Unix or other academic
Unix version has a local RFC-822 compliant network. They can well be
isolated from the Internet. Essentially all the academic CS networks in
the United Kingdom are in this position; they run locally DARPA/NSF
Internet style (usually multiple) networks, but they are connected by an
OSI/ISO/X.25 WAN (Janet).
This is also true for many sites outside the USA; most software
delivered with Unix machines is by default RFC-compliant, but getting a
connection to the Internet, or even just get pointed to by the DNS may
be not easy.
I understand that there are some company networks in the USA that are
RFC compliant but are not connected or visible to the DARPA/NSF
Internet, either because they do not care, or for obsessive security
reasons.
There will be many funny happenings in Europe and the United Kingdom in
particular as more and more sites get connected to the DARPA/NSF
Internet...
--
Piercarlo "Peter" Grandi | ARPA: pcg%cs.aber.ac.uk@nsfnet-relay.ac.uk
Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg
Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.ukfitz@wang.com (Tom Fitzgerald) (08/07/90)
pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: > I understand that there are some company networks in the USA that are > RFC compliant but are not connected or visible to the DARPA/NSF > Internet, either because they do not care, or for obsessive security > reasons. For us it's lack of money. It would cost us $29K/year in fees, plus leased line costs, to get onto NEARnet. Since there are only a few groups here in Wang that want Internet connectivity, the per-user cost would be too high. Maybe in a couple of years... --- Tom Fitzgerald Wang Labs fitz@wang.com 1-508-967-5278 Lowell MA, USA ...!uunet!wang!fitz
davecb@yunexus.YorkU.CA (David Collier-Brown) (08/08/90)
pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: I understand that there are some company networks in the USA that are RFC compliant but are not connected or visible to the DARPA/NSF Internet, either because they do not care, or for obsessive security reasons. fitz@wang.com (Tom Fitzgerald) writes: | For us it's lack of money. Well, I used to administer one of those disjoint subnets, and DNS service was a mere nicety. If I seriously wished to do mail with the rest of the world, I could do so... but had little need to. It should be noted that, while common, most of these disjoint subnets don't have a need for DNS service, because they communicate via ``traditional'' methods. Ie, their users write down addresses, keep phonebooks, use uucp pathalias, etc. If they communicate at all (:-)). If I was faced with making one such subnet communicate, I'd do so by indirection [Note: I'm faced with making four such subnets communicate in the coming academic year!]. Given a local DNS, I'd teach it the Internet way of contacting the intermediary (x25 gateway, trusted workstation, tape drive, etc). I'd teach the intermediary the rest. This requires a mailer that will will wait for arbitrarily long times for the DNS to get ``primed'' with the information it needs to construct a valid address, and could absolutely roadblock an ill-advised user agent that tried to use DNS queries to help its user (:-)). Fortunatly, I have such a mailer(MTA) and a non-helpfull user agent. Alas, I don't see the relevance of RFC 987 mappings to this problem. If I was gatewaying into another world and not just using it as transport... Has this discussion drifted? --dave (progress reports will be posted/mailed if desired) c-b -- David Collier-Brown, | davecb@Nexus.YorkU.CA, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave Willowdale, Ontario, | "And the next 8 man-months came up like CANADA. 416-223-8968 | thunder across the bay" --david kipling