- db-wg - mailman.ripe.net

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

Network Upgrade
by Brian Riddle 27 Jun '06

27 Jun '06

[Apologies for duplicate e-mails] Dear Colleagues, I am pleased to announce that the network is now stable following the recent problems we experienced during last week's network upgrade. We have identified two key issues responsible for the instability. 1. Our current firewalls have been chosen to generously accommodate all previously experienced traffic levels. This is an IPv6 related issue which does not affect the stability of the network. 2. We have agreed with Juniper that this high CPU utilisation is an abnormal state which must be addressed. We have open tickets with our suppliers concerning these issues. The network upgrade has been a long-term project with many carefully planned and implemented steps. It is great to see the end of the tunnel appearing and we thank you for your patience and support in this matter. Regards, Brian Riddle IT Manager RIPE NCC

1 0

Yesterday, 21 June, from 12:54 - 13:29 (CET), the RIPE NCC experienced a,network outage.
by Brian Riddle 22 Jun '06

22 Jun '06

[Apologies for duplicate e-mails.] Dear Colleagues, Yesterday, 21 June, from 12:54 - 13:29 (CET), the RIPE NCC experienced a network outage. The outage was caused by a firewall failure during the implementation of our new network infrastructure. We are currently working with Juniper to investigate the problem. We have scheduled maintenance today, 22 June, from 18:00 - 21:00 (CET) to resolve this. During this time, there will be some interruption to services. We apologise for any inconvenience caused by yesterday's outages and today's scheduled maintenance. If you have any questions, please e-mail: <ops(a)ripe.net> Regards, Brian Riddle IT Manager RIPE NCC -- Brian Riddle RIPE Network Coordination Center IT Manager Singel 258 Amsterdam NL http://www.ripe.net +31 20 535 4444 GPG Key fingerprint = 0EBA E8BA 236A D4CD B7A8 C679 A353 054D 2D35 9BE9

1 0

Bug report
by Max Tulyev 22 Jun '06

22 Jun '06

Hi! I can access to Crypt CGI interface at https://www.ripe.net/cgi-bin/crypt.cgi from 195.209.50.18 (IPv4), but from 2a01:d8:0:99:211:11ff:fe1f:bfc9 (IPv6) I can't. I can see http://www.ripe.net (not https probably?) from both addresses. -- WBR, Maxim V. Tulyev (MT6561-RIPE, 2:463/253@FIDO)

1 0

RIPE NCC (AS3333) Maintenance 18:00 - 21:00 (CEST) Today, June 21.
by James Aldridge 21 Jun '06

21 Jun '06

[Apologies for duplicate e-mails.] Dear Colleagues, The RIPE NCC will carry out emergency network maintenance today, June 21, between 18:00 and 21:00 (CEST). During this time, there will be some interruption to our peerings. This work is part of a programme of ongoing network upgrades. We apologise for any inconvenience that this may cause. If you have any questions, please contact: <ops(a)ripe.net> Regards, James -- James Aldridge, Systems & Network Engineer, RIPE NCC Operations Group Tel: +31 20 535 4444 / Fax: +31 20 535 4445

1 0