- db-wg - mailman.ripe.net

Re: ripe-db question
by Brent_Frere＠ses-astra.com 31 Aug '00

31 Aug '00

We (SES, Societe Europeene des Satellites, operator of Astra satellite system) assign IP addresses to end-customers who are using our Internet access by satellite. The only geographic limit we are sure about them is that they are in the Astra satellite system footprint... Footprint is visible at http://www.ses-astra.com/multimedia/bbi So I think this might slighly change your statistics if you count all them as Luxembourg citizens... Brent Frere, SES (Astra) Chateau de Bezdorf L-6815 Betzdorf Grand-Duchy of Luxembourg General phone: +352-710.725-1 Direct phone: +352-710.725-401 E-mail: bfrere(a)ses-astra.com URL: http://www.ses-astra.com "mediaWays Hostmaster" To: lir-wg(a)ripe.net, db-wg(a)ripe.net <hostmaster@medi cc: aways.net> Subject: ripe-db question Sent by: owner-lir-wg@rip e.net 08/30/00 05:23 PM Hi, some strange question: we need a complete list of assigned IP-Addresses in the european part of ripe region sort by country for a customer. Is there any chance to get it per whois/some application or do we buy some part of whois-db from ripe? The background is that a Online-Service needs this part of information to display the right website (on his top-level Webserver wich are reached by every online user first) for every user by his language. We are grateful for each assistance. Kind regards, _____________________________ Stephan Mankopf Networks/Backbone +49 5241 80 88729 stephan.mankopf(a)mediaways.net

1 0

RE: ripe-db question
by Stefan.Gasteiger＠Gendorf.de 30 Aug '00

30 Aug '00

You should use MIME content negotiation for this purpose. Have a look at: http://www.apache.org/docs/mod/mod_mime.html#multipleext Stefan Gasteiger SG5599-RIPE I+K Betrieb (zertifiziert nach DIN EN ISO 9001) InfraServ Gendorf Tel.: +49 8679 7 5599 Fax: +49 8679 7 39 5599 Mobiltel.: +49 172 8649205 E-Mail: Stefan.Gasteiger(a)gendorf.de > -----Original Message----- > From: mediaWays Hostmaster [mailto:hostmaster@mediaways.net] > Sent: Wednesday, August 30, 2000 4:24 PM > To: lir-wg(a)ripe.net; db-wg(a)ripe.net > Subject: ripe-db question > > > Hi, > > some strange question: > we need a complete list of assigned IP-Addresses > in the european part of ripe region sort by country > for a customer. > Is there any chance to get it per whois/some > application or do we buy some part of whois-db from ripe? > > The background is that a Online-Service needs this part > of information to display the right website (on his top-level > Webserver wich are reached by every online user first) > for every user by his language. > > We are grateful for each assistance. > > Kind regards, > _____________________________ > Stephan Mankopf > Networks/Backbone > +49 5241 80 88729 > stephan.mankopf(a)mediaways.net > > > > >

1 0

Draft Minutes of the DB WG meeting RIPE 36
by Nigel Titley 29 Aug '00

29 Aug '00

Gentlefolk, Here are the draft minutes to the DB WG meeting at RIPE 36, in Budapest. Due to a fit of spring-cleaning, I ended up deleting my notes of the first part of the meeting. Please feel free to fill any gaps and correct any errors. best regards Nigel Draft Minutes for the Database Working Group Meeting RIPE-36, May 2000, Budapest, HU 1. Draft Thursday, May 18, 2000 at 10:30 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ A. Administrative stuff (Wilfried Woeber, chair) . scribe Nigel Titley volunteered to take the minutes . raw scribe notes distributed Wilfried had not had time to process the raw notes from RIPE 35, but these were circulated in lieu of full minutes. . help offered by - Nigel Titley, - Ulf Kieber Wilfried asked the WG if they were happy to accept the help offered by Nigel Titley and Ulf Kieber. Nigel would help with the PR and documentation side of the group, and Ulf will help to co-ordinate the working group. He received approval from WG on this issue. B. RIPE DB, operational update (Andrei Robachevsky, RIPE NCC) Andrei Robachevsky gave an operational update on the state of the RIPE DB. Amongst the many statistics that he presented it was noted the very large number of domain objects, mostly from the .de domain. It was explained that these objects would be shortly devolved to the DE-NIC whois server, and plans were currently being formulated to perform this move with minimum disruption to the RIPE community. C. DB Software Re-Implementation (Joao Damas, RIPE NCC) Joao Damas gave a short presentation on the progress of the DB Software re-implementation project. D. Report on Certification Authority activities (Paul Gampe, APNIC) Paul Gampe gave a very interesting presentation on the use of X509 certificates for authentication when updating the APNIC database. The following points were noted: - Training at the next RIPE meeting might be useful, to provide a view of X509 vis-a-vis PGP. There appears to be a degree of convergence between the two systems. - It was noted that it will be soon possible to sign X509 keys with PGP signatures and vice versa. - The main objection to using X509 is the cost of the commercial licenses. The first phase of the implementation will sort out licenses for users. Much cheaper (free) approaches are on their way. E. Activity Plan for next year! It was noted that input to the RIPE-NCC activity plan was needed before September. Suggestions received from the WG included - Use of X509 signature for authentication (as per APNIC) - Support for other character sets than ASCII. (Joao noted that the new code is 8-bit clean, but that there is problem wit the reproduction of character sets. The best he felt able to do was to track progress by other sources, and to keep the code clean). - Removal of further domain objects from the database. The problem being that existing applications must not be affected. It was suggested that the RIPE-NCC could offer help to other ccTLDs to set up their own whois databases. It was suggested that we ask CENTR to produce a regular report and to try and get domain objects shifted out of the DB. [AP: Wilfried Woeber and Joao Damas] F. Input from other WGs - EIX-WG would like an object in the DB to describe IXs. It was also suggested that a peering contact in the aut-num object could be useful. There was some support for both these proposals and it was suggested that a formal request be made to the WG by email. - Routing WG. No further input had been received from the Routing WG re native multicast. It was felt that this would soon need looking at. The Routing WG needs to add an entry to the RPSL Draft. G. AOB - A suggestion (Joel Rowbottom) was made to use XML for registration templates. Suggestions as to how to do this would be gratefully received. [AP: Joao Damas to produce a presentation for the RIPE 37 meeting] - A suggestion to use a mail-to authentication scheme was received from Michael Battilana (IANA). The idea being that agreement to proceed with a modification would be obtained via a token and confirmation from a know mail mail address. It was agreed that this was not very easy to do as it is stateful and could lead to DOS attacks on the database. - A brief update was given on CERT/IRT-related issues (WW144/Jaques Schuurman). Ut was suggested that a pointer be added to inet-num object to point to the IRT role. Anyone interested in this work to contact the WG.

1 0

Whois queries in the RIPE database v3.0
by Andrei Robachevsky 28 Aug '00

28 Aug '00

Dear Colleagues, Please find below an inventory of the query part of the new database software (v3.0). I tried to highlight the differences from the current RIPE Database implementation, but also to explicitly mention some features of the current software that were not documented before. Most of this document is a summary from a more detailed documentation, which is available from http://www/ripencc/pub-services/db/reimp/queries.ps However, some features, like '-d' or '-q sources' flags, are new and we would like to know your opinion and comments on these. Almost all functionality is already implemented, although some minor parts are missing, mainly because we would like to receive your comments first. We will appreciate your comments and suggestions, Best regards, Andrei Robachevsky DB Group Manager RIPE NCC Whois queries in the RIPE database v3.0 ======================================= 1. New queries -------------- -l <ip range> One level less specific. Does NOT return the exact match but only the smallest of the IP ranges that is bigger than the user supplied range and that fully contains it. -x <ip range> Exact match. Returns the inetnum or route object with the ip range matching exactly the user supplied range. If no matching object is found nothing is returned. -K Requests that only primary keys of the objects are to be returned. The exception is a set object, where the members attribute is also returned. -q sources List all available sources. The format of the output is: <source>:<NRTM protocol version>:<mirroring>:<first>-<last> Where <source> - is the string that identifies the Database (e.g. RIPE) NRTM protocol version identifies the version of mirroring protocol (currently 1). <mirroring> can take one of the following values: Y/N/X - can mirror/cannot mirror/obscured <first> is the lowest serial number available <last> is the most recent serial number available The following semantics apply: Y:<first>-<last> mirroring allowed, serials from range <first>-<last> available N:<first>-<last> mirroring not allowed for administrative reasons. Ask Database Administration for permission. N:0-<last> mirroring physically not possible (e.g. static snapshot of serial <last>) X:<msg> no mirroring allowed. An explanation is given in <msg>. -q version Displays version number of the server software. -d Triggers inclusion of in-addr.arpa and ip6.int domain objects in the result of IP lookup. By default in-addr.arpa and ip6.int domain objects are not included in the output. With -d flag it is possible to have More/less specific lookups for in-addr.arpa and ip6.int domains. Their use is similar to those for IP numbers except that lookups have to be on 8 bit boundaries for IPv4 lookups and 4 bit boundaries for IPv6 lookups. 2. Inverse queries. ------------------ The following inverse queries are supported by v3.0 software: -iac (or -iadmin-c) <nic-handle|name> Returns all objects whose admin-c attribute matches the query argument. -itc (or -itech-c) <nic-handle|name> Returns all objects whose tech-c attribute matches the query argument. -izc (or -izone-c) <nic-handle|name> Returns all objects whose zone-c attribute matches the query argument. -iah (or -iauthor) <nic-handle|name> Returns all objects whose author attribute matches the query argument. -icn (or -icross-nfy) <nic-handle|name> Returns all objects whose cross_nfy attribute matches the query argument. -ipn (or -iperson) <nic-handle|name> Equivalent to -iac,tc,zc,ah,cn (or -iadmin-c,tech-c,zone-c,author,cross-nfy). -iny (or -inotify) <e-mail address> Returns all objects whose notify attribute matches the query argument. -idt (or -iupd-to) <e-mail address> Returns all objects whose upd-to attribute matches the query argument. -imb (or -imnt-by) <maintainer name> Returns all objects whose mnt-by attribute matches the query argument. -iml (or -imnt-lower) <maintainer name> Returns all objects whose mnt-lower attribute matches the query argument. -imr (or -imbrs-by-ref) <maintainer name> Returns all objects whose mbrs-by-ref attribute matches the query argument. -imn (or -imnt-nfy) <e-mail address> Returns all objects whose mnt-nfy attribute matches the query argument. -imu (or -imnt-routes) <maintainer name> Returns all objects whose mnt-routes attribute matches the query argument. -ict (or -icross-mnt) <maintainer name> Returns all objects whose cross-mnt attribute matches the query argument. -ior (or -iorigin) <AS key> Returns all objects whose origin attribute matches the query argument. -ila (or -ilocal-as) <AS key> Returns all objects whose local-as attribute matches the query argument. -imo (or -imember-of) <set name> Returns all objects whose member-of attribute matches the query argument and their claim is validated by mbrs-by-ref attribute of the set. Absence of mbrs-by-ref attribute means that the membership is only defined by the members attribute of the set. -irz (or -irev-srv) <hostname|IP address> Returns all objects whose rev-srv attribute matches the query argument. -ins (or -inserver) <hostname|IP address> Returns all objects whose nserver attribute matches the query argument. -isd (or -isub-dom) <domain name> Returns all objects whose sub-dom attribute matches the query argument. -irb (or -ireferral-by) <maintainer name> Returns all objects whose referral-by attribute matches the query argument. 3. Other differences from v2.x software --------------------------------------- -iro (or -irole) <nic-handle|name> This query is not supported. -k Is accepted without an argument. In this case it just opens a persistent connection to a server. The next -k without argument will close the connection.

1 1

RE: ccTLD data moving from RIPE db
by Wilfried Woeber, UniVie/ACOnet 17 Aug '00

17 Aug '00

