- db-wg - mailman.ripe.net

FYI: 193.in-addr.arpa delegation
by Marten Terpstra 17 Mar '93

17 Mar '93

Folks, the delegation of 193.in-addr.arpa is a fact. % host -vt any 193.in-addr.arpa 193.in-addr.arpa 518400 IN SOA ns.ripe.net hostmaster.ripe.net ( 100010 ;serial (version) 28800 ;refresh period 7200 ;retry refresh time 604800 ;expiration period 518400 ;default ttl ) 193.in-addr.arpa 518400 IN NS ns.ripe.net 193.in-addr.arpa 518400 IN NS ns.eu.net 193.in-addr.arpa 518400 IN NS ns.uu.net 193.in-addr.arpa 518400 IN NS layon.inria.fr 193.in-addr.arpa 518400 IN NS sunic.sunet.se 193.in-addr.arpa 518400 IN NS munnari.oz.au -Marten ------- Forwarded Message Date: Tue, 16 Mar 93 20:06:13 PST From: bobm(a)nic.ddn.mil (Bob McCollum ) To: Marten.Terpstra(a)ripe.net (Marten Terpstra) cc: markk(a)nic.ddn.mil (Mark Kosters), scottw(a)nic.ddn.mil (Scott Williamso n) Subject: Re: 193.in-addr.arpa updated at the NCC > Ready to go ! > > -Marten Marten, The release has gone out. Everything looked ok from our end. We have made internet history. ;^) Please let us know if you see anything unusual! Thanks! Bob Mc ------- End of Forwarded Message

1 0

Autonomous Systems Available via RIPE WHOIS
by Daniel Karrenberg 12 Mar '93

12 Mar '93

Autonomous System (AS) information is now available from the RIPE whois server. The server will accept queries for AS<number>. Very basic information about most existing ASes from the NIC and other sources has been entered with a source attribute of INTERNIC and will only be found if the -a flag is passed to the whois server. This information is also available as file from ftp.ripe.net in file ripe/dbase/asn.db.Z. In order to get things going some instances of the new RIPE AS object have also been entered already. For example whois as786 will produce aut-num: AS786 descr: The JANET IP Service descr: UK as-in: AS60 50 AS60 as-in: AS766 100 AS766 as-in: AS1263 45 DEFAULT as-in: AS1275 100 AS1275 as-in: AS1290 50 AS1290 as-in: AS1755 102 RIPE-DB AND NOT (LOCAL AS786) as-in: AS1849 50 AS1849 as-in: AS1930 100 AS1930 as-in: AS2107 100 AS2107 as-in: AS2111 100 AS2111 as-out: AS60 AS786 AS766 as-out: AS766 AS786 AS1755 as-out: AS1263 AS786 AS766 AS1930 AS2107 AS2111 as-out: AS1275 AS786 AS1755 as-out: AS1290 AS786 as-out: AS1755 AS786 AS766 AS1275 AS1930 AS2107 AS2111 as-out: AS1849 AS786 AS1755 as-out: AS1930 AS786 AS1755 as-out: AS2107 AS786 AS1755 as-out: AS2111 AS786 AS1755 default: AS1263 1 guardian: jips-nosc(a)noc.ulcc.ac.uk admin-c: Duncan Rogerson admin-c: Kevin Hoadley tech-c: Duncan Rogerson tech-c: Kevin Hoadley remarks: AS2111 link is not yet active, coming soon. changed: D.Rogerson(a)nosc.ja.net 930226 source: RIPE A description of the AS object can be found in appendix A of document ripe-81. We also accept updates and additions of AS objects in the RIPE database at <ripe-dbm(a)ripe.net>. We urge everyone to send in AS objects a.s.a.p.. They do not necessarily need to include the routing policy information (as-in, as-out, default and guardian). If you want to jump in at the deep end you could read ripe-81 and generate the routing policy as well. We will be happy to help you with this. However don't put off sending in the basic information because of this. There is a real benefit in this being available too. Further plans: The NCC will generate AS objects for all ASes being used in the European Internet and not present in the database during the next week and send them to the suspected contact persons for validation. Shortly after these are installed, a new update procedure for the aut-sys tag of network objects will be anabled. This procedure is described in ripe-81. Basically it means that aut-sys tags will be generated from information supplied by the AS guardians. Initially the NCC will be guardian for all ASes which do not have a guardian yet and process change requests manually. Please do not hesitate to contact us if you have any questions about this. The NCC Staff PS: A new ripe document containing all database templates and update procedures is being prepared and will be released shortly.

