- db-wg - mailman.ripe.net

Prototype of RPSLng Whois Server
by DB Role Account 28 Jun '04

28 Jun '04

[ Apologies for duplicate messages ] Dear Colleagues, The RIPE NCC Software Engineering Group provides an RPSLng prototype whois server on host rpslng.ripe.net, port 53001. RPSLng is an effort to extend the RPSL language, enabling the language to document routing policies for the IPv6 and multicast address families currently used in the Internet. The prototype RPSLng whois server has been updated to implement draft-blunk-rpslng-05.txt the latest Internet Draft of the RPSLng effort: ftp://ftp.ripe.net/internet-drafts/draft-blunk-rpslng-05.txt One discrepancy between the draft and the prototype server is that, the optional list of prefixes between the '{' and '}' in the "mnt-routes:" attributes of AUT-NUM and ROUTE6 objects has not been implemented. This functionality will be added later. The prototype database contains a snapshot of the RIPE Whois Database. It can be updated by sending mails to <rpslng-auto(a)ripe.net>. Please note, this database is only for test purposes and updates performed on it will NOT be reflected on the production RIPE Whois Database. The prototype RPSLng server was put into production in May 2003. We have refreshed the contents of the prototype database using a recent snapshot from the live RIPE Whois Database. We have kept the ROUTE6 objects, as well as AUT-NUM objects with "mp-*" attributes, while refreshing the contents. Up-to-date details can be found at: http://www.ripe.net/db/rpslng Regards, Shane Kerr Software Engineering Department Manager RIPE NCC

1 0

Delay in mailed updates to Database
by Shane Kerr 15 Jun '04

15 Jun '04

Colleagues, Due to shortage of free disk space on the main Whois server, mail updates were not processed between 14/06/2004 at 20:30 and 15/06/2004 at 14:00. The problem is now fixed, and updates are being processed normally. Updates that were submitted using Webupdates and Syncupdates were processed during this period without interruption. Apologies for the inconvenience. Best Regards, -- Shane Kerr Software Engineering Department Manager RIPE NCC

1 0

Proposed Change 2004.2: Removal of "referral-by:" Attribute
by Engin Gunduz 14 Jun '04

14 Jun '04

Dear Colleagues, This is a proposed change to improve the content of the RIPE Database. Please review and let us know if you have any comments. [2004.2] Removal of "referral-by:" Attribute from the MNTNER Object ------------------------------------------------------------------- Change: Remove the "referral-by:" attribute from the MNTNER objects' schema. This attribute is currently a mandatory attribute for MNTNER objects. The RIPE NCC will also remove this attribute from all existing MNTNER objects in the RIPE Whois Database. Motivation: The "referral-by:" attribute was introduced into MNTNER objects when the RIPE Whois Database was transitioning from version 2 whois software to version 3, which implements RFC2622 (RPSL) and RFC2725 (RPS Security). "referral-by:" is defined in RFC2725: ============== referral-by This attribute is required in the maintainer object. It may never be altered after the addition of the maintainer. This attribute refers to the maintainer that created this maintainer. It may be multiple if more than one signature appeared on the transaction creating the object. auth-override An auth-override attribute can be added, deleted, or changed by a transaction submitted by maintainer listed in the referral-by. An auth-override can only be added to a maintainer if that maintainer has been inactive for the prior 60 days. The auth-override attribute itself contains only the date when the attribute will go into effect which must be at least 60 days from the current date unless there is already authorization to modify the maintainer. After the date in the auth-override is reached, those identified by the maintainer in the referral-by have authorization to modify the maintainer. This attribute exists as a means to clean up should the holder of a maintainer become unresponsive and can only take effect if that maintainer does not remove the auth-override in response to the automatic notification that occurs on changes. The existing "mnt-by" attribute references the "maintainer" object type. The "mnt-by" attribute is now mandatory in all object types. A new maintainer may be added by any existing maintainer. The "referral-by" attribute is now mandatory in the "maintainer" object to keep a record of which maintainer made the addition and can never be changed. Maintainers cannot be deleted as long as they are referenced by a "referral-by" attribute elsewhere. ============== The RIPE NCC introduced the "referral-by:" attribute as a place-holder, without implementing its functionality. It was thought that the attribute would be useful in the future and make it as compatible as possible with RFC2622 and RFC2725. However, it is now clear that an attribute that is not currently used (and with no plans to use it in the near future) is confusing for the database users. It can easily be re-introduced if the need arises. Regards, Engin Gunduz RIPE NCC Software Engineering Department References: [RFC2622] Routing Policy Specification Language (RPSL) ftp://ftp.ripe.net/rfc/rfc2622.txt [RFC2725] Routing Policy System Security ftp://ftp.ripe.net/rfc/rfc2725.txt