[ editorial: I think this should move from lir-wg(a)ripe.net to db-wg(a)ripe.net So, for any follow-up, please use db-wg and remove lir-wg. Thanks. ] Alex, >Then today I got a mail from the .IE domain registry, asking me to remove >entries from the RIPE DB for some .ie domains I have. The RIPE NCC, or the RIPE community never had any authority over the ccTLD name tree in the RIPE-DB. The individual sub-trees were (some still are) managed by the respective TLDs. So, from that point of view, the request in itself is probably valid. > So far so good, >except that the .ie domain registry does not have a functional whois >database to which we can move this data. If I comply, the data will no >longer be accessible from any whois databse. Well, not necessarily so. What "we" (the people and groups involved to migrate the name sub-trees to dedicated registries, maintined by the TLDs) had in mind was to preserve the "single point of entry" for the RIPE region to query domain names. To that end, the DB software was extended to support a referral mechanism. Assuming that this technology is deployed, you could still send your query to whois.ripe.net and the software would try to find a referred-to server which is authoritative for the name-tree. The RIPE server would then forward the request and send the answer back to the client. Quite a few TLD registries, which already have moved away from using the RIPE DataBase have completed that setup. Others are in the process of fixing migration problems. Other, obviously, have decided to _not_ use that option. Sigh. I'm still working with the RIPE NCC's DB group and CENTR to fixing deployment problems related to the referral mechanism. A couple of days ago, a summary page has become available on CENTR's server: http://www.centr.org/technical/ripe-db.html >Is this therefore a valid request? > >Thanks, Best regards Wilfried (DB-WG chair) _________________________________:_____________________________________ Wilfried Woeber : e-mail: Woeber(a)CC.UniVie.ac.at UniVie Computer Center - ACOnet : Tel: +43 1 4277 - 140 33 Universitaetsstrasse 7 : Fax: +43 1 4277 - 9 140 A-1010 Vienna, Austria, Europe : RIPE-DB: WW144, PGP keyID 0xF0ACB369 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~:~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The strange thing about common sense is that it is so uncommon. Buddah

1 0

RIPE-181 server to be decommissioned
by gerald＠merit.edu 11 Aug '00

11 Aug '00

As many of you know, Merit began a production RPSL service on 11/1/99. RIPE-181 and RPSL coexisted on our production server until 1/1/00; after that date, RIPE-181 updates were no longer accepted and only queries were available on the special RIPE-181 server. Merit will now complete the final stage of its transition to RPSL by decommissioning its RADB RIPE-181 server on Wednesday, August 23, between 5:00-8:00 A.M. EDT. Query activity has been extremely light on the RIPE-181 server and the remaining users have been notified by private email about the termination of this service. This change will not impact our production RPSL service. Please send your questions and comments to db-admin(a)radb.net. IRRd Team --Gerald Winters

1 0

RIPE whoisd re-implementation: RIP-0.4.0beta1 software snapshot
by RIPE NCC Staff 07 Aug '00

07 Aug '00

Dear All, this mail is to notify you of the further advancements in the development of the new implementation of the RIPE Database software. Today, we have freezed the source code into a new snapshot. There has been a certain amount of changes from the last snapshot. Multiple repository support has been added, a test mode is now available to update the database, MIME messages are now supported by dbupdate, the configuration module has been integrated, and many bugs have been fixed. You can download this last snapshot at the following URL: ftp://ftp.ripe.net/ripe/dbase/reimp/RIP-0.4.0beta1.tar.gz You can also test the functionality of this snapshot of the RIP whois server in 2 ways: - By querying the host reimp.ripe.net at port 43; you will find there a Near-Real-Time Mirror of the RIPE Database. - By using the RIP Test Database. You can send test updates to this database at the address <rip-test(a)ripe.net>, and you can query this database at reimp.ripe.net port 4343. This database is running in test mode, so you can create any type of objects there, even maintainers. We would be very pleased if you could test the new implementation in both ways, and let us know your opinions. Please send your comments and bug reports to the <db-beta(a)ripe.net> mailing list. To subscribe to this list, send a message to <majordomo(a)ripe.net> with the line: subscribe db-beta in the body of your letter. This is a moderated mailing list so some delays in subscription are possible. Regards, Filippo Portera ____________________________ RIPE Database Administration.

2 1

PGPKEY Reminder
by gerald＠merit.edu 27 Jul '00

27 Jul '00

On 7/30/00 between 5 AM - 8 AM EDT Merit will convert from 'PGP-FROM' to 'PGPKEY' authentication as described in RFC 2726. All maintainer object 'PGP-FROM' instances will be converted to a 'PGPKEY' instance and a 'key-cert' object will be created for each unique 'PGPKEY' instance. After the conversion all public keys used for signing DB submissions will be visible in the registry as 'key-cert' objects. Registering public keys allows users to verify a maintainer's identity and to submit, update and maintain their own public keys like any other DB object. Normal PGP signing of DB submissions will continue to work exactly as before the conversion. The conversion should be seamless to our DB user community and no action is required. Merit has sent email to all users who will be affected by the conversion. The new 'PGPKEY' scheme makes it easier for users to integrate PGP signing into their DB update process. It is our wish that into the future all registry users will PGP sign their DB submissions. Please see www.radb.net/docs/keyfaq.html for additional information on the conversion process and tutorial information regarding the use of 'PGPKEY' authentication. Please consult RFC 2726 for the authoritative specification. IRRd team --Gerald Winters

1 0

***Announcement: Merit to convert to 'PGPKEY' authentication (RFC 2726)
by gerald＠merit.edu 18 Jul '00

18 Jul '00

On 7/30/00 between 5 AM - 8 AM EDT Merit will convert from 'PGP-FROM' to 'PGPKEY' authentication as described in RFC 2726. All maintainer object 'PGP-FROM' instances will be converted to a 'PGPKEY' instance and a 'key-cert' object will be created for each unique 'PGPKEY' instance. After the conversion all public keys used for signing DB submissions will be visible in the registry as 'key-cert' objects. Registering public keys allows users to verify a maintainer's identity and to submit, update and maintain their own public keys like any other DB object. Normal PGP signing of DB submissions will continue to work exactly as before the conversion. The conversion should be seamless to our DB user community and no action is required. Merit will send email to all users who will be affected by the conversion. The notice will give users a chance to remove their PGP references if (for whatever reason) they do not wish to take part in the new PGP authentication scheme. The new 'PGPKEY' scheme makes it easier for users to integrate PGP signing into their DB update process. It is our wish that into the future all registry users will PGP sign their DB submissions. Please see www.radb.net/docs/keyfaq.html for additional information on the conversion process and tutorial information regarding the use of 'PGPKEY' authentication. Please consult RFC 2726 for the authoritative specification. IRRd team --Gerald Winters

1 0

New object
by Stephen Burley 11 Jul '00

11 Jul '00

Hi I have a quick question has any ever thought of creating a company object, which is much the same as a person object but it means that any range of IP's assigned to a company will easily be traced. Making it easier to find the total amount IP space assigned to a company/org , which frankly at the moment is impossable. Regards -- ------------------------------------------------------------------------ Stephen Burley "If patience is a virtue, and ignorance is bliss, UUNET EMEA Hostmaster you can have a pretty good life Stephenb(a)uk.uu.net if you're stupid and willing to wait" ------------------------------------------------------------------------

4 6

Duplicate mails
by NCC local-ir list Moderator 07 Jul '00

07 Jul '00

Dear subscribers, Please notice that we are experiencing some strange mail behaviour at the moment. The previous mail from Mr Henning Brauer seems to have been re-sent to the lists in error. We are not sure of the cause yet. Before replying to what may seem like an old thread, please check the sent date. We will endeavour to prevent any more of these mails leaking through. Regards, John Crain Head of Internal Services

1 0

RE: a few matters about security and consistency
by adrian.pauling＠bt.com 06 Jul '00

06 Jul '00

Dear All, Issue 1 is of interest to anyone involved with RIPE database. It must be in the RIPE communities interest to keep data as up to date and accurate as possible. Auditing is a resource hungry task and a pain in the asynchronous port, but is necessary to maintain and improve the quality of the data within the database. Is it acceptable for RIPE database to periodically, say once a year, to contact via e-mail each person and role object? The objective would be to ensure the person / role object are up to date. If there was no response, perhaps within a 4 week period, any associated maintainer object could be used to identify other people who could up date the records. If there is no maintainer, then a RIPE Hostmaster maintainer or notify attribute could be added to the record - and mark the record as out of date as appropriate . This would be a small overhead to everyone who is on the RIPE database that would ensure and improve the integrity of data within the database, for a piece of work on the database. From below, there is a possibility of up to 10 % of records on the database being inaccurate. That can not be an acceptable situation. Issue 2 is beyond the direct scope of the LIR-WG. However, I recollect that at RIPE 35 there was a suggestion of adding a new database record to the RIPE database, to clearly identify those networks which had a CERT team - has any progress been made? Regards, Adrian F Pauling :-)NEL2C Internet Protocol Manager acd Information Systems Engineering Technical Architecture AFP1-RIPE / AFP-ARIN / AFP25-InterNIC * adrian.pauling(a)bt.com * +44 19 2685 1992 / +44 78 0290 4877 British Telecommunications plc Registered Office 81 Newgate Street London EC1A 7AJ Registered in England no 1800000 > -----Original Message----- > From: Mark Lastdrager [SMTP:mark@pine.nl] > Sent: 05 July 2000 21:53 > To: lir-wg(a)ripe.net > Cc: cert(a)pine.nl > Subject: a few matters about security and consistency > > Hi, > > There are two matters I want to discuss, which are related from my point > of view. > > Yesterday, ons of our hosts was attacked (Denial of Service). The attacker > was using the DNS DOS described in > http://www.ciac.org/ciac/bulletins/j-063.shtml (AUSCERT AL-1999.004) for > this. > > The used attack in short: Small DNS queries are sent from the attacker > to each of the DNS servers. These queries contain the spoofed IP address > of the target. The DNS servers respond to the small query with a large > response. These responses are routed to the target, causing link > congestion and possible denial of Internet connectivity. > > This morning, we took our tcpdump logs of the attacks, and built a script > which queried the Ripe database for the admins of the abused > ('man-in-the-middle') networks. We got almost 900 unique email adresses > out of this, to whom we sent a clear email describing what happened and > asking for any logs or other usable information to find out who the > attacker is. We we astonished how many people reacted with usefull > information, we are still investigating right now. > > It pointed out we were not the only one attacked, it now looks like the > attacker (or attackers ofcourse) is abusing most of the 194.x network to > amplify the DNS requests pointing at a lot of Dutch hosts and even some > in the USA. > > Ok, that was the scary part ;-) If you operate 1 or more DNS servers, > please read the AUSCERT document and apply the workarounds they mention > there (only allow your nameserver(s) to answer to queries from trusted > hosts and/or zones you are authoritive for). If will really help from > people abusing your network and filling up your pipe(s). > > Matter 1: > > What scared me was the great amount of bounced mail we got back from the > 900 mails we sent. I think at least 10% did not exist. Besides that we got > a lot of replies like 'hey don't bother me, I don't work there > anymore'. Why doesn't RIPE test periodically if email adresses still work? > > > Matter 2: > > Like I said, we got a lot of useful replies and they all more or less > contained the same information. People had full, non-working internet > links for days because of the attacks and were very happy that we pointed > them to the 'Auscert workaround' because now they've closed their DNS'es > the traffic (and business!) goes back to normal. Because of the info we > got, we are -while I write this- trying to trace back to the origin of the > spoofed packets. > > I think it would be very helpful if there was a mailinglist where European > operators could discuss this kind of incidents, like the USA people do at > the Securityfocus mailinglist > (http://www.securityfocus.com/templates/archive.pike?list=75). I think the > introduction at http://www.securityfocus.com/forums/incidents/intro.html > would describe the use of such a list very well. Incidents like this DOS > which affect a lot of European networks could be stopped much quicker, and > if you can contact your fellow operators you don't have to waste expensive > time trying to track down those stupid scriptkids (believe me.. it takes a > lot of time ;-)). Ofcourse things like virii, talk about used exploits > etc. are on-topic and interesting too. > > Like I said: time is money, so we set up the list > euro-incidents(a)security.nl already. Anybody can subscribe at > http://www.security.nl/mailman/listinfo/euro-incidents. > > Thanks for your time, > > Mark Lastdrager > Pine Internet > > -- > email: mark(a)lastdrager.nl :: ML1400-RIPE :: tel. +31-70-3111010 > http://www.pine.nl :: RIPE RegID nl.pine :: fax. +31-70-3111011 > PGP key ID 92BB81D1 :: Dutch security news @ http://security.nl > Today's excuse: We only support a 28000 bps connection. > > > > >

