- db-wg - mailman.ripe.net

RE: [db-wg] abuse-c
by TAYON, Julien 13 Jan '04

13 Jan '04

MarcoH <mailto:marcoh@marcoh.net> wrote: > On Tue, Jan 13, 2004 at 04:14:13PM +0100, Christian Rasmussen wrote: >> Hi Marco, >> >> >> Okay, I think I now understand better what you mean. There are >> different levels of check of entered abuse address: >> >> 1. Nothing >> 2. Syntax check >> 3. Address validity check (as previously described) >> 4. Response time check > > level 4 would be to run random audits on the information present in > the database. > Last time I misfilled an inetnum abuse with a mnt-lower ( yes I did :( ). as my email was present in changed: they complained a lot to everybody even in the "upper block" including me that abuse email was wrong. My idea is if internet user follow the RFC and their common erratic sense (i.e. complaining to the "upper authority" if no response from the implied inetnum) and we all read our emails, everything should be fine. I think internet users are really are our best low cost efficient auditing system, and we might listen to them. If you want to pay for something that is free though ... well it is no matter to me. -- Julien Tayon LDCOM networks BU DATA- +33 1 70 18 14 45 1 square Chaptal , 92309 Levallois Cedex

1 0

Database Modifications for X.509 Support
by Shane Kerr 13 Jan '04

13 Jan '04

All, Attached please find a description of the database modifications necessary to implement X.509 authentication in the RIPE Database. This is the outcome of previous discussions on the mailing list, presentations and discussions at RIPE meetings, and a review of the implementation details. The only new feature added is making "fingerpr:" an inverse key, which helps dbupdate lookup the appropriate X.509 key. -- Shane Kerr Software Engineering Group Manager RIPE NCC Database Modifications for X.509 Support 1. Proposal ------------- To add X.509 authentication to the RIPE Database. 2. Changes to the key-cert class -------------------------------- The key-cert class will be altered to allow both PGP and X.509 certificates to be represented. PGP certificates will remain the same. X.509 certificates will have the following attributes: - "key-cert:" will be of the form X509-nnn, where nnn is a unique number assigned by the database. (See "Primary key for X.509 KEY-CERT objects" below.) - "method:" will be X509. - "owner:" will be the Distinguished Name (DN) of the certificate. Sometimes this is called the certificate subject. - "fingerpr:" will be the MD5 fingerprint of the certificate. - "certif:" will contain the ASCII representation of the X.509 certificate. The "fingerpr:" attribute will become an inverse key. The format and meaning of all other attributes remain unchanged. Example of an X.509 KEY-CERT object: key-cert: X509-42 method: X509 owner: /C=NL/O=RIPE NCC/OU=Members/CN=eu.ripe-ncc.shane/Email=shane(a)ripe.net fingerpr: D5:92:29:08:F8:AB:75:5F:42:F5:A8:5F:A3:8D:08:2E certif: -----BEGIN CERTIFICATE----- certif: MIID/DCCA2WgAwIBAgICAIQwDQYJKoZIhvcNAQEEBQAwcTELMAkGA1UEBhMCRVUx certif: EDAOBgNVBAgTB0hvbGxhbmQxEDAOBgNVBAoTB25jY0RFTU8xHTAbBgNVBAMTFFNv . . . certif: hZNmF5c/d0gauqvL+egb+3V+Zg+sJTzHMVKQLF1ybWgJjU75Pi+mO7BG0zsQ13pT certif: YxuZCR2W15nwt7zLiHtmfw== certif: -----END CERTIFICATE----- remarks: Sample Key Certificate notify: ripe-dbm(a)ripe.net mnt-by: RIPE-DBM-MNT changed: ripe-dbm(a)ripe.net 20040101 source: RIPE 3. Primary key for X.509 KEY-CERT objects ----------------------------------------- The "key-cert:" attribute is the primary key of KEY-CERT objects. This will be given a generated value that is the object ID. X.509 object IDs are auto-generated similar to the way person/role "nic-hdl:" attributes are auto-generated. For new KEY-CERT objects, the user must use AUTO-<digit> during creation of the object, it will then it will be assigned an appropriate ID. The key-cert ID cannot be reused. If a key-cert ID was used in the past by a KEY-CERT object and then deleted, this ID cannot be used in new KEY-CERT objects. Using a unique identifier is different from the PGP object IDs. In PGP, the key ID is used as part of the object ID (specified in RFC 2726). This is a 32-bit value, expressed in hexadecimal. There are several problems with this. Collisions occur (*), and keys can be spoofed (**). This is less of a problem with X.509 because it uses much longer fingerprints; however, in any system where the source of the fingerprint is passed to other users the possibility exists of a third party adding the certificate to the database. 4. Change to the "auth:" attribute ---------------------------------- The "auth:" attribute is present in MNTNER and IRT objects, and specifies the authentication scheme of the maintainer. The following additional value will be added: X509-<id> Strong scheme of authentication. This string is the same one that is used in the corresponding KEY-CERT object's "key-cert:" attribute. 5. Change to authentication --------------------------- When a maintainer specifies an X.509 KEY-CERT object the signature, using the private key associated with the certificate contained in the KEY-CERT object, will authenticate that maintainer. 6. Changes to e-mail processing ---------------------------- S/MIME messages will be accepted. S/MIME messages must not be encrypted; an encrypted message will be rejected as invalid input. Either the whole message may be an S/MIME signed message or one MIME part may contain an S/MIME signed message. S/MIME may be used fully, partially, or not at all with other authentication mechanisms. Therefore, it is acceptable to receive a message that is an S/MIME signed message which has been further signed by PGP, or an S/MIME message may be forwarded with the addition of a password at the outer level. 7. Changes to synchronous updates --------------------------------- The server will accept SSL connections with any client side certificate, this certificate will be used to authenticate any updates. (*) http://www.imc.org/ietf-openpgp/mail-archive/msg00484.html (**) http://archives.neohapsis.com/archives/vuln-dev/2001-q4/0147.html

2 1

abuse-c
by Rev Adrian Kennard 13 Jan '04

13 Jan '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I am new to this mailing list, so forgive me if this has been covered before. It seems there is a pretty clear need for an extra field in inetnum and inet6num records, specifically something like an abuse-c field referencing a person record. A lot of inetnum records I have seen have a remarks field identifying the abuse ocntact, but this is in an inconsistent format making it difficult to automate in any way. It also seems that a lot of network administrators (admin-c) do not feel they should administer their network to remove viruses, etc, and get quite annoyed when contacted regarding abuse. What would be the procedure for proposing such a new field? - -- Rev Adrian Kennard uk.aa -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQE//o/MHBb4e52L0Y0RAoPzAJ9Vp94eC6DMAPvAK7Lx5HiiVBPQSgCfTfFZ HfzTEAB6TwmsFBbivTe4KaU= =mlgj -----END PGP SIGNATURE-----

14 29

Re: abuse-c
by Thor Kottelin 13 Jan '04

13 Jan '04

So, we already have the irt object and the trouble attribute. Additionally, abuse is often reported based on admin-c, tech-c, changed, remarks and $DEITY knows what. Please let's not add to the confusion by creating even more attribute or object types. As for the irt object requiring a maintainer, that requirement exists for security, the need for which should be obvious in the context of abuse reports as well. The obvious hardliner approach would be to require future inetnum updates to carry valid mnt-irt attributes. Thor -- http://thorweb.anta.net/

3 3

Re: db-wg digest, Vol 1 #152 - 13 msgs
by Rev Adrian Kennard 12 Jan '04

12 Jan '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 | From: Thor Kottelin <thor(a)anta.net> | So, we already have the irt object and the trouble attribute. | Additionally, | abuse is often reported based on admin-c, tech-c, changed, remarks and | $DEITY knows what. Please let's not add to the confusion by creating | even more attribute or object types. There is a clear problem with what we have now, whether techncially or simply awareness, as it is clear that lots and lots of inet[6]num objects have remarks identifying abuse contacts in a variety of formats. There is a need for people to identify abuse contacts associated with an IP[6]. "trouble" does not help as it is also free format and so not much better than remarks. "irt" may be the answer, and I am creating one for our use at present (still not had a reply - why is it a manual process?). It may be over complex. It is not well publicised to those that need to know. Even those that know of it (and I had seen it) do not realise it is the way to put an abuse contact on an inetnum (hence my original question). FYI, our abuse report scripts now look for a mnt-irt field and if not found go for the admin-c field. They used to just go for the admin field. However, I do think something has to be done as it is a nonsense the way it is now. - -- Rev Adrian Kennard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFAAufMHBb4e52L0Y0RAoHlAJ0ZLrp5QiftL7iWEqpcUxVUxZjLSgCcC8Vo j86xkD4uQ0dcTkzcWOOjtaU= =ykiB -----END PGP SIGNATURE-----

1 0

Re: [db-wg] abuse-c
by Wilfried Woeber, UniVie/ACOnet 12 Jan '04

12 Jan '04

Hi John! >Menno Pieters (Stelvio) wrote: >> TI is an organisation that verifies the information, so that it can be >> *trusted*. For ordinary users it may be to hard to understand this and >> how to make sure it all correct. For IRT among eachother it may be >> important. > >But all that going via the TI route gives you is a "mnt-by: TI" entry in >your object. Yes - what is wrong with that? > There are other non-RIPE ways for teams to infer how much >trust they should give to another team, Correct. >and overloading mnt-by seems undesirable. Maybe, but I don't see what the downside is in using a mechanism which is there, instead of inventing something new. Actually it was - maybe - blue-eyed to invent a new object type. Inventing a new attribute _without a proper syntax and semantic to go with it_ is probably not too much better... >Some useful changes would be renaming the IRT object to something more >general, like Abuse (?) object If we can reach consensus that this should be the name I expect the NCC to make the necessary modifications to the implementation. The problem (which was discussed in various environments more than once!) is that different entities have a different interpretation of the word "abuse". >and for it to be returned by default when querying an IP (or AS). I keep hearing that again and again (and from the incident/abuse point of view I agree!), so I'll put it onto the DB-WG. Maybe others can try to put it onto other WGs' agendas, as this is a pretty big change to the behaviour of the whois server. >The seperation into an easily maintainable object which includes stuff >in addition to email address (like postal address, pgp and phone) are >useful enhancements to "trouble:". > >Cheers >John Wilfried.

2 1

Re: [db-wg] abuse-c
by Wilfried Woeber, UniVie/ACOnet 12 Jan '04

12 Jan '04

> Not if the relevant IRT object is automatically returned for every > inetnum query. This is what ARIN does, BTW. Could I see an example of ARIN doing that, please? Or - what is the query to get this from ARIN? Thanks, Wilfried.

2 1

RE: [db-wg] abuse-c
by Wilfried Woeber, UniVie/ACOnet 12 Jan '04

12 Jan '04

Christian, >I have a lot of inetnum objects which I need the same abuse address for so I >would REALLY appriciate not having to change each and everyone of them!.. :) supporting that was one of the goals in the design of the IRT object. All the (resources described by a set of) objects which are handled by the same incident team or function just get linked to the same IRT object. If you want to make any changes, then you update the info in _one_ place - much like the maintainer approach. And, the IRT structure supports hierarchy (for those resources which do have a hierarchy :-) It allows quite a few other things to be nicely described and maintained, eg. - giving key info if you want to use encryption for your complaint, or verify the identity of the security contact you get an answer from - decoupling of IP-Address management from operations ("rouitng") and incident handling - registering credibility info with this contact info, like the Trusted Introducer, which was the first structure to use this machinery. We are definitely still missing some things to make it fly high... Things that come to my mind without doing a full inventory: - make additional documentation available (TF-CSIRT is actively working on this) - try to get it deployed and _used_ (I'd look into the direction of the Anti-Spam folks to help with this) - maybe modify the default answer from the server for a whois query (what would the impact be on the "other" users of the registry data?) - try to define complaint handling roles in a concise way to allow selecting the "correct" contact from an object. (this doesn't chance whether you put it into an inetnum or an IRT object ;-) (I guess there will be another attempt in Madrid next week to deal with that amongst the incident handlers, and we may come back with a proposal or at least an idea) Wilfried.