2 1

in-addr.arpa zone data in RIPE database
by Daniel Karrenberg 03 Mar '93

03 Mar '93

Folks, since we have observed many inconsistencies between the RIPE database and the DNS regarding reverse mapping zones in in-addr.arpa we have developed a little checking script. The current output can be found in ftp.ripe.net:ripe/ripe-op/in-addr.check It lists all networks for which discrepancies have been detected as follows: First the RIPE database entry in short format: *in: 128.131.0.0 *na: TUNET-F *de: LAN Technical University of Vienna *cy: AT *ac: Johannes Demel *tc: Johannes Demel *co: LOCAL *as: 697 *rz: tunamea.tuwien.ac.at tunameb.tuwien.ac.at *ch: demel(a)noc.tuwien.ac.at 930202 *so: RIPE Then a list of all reverse servers as listed in the database: DB servers: tunamea.tuwien.ac.at tunameb.tuwien.ac.at Then a list of all reverse servers found in the DNS: DNS servers: Then a diagnostic each server which has something wrong: tunamea.tuwien.ac.at: only in DB and not reverse server for 128.131.0.0! tunameb.tuwien.ac.at: only in DB and not reverse server for 128.131.0.0! Then a list of suggested actions to resolve the inconsistency: DB remove 128.131.0.0: tunamea.tuwien.ac.at tunameb.tuwien.ac.at Note that the recommended actions are not the only way to resolve the problem. In the example above one could also set up the name servers and register them in the DNS. The script tries the shortes path. Please go through the list and see wether any of your nets needs action. Questions: Should we automatically make the suggested changes in the RIPE database? Or should we send mail to the technical contacts asking them to change things? We have asked the NIC accept change notices from us, so that registration of reverse servers in the database would be enough to get them into the DNS. Is this desirable? Daniel By way of example here is the start of the current file: *in: 128.131.0.0 *na: TUNET-F *de: LAN Technical University of Vienna *cy: AT *ac: Johannes Demel *tc: Johannes Demel *co: LOCAL *as: 697 *rz: tunamea.tuwien.ac.at tunameb.tuwien.ac.at *ch: demel(a)noc.tuwien.ac.at 930202 *so: RIPE DB servers: tunamea.tuwien.ac.at tunameb.tuwien.ac.at DNS servers: tunamea.tuwien.ac.at: is only in DB and is not reverse server for 128.131.0.0! tunameb.tuwien.ac.at: is only in DB and is not reverse server for 128.131.0.0! DB remove 128.131.0.0: tunamea.tuwien.ac.at tunameb.tuwien.ac.at *in: 129.177.0.0 *na: BERGEN-NET *de: Bergen University, Norway *cy: NO *ac: Kenneth Hostland *tc: Kenneth Hostland *co: NORDU RIPE NSF *as: 224 *gw: kth *rz: alf.uib.no eik.ii.uib.no aun.uninet.no *ch: ripe-dbm(a)ripe.net 920914 *so: RIPE DB servers: alf.uib.no aun.uninet.no eik.ii.uib.no DNS servers: alf.uib.no aun.uninett.no eik.ii.uib.no aun.uninet.no: is only in DB and does not exist! aun.uninett.no: is only in DNS and is OK DB add 129.177.0.0: aun.uninett.no DB remove 129.177.0.0: aun.uninet.no note: obiously a spelling error in the database *in: 129.206.0.0 *na: HD-NET *de: University of Heidelberg *de: BelWue *cy: DE *ac: Michael Hebgen *tc: Lothar Binding *tc: Peter Merdian *co: RIPE NSF WIN *rl: HEPNET *bl: DESY *as: 553 *gw: crn *rz: sun0.URZ.Uni-Heidelberg.DE sun1.URZ.Uni-Heidelberg.DE noc.BelWue.DE ns.Germany.EU.net deins.Informatik.Uni-Dortmund.DE *ch: rv(a)Informatik.Uni-Dortmund.DE 920530 *ch: ar(a)deins.Informatik.Uni-Dortmund.DE 920601 *ch: ripe-dbm(a)ripe.net 920602 *so: RIPE DB servers: deins.informatik.uni-dortmund.de noc.belwue.de ns.germany.eu.net sun0.urz.uni-heidelberg.de sun1.urz.uni-heidelberg.de DNS servers: sun0.urz.uni-heidelberg.de sun1.urz.uni-heidelberg.de deins.informatik.uni-dortmund.de: is only in DB and is OK noc.belwue.de: is only in DB and is OK ns.germany.eu.net: is only in DB and is OK DNS add 129.206.0.0: deins.informatik.uni-dortmund.de noc.belwue.de ns.germany.eu.net note: the DNS is missing some servers *in: 130.37.0.0 *na: VU-NET *de: Vrije Universiteit Amsterdam *de: Amsterdam *cy: NL *ac: Jacques Schuurman *tc: Jacques Schuurman *co: RIPE NSF SARA SURF *gw: cwi *rz: ohrid.cca.vu.nl *rz: star.cs.vu.nl *ch: dfk(a)cwi.nl 900802 *ch: Erik-Jan.Bos(a)surfnet.nl 920708 *ch: Erik-Jan.Bos(a)surfnet.nl 920708 *ch: ripe-dbm(a)ripe.net 920708 *ch: martijn(a)nluug.nl 921110 *so: RIPE DB servers: ohrid.cca.vu.nl star.cs.vu.nl DNS servers: hardy.nat.vu.nl ohrid.cca.vu.nl star.cs.vu.nl hardy.nat.vu.nl: is only in DNS and is OK DB add 130.37.0.0: hardy.nat.vu.nl *in: 130.192.0.0 *na: TORINO-IT-LAN *de: Politecnico di Torino *de: CISIP *cy: IT *ac: Silvano Gai *tc: Antonio Lioy *co: GARR *as: 137 *rz: 130.192.2.91 leonardo.polito.it *rz: 130.192.2.117 galileo.polito.it *rz: 130.192.3.1 ercole.polito.it *rz: 192.12.192.5 dns.nis.garr.it *rm: LAN's and MAN connecting University departments and *rm: research institutes located in or near Torino *rm: fully managed *ch: ip-reg(a)nis.garr.it 930115 *so: RIPE DB servers: dns.nis.garr.it ercole.polito.it galileo.polito.it jolly.nis.garr.it leonardo.polito.it DNS servers: dns.nis.garr.it ercole.polito.it galileo.polito.it leonardo.polito.it jolly.nis.garr.it: is only in DB and is OK DNS add 130.192.0.0: jolly.nis.garr.it note: the addresses in the database are not conforming to the database format, but the script resolves them and deletes duplicate entries *in: 130.231.0.0 *na: OUNET *de: University Ethernet network *de: Oulu University *de: Oulu *cy: FI *ac: Kaisu Ranta *tc: Raimo Salo *co: NORDU RIPE NSF FUNET *as: 1741 *rz: ousrvr.oulu.fi *ch: lk-kr(a)finou.oulu.fi 930119 *so: RIPE DB servers: ousrvr.oulu.fi DNS servers: hydra.helsinki.fi ousrvr.oulu.fi hydra.helsinki.fi: is only in DNS and is OK DB add 130.231.0.0: hydra.helsinki.fi *in: 130.251.0.0 *na: GENUANET *de: Universita' degli Studi di Genova *cy: IT *ac: Pier Paolo Puliafito *tc: Tiziana Podesta' *co: GARR *as: 137 *rz: 192.148.193.8 sun.cisi.unige.it SUN UNIX *rz: 130.251.1.4 dist.dist.unige.it SUN UNIX *rm: Multiple interconnected LANs of academic institutes *rm: located in Genoa *ch: ip-reg(a)nis.garr.it 930210 *so: RIPE DB servers: dist.dist.unige.it sun sun.cisi.unige.it unix DNS servers: carla.dist.unige.it dist.dist.unige.it nameserver.cnr.it carla.dist.unige.it: is only in DNS and is not responding! nameserver.cnr.it: is only in DNS and is OK sun: is only in DB and does not exist! sun.cisi.unige.it: is only in DB and is OK unix: is only in DB and does not exist! DB add 130.251.0.0: nameserver.cnr.it DNS add 130.251.0.0: sun.cisi.unige.it DB remove 130.251.0.0: sun unix note: "interesting" syntax server data seems out of date *in: 131.114.0.0 *na: PISA-NET *de: Consiglio Nazionale delle Ricerche *de: Pisa *cy: IT *ac: Marco Sommani *tc: Vittorio Miori *co: GARR *as: 137 *rz: 192.12.192.4 nameserver.cnr.it *rz: 128.84.254.152 odin.cs.cornell.edu *rz: 131.114.1.32 itgbox.cnuce.cnr.it *rz: 192.65.81.6 ns.surfnet.nl *rz: 131.114.21.10 serra.unipi.it *rm: Multiple-Lan of CNR institutes and University departments in Pisa *rm: This net belongs to the nation-wide CNRnet, coordinated *rm: thru the cnr-core working group. CNRnet is member of GARR. *ch: ip-reg(a)nis.garr.it 930204 *so: RIPE DB servers: itgbox.cnuce.cnr.it nameserver.cnr.it ns.surfnet.nl odin.cs.cornell.edu serra.unipi.it survey.surfnet.nl DNS servers: itgbox.cnuce.cnr.it nameserver.cnr.it ns.surfnet.nl odin.cs.cornell.edu serra.unipi.it survey.surfnet.nl: is only in DB and is OK DNS add 131.114.0.0: survey.surfnet.nl *in: 131.155.0.0 *na: TUENET1 *de: Technische Universiteit Eindhoven *de: Eindhoven *cy: NL *ac: Joop Schillemans *tc: Joep Brand *co: RIPE NSF SURF *ni: 1=590 *rz: tuegate.tue.nl *ch: piet(a)cwi.nl 910501 *so: RIPE DB servers: tuegate.tue.nl DNS servers: rc6.urc.tue.nl tuegate.tue.nl rc6.urc.tue.nl: is only in DNS and is OK DB add 131.155.0.0: rc6.urc.tue.nl *in: 131.174.0.0 *na: NUNET *de: Universiteit Nijmegen *de: Nijmegen *cy: NL *ac: Jos Alsters *ac: Peter van Campen *tc: Jos Alsters *tc: Peter van Campen *co: RIPE NSF SURF *ni: 1=590 *rz: wn1.sci.kun.nl *rz: wn3.sci.kun.nl *ch: piet(a)cwi.nl 910501 *so: RIPE DB servers: wn1.sci.kun.nl wn3.sci.kun.nl DNS servers: wn0.sci.kun.nl wn3.sci.kun.nl wn0.sci.kun.nl: is only in DNS and is OK wn1.sci.kun.nl: is only in DB and does not exist! DB add 131.174.0.0: wn0.sci.kun.nl DB remove 131.174.0.0: wn1.sci.kun.nl *in: 131.211.0.0 *na: RUUNET *de: Universiteit Utrecht *de: Utrecht *cy: NL *ac: Dre Hopmans *tc: Dre Hopmans *co: RIPE NSF SURF *ni: 1=590 *rz: accucx.cc.ruu.nl *rz: praxis.cs.ruu.nl *ch: piet(a)cwi.nl 910501 *so: RIPE DB servers: accucx.cc.ruu.nl praxis.cs.ruu.nl DNS servers: accucx.cc.ruu.nl infix.cs.ruu.nl kali.cc.ruu.nl infix.cs.ruu.nl: is only in DNS and is OK kali.cc.ruu.nl: is only in DNS and is OK praxis.cs.ruu.nl: is only in DB and is not responding! DB add 131.211.0.0: infix.cs.ruu.nl kali.cc.ruu.nl