1 0

Re: Antwort: Re: Antwort: Re: AW: AW: Deletion of .de domain objects
by henning.brauer＠bsmail.de 03 Jul '00

03 Jul '00

----- Forwarded by Henning Brauer/BSWS/DE on 30.06.00 13:16 ----- Henning Brauer To: "Sabine Dolderer/Denic" <dolderer(a)denic.de> 30.06.00 13:14 cc: Subject: Re: Antwort: Re: Antwort: Re: AW: AW: Deletion of .de domain objects (Document link: Henning Brauer) a) agree. But the Maintainer-Scheme works really good, so I do nao see any reason for changing this. b) Just one Example (now): bss004:~ # whois -h whois.denic.de NOC54-RIPE Connection refused; server has reached maximum number of clients. Anonther: dns.denic.de didn't answered authoritative for de-Domains Yesterday evening... c) No One would sya anything if you would just take the ripe-solution so we had to change email-adress for updates. Even other changes, like source: and perhaps phone, fax and so in beeing optional, would be acceptable. But there is no doc how updates will be made! d) customers do agree to this when putting ther data in the DB. As I said before: Just make phone and fax optional, everbody will agree. If it would be true what you are saying here, even Telephone books would be illegal. e) just compare whois -h whois.ripe.net NOC54-RIPE with whois -h whois.denic.de NOC54-RIPE. I'd like to show you this here, but DENIC's whois-Server is not reponding. The problem is that if you di an whois-query for an .de-Domain (in most cases using one of the web-interface) you'll see the crippeled data from ther denic whois-db. f) means there will be costs? You do not answer the question here. g) answer? Thanks for participationg this discussion. But why was this discussion not possible before doing the move?? As said before: RIPE-Meetings and hostmaster-list ARE closed communities, the db-wg(a)ripe.net would have been the right place. Greetings Henning Brauer Hostmaster BSWS ------------------------------------------------ BS Web Services Roedingsmarkt 14 20459 Hamburg Germany info(a)bsmail.de www.bsws.de fon: +49 40 3750357-0 fax: +49 40 3750357-5 PLEASE USE EMAIL WHERE POSSIBLE "Sabine Dolderer/Deni To: henning.brauer(a)bsmail.de c" cc: db-wg(a)ripe.net, info(a)denic.de, lir-wg(a)ripe.net, robert(a)martin-legene.dk <dolderer@den Subject: Antwort: Re: Antwort: Re: AW: AW: Deletion of .de domain objects ic.de> 30.06.00 12:44 Hello, On 30.06.00 11:07 henning.brauer(a)bsmail.de wrote: > > > Hi, > > thats not really the point of our critics. > a) changes only be made by members???? as every DE-domainowner is our customer and we are responisble to him about the security of his domainname we must assure that changes are made in a verifyable and accountable way. It is important that there is a documented responsibility. > b) technical solution - RIPE's solutions are working really good, DENIC's > past solutions are poor no comment. > c) change in interfaces not acceptable changes in interfaces are sometimes necessary. But I am with you that this should happen very rarely and should be prepared very well and people should be informed very soon -- but we tried to make all this. > d) contact info's, especially phone and fax, are REALLY important for the > hostmasters to inform each other about technical probs. If this could be > against German's laws, just make these fields optional. we are only allowed to publish these things if the custoumer have signed that he allows the publishing. Currently we think that from nearly none of the persons in the RIPE-DB this allowence is there. For the future we plan to let the people the choice to publish these data. > e) putting so named "non-operational data" or "test data" which is > incomplete and partly incorrect in production systems (it IS in > productionis - just do an whoi-query...) is not acceptable sorry I don't understand these point. Maybe you can show me an example of these "test data". > f) plans making life for non-members harder -> DENIC tries to get more > payin' members???? As we are working on a costrecovery base (non-profit) more members don't means automatically more income. But surely are we are interested in organisations taking the responsibitlity and sharing the risk to run the German Registry as a self regulating body for the benefits of the German Internet Community. > g) plans to charge for person: and role: records? > h) to be continued... Regards Sabine > > pls see http://denicpetition.bsws.de > > Greetings from Germany > > Henning Brauer > Hostmaster BSWS > > ------------------------------------------------ > BS Web Services > Roedingsmarkt 14 > 20459 Hamburg > Germany > > info(a)bsmail.de > www.bsws.de > > fon: +49 40 3750357-0 > fax: +49 40 3750357-5 > > PLEASE USE EMAIL WHERE POSSIBLE > > > > "Sabine > Dolderer/Deni To: henning.brauer(a)bsmail.de > c" cc: db-wg(a)ripe.net, info(a)denic.de, > lir-wg(a)ripe.net, robert(a)martin-legene.dk > <dolderer@den Subject: Antwort: Re: AW: AW: > Deletion of .de domain objects > ic.de> > > 30.06.00 > 10:39 > > > > > > > Hello, > > speaking for DENIC ;-). I will try to comment about the reasons why we > have (or even must) done the migration. > > First of all I want to try to summarize the problems we are faced in the > past and then I will come to an explanation of the solution we choose. > > Problems: > > There were a lot of discussions in the past about domain-objects in the > RIPE-database and that they cause too much capacity for RIPE to maintain > their database for this amount of objects. > > There was a common understanding that RIPE is not a service provider for > domainregistries like ccTLDs but there were indeed suggestions to offer or > assist us in this kind of service. > > There were a lot of pressure from our dataprotection office that due to > our business we pubish data (or we urge provider to puplish data of their > customers) which is not allowed to publish under German data protection > laws. Mainly the existence of the inverse query feature and the publishing > of data like phone-, faxnumbers and email addresses was critisized. > > We have had also a lot of discussions about the issue with other ccTLDs > and with people from the EU commission. The fundamental outcome of these > discussion was that there is no real issue to export personal data from > the coutries to acentral database and that this should therefore stopped > very soon. If the data is stored locally everybody can impose individually > there dataprotection laws. Nevertheless there should be a central > entrypoint to look for domain-data and therefore we support the RIPE > referal mechanism and are looking together with other ccTLDs and the db-wg > from RIPE at solutions like using the SRV-RR for whois-queries (see > rfc2782 for a documentation) > > Solution > > So as I pointed out above there was no other solution than to migrate the > domainobjects to a DENIC based domainquery mechanism. People who followed > the discussion know that DENIC is on there way out of RIPE. Actually it > was a dicission made by the RIPE db-wg in Amsterdam (February?) that there > should be no domainobject in the database after June 30th. > > Why do we publish less data than RIPE does? > > I have tried to explain it also above due to German dataprotection laws we > are allowed to publish only "necessary data" without formal agreement with > the applicant. > > Whats necessary concerning a domainname? > > We agreed with the people from the dataprotection office that there is no > necessity to no more about a admin-c of the domain than his address > because if you need for legal issues to come in contact with him thats the > only thing you need. > > Concerning the tech-c and the zone-c he finally agreed that there is a > necessity due to technical urgencies to publish phone and email-addresses > and so we will implement this very soon. > > I hope I have help you a little bit in understanding our position. I am > really sorry that due to this discussion I get the feeling that people > felt we are doing things without thinking or good reasons or just to make > them angry. I hope you see there are - as usual - two sides of a medal and > you see know the other side a little bit better, > > Regards Sabine > > > On 30.06.00 09:39 henning.brauer(a)bsmail.de wrote: > > > > > > Hi, > > > > I'm sorry for that, received a mail in german and replied.... > > once again in english: > > > > I'd like to see a common procedure against the behaviour od DENIC. > > There are lot's of problems with the DENIC's solution, and if you think > on > > the past working of DENIC, you would really wish that there are no > domain > > or person or role-objects in a database controlled by them.... > > The current solution by RIPE (for the Handles) works great. Most of us > > developed tools, webinterfaces, mailrobos and so on to deal with the > > procedure of creating, updating and deleting RIPE-Handles. All of us > could > > live with a change of the email-adress to send the requests to, but not > > with totally new formats and and totally different concepts. It would be > a > > good idea for DENIC to take the (really great working) RIPE-solution. > > The manner aof DENICs working now is inacceptable. Anybody making > > whois-querys with one of the uncountable webinterfaces gets the cripled > > contact data displayed. How the not with blindness strucked of us have > > seen, there is lots of data missing in the persons:s and role:s-data: > > remarks, mnt-by, phone, fax, trouble, notify, changed and (for the > role:s) > > admin-c and tech-c. On Example: in our role-handle (compare whois -h > > whois.denic.de NOC54-RIPE against whois -h whois.ripe.net NOC54-RIPE) > is > > described how to make updates and who to cantact for whatever. This info > is > > now missing. Remember: this (in DENICs words "non-operational data" or > > "just a test") criple data is displayed whenever you query a german > domain! > > The most people won't hav the idea to query whois.denic.de for the > domain > > and then whois.ripe.net for the person:s and role:s, and I'm sure that > even > > no webinterface to whois does so. This means tons of senseless work for > us! > > It is really inacceptable insolence by DENIC to take data out of the > > RIPE-Database, changing it and then publishing it! With RIPE this is > > inconceivablily, have a look at their policy. I'm not sure if this is > not > > against german or europeen laws, but I'm not a lawyer. If I think of the > > future, all domain:s, person:s and role:s at DENICs database... beam me > > back a few years, please. > > Putting the domain:s in DENICs own database is acceptable. There is no > > really change for us (ok, I had to add two exra lines to our > > whois-webinterface's code...), because we register Domains through DENIC > or > > resellers (most of us are not members of DENIC because this is really > > expensive, so we are depend on resellers). With person:s and > > role:s-objects, surely all of us are working directly with the > > RIPE-Database. It is inacccetable if changes will only be possible by > > DENIC's members. This means weeks or eve months of handwork for us. Then > > the resellers will complete their (mail-)interfaces for changing , and > > parallel tio doing lots of work by hand we have to completely redevelop > our > > tools, webinterfaces, mailrobos and so on!!! > > > > This can not be the way to our future. > > > > Let's join to make DENIC know that this is inacceptable. Contact your > DENIC > > reseller and tell them what you think about this. They control DENICs > > board... > > > > Greetings from Germany > > > > Henning Brauer > > Hostmaster BSWS > > > > ------------------------------------------------ > > BS Web Services > > Roedingsmarkt 14 > > 20459 Hamburg > > Germany > > > > info(a)bsmail.de > > www.bsws.de > > > > fon: +49 40 3750357-0 > > fax: +49 40 3750357-5 > > > > PLEASE USE EMAIL WHERE POSSIBLE > > > > > > > > Robert > > Martin-Legène To: henning.brauer(a)bsmail.de > > <robert@martin- cc: > > legene.dk> Subject: Re: AW: AW: > Deletion > of > > .de domain objects > > Sent by: > > r(a)jenslyn.nisse > > .dk > > > > > > 30.06.00 05:49 > > > > > > > > > > > > > > Hallo. > > > > This is a list in English. > > > > What did you write? > > > > On Thu, 29 Jun 2000 henning.brauer(a)bsmail.de wrote: > > > > > > > > Ein gemeinsames Vorgehen gegen dieses Vorgehen des DENIC sähe ich sehr > > sehr > > > gerne. > > > Es ergeben sich zig Probleme aus der DENIC-Lösung, und wenn ich so an > die > > > Bearbeitungszeiten denke... > > > Die Lösung mit den RIPE-Handles funktioniert wunderbar. Die meisten > von > > uns > > > haben Werkzeuge/Webinterfaces/Mailrobos/.... entwickelt, um damit zu > > > Arbeiten. Mit einer Änderung der eMail-Adresse und einer Abfrage > > > DENIC-oder-nicht können wir wohl alle leben, mit völlig neuen Formaten > > und > > > Vorgehensweise zum Updaten/Anlegen von RIPE (oder dann DENIC)-Handles > > > nicht. Das DENIC wäre gut beraten, die RIPE-Lösung zu übernehmen. > > > Die Art und Weise, mit der DENIC hier vorgeht, finde ich > > unverantwortlich. > > > Jeder, der jetzt Abfragen über eins der zahllosen Webinterfaces für > whois > > > macht (oder gar selbst whois kennt ;-)) kriegt jetzt die DENIC-(test? > > > -)Handles angezeigt. In unserem Rollenhandle ist unter anderem klar > > > beschrieben, was für Updates etc. zu tun ist und wer für was zu > > > kontaktieren ist. Kommen diese Infos jetzt nicht mehr, laufen wieder > > alle, > > > zum Teil unnützen, Anfragen irgendwo zentral auf und verursachen > > > unnötigerweise zusätzliche Arbeit. Und das das DENIC ohne Zustimmung > der > > > Betroffenen Daten derselben ändert und Infos rausfallen lässt, ist > eine > > > bodenlose Frechheit. Beim RIPE ist das durch deren Policy ganz klar > > > ausgeschlossen. Wenn ich die vergangene und vor allem jetztige > > Arbeitsweise > > > des DENIC sehe, wird mir ganz anders bei dem Gedanken daran, das alle > > > Domain und vor allem Personenrecords bei denen in der Datenbank > liegen. > > Bei > > > den Domainrecords ist das aktzeptabel, da sich an der Arbeitsweise für > > uns > > > nichts ändert - registrieren, update usw tun wir eh übers DENIC oder > > deren > > > Reseller. Bei den Person- und Role-Records arbeiten wir wohl alle > direct > > > auf die RIPE-Datenbank, und da ist es nicht akzeptabel wenn plötzlich > > alle > > > Änderungen nur noch über DENIC-Mitglieder möglich sind - für uns als > > > nicht-Mitglied also nur über nen Reseller. Bis die dann soweit sind > und > > > eine automatisierbare Möglichkeit zum Anlegen/Updaten usw. von > > > Persons/Roles geschaffen haben, geht sicherlich noch einige Zeit ins > > Land, > > > und dann wird es da wohl auch auf ein völlig neues Format rauslaufen. > > Folge > > > also? Wir müssen erstmal Wochen- oder gar Monatelang Handles per Hand > > > bearbeiten und dann auch noch parallel (wenn die Reseller soweit sind) > > > unsere Robos umbauen... nein danke. > > > > > > Gruss > > > > > > Henning Brauer > > > Hostmaster BSWS > > > > > > ------------------------------------------------ > > > BS Web Services > > > Roedingsmarkt 14 > > > 20459 Hamburg > > > Germany > > > > > > info(a)bsmail.de > > > www.bsws.de > > > > > > fon: +49 40 3750357-0 > > > fax: +49 40 3750357-5 > > > > > > PLEASE USE EMAIL WHERE POSSIBLE > > > > > > > > > > > > "NCC Network > > > Coordination To: > > <henning.brauer(a)bsmail.de> > > > Center" cc: <owner-loca-ir(a)ripe.net> > > > <ncc@mediasca Subject: AW: AW: Deletion > of > > .de domain objects > > > pe.de> > > > > > > 29.06.00 > > > 18:04 > > > > > > > > > > > > > > > > > > > > > Wie wärs mit einem gemeinschaftlichen Complaint ans DENIC? > > > Einige an der Diskussion beteiligte Leute bemerkerten ja auch schon, > > > das es weder statthaft noch logisch sei, seitens der DENIC > Maintainerlose > > > Objekte mit einem DENIC-P Maintainer zu versehen. > > > Die nun bei einer Abrage des denics4 gezeigten Objekte enthalten ja, > wie > > > unten schon bemerkt, gar keinen Maintainer. > > > Wenn dieser Datenbestand nun doch Tatsache ist oder wird, dann... au > > weia. > > > In der Diskussion wurde ja auch schon darüber gemutmasst, dass > > > wahrscheinlich auch wieder nur DENIC Mitglieder überhaupt Änderungen > > > vornehmen können und das ist dann wahrhaftig grauselig. > > > > > > MfG > > > Martin Ahrens > > > > > > Mediascape Hostmasters > > > > > > -----Ursprüngliche Nachricht----- > > > Von: henning.brauer(a)bsmail.de [mailto:henning.brauer@bsmail.de] > > > Gesendet: Donnerstag, 29. Juni 2000 17:40 > > > An: NCC Network Coordination Center > > > Betreff: Re: AW: Deletion of .de domain objects > > > > > > > > > > > > Kann ich nur hoffen. > > > Wie andere in der Liste (mit weniger Tomaten auf den Augen) schon > bemerkt > > > haben, fehlen auch die mnt-by's, notifys, phone, und diverser anderer > > Kram. > > > > > > Gruss > > > > > > Henning Brauer > > > Hostmaster BSWS > > > ------------------------------------------------ > > > BS Web Services > > > Roedingsmarkt 14 > > > 20459 Hamburg > > > Germany > > > > > > info(a)bsmail.de > > > www.bsws.de > > > > > > fon: +49 40 3750357-0 > > > fax: +49 40 3750357-5 > > > > > > PLEASE USE EMAIL WHERE POSSIBLE > > > > > > > > > > > > "NCC Network > > > Coordination To: > > <henning.brauer(a)bsmail.de> > > > Center" cc: > > > <ncc@mediasca Subject: AW: Deletion of > .de > > > domain objects > > > pe.de> > > > > > > 29.06.00 > > > 16:00 > > > > > > > > > > > > > > > > > > > > > Hallo, > > > > > > was Sie (w.u.) bemerkten, ist mir auch schon aufgefallen. DENIC hat > Daten > > > aus Person und Role Objekten des Ripe NCC offenbar in gekürzter Form > > > übernommen. Allerdings sind alle Objekte mit > > > > > > changed: test(a)nowhere.denic.de 2000MMDD > > > > > > versehen. Handelt es sich hier ggf. noch um eine Testvariante der > > > Übernahme? > > > > > > MfG > > > Martin Ahrens > > > > > > Mediascape Hostmasters > > > > > > -----Ursprüngliche Nachricht----- > > > Von: owner-local-ir(a)ripe.net [mailto:owner-local-ir@ripe.net]Im > Auftrag > > > von henning.brauer(a)bsmail.de > > > Gesendet: Donnerstag, 29. Juni 2000 13:23 > > > An: lir-wg(a)ripe.net; db-wg(a)ripe.net; local-ir(a)ripe.net > > > Betreff: Re: Deletion of .de domain objects > > > > > > > > > > > > Hi, > > > > > > I just queryed our own main domain and have seen that the person and > > roles > > > had also "DENIC" as source. > > > But really more interesting: WHERE ARE THE REMARK:s???? > > > try whois -h whois.ripe.net NOC54-RIPE and whois -h whois.denic.de > > > NOC54-RIPE. > > > > > > Greetings from Germany > > > > > > Henning Brauer > > > Hostmaster BSWS > > > ------------------------------------------------ > > > BS Web Services > > > Roedingsmarkt 14 > > > 20459 Hamburg > > > Germany > > > > > > info(a)bsmail.de > > > www.bsws.de > > > > > > fon: +49 40 3750357-0 > > > fax: +49 40 3750357-5 > > > > > > PLEASE USE EMAIL WHERE POSSIBLE > > > > > > > > > > > > RIPE Database > > > Administratio To: lir-wg(a)ripe.net, > > > db-wg(a)ripe.net, local-ir(a)ripe.net > > > n cc: > > > <ripe-dbm@rip Subject: Deletion of .de > > > domain > > > objects > > > e.net> > > > Sent by: > > > owner-lir-wg@ > > > ripe.net > > > > > > > > > 29.06.00 > > > 12:45 > > > > > > > > > > > > > > > > > > > > > > > > -------- > > > Dear Colleauges, > > > > > > We are happy to announce that we have successfully completed > > > the first phase of migrating .de domain objects and related objects > > > to DENIC's own whois database. Now there are no .de domain objects > > > in RIPE whois database except for the top level one. > > > > > > Normal operation of our database has been resumed at 9:30am, Central > > > European Summer Time. > > > > > > If you have any question, please reply to ripe-dbm(a)ripe.net. > > > > > > -- > > > Filippo Portera > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Robert Martin-Legene > > > > > > > > > > > Sabine Dolderer > DENIC eG > Wiesenhüttenplatz 26 > D-60329 Frankfurt > > eMail: Sabine.Dolderer(a)denic.de > Fon: +49 69 27235 0 > Fax: +49 69 27235 235 > > > > Sabine Dolderer DENIC eG Wiesenhüttenplatz 26 D-60329 Frankfurt eMail: Sabine.Dolderer(a)denic.de Fon: +49 69 27235 0 Fax: +49 69 27235 235