1 0

ANNOUNCEMENT: "auth:" Attribute is Now Searchable
by DB-News 14 Jun '04

14 Jun '04

Dear Colleagues, This is a short announcement to inform you that the "auth:" attribute of MNTNER and IRT objects are now inverse keys, allowing users to search for objects with a specific "auth:" attribute. The schemata of MNTNER and IRT objects are as follows: mntner: [mandatory] [single] [primary/look-up key] descr: [mandatory] [multiple] [ ] org: [optional] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [optional] [multiple] [inverse key] upd-to: [mandatory] [multiple] [inverse key] mnt-nfy: [optional] [multiple] [inverse key] auth: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] referral-by: [mandatory] [single] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] irt: [mandatory] [single] [primary/look-up key] address: [mandatory] [multiple] [ ] phone: [optional] [multiple] [ ] fax-no: [optional] [multiple] [ ] e-mail: [mandatory] [multiple] [lookup key] signature: [mandatory] [multiple] [ ] encryption: [mandatory] [multiple] [ ] org: [optional] [multiple] [inverse key] admin-c: [mandatory] [multiple] [inverse key] tech-c: [mandatory] [multiple] [inverse key] auth: [mandatory] [multiple] [inverse key] remarks: [optional] [multiple] [ ] irt-nfy: [optional] [multiple] [inverse key] notify: [optional] [multiple] [inverse key] mnt-by: [mandatory] [multiple] [inverse key] changed: [mandatory] [multiple] [ ] source: [mandatory] [single] [ ] An example query to find objects with the "auth: PGPKEY-00D69859", would be: $ whois -r -iauth PGPKEY-00D69859 % This is the RIPE Whois server. % The objects are in RPSL format. % % Rights restricted by copyright. % See http://www.ripe.net/ripencc/pub-services/db/copyright.html mntner: ENGIN-MNT descr: Engin's mntner admin-c: EG792-RIPE upd-to: engin(a)ripe.net mnt-nfy: engin(a)ripe.net auth: PGPKEY-00D69859 mnt-by: ENGIN-MNT referral-by: RIPE-DBM-MNT changed: engin(a)ripe.net 20000313 changed: engin(a)ripe.net 20020531 source: RIPE Please note that inverse queries are only possible for PGPKEY and X509 authentication methods. The DES (CRYPT-PW) and MD5 (MD5-PW) encrypted passwords are not inverse searchable due to security concerns. If you have any questions, please do not hesitate to contact <ripe-dbm(a)ripe.net>. Regards, -- Engin Gunduz RIPE NCC Software Engineering Department

1 0

Modifying the ACL for the whois server
by Marwan El-Sherif 07 Jun '04

07 Jun '04

Dear Group, The whois server has a very good feature implemented in it that protects it from any form of abuse by enforcing ACL points. Now because most of our staff are not very familiar with the CLI whois client, we decided to go for a web interface for querying the whois server. So we ran into the problem of the web server's IP being blacklisted. I looked around the configuration of the ACL but could not find any way to exclude such IPs from the 'ACL points' system. We already have the proper protection from any abuse on the web server. We are running the RIPE Whois server 3.0.2. Is there any way to exclude certain IPs from being blacklisted? Regards, Marwan El-Sherif

2 1

problems with NRTM
by Patrick Rother 01 Jun '04

01 Jun '04