5 15

Re: in-addr.arpa zone data in RIPE database
by jalm＠spirou.puug.pt 03 Mar '93

03 Mar '93

...... Still, there are the issues of the DNS versus the DB, but I feel that others are already dealing with that one ;-) In the previous discussion concerning DNS and RIPE database coherence, I think that we should try to keep separate different issues (DNS and RIPE dbm). 1) We have a system designed to deal with addressing, naming servers, etc. the DNS. We should concentrate on this system for this purpose. It should be considered the real source of information for the data it as been designed to deal with. So, the place were I can find the information about servers, addresses, etc. is in the DNS. Well, DNS has been designed to be managed in a decentralized way. This is a very good point but it has a very bad point: in general it contains lots of errors and inconsistencies. Conclusion: we should invest in tools to detect such errors and notify the administrators concerned. There are some of these tools available in the archive of RIPE. Anyway, I, as an administrator, would prefer to have a single point of focus for stating which are the servers running authoritative for my domain or for the reverse mapping of my network and that is the DNS, nothing more. 2) We have the RIPE database: this is a very good tool to deal with some administrative data. Well, lets use it for this purpose. Anyway, we should avoid to have to deal manually with DUPLICATE data. So, we should avoid to have information about servers and addresses of those servers in the RIPE dbm. My suggestion is: use the RIPE dbm to deal * only * with those informations that cannot be effectively registered in the DNS. If we decide to maintain in the RIPE dbm information about DNS servers, those fields should be automatically updated from the DNS on a (for example) monthly basis. And its semantics should be seen as "the vison about this subject that the tools of the RIPE NCC have been able to extract from the DNS some XXX days ago". I do not believe on centralized repositories and management unless I have no other way to avoid it. I do not believe in consistency maintained mannually by hundreds (thousands ?) of administrators. Jose'