2 1

Re: Deletion of .de domain objects
by henning.brauer＠bsmail.de 03 Jul '00

03 Jul '00

Hi, I just queryed our own main domain and have seen that the person and roles had also "DENIC" as source. But really more interesting: WHERE ARE THE REMARK:s???? try whois -h whois.ripe.net NOC54-RIPE and whois -h whois.denic.de NOC54-RIPE. Greetings from Germany Henning Brauer Hostmaster BSWS ------------------------------------------------ BS Web Services Roedingsmarkt 14 20459 Hamburg Germany info(a)bsmail.de www.bsws.de fon: +49 40 3750357-0 fax: +49 40 3750357-5 PLEASE USE EMAIL WHERE POSSIBLE RIPE Database Administratio To: lir-wg(a)ripe.net, db-wg(a)ripe.net, local-ir(a)ripe.net n cc: <ripe-dbm@rip Subject: Deletion of .de domain objects e.net> Sent by: owner-lir-wg@ ripe.net 29.06.00 12:45 -------- Dear Colleauges, We are happy to announce that we have successfully completed the first phase of migrating .de domain objects and related objects to DENIC's own whois database. Now there are no .de domain objects in RIPE whois database except for the top level one. Normal operation of our database has been resumed at 9:30am, Central European Summer Time. If you have any question, please reply to ripe-dbm(a)ripe.net. -- Filippo Portera

17 22

NEW MAILINGLIST for .de-issues !!
by Sabine Dolderer/Denic 30 Jun '00

30 Jun '00

Hello this is my very last mail (for now ;-) ) for things concerning DE-domains as I think (and it was told me) that the list was bothered to much. Further discussion could and should take place on the list public-l(a)denic.de You can subscribe to that list in simply sending an email to majordomo(a)denic.de with subscribe public-l in the body. You will then get a confirmation back which you have to send back again. I hope that this list will be a platform for the community to get in contact and discuss their issues with us. The prefered language on that list should be German. Regards Sabine Sabine Dolderer DENIC eG Wiesenhüttenplatz 26 D-60329 Frankfurt eMail: Sabine.Dolderer(a)denic.de Fon: +49 69 27235 0 Fax: +49 69 27235 235

1 0

Antwort: Re: Deletion of .de domain objects
by Sabine Dolderer/Denic 30 Jun '00

30 Jun '00

On 30.06.00 14:55 Entire Systems NOC <noc(a)entire-systems.com> wrote: > > Hi Gerd, > > [lir-wg stripped out] > > On Fri, Jun 30, 2000 at 12:49:27PM +0200, Gert Doering, Netmaster wrote: > > The RIPE-Meetings are open for everybody. > > Open for the ones with big pockets, right. > > > (or read the minutes, which are open on the web) > > See my response to Sabine Dolderer. Give me URL to any information > about this massive action somewhere on www.ripe.net. I can't find > any. I just found notices in the open available protocols www.centr.org/meetings/#technical Look at the 2nd & 3rd meeting/workshop Additionally I found an Action to the RIPE Chair in the minutes of RIPE 33 which was September last year. TLD-33.2 [Chair] Initiate discussion of issues arising around domain objects in RIPE database. Some discussion has taken place between interested parties, especially RIPE-NCC, CENTR and certain registries. Transferred to CENTR, for decision during next week (beginning 27 September 1999). I have not checked all documents but there should be more hints Regards Sabine > > > Best regards, > Daniel > > -- > Entire Systems Network Operations Center noc(a)entire-systems.com > Entire Systems GmbH - Ferbachstrasse 12 - 56203 Hoehr-Grenzhausen, Germany > InterNIC-Handle: ES1238-ORG RIPE-Handle: ESN10-RIPE Tel: +49 2624 9550-55 > GnuPG/PGP Key-ID: 0xBF3C40C9 http://www.entire-systems.com/noc/noc-key.asc > GnuPG/PGP Fingerprint: 1F3F B675 1A38 D87C EB3C 6090 C6B9 DF48 BF3C 40C9 > Sabine Dolderer DENIC eG Wiesenhüttenplatz 26 D-60329 Frankfurt eMail: Sabine.Dolderer(a)denic.de Fon: +49 69 27235 0 Fax: +49 69 27235 235

