July 1992 - dns-wg - mailman.ripe.net

Re: Suggestion from Piet Beertema
by Arnold Nipper 23 Jul '92

23 Jul '92

> As far as I remember there is a "*di" - tag for domain name > entries listing IP adresses used in this domain. Hence no > usual "nslookup"! >A "*di" tag may ever have been proposed, but I don't >see it in any of the RIPE templates. Just have a look at document "ripe-w02" chapter 2.1 (RIPE Databases; R.Blokzijl <k13(a)nikhef.nl>; 28 August, 1990) Arnold

3 5

Re: Suggestion from Piet Beertema
by root＠estec.esa.nl 22 Jul '92

22 Jul '92

thank you the only OSF offices that i know of are in Munich, the US and Japan regards

2 1

Re: Suggestion from Piet Beertema
by Arnold Nipper 22 Jul '92

22 Jul '92

> Suppose "nslookup" does domain name to adress translation, > "net" does IP adress to IP net translation and finally > "connect" gives the connect information about IP networks What I was thinking of was the "*n[io]" - tag already used. (e.g: *ni: 1=701 2=1800 3=1238 ) > (This information already is in the RIPE DB), then > connect ( net ( nslookup ( domain name ) ) ) > does what you want. >No, it doesn't. The connect field gives the connectivity >a given network has, partly in "real" connectivity (e.g. >"EU"), partly in "pseudo" connectivity ("RIPE"), but it >doesn't state which the network service providers are nor >nor the order in which these are service providers. And >the latter is extremely important for determining policy >based routing. The least that should be done to treat the >connect field as routing source is to list the mnemonics >that stand for the real service providers in order of >routing preference (for the associated network of course). >However, I don't like this "solution" at all, given the >mix of "real" and "pseudo" connectivity in the connect >field. Besides, a new field could be based an AS numbers >in order of preference, much like the NSFnet policy routing >database does now, making life infinitely easier. > >Furthermore I would consider building potentially large >access or other lists for a router in the suggested way, >through massive DNS queries, a crime... As far as I remember there is a "*di" - tag for domain name entries listing IP adresses used in this domain. Hence no usual "nslookup"! > > Don't overload the DB with information (Current size: 7315558 Byte. > We started with some hundred KB). >It will keep on growing anyway, especially when the RIPE, >NIC and Merit databases get synchronized. Database size >should not be used as an argument to keep out *useful* Don't misunderstand me!! I don't want to keep out *useful* information. I just want to minimize and streamline the DB. Keep the DB as small as possible and join the information on your local machine (NO DNS lookups!). >and authoritative information. > > > Piet Arnold

2 1

Suggestion from Piet Beertema
by Daniel Karrenberg 22 Jul '92

22 Jul '92

------- Forwarded Message Date: Tue, 21 Jul 1992 11:45:04 +0200 From: Piet.Beertema(a)mcsun.EU.net Sender: piet(a)mcsun.EU.net To: ncc(a)ripe.net Subject: Suggestion Add a "connect" field to domain entries, showing the service provider(s) for a particular domain; alternatively set up a new field for it, although I can't think of an appropriate name for it right away. This feature would be valuable, as it would provide sites all over Europe with the possibility to exert access control on domain names, using the RIPE whois database as authoritative source (like it is used already for e.g. router access lists). Piet ------- End of Forwarded Message

2 1

Re: Suggestion from Piet Beertema
by Arnold Nipper 22 Jul '92

22 Jul '92

>Subject: Suggestion from Piet Beertema >From: Daniel Karrenberg <Daniel.Karrenberg(a)ripe.net> >Date: Wed, 22 Jul 92 13:52:14 +0200 >Sender: Daniel.Karrenberg(a)ripe.net > >------- Forwarded Message > >Date: Tue, 21 Jul 1992 11:45:04 +0200 >From: Piet.Beertema(a)mcsun.EU.net >Sender: piet(a)mcsun.EU.net >To: ncc(a)ripe.net >Subject: Suggestion > >Add a "connect" field to domain entries, showing the service >provider(s) for a particular domain; alternatively set up a >new field for it, although I can't think of an appropriate >name for it right away. >This feature would be valuable, as it would provide sites all >over Europe with the possibility to exert access control on >domain names, using the RIPE whois database as authoritative >source (like it is used already for e.g. router access lists). > > > Piet > >------- End of Forwarded Message Suppose "nslookup" does domain name to adress translation, "net" does IP adress to IP net translation and finally "connect" gives the connect information about IP networks (This information already is in the RIPE DB), then connect ( net ( nslookup ( domain name ) ) ) does what you want. What I want to say is: a domain name ( when used acessing a site ) can be mapped onto an IP address. Don't overload the DB with information (Current size: 7315558 Byte. We started with some hundred KB). Arnold