2 1

Re: in-addr.arpa zone data in RIPE database
by keith＠pipex.net 02 Mar '93

02 Mar '93

In <9303021347.AA06706(a)mcsun.EU.net>, <Piet.Beertema(a)mcsun.EU.net> wrote: > Interaction is fine. But RIPE stepping into someone else's > authority is quite something different! > I don't see any problem with that as long as we (european > networking people) agree to send update to the RIPE-NCC > instead of sending them to the NIC. > RIPE-DB and DNS are entirely different objects. I would > like RIPE to notify me *in some cases* about discrepancies > between my entries in the RIPE-DB and my DNS entries, but > I do *NOT* want RIPE to step into my authority by asking > or telling the NIC to change *MY* DNS info because they > found discrepancies: I may well have good reason why those > discrepancies exist. This is a bit of an aside to the debate above, but there is something that has struck me as obvious which would make the management of in-addr.arpa much easier for everyone, and help with the above issue. Why not get all of 193.in-addr.arpa delegated to the RIPE NCC, and have it in turn delegate xx.193.in-addr.arpa to the service providers ? That way we don't have to deal directly with the creaking NIC, but authority is still delineated clearly by existing DNS mechanisms. This has not been possible in the past, due to the restriction of in-addr DNS delegations needing to be on byte boundaries, *but* that is exactly how the RIPE supernet block is being assigned. Or have I missed a good reason why this won't work ? Keith Mitchell Network Manager Public IP Exchange keith(a)pipex.net 216 The Science Park keith(a)unipalm.co.uk Cambridge, UK Phone: +44 223-424616 Fax: +44 223-426868