2 1

A change in the referred query result format
by Engin Gunduz 30 Jun '00

30 Jun '00

Dear Colleagues, Please note the following slight change, which may affect some of the scripts using RIPE db: When doing a referred query, the users used to get a response starting with: The object shown below is NOT in the RIPE database. It has been obtained by querying a remote server: (host_name) at port port_no. To see the object stored in the RIPE database use the -R flag in your query. Since this text may be interpreted by some scripts as an object in the db, we have changed it to contain leading '%' characters: % The object shown below is NOT in the RIPE database. % It has been obtained by querying a remote server: % (whois.denic.de) at port 43. % To see the object stored in the RIPE database % use the -R flag in your query. % %%% Start of referred query result We have also added the last line, "%%% Start of referred query result", to clearly indicate where the referred result starts. If you have any questions, please don't hesitate to contact <ripe-dbm(a)ripe.net>. Regards, Engin Gunduz RIPE NCC Database Group

1 0

Antwort: Re: Deletion of .de domain objects
by Sabine Dolderer/Denic 30 Jun '00

30 Jun '00

Dear Stephen, On 30.06.00 15:00 Stephen Burley <stephenb(a)uk.uu.net> wrote: > > Michael Holzt wrote: > > > On Thu, Jun 29, 2000 at 04:26:03PM +0000, Stephen Burley wrote: > > > That ones easy, it should never have been used for this info RIPE is the > > > rIPe repository not the domains authority. > > > > Perhaps it wasn't designed for this usage, but it was clearly the best > > system we ever had for domain registry. > > No it was the best publicly available without re-engineering it, which does not > give you (deNIC) the right to use it. long time ago in Internet history ccTLD and IP people are not divided and both did there best to serve the Community. In this time DENIC has also registered both IP numbers and domains. We were part of the RIPE community. In these times both parties agreed that it is a good idea to store domain data in the RIPE database and therefore RIPE has implemented this. BtW in this times the we also dreamed from handle referal between INTERNIC, RIPE & ARIN ;-). In the meantime we see that ccTLD-databases expands much faster than IP-databases. Thats life and we are in cooperation looking for solutions. > > > > You could use the same person > > handles for a number of top level domains which reduced the work in a great > > way. Now we will have to cope with different person handles for every > > registry, with complicated update procedures and so on. > > > > Good process, wrong DB, the software to run the identical DB structure has > always been available to use and create your own (deNIC's) copy cat DB taking > advantage of the fine processes put in place by the RIPE community and the > engineering of the DB team in the NCC. So there was never any need to populate > our DB just to take advantage of the DB structure - deNIC should have created > there own. Thats wrong. There were discussions in this time and there was a feeling that it's usefull. That feeling has changed and we take the consequences. Don't change history. > > > > > > The wiser solution would be, if the registries would have agreed on > > supporting the central ripe database by funding and services. I don't see > > how the costs can be lower for several independent registries than for one > > community-payed-for central registry. > > Look to CENTR for this not the RIPE community. Thats also not a duty of CENTR to serve a central database. It's a duty of the ccTLD manager and CENTR to look for a distributed solution. > > > > > > > > If you want to see what can happen when all this information disappears from > > ripe and will be moved to other registries, just take the DeNIC (or the > > CORE) as an example. For both registries i don't know how to update my > > handles or can do it only by asking an official registrar / member. > > > > This fragmentation of registries will only lead to unreliable and outdated > > informations in the databases. > > That is what CENTR is for, use it. > > > > > > > > > The only domains that are in there are the reverse domains for very good > > > reasons. > > > > No, the ripe database contains in the moment data for at least 21 top > > level (country) domains. > > > > Which is fine but i think it will also move to servers run by CENTR eventualy - > and again they are there for historicaly good reasons. they will move to servers managed by their local tld. > > > > > > > designed to for this use and so give the RIPE community back the level of > > > response from the servers/systems the community funded and frankly deserve. > > > > The ripe database was always very well in service. > > Wrong the most objects in the DB are now domain objects and most of the updates > are for person obs and domain obs - as reported at all RIPE meetings - and the > response time to updates is considerably impacted by the amount dom and person > objects being queried and updated. Regards Sabine > > Regards > Stephen Burley > UUNET EMEA Hostmaster > > > > > > > -- > > With kind regards > > > > Michael Holzt > > > Sabine Dolderer DENIC eG Wiesenhüttenplatz 26 D-60329 Frankfurt eMail: Sabine.Dolderer(a)denic.de Fon: +49 69 27235 0 Fax: +49 69 27235 235

1 0

Antwort: Re: AW: AW: Deletion of .de domain objects
by Sabine Dolderer/Denic 30 Jun '00

30 Jun '00