2 1

Re: Domains in the RIPE database
by rafal＠cocos.fuw.edu.pl 06 Jul '92

06 Jul '92

Yes, in my opinion this information is spurious while causing unnecesary work for the NCC sfaff. As such the domain registration should be discontinued. Rafal

1 0

Domains in the RIPE database
by Daniel Karrenberg 06 Jul '92

06 Jul '92

While I am busy asking difficult questions :-). Recent statistics show that the number of domain entries in the RIPE database is increasing at a sub-linear rate. I infer from this that by far not all European domains are represented by domain objects in the database. At the same time RFC1183 defines a method of incorporating contact information for zones into the DNS itself. Doesn't this invalidate the rationale for keeping information about domains in the database? Should we discontinue the domain object in the database? Daniel

2 1

NCC to provide secondary name service for Top Level Domains?
by Daniel Karrenberg 06 Jul '92

06 Jul '92

Thomaz Kalin has raised the question with me whether the NCC should provide secondary domain service for top level domains with servers located in Europe and (by arrangement) on other continents. Should this be added to the NCC activity plan? So far my personal experience has been that all top level domain administrators have been able to make satisfactory arrangements for this service. Daniel

2 1

Re: Problems sending to Master400.it
by Havard.Eidnes＠runit.sintef.no 03 Jul '92

03 Jul '92

> I (one of the manager of the EUnet-FR backbone machine: corton.inria.fr) > would have been deeply flattered by Master400.it selecting us as their > relay between SMTP and X.400 world (likely based on the excellence > of our service). This choice would of course have led to some kind of > 'contract', or at least minimum initial agreement; which we often > accept in the context of EUnet to help connectivity. > > Unfortunatly, no such agreement exist, nor any initial agreement have > ever been made between Master400 and EUnet-FR; agreement which would > have allowed us to set up the proper dedicated routes directing to Master400 > once the mail is caught by the MX on corton. I really should have guessed that. It's of course difficult for you to set up something you haven't been asked about and where no agreement exists. My apologies for indicating that this was a problem of yours. However, I think that some of the people receiving your message (and this) will feel a responsibility to contact the people administrating the x.400 service in Master400, Italy, to get the proper agreements in place, have the SMTP/ x.400 gateway configured accordingly and to complete the associated DNS registrations. Isn't it natural that the people behind domain(a)nis.garr.it take this ball? Regards, Havard

1 0

Re: Problems sending to Master400.it
by Yves Devillers 02 Jul '92

02 Jul '92