1 0

RE: [db-wg] abuse-c
by TAYON, Julien 12 Jan '04

12 Jan '04

John Green <mailto:j.green@ukerna.ac.uk> wrote: > I have never understood what this gives you. If "Evil Company" wants > to misdirect abuse reports (why?) they can circumvent this by making > a fake IRT object with IRT XYZ as the contact email address. > If people circumvent this they are either evil or incompetent which is alreday a strong hint to be suspicious. Julien Tayon LDCOM networks BU DATA- +33 1 70 18 14 45 1 square Chaptal , 92309 Levallois Cedex

4 4

Defined roles
by Rev Adrian Kennard 12 Jan '04

12 Jan '04

Following on from the comment bt Shane Kerr > Also, what various contact information means is not clear. What > administration does the "admin-c:" do exactly? Only update the RIPE > Database? Coordinate with the RIPE NCC? Is it the CEO of a company? > The manager of the IT department? Or an independent contractor who handles > all the details of connectivity? I have to agree that "what is the responsibility" or perhaps just "the role" of the admin-c and tech-c. From what I have read on RIPE documents the role is not at all clear. I believe it said the admin contact has to be at the same address as the network? So what of unattended sites? There are many questions, and perhaps there should be some attempt to define more accurately what admin-c and tech-c are meant to be used for. As internet usage is becoming more of an issue (spam, child porn, etc) I can't help feeling that there should be some formal "responsibility" associated with an inetnum (like we have a "keeper of a vehicle" in the UK who has some responsibilities). I suspect to go this far would request some legal framework in countries affected, but RIPE could at least indicate, say, "The admin contact is intended to take responsibility for the IP addresses" or some such, which would be a good basis. Of course, if there was an abuse-c, then this could be a document explaining the detailed role of admin-c, tech-c, and abuse-c. Also, the "trouble" field is a good thought - maybe we should add "trouble" to inetnum, as there is already a field name defined for the purpose essentially. Just an idea. -- Rev Adrian Kennard Andrews & Arnold Ltd / AAISP www.aaisp.net.uk

