- db-wg - mailman.ripe.net

Website/Link in ERROR:201 whois output outdated?
by Sascha Lenz 03 Aug '11

03 Aug '11

Hi, i just realized that at least one of the URLs/links the RIPE-db software hands out seems to be outdated (since the RIPE website redesign?) Someone asked me about an error reply he received while trying to query the db and he found this in an ERROR:201 response : % Sorry, access from your host has been permanently % denied because of a repeated excessive querying. % Please see http://www.ripe.net/db/err201.html <---- % for more information. ...which is 404 Just a heads up. Probably there are more outdated links, we/the NCC might want to check that. I can't reproduce this since i have no blocked IP myself (that i know of), so there is a chance the other person is doing something wrong or got a weird whois client and this is not a problem in the database texts. . o O(and if i'm a total dork than those responses are hardcoded in the client) (P.S.: We're not sure why his IP(v6) address is blocked, but that's a different story) -- Mit freundlichen Grüßen / Kind Regards Sascha Lenz [SLZ-RIPE] Senior System- & Network Architect

1 0

Re: [db-wg] Analysis of MNTNER Authentication
by Denis Walker 28 Jul '11

28 Jul '11

Hi Peter We looked a little deeper into this. We noticed there are only 50 MNTNER objects in the database that do NOT have a password. They use a combination of PGP and/or X.509 only. So we looked at where these MNTNERs are used. There are probably many ways to look at this. The one we chose is how allocated address space is managed by LIRs. So we looked at the "mnt-lower:" on the allocation INETNUM objects. Some of these 50 MNTNERs are used in this way. The "mnt-lower:" allows assignments to be created. So this can be seen as a measure of control over the assigned address space. We calculated the cumulative size of the allocation blocks where one of these 50 MNTNERs is used as the "mnt-lower:" as a percentage of the total allocated address space. Cumulative total of allocations 4722688 using one of these 50 MNTNERS Total allocated address space 555648000 Percentage of address space 0.85% controlled by PGP/X.509 only (without any passwords) For the other 99.15% of address space, there may be a PGP or X.509 credential in the MNTNER object, but in addition to a password. Regards Denis Walker Business Analyst RIPE NCC Database Group On 21/06/11:26 7:14 PM, Peter Koch wrote: > Denis, > > thanks a lot for producing the numbers and information. > >> The next step was to look into the referenced MNTNER objects to see how >> many used password, PGP or X.509, and in what combination and numbers. >> >> MNTNER with one auth containing a password = 27,434 85% >> MNTNER with only password = 27,796 86% >> MNTNER with one auth containing a PGP = 952 3% >> MNTNER with only PGP = 1,507 5% >> MNTNER with one auth containing an X.509 = 16 <1% >> MNTNER with only X.509 = 21 <1% >> MNTNER with password plus either PGP or X.509 = 3,023 9% >> MNTNER with PGP plus X.509 (no password) = 50 <1% >> MNTNER with one password plus multiple PGP = 357 1% >> MNTNER with one PGP plus multiple password = 59 <1% > > in addition to what Shane suggested (which methods are actually _used_), I'd > be interested to learn how large of a percentage of the address space (as opposed to > the number of objects) is covered by "password" authentication. This is > to avoid artefacts by passwords being used for small chunks and PGP/X.509 > for the larger ones - or vice versa. > > Thanks, > Peter >

1 0

New Syncupdates service
by Denis Walker 21 Jul '11

21 Jul '11

Dear Colleagues, As part of the RIPE NCC Database Group's ongoing efforts to improve our infrastructure, we are pleased to announce the launch of a completely re-written Syncupdates service. This new Syncupdates is easier to maintain and improve than the old version, which was written almost ten years ago. The Syncupdates interface for users of the service is unchanged, so from a user viewpoint, nothing has changed. Any software or scripts written to access Syncupdates will continue to work without any need for modifications. A more detailed article will follow shortly on RIPE Labs with additional technical details about the new Webupdates and Syncupdates services. If you do have any problems with the new Syncupdates please contact <ripe-dbm(a)ripe.net>. Regards Denis Walker Business Analyst RIPE NCC Database Group

1 0

DOMAIN attributes review
by Denis Walker 14 Jul '11

14 Jul '11

[Apologies for duplicate emails.] Dear Colleagues, At the RIPE 62 Meeting we were asked to consider the attributes in DOMAIN objects. With the removal of any hierarchy in reverse delegations and the removal of forward domain data there is no longer any use case for the "mnt-lower:" attribute. Other attributes that are considered to be used only for forward domains are: - "refer:" - "sub-dom:" - "dom-net:" The statistics listed below show how many of the above attributes have been added to reverse delegations and ENUMs. The RIPE NCC would like to ask the community if anyone sees any justification for the use of these attributes in reverse delegations or ENUMs. If there is no justification, all four of these attributes can be removed from all DOMAIN objects when the last two TLD operators move their data out of the RIPE Database. This is anticipated to occur by the end of 2011. To keep any discussion focussed please send any comments or feedback to the DNS Working Group Mailing list. Regards Denis Walker Business Analyst RIPE NCC Database Group Statistics ---------- Number of each attribute used in reverse delegations or ENUMs and the number of unique maintainers who manage these objects. "refer:" = 6 unique maintainers = 1 "sub-dom:" = 271 unique maintainers = 23 "dom-net:" = 2219 unique maintainers = 140 "mnt-lower:" = 46485 unique maintainers = 4208