3 2

Re: Database Update Acknowledgement Messages
by Daniel Karrenberg 24 Feb '93

24 Feb '93

> Piet.Beertema(a)mcsun.EU.net writes: > > I don't like the idea of *by default* getting all or even > upto 20 (or some other limit) changed objects reported. > However, in some cases I would like to have this feature. > How about making it depend on the presence of the "ACK" > keyword in the Subject: line? OK, this sounds reasonable. I have implemented this using the string LONGACK rather than ACK which might legitimately be in the subject line. If you send us an update with the string LONGACK (in capitals) somewhere in the Subject:-line, the acknowledgements will contain a line saying Update OK: <object-name> for each update which generated no messages. The updates generating messages will return the full object and messages as before. Please let us know your experiences and suggestions. Daniel

1 0

Database Update Acknowledgement Messages
by Daniel Karrenberg 24 Feb '93

24 Feb '93

Effective immediately the acknowledgements we send out for database updates will mention the "Subject" of the update mail message being acknowledged in addition to the "Message-ID". This should allow easier matching of acknowledgements to update requests. Please let us know if you see any wrong behaviour of this new feature. We also have had requests to mention the names of all objects updated e.g. person, network, domain etc.. We have refrained from doing this as it would produce *very* long acknowledgements in some cases. We were thinking of providing it for updates containing less objects than a threshold of -say- 20. Anyone who wants this in addition to the Subject please speak up with an explanation why to the list. Then we can make a decision whether it is worthwhile. Daniel