1 0

E-mail Client Testing for S/MIME Compliance
by Denis Walker 09 Jan '04

09 Jan '04

[apologies for duplicate messages] Dear Colleagues, At the RIPE 45 Meeting a proposal was presented to implement an additional form of strong authentication for protecting objects in the RIPE Database and to allow for secure communication by e-mail with the RIPE NCC. This implementation uses the X.509 certificates. A question was raised by some members about how widespread is the compliance of S/MIME within mail clients. The RIPE NCC Software Engineering Department has undertaken a study to evaluate the use of S/MIME by mail clients. The results of this study can be found on our web site at: http://www.ripe.net/ripencc/pub-services/db/mail_client_tests.html Regards, -- Denis Walker Software Engineering Department RIPE NCC

4 5

Domail Clean-up
by RIPE Database Manager 06 Jan '04

06 Jan '04

Dear Colleagues, As of 6 January, 2004, messages concerning inconsistencies between "nserver:" attributes in DOMAIN objects and delegation NS RRs in our zone files will be sent out. The messages will be mailed to various contact addresses for the relevant DOMAIN objects. In addition to the description of the inconsistencies, an indication of the 'default actions' will also be provided. We kindly request data be updated so that the inconsistencies are corrected before 1 March, 2004. About two weeks before 1 March, 2004 we will send a second set of warnings for the remaining inconsistencies. By 1 March, 2004 all remaining inconsistencies will be cleaned by the RIPE NCC, using the 'default actions'. If you receive a warning about inconsistencies we recommend that you fix the data yourself. It may be that you receive multiple mails for multiple domains with multiple inconsistencies. If you want to configure a dedicated mail filter the messages will contain the subject header "Subject: Reverse DNS inconsistencies in the RIPE Database" and originate "From: <ripe-dbm(a)ripe.net>". If you have further questions please contact <ripe-dbm(a)ripe.net>. Background The cleanup is part of the effort to streamline reverse DNS operations [1] and make it easier for network range users to manipulate related DOMAIN objects. The goal of the cleanup [2] is to streamline the contents of DOMAIN objects and zone configuration files so that we can create zone files from the Whois Database. An explanation of the various possible inconsistencies can be found at: http://www.ripe.net/reverse/rdns-project/Cleanup.html. ----- [1]: Original proposal http://www.ripe.net/reverse/proposal.html. Discussion on this proposal has taken place on the RIPE NCC Services WG mailing list and was summarized in: http://www.ripe.net/ripe/mail-archives/ncc-services-wg/2003/msg00361.html [2]: Original cleanup proposal http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00738.html. ----- Can Bican Software Engineering Department Olaf Kolkman New Projects Group RIPE NCC