In your previous mail you wrote: Hi, my PP mail MTA just received a message via x.400 originating in the x.400 ADMD Master400 in Italy. The sending user had requested a positive delivery report for the message. Unfortunately, my PP MTA was not configured to route the DR back via x.400, so it tried to use SMTP instead. Your system, corton.inria.fr is the preferred mail exchanger for the Master400.it domain and its subdomains. Sending back the DR via SMTP is not really a problem for my system (although it leads to loss of functionality of the sender of the original message), but unfortunately this failed. After looking into this a little further, it appears that it is corton.inria.fr which is the problem. My PP MTA said: > Your message was not delivered to > VINCENZO.COZZOLINO(a)ENEL.ENELUTI.Master400.it > for the following reason: > Unknown Address > MTA 'ENEL.ENELUTI.Master400.it' gives error message > <VINCENZO.COZZOLINO(a)ENEL.ENELUTI.Master400.it>... hostname < > ENEL . ENELUTI . Master400 . it > unknown to name-server This was verified this way: % mconnect corton.inria.fr connecting to host corton.inria.fr (192.93.2.5), port 25 connection open 220 corton.inria.fr The EUnet gateway to France - Thu, 2 Jul 1992 13:44:06 + 0200 - (Sendmail+IDA+ 5.65c8d/92.02.29) vrfy vincenzo.cozzolino(a)enel.eneluti.master400.it 554 vincenzo.cozzolino(a)enel.eneluti.master400.it... hostname < enel . enelut i . master400 . it > unknown to name-server quit 221 corton.inria.fr closing connection % Which name-server is corton talking about? The master400.it domain has (as far as I can see) been properly registered in the DNS with both a "direct" MX and a wildcard MX for *.master400.it. The parties wanting to communicate would probably appreciate it if this problem could be fixed. If you could report back to me, I will notify the two parties wanting to communicate. Thanks. - Havard, (one of) postmaster(a)runit.sintef.no --> Havard, I (one of the manager of the EUnet-FR backbone machine: corton.inria.fr) would have been deeply flattered by Master400.it selecting us as their relay between SMTP and X.400 world (likely based on the excellence of our service). This choice would of course have led to some kind of 'contract', or at least minimum initial agreement; which we often accept in the context of EUnet to help connectivity. Unfortunatly, no such agreement exist, nor any initial agreement have ever been made between Master400 and EUnet-FR; agreement which would have allowed us to set up the proper dedicated routes directing to Master400 once the mail is caught by the MX on corton. You will certainly understand that it's quite hard for us to set up a special route (eg: non MX driven) for an entity we have never known of before. I suspect that this MX has been set by persons not understanding the full details and subtleties of MX, a well used tehcnique in the IP world. May I suggest those people read the excellent paper Piet Beertema once wrote in the context of RIPE DNS WG, as stored in ~ftp/ripe/doc/lpr/DNS-advice.txt on machine mcsun.eu.net Please note that this paper has been approved as a RIPE recommendation. It contains a good description of this "MX records surprise" (quoting Piet's paper): In a sense similar to point 3. Sometimes nameserver managers enter MX records in their zone files that point to external hosts, without first asking or even informing the systems managers of those external hosts. This has to be fought out between the nameserver manager and the systems managers involved. Only as a last resort, if really nothing helps to get the offending records removed, can the systems manager turn to the naming authority of the domain above the offending domain to get the problem sorted out. Here is what DNS query yield on corton: > Master400.it Server: corton.inria.fr Address: 192.93.2.5 Master400.it preference = 10, mail exchanger = corton.inria.fr Master400.it preference = 20, mail exchanger = infngw.infn.it Master400.it preference = 30, mail exchanger = cosine-gw.infn.it corton.inria.fr internet address = 192.93.2.5 infngw.infn.it internet address = 131.154.1.1 cosine-gw.infn.it internet address = 140.105.6.99 Another query for zone trasnfert for IT, as stored on NIS.GARR.IT shows the following setting up: master400 MX 10 corton.inria.fr master400 MX 20 infngw.infn.it master400 MX 30 cosine-gw.infn.it *.master400 MX 10 corton.inria.fr *.master400 MX 20 infngw.infn.it *.master400 MX 30 cosine-gw.infn.it And also: y-net MX 10 corton.inria.fr y-net MX 20 infngw.infn.it y-net MX 30 cosine-gw.infn.it *.y-net MX 10 corton.inria.fr *.y-net MX 20 infngw.infn.it *.y-net MX 30 cosine-gw.infn.it The latter one direct mail for *y-net.it to the gateway to ynet-gw, which happens to be chenas.inria.fr rather than corton.inria.fr The recommendation by YMU (Ynet management unit) are that an MX should point to chenas.inria.fr, and only to it. This later point has to be dealt with directly with Teleo in Bruxelles. Cordialement, Yves ---------------------------------------------------------------- Yves Devillers Internet: Yves.Devillers(a)inria.fr Institut National de Recherche Goodie-Oldie: ...!uunet!inria!devill en Informatique et Automatique Phone: +33 1 39 63 55 96 INRIA, Centre de Rocquencourt Fax: +33 1 39 63 53 30 BP 105, 78153 Le Chesnay CEDEX Twx: 633 097 F France.

1 0