Hello, speaking for DENIC ;-). I will try to comment about the reasons why we have (or even must) done the migration. First of all I want to try to summarize the problems we are faced in the past and then I will come to an explanation of the solution we choose. Problems: There were a lot of discussions in the past about domain-objects in the RIPE-database and that they cause too much capacity for RIPE to maintain their database for this amount of objects. There was a common understanding that RIPE is not a service provider for domainregistries like ccTLDs but there were indeed suggestions to offer or assist us in this kind of service. There were a lot of pressure from our dataprotection office that due to our business we pubish data (or we urge provider to puplish data of their customers) which is not allowed to publish under German data protection laws. Mainly the existence of the inverse query feature and the publishing of data like phone-, faxnumbers and email addresses was critisized. We have had also a lot of discussions about the issue with other ccTLDs and with people from the EU commission. The fundamental outcome of these discussion was that there is no real issue to export personal data from the coutries to acentral database and that this should therefore stopped very soon. If the data is stored locally everybody can impose individually there dataprotection laws. Nevertheless there should be a central entrypoint to look for domain-data and therefore we support the RIPE referal mechanism and are looking together with other ccTLDs and the db-wg from RIPE at solutions like using the SRV-RR for whois-queries (see rfc2782 for a documentation) Solution So as I pointed out above there was no other solution than to migrate the domainobjects to a DENIC based domainquery mechanism. People who followed the discussion know that DENIC is on there way out of RIPE. Actually it was a dicission made by the RIPE db-wg in Amsterdam (February?) that there should be no domainobject in the database after June 30th. Why do we publish less data than RIPE does? I have tried to explain it also above due to German dataprotection laws we are allowed to publish only "necessary data" without formal agreement with the applicant. Whats necessary concerning a domainname? We agreed with the people from the dataprotection office that there is no necessity to no more about a admin-c of the domain than his address because if you need for legal issues to come in contact with him thats the only thing you need. Concerning the tech-c and the zone-c he finally agreed that there is a necessity due to technical urgencies to publish phone and email-addresses and so we will implement this very soon. I hope I have help you a little bit in understanding our position. I am really sorry that due to this discussion I get the feeling that people felt we are doing things without thinking or good reasons or just to make them angry. I hope you see there are - as usual - two sides of a medal and you see know the other side a little bit better, Regards Sabine On 30.06.00 09:39 henning.brauer(a)bsmail.de wrote: > > > Hi, > > I'm sorry for that, received a mail in german and replied.... > once again in english: > > I'd like to see a common procedure against the behaviour od DENIC. > There are lot's of problems with the DENIC's solution, and if you think on > the past working of DENIC, you would really wish that there are no domain > or person or role-objects in a database controlled by them.... > The current solution by RIPE (for the Handles) works great. Most of us > developed tools, webinterfaces, mailrobos and so on to deal with the > procedure of creating, updating and deleting RIPE-Handles. All of us could > live with a change of the email-adress to send the requests to, but not > with totally new formats and and totally different concepts. It would be a > good idea for DENIC to take the (really great working) RIPE-solution. > The manner aof DENICs working now is inacceptable. Anybody making > whois-querys with one of the uncountable webinterfaces gets the cripled > contact data displayed. How the not with blindness strucked of us have > seen, there is lots of data missing in the persons:s and role:s-data: > remarks, mnt-by, phone, fax, trouble, notify, changed and (for the role:s) > admin-c and tech-c. On Example: in our role-handle (compare whois -h > whois.denic.de NOC54-RIPE against whois -h whois.ripe.net NOC54-RIPE) is > described how to make updates and who to cantact for whatever. This info is > now missing. Remember: this (in DENICs words "non-operational data" or > "just a test") criple data is displayed whenever you query a german domain! > The most people won't hav the idea to query whois.denic.de for the domain > and then whois.ripe.net for the person:s and role:s, and I'm sure that even > no webinterface to whois does so. This means tons of senseless work for us! > It is really inacceptable insolence by DENIC to take data out of the > RIPE-Database, changing it and then publishing it! With RIPE this is > inconceivablily, have a look at their policy. I'm not sure if this is not > against german or europeen laws, but I'm not a lawyer. If I think of the > future, all domain:s, person:s and role:s at DENICs database... beam me > back a few years, please. > Putting the domain:s in DENICs own database is acceptable. There is no > really change for us (ok, I had to add two exra lines to our > whois-webinterface's code...), because we register Domains through DENIC or > resellers (most of us are not members of DENIC because this is really > expensive, so we are depend on resellers). With person:s and > role:s-objects, surely all of us are working directly with the > RIPE-Database. It is inacccetable if changes will only be possible by > DENIC's members. This means weeks or eve months of handwork for us. Then > the resellers will complete their (mail-)interfaces for changing , and > parallel tio doing lots of work by hand we have to completely redevelop our > tools, webinterfaces, mailrobos and so on!!! > > This can not be the way to our future. > > Let's join to make DENIC know that this is inacceptable. Contact your DENIC > reseller and tell them what you think about this. They control DENICs > board... > > Greetings from Germany > > Henning Brauer > Hostmaster BSWS > > ------------------------------------------------ > BS Web Services > Roedingsmarkt 14 > 20459 Hamburg > Germany > > info(a)bsmail.de > www.bsws.de > > fon: +49 40 3750357-0 > fax: +49 40 3750357-5 > > PLEASE USE EMAIL WHERE POSSIBLE > > > > Robert > Martin-Legène To: henning.brauer(a)bsmail.de > <robert@martin- cc: > legene.dk> Subject: Re: AW: AW: Deletion of > .de domain objects > Sent by: > r(a)jenslyn.nisse > .dk > > > 30.06.00 05:49 > > > > > > > Hallo. > > This is a list in English. > > What did you write? > > On Thu, 29 Jun 2000 henning.brauer(a)bsmail.de wrote: > > > > > Ein gemeinsames Vorgehen gegen dieses Vorgehen des DENIC sähe ich sehr > sehr > > gerne. > > Es ergeben sich zig Probleme aus der DENIC-Lösung, und wenn ich so an die > > Bearbeitungszeiten denke... > > Die Lösung mit den RIPE-Handles funktioniert wunderbar. Die meisten von > uns > > haben Werkzeuge/Webinterfaces/Mailrobos/.... entwickelt, um damit zu > > Arbeiten. Mit einer Änderung der eMail-Adresse und einer Abfrage > > DENIC-oder-nicht können wir wohl alle leben, mit völlig neuen Formaten > und > > Vorgehensweise zum Updaten/Anlegen von RIPE (oder dann DENIC)-Handles > > nicht. Das DENIC wäre gut beraten, die RIPE-Lösung zu übernehmen. > > Die Art und Weise, mit der DENIC hier vorgeht, finde ich > unverantwortlich. > > Jeder, der jetzt Abfragen über eins der zahllosen Webinterfaces für whois > > macht (oder gar selbst whois kennt ;-)) kriegt jetzt die DENIC-(test? > > -)Handles angezeigt. In unserem Rollenhandle ist unter anderem klar > > beschrieben, was für Updates etc. zu tun ist und wer für was zu > > kontaktieren ist. Kommen diese Infos jetzt nicht mehr, laufen wieder > alle, > > zum Teil unnützen, Anfragen irgendwo zentral auf und verursachen > > unnötigerweise zusätzliche Arbeit. Und das das DENIC ohne Zustimmung der > > Betroffenen Daten derselben ändert und Infos rausfallen lässt, ist eine > > bodenlose Frechheit. Beim RIPE ist das durch deren Policy ganz klar > > ausgeschlossen. Wenn ich die vergangene und vor allem jetztige > Arbeitsweise > > des DENIC sehe, wird mir ganz anders bei dem Gedanken daran, das alle > > Domain und vor allem Personenrecords bei denen in der Datenbank liegen. > Bei > > den Domainrecords ist das aktzeptabel, da sich an der Arbeitsweise für > uns > > nichts ändert - registrieren, update usw tun wir eh übers DENIC oder > deren > > Reseller. Bei den Person- und Role-Records arbeiten wir wohl alle direct > > auf die RIPE-Datenbank, und da ist es nicht akzeptabel wenn plötzlich > alle > > Änderungen nur noch über DENIC-Mitglieder möglich sind - für uns als > > nicht-Mitglied also nur über nen Reseller. Bis die dann soweit sind und > > eine automatisierbare Möglichkeit zum Anlegen/Updaten usw. von > > Persons/Roles geschaffen haben, geht sicherlich noch einige Zeit ins > Land, > > und dann wird es da wohl auch auf ein völlig neues Format rauslaufen. > Folge > > also? Wir müssen erstmal Wochen- oder gar Monatelang Handles per Hand > > bearbeiten und dann auch noch parallel (wenn die Reseller soweit sind) > > unsere Robos umbauen... nein danke. > > > > Gruss > > > > Henning Brauer > > Hostmaster BSWS > > > > ------------------------------------------------ > > BS Web Services > > Roedingsmarkt 14 > > 20459 Hamburg > > Germany > > > > info(a)bsmail.de > > www.bsws.de > > > > fon: +49 40 3750357-0 > > fax: +49 40 3750357-5 > > > > PLEASE USE EMAIL WHERE POSSIBLE > > > > > > > > "NCC Network > > Coordination To: > <henning.brauer(a)bsmail.de> > > Center" cc: <owner-loca-ir(a)ripe.net> > > <ncc@mediasca Subject: AW: AW: Deletion of > .de domain objects > > pe.de> > > > > 29.06.00 > > 18:04 > > > > > > > > > > > > > > Wie wärs mit einem gemeinschaftlichen Complaint ans DENIC? > > Einige an der Diskussion beteiligte Leute bemerkerten ja auch schon, > > das es weder statthaft noch logisch sei, seitens der DENIC Maintainerlose > > Objekte mit einem DENIC-P Maintainer zu versehen. > > Die nun bei einer Abrage des denics4 gezeigten Objekte enthalten ja, wie > > unten schon bemerkt, gar keinen Maintainer. > > Wenn dieser Datenbestand nun doch Tatsache ist oder wird, dann... au > weia. > > In der Diskussion wurde ja auch schon darüber gemutmasst, dass > > wahrscheinlich auch wieder nur DENIC Mitglieder überhaupt Änderungen > > vornehmen können und das ist dann wahrhaftig grauselig. > > > > MfG > > Martin Ahrens > > > > Mediascape Hostmasters > > > > -----Ursprüngliche Nachricht----- > > Von: henning.brauer(a)bsmail.de [mailto:henning.brauer@bsmail.de] > > Gesendet: Donnerstag, 29. Juni 2000 17:40 > > An: NCC Network Coordination Center > > Betreff: Re: AW: Deletion of .de domain objects > > > > > > > > Kann ich nur hoffen. > > Wie andere in der Liste (mit weniger Tomaten auf den Augen) schon bemerkt > > haben, fehlen auch die mnt-by's, notifys, phone, und diverser anderer > Kram. > > > > Gruss > > > > Henning Brauer > > Hostmaster BSWS > > ------------------------------------------------ > > BS Web Services > > Roedingsmarkt 14 > > 20459 Hamburg > > Germany > > > > info(a)bsmail.de > > www.bsws.de > > > > fon: +49 40 3750357-0 > > fax: +49 40 3750357-5 > > > > PLEASE USE EMAIL WHERE POSSIBLE > > > > > > > > "NCC Network > > Coordination To: > <henning.brauer(a)bsmail.de> > > Center" cc: > > <ncc@mediasca Subject: AW: Deletion of .de > > domain objects > > pe.de> > > > > 29.06.00 > > 16:00 > > > > > > > > > > > > > > Hallo, > > > > was Sie (w.u.) bemerkten, ist mir auch schon aufgefallen. DENIC hat Daten > > aus Person und Role Objekten des Ripe NCC offenbar in gekürzter Form > > übernommen. Allerdings sind alle Objekte mit > > > > changed: test(a)nowhere.denic.de 2000MMDD > > > > versehen. Handelt es sich hier ggf. noch um eine Testvariante der > > Übernahme? > > > > MfG > > Martin Ahrens > > > > Mediascape Hostmasters > > > > -----Ursprüngliche Nachricht----- > > Von: owner-local-ir(a)ripe.net [mailto:owner-local-ir@ripe.net]Im Auftrag > > von henning.brauer(a)bsmail.de > > Gesendet: Donnerstag, 29. Juni 2000 13:23 > > An: lir-wg(a)ripe.net; db-wg(a)ripe.net; local-ir(a)ripe.net > > Betreff: Re: Deletion of .de domain objects > > > > > > > > Hi, > > > > I just queryed our own main domain and have seen that the person and > roles > > had also "DENIC" as source. > > But really more interesting: WHERE ARE THE REMARK:s???? > > try whois -h whois.ripe.net NOC54-RIPE and whois -h whois.denic.de > > NOC54-RIPE. > > > > Greetings from Germany > > > > Henning Brauer > > Hostmaster BSWS > > ------------------------------------------------ > > BS Web Services > > Roedingsmarkt 14 > > 20459 Hamburg > > Germany > > > > info(a)bsmail.de > > www.bsws.de > > > > fon: +49 40 3750357-0 > > fax: +49 40 3750357-5 > > > > PLEASE USE EMAIL WHERE POSSIBLE > > > > > > > > RIPE Database > > Administratio To: lir-wg(a)ripe.net, > > db-wg(a)ripe.net, local-ir(a)ripe.net > > n cc: > > <ripe-dbm@rip Subject: Deletion of .de > > domain > > objects > > e.net> > > Sent by: > > owner-lir-wg@ > > ripe.net > > > > > > 29.06.00 > > 12:45 > > > > > > > > > > > > > > > > -------- > > Dear Colleauges, > > > > We are happy to announce that we have successfully completed > > the first phase of migrating .de domain objects and related objects > > to DENIC's own whois database. Now there are no .de domain objects > > in RIPE whois database except for the top level one. > > > > Normal operation of our database has been resumed at 9:30am, Central > > European Summer Time. > > > > If you have any question, please reply to ripe-dbm(a)ripe.net. > > > > -- > > Filippo Portera > > > > > > > > > > > > > > > > > > > > > > > > -- > Robert Martin-Legene > > > > > Sabine Dolderer DENIC eG Wiesenhüttenplatz 26 D-60329 Frankfurt eMail: Sabine.Dolderer(a)denic.de Fon: +49 69 27235 0 Fax: +49 69 27235 235

6 6

petition against DENIC's plans
by henning.brauer＠bsmail.de 30 Jun '00

30 Jun '00

Hi all, I've setup a quick and dirty Website to vote against DENIC's plans. Please sign: http://denicpetition.bsws.de I just copied my mails regarding this, so if there is anybody out to rewrite the text... please send them to hostmaster(a)bsws.de. Greetings from Germany Henning Brauer Hostmaster BSWS ------------------------------------------------ BS Web Services Roedingsmarkt 14 20459 Hamburg Germany info(a)bsmail.de www.bsws.de fon: +49 40 3750357-0 fax: +49 40 3750357-5 PLEASE USE EMAIL WHERE POSSIBLE

3 2

Antwort: Re: Deletion of .de domain objects
by Sabine Dolderer/Denic 30 Jun '00

30 Jun '00

Hello Daniel, On 30.06.00 12:05 Daniel Roesen <noc(a)entire-systems.com> wrote: > > Dear Sabine, > > On Fri, Jun 30, 2000 at 10:39:51AM +0200, Sabine Dolderer/Denic wrote: > > speaking for DENIC ;-). I will try to comment about the reasons why we > > have (or even must) done the migration. > > Please explain why you remove the well-working maintainer scheme. We don't remove the maintainer scheme. What we have done is to protect every Person which hasn't a maintainer with our maintainer to prevent people from deleting unreferenced objects. As these updates (~100.000) was generated, a lot of people started to recognize that there was a problem and sends updates with their maintainer. If you understand the RIPE queueing model you will know that small updates are served faster from RIPE than the bigger ones to keep chances fair. Therefore people saw that we try to put our maintainer to their one day earlier updated persons. They don't see that these requests are send one week earlier not knowing about the maintainer. As these updates were maid accidentally this was corrected later. BtW. If somebody wants to change a DENIC-P maintainer whith his own one. This can be done either by the DENIC member he cooperated with (prefered ;-) ) or by hostmaster(a)denic.de. BUT: Please keep in mind - we will go completely out of the RIPE-DB there is no need to create own maintainers for the meantime. > > > There were a lot of pressure from our dataprotection office that due to > > our business we pubish data (or we urge provider to puplish data of their > > customers) which is not allowed to publish under German data protection > > laws. > > It is allowed. Every customer agreed that his information is published > in a public database. I want not to go too deeply in this discussion but believe me that it's not that easy. I still use these argumentation too hoping noone proofs it ;-). > > > Mainly the existence of the inverse query feature and the publishing > > of data like phone-, faxnumbers and email addresses was critisized. > > Regarding phone, fax and email addresses: with this logic even > phone books would be illegal. If you go for a telefon you are explicitely ask if you want to have additionally to the telefonline a phonebook entry. If you refuse you still get the line. > > > I am really sorry that due to this discussion I get the feeling > > that people felt we are doing things without thinking or good > > reasons or just to make them angry. > > Please explain why this was all negotiated behind closed doors > (RIPE-Meetings and hostmaster-l ARE closed doors) although it has > a wide impact on ALL domain customers and non-DENIC-members > (resellers). RIPE-Meetings are open to everybody. The minutes are published on the web. Why do you beleave they are closed? Maybe you can give me a hint where you think that these sort of discussions should take place. Best Regards Sabine > > > Best regards, > > Daniel Roesen > Entire Systems NOC > > -- > Entire Systems Network Operations Center noc(a)entire-systems.com > Entire Systems GmbH - Ferbachstrasse 12 - 56203 Hoehr-Grenzhausen, Germany > InterNIC-Handle: ES1238-ORG RIPE-Handle: ESN10-RIPE Tel: +49 2624 9550-55 > GnuPG/PGP Key-ID: 0xBF3C40C9 http://www.entire-systems.com/noc/noc-key.asc > GnuPG/PGP Fingerprint: 1F3F B675 1A38 D87C EB3C 6090 C6B9 DF48 BF3C 40C9 > Sabine Dolderer DENIC eG Wiesenhüttenplatz 26 D-60329 Frankfurt eMail: Sabine.Dolderer(a)denic.de Fon: +49 69 27235 0 Fax: +49 69 27235 235

2 1

Antwort: Re: Antwort: Re: AW: AW: Deletion of .de domain objects
by Sabine Dolderer/Denic 30 Jun '00

30 Jun '00