1 0

zone-c not mandatory
by Daniel Karrenberg 22 Feb '93

22 Feb '93

I think Blasco ghas a point there and will implement this unless someone cries "stop". Daniel ------- Forwarded Message Date: Fri, 19 Feb 93 18:49:25 MET From: bonito(a)nis.garr.it (Antonio_Blasco Bonito) To: ripe-dbm(a)ripe.net cc: staff(a)nis.garr.it Subject: zone-c tag Hello NCC people, I think the update procedure is not right giving the following error: > domain: fis.uniurb.it > descr: Universita' degli Studi di Urbino > descr: Istituto di Fisica > remarks: It is a public institution devoted to researches in some fields > remarks: of Physics and Biomedical Engineering and teaching > admin-c: Filippo Martelli > tech-c: Flavio Vetrano > tech-c: Pietro Dominici > remarks: MX-only > source: RIPE > changed: domain(a)nis.garr.it 930217 > WARNING: mandatory attribute "zone-c" missing in object A MX-only domain has no nameserver and therefore cannot have a zone-c contact information. I think that zone-c should not be considered a mandatory attribute. All my best. - ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito(a)nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 - ---------- ---------- ------- End of Forwarded Message

4 4

Re: problems with data base updates
by Marten Terpstra 19 Feb '93

19 Feb '93

rv(a)deins.informatik.uni-dortmund.de writes: * Hello, * * recently I mentioned to Daniel on the phone, that it looks like some * "connect:" fields are filtered (without warning) in the RIPE data base. * I just came across an example (I will keep looking), the record for * network 139.1: I'm very sorry to say that this is all my fault, and it was even worse than some "connect:" fields dissapearing ... In fact what happened is that all LOCAL connect fields dissapeared from the database because of an(other) error in the procedure that adds the routing tags to the database. I have done the following to correct this: - modified the script that adds the routing tags to leave the connect fields in, - rebuild the database, and added a "connect: LOCAL" field to any network that had no connect tag in the current database. I have checked this extensively and are sure that ONLY "connect: LOCAL" fields dissapeared. All other connect fields were not removed, and still have their old value. My apologies for this error. If you do find any inconsistencies, please inform us, and we will process with the highest priority. -Marten

1 0

Possible addition tag for the aut-sys object.
by Tony Bates 05 Feb '93

05 Feb '93

Please find enclosed a small propsed additional tag that I would like to get put into the next and perhaps final round of the documet due out early next. Also note that so far I have had little feedback on the paper as it stands. I have already made some changes in terms of cosmetics and some of the remaining holes but would still be interested in any comments. --Tony. Addition of a "default: " tag to the Proposed "aut-sys" database object. ------------------------------------------------------------------------ Currently, in the paper the method for detailing default routing is by use of the KEYWORD "DEFAULT" as I call it in the routing policy expression. However, upon reflection we feel it may be useful to to express this is terms of a tag itself. Basically, this details which AS neighbor you choose to select default routing to. So the format of the default tag would be. default: <as-num> <preference>, multiple lines, optional So for example if you are AS1 with two connections to the outside world, AS 2 and AS 4. And generally you take some transit networks in on both paths but select default for one (say AS 4) and if this goes away use AS 2 as backup this you would express it something like this. AS 3 | | --------------- AS 1------------AS 2-------------( Global ) | ( ) | ( Internet ) +------------AS 4-------------(_______________) | | | AS 5 The routing policy description would be as follows: aut-sys: AS1 as-in: AS2 100 AS2 AS3 as-out: AS2 AS1 as-in: AS4 100 AS4 AS5 as-out: AS4 AS1 default: AS4 100 default: AS2 150 <administrative stuff > If equal preferences are given this is also fine but of course the matter is purely local as to how this may be implemented. We also make distinction as to how default is reached (i.e. by a given network or use of 0.0.0.0, etc) as again this is purely a local bi-lateral matter and very much implementation dependent.

1 1