1 0

RIPE Database Query API on RIPE Labs
by Paul Palse 22 Mar '10

22 Mar '10

Dear colleagues, We implemented a RIPE Database Query API in form of a RESTful Web Service. See a detailed description on RIPE Labs: http://labs.ripe.net/content/ripe-database-api We are curious to find out if this is useful and what additional features you would like to see in the future. Please put your comments in the forum set up for this discussion: http://labs.ripe.net/content/ripe-database-api-0 Regards, Paul Palse -- Database Group Manager at RIPE NCC http://www.ripe.net/info/ncc/contact.html

1 0

Call for agenda items, DB-WG Meeting during RIPE60, Prague, CZ
by Wilfried Woeber, UniVie/ACOnet 21 Mar '10

21 Mar '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear DB-WG folks, planning activities for the next RIPE Meeting - RIPE60 in Praha, CZ - have already started, thus this call for agenda items. Please submit (to the WG list!) your item requests and|or suggest topics for discussion to be included in the draft agenda! (I plan to distribute the 1st version of the draft agenda around the 28th of March.) Please note that the DataBase-WG meeting is scheduled for *Thursday* (in the morning, starting at 09:00). The overall RIPE 60 meeting outline is already available at http://www.ripe.net/ripe/meetings/ripe-60/meeting-plan.html Looking forward to a successful meeting and seeing you in Prague, Wilfried. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (MingW32) iQCVAwUBS6Xby9/RXX7wrLNpAQI3NQP/XBLWwyzLo5PfnLSaJk2gfb3YKW+zirb5 7UcNlFmWuxriLtk57YFIbvjl6mrbAA+9dtfm6l8Lt7cZWDdyljDBKL9o33+p+boQ kPyLpDSLoPRIcN6/5cQCxZbHhYd8HTmfvFu4MUGPmRTbQtLJQxvqTsxvxzeiwNI1 um7KUVrwNcA= =cyqz -----END PGP SIGNATURE-----

1 0

Clean-up of backlog of unreferenced personal data completed
by Denis Walker 08 Mar '10

08 Mar '10

[Apologies for duplicate emails] Dear Colleagues, The RIPE NCC has now completed the clean-up of the backlog of unreferenced PERSON and ROLE objects in the RIPE Database. The results of this process can be seen on the RIPE Database inconsistency graph for Unreferenced Person/Role Objects: http://www.ripe.net/projects/dbconstat/cons-unrefpero.html Since this process began, almost half a million objects have been deleted. Our Customer Services Department received only a handful of tickets related to these object deletions. The clean-up script will continue to run and keep the RIPE Database clear of unreferenced PERSON and ROLE objects. For details of this process, see: http://www.ripe.net/db/support/unreferenced-personal-data-clean-up.html Users of the RIPE Database should only create these objects containing personal data when there is a need for them. They should not be created until there is an imminent need to reference them. Regards, Denis Walker Business Analyst RIPE NCC Database Group

1 0

Ripe DB mirroring
by mfaraji＠aut.ac.ir 08 Mar '10

08 Mar '10

Hi I want to build a database like ripe. But I only want to store information about ip addresses of my country. I downloaded your software. How can I download objects which are related to ip addresses of my country? Thnaks,

2 1

Clean-up of unreferenced personal data in RIPE Database
by Denis Walker 23 Feb '10

23 Feb '10

[Apologies for duplicate emails] Dear Colleagues, The RIPE NCC Database Group has restarted the clean-up of unreferenced personal data. This follows the process outlined in the document recently published at: http://www.ripe.net/db/support/unreferenced-personal-data-clean-up.html Regards Denis Walker Business Analyst RIPE NCC Database Group

1 0

Mandatory maintainer on PERSON and ROLE objects
by Denis Walker 18 Feb '10

18 Feb '10

[Apologies for duplicate emails] Dear Colleagues, The Data Protection Task Force asked the RIPE NCC to enforce maintaining all data in the RIPE Database. Currently, the "mnt-by:" attribute is optional in PERSON and ROLE objects. The RIPE NCC has now made this attribute mandatory in both these object types in a test environment. We recommend that anyone who uses automated scripts to generate or modify these objects should test their procedures and scripts against the test facilities. The test server has a recent copy of the RIPE Database data. One significant effect of this change is the circular dependency between PERSON and MNTNER objects. For a new user with no data in the RIPE Database, these two objects must be created together. This cannot be done by the normal update methods. There is a new user start-up interface that creates this pair of objects: https://www.db.ripe.net/cgi-bin/new-user-startup.pl This start-up process is described in the new RIPE Database Update Reference Manual: http://www.ripe.net/db/docs.html The test service is available on a test server at the following URL: whois-mandatory-mntby.db.ripe.net Queries to this database instance can be directed to: whois-mandatory-mntby.db.ripe.net:43 Email updates can be sent to<auto-dbm-mandatory-mntby(a)ripe.net>. Synchronous updates are available at: https://syncupdates-mandatory-mntby.db.ripe.net/ Near Real-Time Mirror (NRTM) access is available at: whois-mandatory-mntby.db.ripe.net:4444 Regards Denis Walker Business Analyst RIPE NCC Database Group

1 0