Hello, On 30.06.00 11:07 henning.brauer(a)bsmail.de wrote: > > > Hi, > > thats not really the point of our critics. > a) changes only be made by members???? as every DE-domainowner is our customer and we are responisble to him about the security of his domainname we must assure that changes are made in a verifyable and accountable way. It is important that there is a documented responsibility. > b) technical solution - RIPE's solutions are working really good, DENIC's > past solutions are poor no comment. > c) change in interfaces not acceptable changes in interfaces are sometimes necessary. But I am with you that this should happen very rarely and should be prepared very well and people should be informed very soon -- but we tried to make all this. > d) contact info's, especially phone and fax, are REALLY important for the > hostmasters to inform each other about technical probs. If this could be > against German's laws, just make these fields optional. we are only allowed to publish these things if the custoumer have signed that he allows the publishing. Currently we think that from nearly none of the persons in the RIPE-DB this allowence is there. For the future we plan to let the people the choice to publish these data. > e) putting so named "non-operational data" or "test data" which is > incomplete and partly incorrect in production systems (it IS in > productionis - just do an whoi-query...) is not acceptable sorry I don't understand these point. Maybe you can show me an example of these "test data". > f) plans making life for non-members harder -> DENIC tries to get more > payin' members???? As we are working on a costrecovery base (non-profit) more members don't means automatically more income. But surely are we are interested in organisations taking the responsibitlity and sharing the risk to run the German Registry as a self regulating body for the benefits of the German Internet Community. > g) plans to charge for person: and role: records? > h) to be continued... Regards Sabine > > pls see http://denicpetition.bsws.de > > Greetings from Germany > > Henning Brauer > Hostmaster BSWS > > ------------------------------------------------ > BS Web Services > Roedingsmarkt 14 > 20459 Hamburg > Germany > > info(a)bsmail.de > www.bsws.de > > fon: +49 40 3750357-0 > fax: +49 40 3750357-5 > > PLEASE USE EMAIL WHERE POSSIBLE > > > > "Sabine > Dolderer/Deni To: henning.brauer(a)bsmail.de > c" cc: db-wg(a)ripe.net, info(a)denic.de, > lir-wg(a)ripe.net, robert(a)martin-legene.dk > <dolderer@den Subject: Antwort: Re: AW: AW: > Deletion of .de domain objects > ic.de> > > 30.06.00 > 10:39 > > > > > > > Hello, > > speaking for DENIC ;-). I will try to comment about the reasons why we > have (or even must) done the migration. > > First of all I want to try to summarize the problems we are faced in the > past and then I will come to an explanation of the solution we choose. > > Problems: > > There were a lot of discussions in the past about domain-objects in the > RIPE-database and that they cause too much capacity for RIPE to maintain > their database for this amount of objects. > > There was a common understanding that RIPE is not a service provider for > domainregistries like ccTLDs but there were indeed suggestions to offer or > assist us in this kind of service. > > There were a lot of pressure from our dataprotection office that due to > our business we pubish data (or we urge provider to puplish data of their > customers) which is not allowed to publish under German data protection > laws. Mainly the existence of the inverse query feature and the publishing > of data like phone-, faxnumbers and email addresses was critisized. > > We have had also a lot of discussions about the issue with other ccTLDs > and with people from the EU commission. The fundamental outcome of these > discussion was that there is no real issue to export personal data from > the coutries to acentral database and that this should therefore stopped > very soon. If the data is stored locally everybody can impose individually > there dataprotection laws. Nevertheless there should be a central > entrypoint to look for domain-data and therefore we support the RIPE > referal mechanism and are looking together with other ccTLDs and the db-wg > from RIPE at solutions like using the SRV-RR for whois-queries (see > rfc2782 for a documentation) > > Solution > > So as I pointed out above there was no other solution than to migrate the > domainobjects to a DENIC based domainquery mechanism. People who followed > the discussion know that DENIC is on there way out of RIPE. Actually it > was a dicission made by the RIPE db-wg in Amsterdam (February?) that there > should be no domainobject in the database after June 30th. > > Why do we publish less data than RIPE does? > > I have tried to explain it also above due to German dataprotection laws we > are allowed to publish only "necessary data" without formal agreement with > the applicant. > > Whats necessary concerning a domainname? > > We agreed with the people from the dataprotection office that there is no > necessity to no more about a admin-c of the domain than his address > because if you need for legal issues to come in contact with him thats the > only thing you need. > > Concerning the tech-c and the zone-c he finally agreed that there is a > necessity due to technical urgencies to publish phone and email-addresses > and so we will implement this very soon. > > I hope I have help you a little bit in understanding our position. I am > really sorry that due to this discussion I get the feeling that people > felt we are doing things without thinking or good reasons or just to make > them angry. I hope you see there are - as usual - two sides of a medal and > you see know the other side a little bit better, > > Regards Sabine > > > On 30.06.00 09:39 henning.brauer(a)bsmail.de wrote: > > > > > > Hi, > > > > I'm sorry for that, received a mail in german and replied.... > > once again in english: > > > > I'd like to see a common procedure against the behaviour od DENIC. > > There are lot's of problems with the DENIC's solution, and if you think > on > > the past working of DENIC, you would really wish that there are no > domain > > or person or role-objects in a database controlled by them.... > > The current solution by RIPE (for the Handles) works great. Most of us > > developed tools, webinterfaces, mailrobos and so on to deal with the > > procedure of creating, updating and deleting RIPE-Handles. All of us > could > > live with a change of the email-adress to send the requests to, but not > > with totally new formats and and totally different concepts. It would be > a > > good idea for DENIC to take the (really great working) RIPE-solution. > > The manner aof DENICs working now is inacceptable. Anybody making > > whois-querys with one of the uncountable webinterfaces gets the cripled > > contact data displayed. How the not with blindness strucked of us have > > seen, there is lots of data missing in the persons:s and role:s-data: > > remarks, mnt-by, phone, fax, trouble, notify, changed and (for the > role:s) > > admin-c and tech-c. On Example: in our role-handle (compare whois -h > > whois.denic.de NOC54-RIPE against whois -h whois.ripe.net NOC54-RIPE) > is > > described how to make updates and who to cantact for whatever. This info > is > > now missing. Remember: this (in DENICs words "non-operational data" or > > "just a test") criple data is displayed whenever you query a german > domain! > > The most people won't hav the idea to query whois.denic.de for the > domain > > and then whois.ripe.net for the person:s and role:s, and I'm sure that > even > > no webinterface to whois does so. This means tons of senseless work for > us! > > It is really inacceptable insolence by DENIC to take data out of the > > RIPE-Database, changing it and then publishing it! With RIPE this is > > inconceivablily, have a look at their policy. I'm not sure if this is > not > > against german or europeen laws, but I'm not a lawyer. If I think of the > > future, all domain:s, person:s and role:s at DENICs database... beam me > > back a few years, please. > > Putting the domain:s in DENICs own database is acceptable. There is no > > really change for us (ok, I had to add two exra lines to our > > whois-webinterface's code...), because we register Domains through DENIC > or > > resellers (most of us are not members of DENIC because this is really > > expensive, so we are depend on resellers). With person:s and > > role:s-objects, surely all of us are working directly with the > > RIPE-Database. It is inacccetable if changes will only be possible by > > DENIC's members. This means weeks or eve months of handwork for us. Then > > the resellers will complete their (mail-)interfaces for changing , and > > parallel tio doing lots of work by hand we have to completely redevelop > our > > tools, webinterfaces, mailrobos and so on!!! > > > > This can not be the way to our future. > > > > Let's join to make DENIC know that this is inacceptable. Contact your > DENIC > > reseller and tell them what you think about this. They control DENICs > > board... > > > > Greetings from Germany > > > > Henning Brauer > > Hostmaster BSWS > > > > ------------------------------------------------ > > BS Web Services > > Roedingsmarkt 14 > > 20459 Hamburg > > Germany > > > > info(a)bsmail.de > > www.bsws.de > > > > fon: +49 40 3750357-0 > > fax: +49 40 3750357-5 > > > > PLEASE USE EMAIL WHERE POSSIBLE > > > > > > > > Robert > > Martin-Legène To: henning.brauer(a)bsmail.de > > <robert@martin- cc: > > legene.dk> Subject: Re: AW: AW: > Deletion > of > > .de domain objects > > Sent by: > > r(a)jenslyn.nisse > > .dk > > > > > > 30.06.00 05:49 > > > > > > > > > > > > > > Hallo. > > > > This is a list in English. > > > > What did you write? > > > > On Thu, 29 Jun 2000 henning.brauer(a)bsmail.de wrote: > > > > > > > > Ein gemeinsames Vorgehen gegen dieses Vorgehen des DENIC sähe ich sehr > > sehr > > > gerne. > > > Es ergeben sich zig Probleme aus der DENIC-Lösung, und wenn ich so an > die > > > Bearbeitungszeiten denke... > > > Die Lösung mit den RIPE-Handles funktioniert wunderbar. Die meisten > von > > uns > > > haben Werkzeuge/Webinterfaces/Mailrobos/.... entwickelt, um damit zu > > > Arbeiten. Mit einer Änderung der eMail-Adresse und einer Abfrage > > > DENIC-oder-nicht können wir wohl alle leben, mit völlig neuen Formaten > > und > > > Vorgehensweise zum Updaten/Anlegen von RIPE (oder dann DENIC)-Handles > > > nicht. Das DENIC wäre gut beraten, die RIPE-Lösung zu übernehmen. > > > Die Art und Weise, mit der DENIC hier vorgeht, finde ich > > unverantwortlich. > > > Jeder, der jetzt Abfragen über eins der zahllosen Webinterfaces für > whois > > > macht (oder gar selbst whois kennt ;-)) kriegt jetzt die DENIC-(test? > > > -)Handles angezeigt. In unserem Rollenhandle ist unter anderem klar > > > beschrieben, was für Updates etc. zu tun ist und wer für was zu > > > kontaktieren ist. Kommen diese Infos jetzt nicht mehr, laufen wieder > > alle, > > > zum Teil unnützen, Anfragen irgendwo zentral auf und verursachen > > > unnötigerweise zusätzliche Arbeit. Und das das DENIC ohne Zustimmung > der > > > Betroffenen Daten derselben ändert und Infos rausfallen lässt, ist > eine > > > bodenlose Frechheit. Beim RIPE ist das durch deren Policy ganz klar > > > ausgeschlossen. Wenn ich die vergangene und vor allem jetztige > > Arbeitsweise > > > des DENIC sehe, wird mir ganz anders bei dem Gedanken daran, das alle > > > Domain und vor allem Personenrecords bei denen in der Datenbank > liegen. > > Bei > > > den Domainrecords ist das aktzeptabel, da sich an der Arbeitsweise für > > uns > > > nichts ändert - registrieren, update usw tun wir eh übers DENIC oder > > deren > > > Reseller. Bei den Person- und Role-Records arbeiten wir wohl alle > direct > > > auf die RIPE-Datenbank, und da ist es nicht akzeptabel wenn plötzlich > > alle > > > Änderungen nur noch über DENIC-Mitglieder möglich sind - für uns als > > > nicht-Mitglied also nur über nen Reseller. Bis die dann soweit sind > und > > > eine automatisierbare Möglichkeit zum Anlegen/Updaten usw. von > > > Persons/Roles geschaffen haben, geht sicherlich noch einige Zeit ins > > Land, > > > und dann wird es da wohl auch auf ein völlig neues Format rauslaufen. > > Folge > > > also? Wir müssen erstmal Wochen- oder gar Monatelang Handles per Hand > > > bearbeiten und dann auch noch parallel (wenn die Reseller soweit sind) > > > unsere Robos umbauen... nein danke. > > > > > > Gruss > > > > > > Henning Brauer > > > Hostmaster BSWS > > > > > > ------------------------------------------------ > > > BS Web Services > > > Roedingsmarkt 14 > > > 20459 Hamburg > > > Germany > > > > > > info(a)bsmail.de > > > www.bsws.de > > > > > > fon: +49 40 3750357-0 > > > fax: +49 40 3750357-5 > > > > > > PLEASE USE EMAIL WHERE POSSIBLE > > > > > > > > > > > > "NCC Network > > > Coordination To: > > <henning.brauer(a)bsmail.de> > > > Center" cc: <owner-loca-ir(a)ripe.net> > > > <ncc@mediasca Subject: AW: AW: Deletion > of > > .de domain objects > > > pe.de> > > > > > > 29.06.00 > > > 18:04 > > > > > > > > > > > > > > > > > > > > > Wie wärs mit einem gemeinschaftlichen Complaint ans DENIC? > > > Einige an der Diskussion beteiligte Leute bemerkerten ja auch schon, > > > das es weder statthaft noch logisch sei, seitens der DENIC > Maintainerlose > > > Objekte mit einem DENIC-P Maintainer zu versehen. > > > Die nun bei einer Abrage des denics4 gezeigten Objekte enthalten ja, > wie > > > unten schon bemerkt, gar keinen Maintainer. > > > Wenn dieser Datenbestand nun doch Tatsache ist oder wird, dann... au > > weia. > > > In der Diskussion wurde ja auch schon darüber gemutmasst, dass > > > wahrscheinlich auch wieder nur DENIC Mitglieder überhaupt Änderungen > > > vornehmen können und das ist dann wahrhaftig grauselig. > > > > > > MfG > > > Martin Ahrens > > > > > > Mediascape Hostmasters > > > > > > -----Ursprüngliche Nachricht----- > > > Von: henning.brauer(a)bsmail.de [mailto:henning.brauer@bsmail.de] > > > Gesendet: Donnerstag, 29. Juni 2000 17:40 > > > An: NCC Network Coordination Center > > > Betreff: Re: AW: Deletion of .de domain objects > > > > > > > > > > > > Kann ich nur hoffen. > > > Wie andere in der Liste (mit weniger Tomaten auf den Augen) schon > bemerkt > > > haben, fehlen auch die mnt-by's, notifys, phone, und diverser anderer > > Kram. > > > > > > Gruss > > > > > > Henning Brauer > > > Hostmaster BSWS > > > ------------------------------------------------ > > > BS Web Services > > > Roedingsmarkt 14 > > > 20459 Hamburg > > > Germany > > > > > > info(a)bsmail.de > > > www.bsws.de > > > > > > fon: +49 40 3750357-0 > > > fax: +49 40 3750357-5 > > > > > > PLEASE USE EMAIL WHERE POSSIBLE > > > > > > > > > > > > "NCC Network > > > Coordination To: > > <henning.brauer(a)bsmail.de> > > > Center" cc: > > > <ncc@mediasca Subject: AW: Deletion of > .de > > > domain objects > > > pe.de> > > > > > > 29.06.00 > > > 16:00 > > > > > > > > > > > > > > > > > > > > > Hallo, > > > > > > was Sie (w.u.) bemerkten, ist mir auch schon aufgefallen. DENIC hat > Daten > > > aus Person und Role Objekten des Ripe NCC offenbar in gekürzter Form > > > übernommen. Allerdings sind alle Objekte mit > > > > > > changed: test(a)nowhere.denic.de 2000MMDD > > > > > > versehen. Handelt es sich hier ggf. noch um eine Testvariante der > > > Übernahme? > > > > > > MfG > > > Martin Ahrens > > > > > > Mediascape Hostmasters > > > > > > -----Ursprüngliche Nachricht----- > > > Von: owner-local-ir(a)ripe.net [mailto:owner-local-ir@ripe.net]Im > Auftrag > > > von henning.brauer(a)bsmail.de > > > Gesendet: Donnerstag, 29. Juni 2000 13:23 > > > An: lir-wg(a)ripe.net; db-wg(a)ripe.net; local-ir(a)ripe.net > > > Betreff: Re: Deletion of .de domain objects > > > > > > > > > > > > Hi, > > > > > > I just queryed our own main domain and have seen that the person and > > roles > > > had also "DENIC" as source. > > > But really more interesting: WHERE ARE THE REMARK:s???? > > > try whois -h whois.ripe.net NOC54-RIPE and whois -h whois.denic.de > > > NOC54-RIPE. > > > > > > Greetings from Germany > > > > > > Henning Brauer > > > Hostmaster BSWS > > > ------------------------------------------------ > > > BS Web Services > > > Roedingsmarkt 14 > > > 20459 Hamburg > > > Germany > > > > > > info(a)bsmail.de > > > www.bsws.de > > > > > > fon: +49 40 3750357-0 > > > fax: +49 40 3750357-5 > > > > > > PLEASE USE EMAIL WHERE POSSIBLE > > > > > > > > > > > > RIPE Database > > > Administratio To: lir-wg(a)ripe.net, > > > db-wg(a)ripe.net, local-ir(a)ripe.net > > > n cc: > > > <ripe-dbm@rip Subject: Deletion of .de > > > domain > > > objects > > > e.net> > > > Sent by: > > > owner-lir-wg@ > > > ripe.net > > > > > > > > > 29.06.00 > > > 12:45 > > > > > > > > > > > > > > > > > > > > > > > > -------- > > > Dear Colleauges, > > > > > > We are happy to announce that we have successfully completed > > > the first phase of migrating .de domain objects and related objects > > > to DENIC's own whois database. Now there are no .de domain objects > > > in RIPE whois database except for the top level one. > > > > > > Normal operation of our database has been resumed at 9:30am, Central > > > European Summer Time. > > > > > > If you have any question, please reply to ripe-dbm(a)ripe.net. > > > > > > -- > > > Filippo Portera > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > Robert Martin-Legene > > > > > > > > > > > Sabine Dolderer > DENIC eG > Wiesenhüttenplatz 26 > D-60329 Frankfurt > > eMail: Sabine.Dolderer(a)denic.de > Fon: +49 69 27235 0 > Fax: +49 69 27235 235 > > > > Sabine Dolderer DENIC eG Wiesenhüttenplatz 26 D-60329 Frankfurt eMail: Sabine.Dolderer(a)denic.de Fon: +49 69 27235 0 Fax: +49 69 27235 235