Hello. I have a problem with a NRTM running at ripe-dbase-3.2.0 software with mysql "Ver 12.22 Distrib 4.0.20, for pc-linux (i686)", i.e. there are some updates failing: # grep -i failed /opt/whoisd/log/ripupd/* | grep -v " 0 objects failed" | tail -20 ripupdlog_RIPE.20040524: 2 objects failed ripupdlog_RIPE.20040524:[4905870] 0.03s FAILED [inetnum:][M:---] ripupdlog_RIPE.20040524: 1 objects failed ripupdlog_RIPE.20040524:[4905925] 0.00s FAILED [inetnum:][M:---] ripupdlog_RIPE.20040524:[4905934] 0.02s FAILED [as-set:][M:---] ripupdlog_RIPE.20040524:[4905945] 0.00s FAILED [inetnum:][M:---] ripupdlog_RIPE.20040524:[4905959] 0.00s FAILED [aut-num:][M:---] ripupdlog_RIPE.20040524: 4 objects failed ripupdlog_RIPE.20040524:[4906036] 0.00s FAILED [aut-num:][M:---] ripupdlog_RIPE.20040524: 1 objects failed ripupdlog_RIPE.20040524:[4906140] 0.45s FAILED [aut-num:][M:---] ripupdlog_RIPE.20040524: 1 objects failed ripupdlog_RIPE.20040524:[4906209] 0.02s FAILED [inetnum:][M:---] ripupdlog_RIPE.20040524: 1 objects failed ripupdlog_RIPE.20040524:[4906272] 0.02s FAILED [inetnum:][M:---] ripupdlog_RIPE.20040524: 1 objects failed ripupdlog_RIPE.20040524:[4906309] 0.00s FAILED [aut-num:][M:---] ripupdlog_RIPE.20040524: 1 objects failed ripupdlog_RIPE.20040524:[4906377] 0.00s FAILED [inetnum:][M:---] ripupdlog_RIPE.20040524: 1 objects failed # The database was completely rebuilt from the daily snapshot at ftp.ripe.net, but the problem still exists. I also tried ripe-dbase-3.2.0-org-obj-beta, but it segfaults regularly at or after every NRTM run, so it is not usable at all. What can I do to get this fixed? Thank you.

2 1

Question on whois server software & org records
by william(at)elan.net 01 Jun '04

01 Jun '04

Quick question. Does current/latest/beta version of RIPE RPSL whois server now support org records? If not when in your plans will you be releasing server code that would support it? -- William Leibzon Elan Networks william(a)elan.net

2 1

Re: [db-wg] Country attribute to be removed?
by Wilfried Woeber, UniVie/ACOnet 28 May '04

28 May '04

Dear Hank, >Can we have a list of who was in attendance, ...while I think the "who" (explicit list of names) is less relevant, I guess you can get that piece of information from the nice folks at meeting(a)ripe.net ... >and how many people voted in favor of removing the country attribute usually we do not conduct formal votes, but rather try to find a common position regarding a particular proposal. The number of people in the room is (as usual) part of my WG summary report to the plenary which is available from the net at http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-plenary-db.p… >and whether people realized that the country attribute is used by organizations? Yes indeed, please see slide #4, item 1. and slide #5 action point AP 48.1 And in particular there was concern that the use of this entry is less than helpful for some parties because there is no way of making sure that data is "correct" (for any definition of correct [1] :-) and relevant for the particular use... >And what is the rule on consensus - does attendance at the RIPE conference >have more weight than discussion in the online mailing list? Yes, and no, but I presume this is off-topic in that context? >-Hank Wilfried. [1] one of the questions for which we could not find an answer is: which country to put into the object - . the country of residence of the LIR . the country of residence of the admin-c: of an piece of address space? . the country off "deployment" (which is fuzzy in itself...) ______________________________________________________________________

1 0

Country attribute to be removed?
by Hank Nussbacher 28 May '04

28 May '04

From the RIPE 48 minutes provided by Nick Hyrka: >DATABASE WORKING GROUP > >- It was agreed that the 'country:' attribute should be either removed or >be optional. I was not at the meeting but reading over the PDF: http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-db-country.p… I believe the consensus in db-wg was to add a ZZ code and *not* to drop the country attribute totally. Israel uses the country attribute to filter ISP prefixes at its IIX: http://www.isoc.org.il/fr_reload.html?iix/2x_tech.4 When was it agreed to have it removed? -Hank

3 3

Re: [db-wg] Proposal: Abuse-C as a Reference
by Wilfried Woeber, UniVie/ACOnet 13 May '04

13 May '04

>Why do you not just use IRT? > >The prime reason, with which I agree, is that there is this 'mandatory' >encryption field. Two things: I have already polled the CERT community regarding the 'mandatory' for the key-cert attributes. As of today, I haven't heard anything which would prevent us from making those 'optional'. The NCC has confirmed that the modification would be straight-forward (and cheap :-). So this is solved, I think. Wilfried.

4 5