1 0

creating a mntner
by Randy Bush 29 Dec '03

29 Dec '03

so, i have a clean database, 3.2.0 server running, blah blah blah now i have the old problem of creating a first mntner: i run bin/dbupdate -c conf/rip.config -t -d mntner: MAINT-RGNET descr: RGnet admin-c: RB366 upd-to: rw(a)rg.net auth: NONE override: <cleartext override password> mnt-by: MAINT-RGNET referral-by: MAINT-RGNET changed: randy(a)psg.com 20031217 source: RGNET ^D and it pukes saying Create FAILED: [mntner] MAINT-RGNET ***Info: Syntax check passed mntner: MAINT-RGNET descr: RGnet admin-c: RB366 upd-to: rw(a)rg.net auth: NONE mnt-by: MAINT-RGNET referral-by: MAINT-RGNET changed: randy(a)psg.com 20031217 source: RGNET ***Error: Unknown object referenced and the interesting part of the debug output up_source_commit: entered with operation [UP_CREATE] up_send_object_db: entered, operation [UP_CREATE] up_send_object_db: object to be sent [ mntner: MAINT-RGNET descr: RGnet admin-c: RB366 upd-to: rw(a)rg.net auth: NONE mnt-by: MAINT-RGNET referral-by: MAINT-RGNET changed: randy(a)psg.com 20031217 source: RGNET ] up_get_transaction_id: entered spent 0.00 sec; got 1 rows from [dbrgnet: INSERT INTO tid VALUES(NULL)] up_get_transaction_id: exiting with new id [18] up_send_object_db: transaction ID [18] SK_write = { sockfd=[7], buf=[ADD], count=[3] SK_write = { sockfd=[7], buf=[ ], count=[1] SK_write = { sockfd=[7], buf=[18], count=[2] SK_write = { sockfd=[7], buf=[ ], count=[2] SK_write = { sockfd=[7], buf=[mntner: MAINT-RGNET descr: RGnet admin-c: RB366 upd-to: rw(a)rg.net auth: NONE mnt-by: MAINT-RGNET referral-by: MAINT-RGNET changed: randy(a)psg.com 20031217 source: RGNET ], count=[218] SK_write = { sockfd=[7], buf=[ ], count=[2] SK_write = { sockfd=[7], buf=[ACK ], count=[4] SK_write = { sockfd=[7], buf=[18], count=[2] SK_write = { sockfd=[7], buf=[ ], count=[2] up_send_object_db: send complete up_send_object_db: received from socket [ %ERROR 4 ] up_send_object_db: received from socket [ E[4][1:RB366]:ref integrity: reference cannot be resolved ] up_send_object_db: received from socket [ ] up_send_object_db: received blank line from socket, stop reading Closing socket... 7 up_send_object_db: exiting with value UP_OK up_interpret_ripudb_result: entered, ripupd_result [%ERROR 4 E[4][1:RB366]:ref integrity: reference cannot be resolved clue by four, please randy

4 11

Re: [db-wg] 3.2.0 make_db getvar cores
by Randy Bush 19 Dec '03

19 Dec '03

> Everything seems OK in your config files you've sent. I could not > replicate your problem. My best bet is that, in rip.config > SOURCEFILE /usr/home/whois/conf/sources.config > points to a file which is _not_ the one you've sent. sigh. with that gdb output? puhleeze! (gdb) back #0 0x805087d in ca_parseSrcLine (lineStr=0xbfbff74c "database:\tdbrgnet", srcStructPtr=0x80c8400) at ca_sourceLoader.c:792 #1 0x8050147 in ca_readSources ( sourcesDefFile=0x80c2840 "/usr/home/whois/conf/sources.config", confVars=0x80b1840) at ca_sourceLoader.c:464 #2 0x804faa2 in ca_init (configFile=0xbfbff9b1 "../conf/rip.config") at ca_initFn.c:87 #3 0x804bc2f in main (argc=7, argv=0xbfbff858) at getvar.c:84 let me try to debug by turning on debugging in ca_sourceLoader.c # /usr/home/whois/utils/getvar -s SAMPLE -c /usr/home/whois/conf/rip.config -p dbhost Inside ca_readSources() function. Sources file is: /usr/home/whois/conf/sources.config We are reading a comment or an empty line ..... line:DATABASE SAMPLEDB:End of line Length of line: 17 LINE >>>DATABASE SAMPLEDBEND_OF_LINE Beginning of a database defintion ..... Database name is: SAMPLEDB line:host: localhost:End of line Length of line: 16 LINE >>>host: localhostEND_OF_LINE tokens[0] = host tokens[1] = localhost VarName: host; dbComp: localhost line:port: 3306:End of line Length of line: 11 LINE >>>port: 3306END_OF_LINE tokens[0] = port tokens[1] = 3306 VarName: port; dbComp: 3306 line:trx_support: n:End of line Length of line: 14 LINE >>>trx_support: nEND_OF_LINE tokens[0] = trx_support tokens[1] = n VarName: trx_support; dbComp: n line:user: rip:End of line Length of line: 10 LINE >>>user: ripEND_OF_LINE tokens[0] = user tokens[1] = rip VarName: user; dbComp: rip line:password: secret:End of line Length of line: 19 LINE >>>password: secretEND_OF_LINE tokens[0] = password tokens[1] = secret VarName: password; dbComp: secret line:/DATABASE:End of line Length of line: 9 LINE >>>/DATABASEEND_OF_LINE We have reached the end of a DATABASE definition Testing the population of the db structure: localhost::3306::n::rip::secret:: ^ wowie zowie! no database name ^ the very problem we sought guess what happens when the password is nine characters! .../ripe-dbase-3.2.0# grep -c strcpy ./modules/ca/ca_sourceLoader.c 16 oh wonderful and thanks a million for the debugging help randy

1 0

3.2.0 make_db getvar cores
by Randy Bush 17 Dec '03

17 Dec '03

o freebsd 4.9-stable, quite recent o all ports just rebuilt o wanted to do a clean fresh install of whois 3.2.0, as i could not successfully convert o successful build o successful install conf/rip.config same as used for 3.1.1 excpt did emacs diff merge to get the syntax changes conf/sources.rip same as used for 3.1.1 except added trx_support: n in mysql, i deleted both databases, RIPADMIN and dbrgnet /scripts# ./make_db -c ../conf/rip.config -s RGNET -0 Error: Non-existent database "dbrgnet" referenced !!! died: +792 ca_sourceLoader.c Segmentation fault (core dumped) ************** ERROR *************** *** 05:19:01 unknown source RGNET ************************************ # gdb /usr/local/src/net/ripe-dbase-3.2.0/utils/getvar/getvar getvar.core GNU gdb 4.18 (FreeBSD) Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"...Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 2627 in elfstab_build_psymtabs Deprecated bfd_read called at /usr/src/gnu/usr.bin/binutils/gdb/../../../../contrib/gdb/gdb/dbxread.c line 933 in fill_symbuf Core was generated by `getvar'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libgthread12.so.3...done. Reading symbols from /usr/local/lib/libglib12.so.3...done. Reading symbols from /usr/local/lib/mysql/libmysqlclient_r.so.10...done. Reading symbols from /usr/lib/libm.so.2...done. Reading symbols from /usr/lib/libcrypt.so.2...done. Reading symbols from /usr/lib/libpam.so.1...done. Reading symbols from /usr/lib/libcipher.so.2...done. Reading symbols from /usr/local/lib/libxml2.so.5...done. Reading symbols from /usr/local/lib/libiconv.so.3...done. Reading symbols from /usr/local/lib/libxslt.so.2...done. Reading symbols from /usr/lib/libc_r.so.4...done. Reading symbols from /usr/lib/libz.so.2...done. Reading symbols from /usr/libexec/ld-elf.so.1...done. #0 0x805087d in ca_parseSrcLine (lineStr=0xbfbff74c "database:\tdbrgnet", srcStructPtr=0x80c8400) at ca_sourceLoader.c:792 792 die; (gdb) back #0 0x805087d in ca_parseSrcLine (lineStr=0xbfbff74c "database:\tdbrgnet", srcStructPtr=0x80c8400) at ca_sourceLoader.c:792 #1 0x8050147 in ca_readSources ( sourcesDefFile=0x80c2840 "/usr/home/whois/conf/sources.config", confVars=0x80b1840) at ca_sourceLoader.c:464 #2 0x804faa2 in ca_init (configFile=0xbfbff9b1 "../conf/rip.config") at ca_initFn.c:87 #3 0x804bc2f in main (argc=7, argv=0xbfbff858) at getvar.c:84 randy

2 2

Re: [sed] problem updating database to 3.2.0
by Randy Bush 17 Dec '03

17 Dec '03

engin pointed out my stupid, using the admin db as opposed to the whois db. but now i fail on the last set # mysql -ufoo -pbar -Ddbrgnet -e'ALTER TABLE acl ADD COLUMN threshold tinyint(3) unsigned Default '4' NOT NULL after trustpass' $SOURCE ERROR 1146 at line 1: Table 'dbrgnet.acl' doesn't exist # mysql -ufoo -pbar -Ddbrgnet -e'ALTER TABLE acl ADD COLUMN maxconn tinyint(3) unsigned Default '6' NOT NULL after threshold' $SOURCE ERROR 1146 at line 1: Table 'dbrgnet.acl' doesn't exist another clue by four please randy

2 1

problem updating database to 3.2.0
by Randy Bush 16 Dec '03

16 Dec '03

running 3.1.1 and trying to get to 3.2.0 first line of UPDATING fails # mysql -ufoo -pbar -DRIPADMIN -e'ALTER TABLE names DROP PRIMARY KEY' ERROR 1146 at line 1: Table 'RIPADMIN.names' doesn't exist clue-by-four please randy

1 0

Announcement Routing Registry Training Courses
by RIPE NCC Training 16 Dec '03

16 Dec '03

------- Dear Colleagues, [apologies for duplicate postings] As a service to its members the RIPE NCC offers the "Routing Registry Training Course". The main objective of the "Routing Registry Training Course" is to familiarise the LIRs with the features of the Routing Registry, while introducing the relevant tools and services of the RIPE NCC. The course also offers practical exercises. OVERVIEW OF TOPICS COVERED IN THE COURSE: - Routing Registry as a part of the RIPE Whois Database and the Internet Routing Registry (IRR) - Specifying routing policies using (RPSL) Routing Policy Specification Language and the RtConfig tool - IRRToolSet - Routing Information Service (RIS) - Routing Registry Consistency Check Project Please note that this is an advanced course. It will: - NOT teach the basics of routing - NOT teach the basics of RIPE Database operations, - NOT describe how to receive Internet resources from the RIPE NCC - NOT describe how to operate a Local Internet Registry (LIR) The target audience of the course are technical staff of LIRs: e.g. network operators, engineers etc. This course is not intended for administrative or management staff (e.g. Hostmasters) . It is assumed that all attendees will be familiar with Border Gateway Protocol routing and with the RIPE Database (i.e. creating/modifying objects). This course is based on interactive exercises in a local network set-up. Please bring your laptops equipped with the following: - A working Ethernet card, - Three meters of Ethernet cable, - A secure connection client, - A web browser. Please be prepared to share your laptop (or at least allow another attendee to "look over your shoulder") if necessary. The Routing Registry Training Course is conducted in the English language and is free of charge, since it is covered by the membership fee. More information about the Routing Registry Training Course can be found at: http://www.ripe.net/training/rr/ REGISTRATION: You can register for a Routing Registry Training Course at the following URL: http://www.ripe.net/cgi-bin/trainingform.pl.cgi Or by completing the registration form at the end of this e-mail and replying to <training(a)ripe.net> . In order to register for a Routing Registry Training Course you must be an employee of an LIR and either: - be an LIR contact - be confirmed by an LIR contact LIR contacts are those employees of an LIR who are registered with RIPE NCC as authoritative contact persons. It is expected that most of those interested in the Routing Registry Training Course will not be an authoritative contact person for their LIR, and therefore will be, refused by the course registration "robot". In order to be admitted to the course, a confirmation e-mail must be sent to <training(a)ripe.net>. Please approach the LIR contacts from your organisation personally, since the identity of LIR contacts is confidential, and the RIPE NCC is unable to divulge contact persons for any given LIR. Kind Regards, Training Team RIPE NCC ************************************************************************* COURSE DATES AND VENUES ======================== Date: Friday 6 February 2004 Time: 0900 - 1700 Location: Amsterdam, The Netherlands AND: Date: Tuesday 17 February 2004 Time: 0900 - 1700 Location: Tehran, Iran AND: Date: Friday 5 March 2004 Time: 0900 - 1700 Location: Rome, Italy AND: Date: Friday 23 April 2004 Time: 0900 - 1700 Location: Istanbul, Turkey AND: Date: Friday 14 May 2004 Time: 0900 - 1700 Location: Bratislava, Slovakia AND: Date: Thursday 24 June 2004 Time: 0900 - 1700 Location: Stockholm, Sweden ************************************************************************* REGISTRATION FORM ================= %START PART 1 - Registration 1) Your name Enter First name, Last name in full e.g. John Doe Mary-Beth Walton # NAME [ ] 2) Your Registry ID (format: country-code.<name of registry>) # REG [ ] 3) Your e-mail address # EMAIL [ ] 4) Your NIC handle (optional) # NICHANDLE [ ] 5) The course you plan to attend (date and location) # COURSE [ ] %END

1 0

RIPE DB missing inetnum referral for 204/8 (and others) to ARIN?
by Daniel Roesen 10 Dec '03

10 Dec '03

Hi, $ whois -h whois.ripe.net 204.152.184.85 [...] inetnum: 0.0.0.0 - 255.255.255.255 netname: IANA-BLK descr: The whole IPv4 address space [...] and nothing else. The referral to ARIN for 204/8 is missing. I've checked a couple of other RIRs /8s which all had the same problem. Was there a deliberate change that I missed? Best regards, Daniel

2 5

Deprecation of "cross-nfy:" and "cross-mnt:" attributes in the RIPE Whois Database
by Katie Petrusha 05 Dec '03

05 Dec '03

[ Apologies for duplicate messages ] Dear colleagues, "cross-nfy:" and "cross-mnt:" attributes will be deprecated in the RIPE Whois Database by 1 February 2004. The RIPE Whois Database previously had a cross notification mechanism. This mechanism used "cross-nfy:" and "cross-mnt:" attributes of route and aut-num objects to notify particular maintainers and contacts when an overlapping route object had been added or removed. In May 2003, this mechanism was deprecated, as it is already covered by Routing Policy System Security functionality. In March 2003, the proposal was circulated to deprecate "cross-nfy:" and "cross-mnt:" attributes in the RIPE Whois Database as they are no longer needed: http://www.ripe.net/ripe/mail-archives/db-wg/2003/msg00035.html Approximately 180 aut-num and 620 route objects will be affected by this change. These objects should be modified before 1 February 2003 and the "cross-nfy:" and/or "cross-mnt:" attributes should be removed from them. As soon as these attributes have been deprecated, they will not be accepted in the RIPE Whois Database. Therefore, we encourage everyone to make the necessary modifications in advance. The RIPE Database Administration will update the objects still requiring modifications to change deprecated attributes into "remarks:" attributes. No individual notifications will be sent. Relevant maintainers will be notified via the usual RIPE Whois Database notification mechanism. This information can be found at: http://www.ripe.net/db/cross_nfy_mnt_deprecation.html -- Katie Petrusha Software Engineering Department RIPE NCC

1 0

Announcement: Redirecting reverse DNS updates
by RIPE Database Manager 05 Dec '03

05 Dec '03

Dear Colleagues, From 8 December 2003, as part of the effort to streamline reverse DNS operations, domain updates that contain in-addr.arpa or ip6.arpa type entries sent to <auto-dbm(a)ripe.net> will automatically be forwarded to <auto-inaddr(a)ripe.net> for processing. This will continue until the two processes are combined into one. Such updates will be processed as follows: - If the update contains only domain objects whose "domain:" attributes end with 'in-addr.arpa' or 'ip6.arpa' , it will be redirected to: <auto-inaddr(a)ripe.net> - If the update contains a mixture of domain objects whose "domain:" attributes end with 'in-addr.arpa' or 'ip6.arpa', as well as other types of database objects, the message will be rejected. The user will receive an e-mail requesting that the objects be separated and re-submitted. - All other e-mails will be processed as normal. - It will not be possible to update these domain objects using syncupdates. Please don't hesitate to contact <ripe-dbm(a)ripe.net> for questions, comments or suggestions. Regards, -- Can Bican Software Engineering Department RIPE NCC

1 1

Domain Cleanup Proposal
by RIPE Database Manager 03 Dec '03

03 Dec '03

Dear Colleagues, A. Introduction This proposal is part of the effort to streamline reverse DNS operations [1] and make it easier for network range users to manipulate related domain objects. Local Internet Registries (LIRs) maintain their reverse delegations at the RIPE NCC through the use of domain objects. For several historical reasons there are a number of inconsistencies between the domain objects and the reverse delegation information in the DNS. Since we want to move to a system in which the Whois Database is the authoritative source for data that is published in the DNS (see [1]), there is a need to remove these inconsistencies. In this proposal, we will address the inconsistencies between data represented through the domain objects in the Whois Database and the reverse delegation data in our zone-files. We will also propose solutions to fix these inconsistencies. Note, this proposal is only relevant for domain objects that the RIPE NCC provides reverse delegation services for i.e. networks delegated to it by the Internet Address and Numbering Association (IANA) and networks transferred to the RIPE Database via the Early Registration Transfer (ERX) Project [2]. This proposal is NOT relevant to domains in the e164.arpa space. B. Type of Inconsistencies - Domain objects that have no delegation in the zone configurations: Reverse DNS-related updates to the RIPE database must be sent to <auto-inaddr(a)ripe.net>, otherwise zone configurations can not be updated. There are objects in the RIPE Database created via methods other than by sending an e-mail to <auto-inaddr(a)ripe.net>, causing this type of inconsistency. - Zone configuration entries that do not exist as domain objects in the RIPE Database: When zone files are updated manually, and not by sending an e-mail to <auto-inaddr(a)ripe.net>, this type of inconsistency occurs. - Conflicting entries in the RIPE Database and zone files: A mismatch between the "nserver:" attributes and the NS Resource Records (RRs) in our zone files occurs as a mixture of the first two inconsistencies. The domain object has been added or modified at one point via <auto-inaddr(a)ripe.net>, but then either updated manually or by <auto-dbm(a)ripe.net>. - Invalid domain objects in the RIPE Database: This type of inconsistency occurs in domain objects that can not map to a valid DNS entry. As an example, 8080.80.in-addr.arpa is an invalid entry. Only reverse address space mapping is taken into account. - Invalid "nserver:" attributes in the RIPE Database: "nserver:" attributes must contain hostnames rather than IP entries. This type of inconsistency occurs when one of the "nserver:" attributes does not contain a host name. C. Preventive remedies - Enforcing domain updates to <auto-inaddr(a)ripe.net> We are in the process of integrating <auto-inaddr(a)ripe.net> and <auto-dbm(a)ripe.net>, so that domain updates and other types of updates can be performed from the same source. Until then, in order to prevent further inconsistencies, updates sent to <auto-dbm(a)ripe.net> containing only reverse domain objects will automatically be forwarded to <auto-inaddr(a)ripe.net>. Updates that contain a mixture of domain and other types of objects will be returned to the user unprocessed, warning him/her to split the objects and resend. A separate announcement has already been sent to related mailing lists about this change. D. Clean-up of Inconsistencies The goal of the clean-up is to streamline the contents of domain objects and zone configuration files so that we can create zone files from the Whois Database. If choices have to be made about which data is more accurate , the data in the DNS has prevalence over the data in the Whois Database. The approach followed in the clean-up is to identify inconsistencies, notify the contact persons for the domain objects, provide them with a suggested fix and allow maintainers to fix their objects (details below). After about six weeks the RIPE NCC will send messages about inconsistencies still present in the system. Two weeks after this message has been sent, the RIPE NCC will apply the suggested fix to the domain objects automatically. - Domain objects that do not exist in zone configurations: Contact persons(*) in the domain object will be notified that the object will be deleted by the given deadline unless it is updated. This procedure will be followed even if the domain object contains valid delegation information. Resubmitting the object will ensure that a valid delegation is created in the DNS. - Zone configuration entries that do not exist as domain objects in the RIPE Database: The contact persons(*) in the less specific inetnum object will be notified that, at a given deadline, place holder records in the RIPE Database will be created for these objects. These can be overridden by the maintainer of the inetnum object. The notification contains a suggested domain object that can be modified and submitted before the deadline if the LIR does not want to have a domain object created automatically. - Conflicting entries in the RIPE Database and zone files: Contact persons(*) in the domain object will be notified that the object will be updated to reflect the contents of the delegation NS RR in the reverse zone files by the given deadline. They will be notified that they can fix these entries by updating them. The notification contains a suggested domain object that can be modified and submitted before the deadline if the LIR does not want to have a domain object modified automatically. The clean-up is not meant to solve lame delegation data (e.g. when the NS RRs at the parent side are different from NS RRs at the child side of a zone). Therefore the suggested domain object might not represent the actual set of authoritative nameservers and fail during submission by the maintainer. - Invalid domain objects in the RIPE Database: Contact persons(*) in the domain object will be notified that the object will be deleted by the given deadline. - Invalid "nserver:" attributes in the RIPE Database: Contact persons(*) in the domain object will be notified that the contents of the "nserver:" attributes will be replaced by the entries in zone files if there are any, otherwise the object will be deleted. One IP address may refer to many hostnames, therefore automatically replacing it with its host entry may be erroneous. *: Contact persons are defined by the NIC handles listed in the "admin-c:", "tech-c:", "zone-c:" and the "mnt-by:" attributes of the domain object. E. Timeline - 7/12/2003: Filtering domain updates to <auto-dbm(a)ripe.net>. Domain objects submitted to <auto-dbm(a)ripe.net> are redirected to the <auto-inaddr(a)ripe.net> interface. - 3/12/2003: An announcement will be sent to the Database WG and DNS WG mailing lists - January 2004:Listing inconsistencies and sending notifications to contact persons. - End of February 2004 (announced approximately two weeks before): Cleanup (creation of place holder records and synchronising conflicting entries) This timeline allows for a two month period in which customers are informed and have the opportunity to fix inconsistencies. The end of February milestone is tentative and may extended during the cleanup if unexpected problems are encountered. E. References [1]: Original proposal http://www.ripe.net/reverse/proposal.html. Discussion on this proposal has taken place on the RIPE NCC Services WG mailing list and was summarised in: http://www.ripe.net/ripe/mail-archives/ncc-services-wg/2003/msg00361.html [2]: Early Registration Transfer [ERX] Project http://www.ripe.net/db/erx/erx-ip/ Regards, -- Can Bican Software Engineering Department Olaf Kolkman New Projects Group RIPE NCC

1 0

Re: [db-wg] Proxy abuse
by Thor Kottelin 30 Nov '03

30 Nov '03

> db-wg-request(a)ripe.net wrote: > From: "CMC" <icaliber(a)voicenet.com> > People using proxies on IRC is getting out of hand. On the Undernet as > example, proxy users can abuse a chat channel; be properly banned and > then return with their real hostmasks... > > I realize that the above statement is very general, however if any people > who are channel operators on any IRC chat network have been experiencing > problems with proxies, is there any solutions that the membership can > offer? Channel modes +ikm +s. Bans; if you run out of space, use dynamic, bot-controlled ban lists. On the server level, proxy checks on connect, and K: lines for the worst offenders. (This isn't at all on topic for db-wg, so follow-ups should go elsewhere. Apologies to everyone.) Thor -- http://thorweb.anta.net/

1 0

Proxy abuse
by CMC 30 Nov '03

30 Nov '03

Hi Friends People using proxies on IRC is getting out of hand. On the Undernet as example, proxy users can abuse a chat channel; be properly banned and then return with their real hostmasks... I realize that the above statement is very general, however if any people who are channel operators on any IRC chat network have been experiencing problems with proxies, is there any solutions that the membership can offer? thank you, charles

1 0

RE: [db-wg] ACCESS to INVALID OBJECTS
by Wilfried Woeber, UniVie/ACOnet 28 Nov '03

28 Nov '03

Dear Allen Turner! >Hello, >For some time now we have been expecting to be given direct access to >INVALID OBJECTS via the LIR Portal. Thanks for bringing this to our attention! >This will be a useful tool for a large LIR to run in conjunction with >public Asused. > >Can we be given a realistic date when it's going to be made available? >It's introduction will save time for both LIR's & RIPE NCC. At first glance that seems to be more like an issue for the Services WG? Or are there anything "database technology"-related aspects to be taken care of? >Regards, >Allen Turner >uk.bt LIR Thanks, Wilfried.

1 0