1 0

Antwort: Re: Deletion of .de domain objects
by Sabine Dolderer/Denic 30 Jun '00

30 Jun '00

On 29.06.00 18:04 "Sascha E. Pollok" <sp(a)iphh.de> wrote: > > >I just got response from the denic regarding my questions about future > >updates to handles. As it seems the change of Handles will now only be > >possible for members of the Denic eG, so many smaller providers who aren't > >members, but are buying their domains from another one will have to redirect > >all changes to this member. I treat this as a very brain-damaged system. > > > >In the meanwhile we have Handles with the same key XYZ-RIPE, with different > >contents in RIPE-db and DeNIC-db (not only the missing remarks, but also > >phone and fax, and if someone makes changes to one of the two handles the > >other will keep the old data). > > F*ck. Then we'll have \S+-RIPE Handles in the DENIC-DB that are > inconsistenc against the Handles in the RIPE-DB. Who has planned this? > > When can't DENIC at least reference RIPE-Handles instead of their > own ones? We mirror the RIPE objects and there will be current no difference between RIPE and DENIC stored information. There is indeed a difference between RIPE and DENIC published information. And that is because of German data protection laws. We migrate to a sheme where personal data has to be stored whithin DENIC and after a while of migration we will stopp to acceppt RIPE Handles and at that point unreferrenced objects whithin RIPE can be deleted and updates have to be made in both databases. BtW: Every German ISP works also under this law and after my discussions with these office there is also a lot for them to do concerning information to their customers when the store privat data in public directories. DENIC is currently trying to get a understanding what procedures and documents a necessary for our ISP customers and will inform them. But concerning the parts where we are formally responsible we have taken after legal consultations the consequences. > > >Why has this mess had to happen? > > And why do I have the feeling I got not really informed by DENIC > prior this happening about the changes? There was more than one year discussion about this issue. It was discussed at many meetings. Before these migration we gave three time notice to our members. I feel really that we have done a lot to keep people informed. Sabine > > Sascha > > --- > Sascha E. Pollok > Internet Port Hamburg > Technical Staff / Network Operations > Grosse Reichenstrasse 27 > D-20457 Hamburg > Germany > Tel. +49 (0)40 37 49 19-0 > Fax +49 (0)40 37 49 19-29 > Email: sp(a)iphh.de > ICQ #38955239 > > > Sabine Dolderer DENIC eG Wiesenhüttenplatz 26 D-60329 Frankfurt eMail: Sabine.Dolderer(a)denic.de Fon: +49 69 27235 0 Fax: +49 69 27235 235

2 1

Antwort: Re: Deletion of .de domain objects
by Sabine Dolderer/Denic 30 Jun '00

30 Jun '00

Hello, On 29.06.00 17:40 Sebastian Willing <s.willing(a)mops.net> wrote: > > Hello! > > On Thu, Jun 29, 2000 at 02:38:12PM +0200, Thorsten Schreiner wrote: > > > I think they want to become a BIG player... but actually can't right > > > > I cannot understand why the DENIC doesn't help funding with one central ripe > > database instead of setting up a own system. The usability and work of the > > ripe database was the best database ever, with automated robot for updates > > within minutes and a very good maintainer scheme. > The RIPE didn't want to serve the .de-namespace for free any longer and it > seems that the DeNic didn't want to pay for the services. > I agree that the better solution would have been to pay the RIPE for service. That was not an option we have as I tried to explain in another email. > > > > In the meanwhile we have Handles with the same key XYZ-RIPE, with different > > contents in RIPE-db and DeNIC-db (not only the missing remarks, but also > > phone and fax, and if someone makes changes to one of the two handles the > > other will keep the old data). No they are currently mirrored but we are not allowed to publish these data. > ....and what if a handle is deleted from one DB but not from the other? Once > the handle # is re-assigned, the owner of a domain depends on the server you > ask. The owner of the domain is the one stored in the DENIC database. Sabine > I think, the best thing is to restore the deleted records from RIPE backups and > to remove the referer to the DeNic-whois-server until either the DeNic is paying > or is running a workable service (maybe with references to the RIPE-whois-server > for persons). > Yours, > S.Willing > > Sabine Dolderer DENIC eG Wiesenhüttenplatz 26 D-60329 Frankfurt eMail: Sabine.Dolderer(a)denic.de Fon: +49 69 27235 0 Fax: +49 69 27235 235

1 0

Antwort: petition against DENIC's plans
by Sabine Dolderer/Denic 30 Jun '00

30 Jun '00

Hello, On 30.06.00 11:01 Sabine Dolderer wrote: > On 30.06.00 10:57 henning.brauer(a)bsmail.de wrote: > > > > Hi all, > > > > I've setup a quick and dirty Website to vote against DENIC's plans. > > Please sign: http://denicpetition.bsws.de > > I just copied my mails regarding this, so if there is anybody out to > > rewrite the text... please send them to hostmaster(a)bsws.de. personally I am not happy that you choose to try to change a decision which was made after a long discussion with a lot of people involved (Starting at a Technical meeting at DENIC one year ago and followed by a lot of discussions at several RIPE meetings) but as a matter of fairness I think you should try to inform the people signing the petition also about the process and the reasons. If you choose to do so you find more information about this issue under http://www.denic.de/doc/DENIC/presse/datenschutz.html or in my last mail to this issue, Thank you Sabine > > > > Greetings from Germany > > > > Henning Brauer > > Hostmaster BSWS > > > > ------------------------------------------------ > > BS Web Services > > Roedingsmarkt 14 > > 20459 Hamburg > > Germany > > > > info(a)bsmail.de > > www.bsws.de > > > > fon: +49 40 3750357-0 > > fax: +49 40 3750357-5 > > > > PLEASE USE EMAIL WHERE POSSIBLE > > > > > Sabine Dolderer > DENIC eG > Wiesenhüttenplatz 26 > D-60329 Frankfurt > > eMail: Sabine.Dolderer(a)denic.de > Fon: +49 69 27235 0 > Fax: +49 69 27235 235 > Sabine Dolderer DENIC eG Wiesenhüttenplatz 26 D-60329 Frankfurt eMail: Sabine.Dolderer(a)denic.de Fon: +49 69 27235 0 Fax: +49 69 27235 235

1 0