July 2006 - db-wg - mailman.ripe.net

<auto-dbm@ripe.net> is slow this afternoon.
by RIPE Database Administration 17 May '18

17 May '18

Dear Colleagues, Because of a very high level of use this afternoon, the response time of <auto-dbm(a)ripe.net> is longer than normal. I have made contact with those who are responsible and I expect the situation to improve as the machine works through the queue. Please be patient. Obviously we at the RIPE NCC Database Group are continuously working to make the performance of the database as good as possible. However, we cannot make improvements in zero time. We thank you for your co-operation up to now and we ask for your continued co-operation so that everyone receives the best possible service. If you have anymore questions, please contact <ripe-dbm(a)ripe.net>. Regards, Ambrose Magee ____________________________ RIPE Database Administration.

2 2

Re: [db-wg] crypted password
by Max Tulyev 25 Jul '06

25 Jul '06

Markus Werner wrote: > Migration steps. > > - Move all auth: MD5-PW to a new md5-pw object and reference them. > > - At some day it is possible to say that md5-pw are obsolet and deny > creation of new objects. So new users get forced to use a other method. > > - After time you can force users to update the auth method everytime > they need to edit an object. Nice. But seems too soft, and it takes a long time to migrate... My view: - Implement md5-pw object in database - Autocreate md5-pw objects for all existing md5 passwords - Autochange hashed passwords with md5-pw objects - Include "remark: see http://... for what's happened" in chaned objects Like it was in person/org objects when russian area phone codes was changed. -- WBR, Maxim V. Tulyev (MT6561-RIPE, 2:463/253@FIDO)

3 2

crypted password
by Max Tulyev 25 Jul '06

25 Jul '06

Hi! Why not to hide crypted password in mntner objects from public queries? It is so easy to crack now. -- WBR, Maxim V. Tulyev (MT6561-RIPE, 2:463/253@FIDO)

6 10

Proposal to change the syntax of "nserver:" attribute
by Katie Petrusha 11 Jul '06

11 Jul '06

[Apologies for duplicate mails] Motivation: We plan to automate management of DNS delegation in the e164.arpa zone (ENUM). The provisioning system, with the RIPE Database as a front end, must support IPv6 glue records. It must also implement complete and consistent IPv4 glue record support. This will mean making changes to the RIPE Database syntax so that it specifies the glue record and update the delegation checks. This proposal covers that syntax. Proposal: We suggest changing the syntax of the "nserver:" attribute in DOMAIN objects as follows: nserver: [domain_name] /or/ nserver: [domain_name] [ipv4_address] /or/ nserver: [domain_name] [ipv6_address] where [domain_name] is the fully qualified DNS name of the name server without a trailing "." [ipv4_address] is an IPv4 address of the name server [ipv6_address] is an IPv6 address of the name server If [domain_name] is followed by an IP address, it must be inside the zone that is being delegated. Any level of a glue name is supported within the valid domain name syntax. Multiple name server lines will need to be used to specify multiple IP addresses for the same hostname. Examples: The following values would be allowed: domain: example.com nserver: ns1.test.net 168.0.0.1 nserver: ns1.test.net 0::0 nserver: ns1.example.com nserver: ns1.d1.example.com All other variants of the values will be rejected. End-of-line comments starting with '#' will be still allowed. Consequences for existing objects: We will not automatically modify any existing objects. Instead we suggest notifying the maintainers of objects that do not comply with the proposed syntax. This will cover around 150 objects. Consequences for the delegation checks: DNS checks applicable to glue records will be added to the Zone Delegation Checker (http://www.ripe.net/rs/reverse/delcheck/delcheck_descr.html) -- Katie Petrusha RIPE NCC

10 16

Re: Need help with ripe-dbase-2.3
by Denis Walker 10 Jul '06

10 Jul '06

Dear Alex Unfortunately version 2 of the RIPE Database code was taken out of production more than 5 years ago. We have archives of the code but no one at the RIPE NCC works on it now. I am sorry but we are unable to assist you with this problem. I have copied this email to the Database Working Group in case some one in the community can assist you. Maybe there are others still running this version of the code. Regards Denis Walker Software Engineering Department RIPE NCC Alex Moura wrote: > Hello, > > We have been using the ripe-dbase-2.3 sucessfully on a server with > perl-5.00503, but now we are having problems to make it run on a new > server with perl-5.8.8. > The server runs, but dies after sucessfully replying a query, > recording only this error message: > > File: (...)/db-root/log/err/errlog > Fatal error: accept failed: No child processes PID: 98560 > > I'd like to know if this code would work with perl-5.8. I will try to > run it with perl-5.6.2, as it seem to be the oldest version od perl > available at the FreeBSD ports. > > We know this code is old, but I'm hopeful to have some answer about > this issue, once we have made some customizations to fufill our > organization needs, and we'd like to avoid - at least for now - having > to port these customizations to the most recent ripe-dbase code. > > Thank you in advance, > > Alex

1 0

2006-03 Policy Proposal Withdrawn (LIR-PARTITIONED status for IPv6)
by Filiz Yilmaz 06 Jul '06

06 Jul '06

PDP Number: 2006-03 LIR-PARTITIONED status for IPv6 Dear Colleagues The proposal 2006-03, LIR-PARTITIONED status for IPv6 has been withdrawn. The proposer decided that the proposal was no longer necessary. You can find the full proposal at: http://www.ripe.net/ripe/policies/proposals/archive/ Regards Filiz Yilmaz RIPE NCC Policy Development Officer

1 0

Yet another ipv6 bug ;)
by Max Tulyev 03 Jul '06

03 Jul '06

Hi! If I go to www.ripe.net right now and ask for ORG-RL14-RIPE in whois from IP 2a01:d8:0:99:211:11ff:fe1f:bfc9 - I get %ERROR:208: connection refused From IP 195.209.61.241 everything seems to be fine. What is it? -- WBR, Maxim V. Tulyev (MT6561-RIPE, 2:463/253@FIDO)

2 1