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@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@ripe.net, db-wg@ripe.net, local-ir@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@ripe.net. -- Filippo Portera
On Thu, Jun 29, 2000 at 01:23:11PM +0200, henning.brauer@bsmail.de wrote:
But really more interesting: WHERE ARE THE REMARK:s????
And phone:, fax-no:, trouble:, notify: etc... Daniel Roesen Entire Systems NOC -- Entire Systems Network Operations Center noc@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
henning.brauer@bsmail.de wrote:
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????
Hi, another nice thing: We just got an error message, saying that DENIC tried to CHANGE a RIPE-HANDLE we protected by "mnt-by"... btw: whois.nic.de doesn't respond to whois-queries at the moment :-) I think they want to become a BIG player... but actually can't right now. Bye, Thorsten -- mailto:ths@salink.net | Thorsten Schreiner http://www.salink.net | SaLink Netzwerkgesellschaft mbH tel: +49 681 93 47 51 | Im Stadtwald, Geb. 30 fax: +49 681 93 47 55 | 66123 Saarbruecken
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. 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). And then the past changes of the DeNIC to set unmaintained Handles under their own Maintainer DENIC-P is abusive usage of the ripe database in my eyes. They had no permission to change our handles and the change made no sense, as the DeNIC won't support maintainers in their own database as mentioned above. Why has this mess had to happen? -- Mit freundlichen Gr|_en / with kind regards Michael Holzt
I cannot understand why the DENIC doesn't help funding with one central ripe database instead of setting up a own system.
distribution/decentralization is the key to scaling on the internet. and the internet is all about scaling. of course, we have to make the technology scalable. hence the discussion about referral etc. randy
On Thu, 29 Jun 2000, Michael Holzt wrote:
I just got response from the denic regarding my questions about future updates to handles. [...]
We would really like to act supportive - but somehow it came we cannot. Noone asked or told us by time. There was no information available in advance and the update session itself was a whole mess. Handles have been changed to mnt-by: DENIC-P even if we have had them protected with our mnt object just a day before. Even better, the corrected address data has also been changed. The reason for this was the use of a two or more days old data backup as a basis for the updates. This leads to a well known problem: lost updates. Great deal. Interestingly, at least some of these overwritten updates came back later. Furthermore, I cannot understand the rules which have been applied to the importer of the DENIC database. Which data is now there? Yesterday's RIPE data? One week before? With corrected updates? And so on.... A strategy that prevents small providers from self-managing "their" domains is inacceptable for us, as well. Stupid enough, that only DENIC members can modify or register domain names. Now, all information should be unchangeable for others than them? Why? In other countries and the internet as a whole, decentralization means deregulation. Maybe, that it is needed that .de domains and data has to leave the RIPE's main database. But does this also mean that handling has to be different or principalized? I say no. -- Best regards, Dipl.-Inform. Jens H|nerberg T: +49-30-39909070 Logivision GmbH F: +49-30-39909079 Alt-Moabit 96c E: info@logivision.de 10559 Berlin W: www.logivision.de Germany
[note local-ir is chopped from cc:] Jens Huenerberg wrote:
On Thu, 29 Jun 2000, Michael Holzt wrote:
I just got response from the denic regarding my questions about future updates to handles. [...]
We would really like to act supportive - but somehow it came we cannot. Noone asked or told us by time. There was no information available in advance and the update session itself was a whole mess. Handles have been changed to mnt-by: DENIC-P even if we have had them protected with our mnt object just a day before. Even better, the corrected address data has also been changed. The reason for this was the use of a two or more days old data backup as a basis for the updates. This leads to a well known problem: lost updates. Great deal.
Interestingly, at least some of these overwritten updates came back later. Furthermore, I cannot understand the rules which have been applied to the importer of the DENIC database. Which data is now there? Yesterday's RIPE data? One week before? With corrected updates? And so on....
Protection of unmaintained person objects referenced from *.de domains was essential because the setup of DENIC database was planned to be done in two phases: first moving domain objects, and then migrating person/role objects. Addition of DENIC-P maintainer prevented these person/role objects from accidental deletion in the period between the two phases. This was done as requested by DENIC and according to their policy. The reason this was done by RIPE NCC and not by DENIC themselves was the RIPE Database performance concerns. Unfortunately due to mistake some objects were updated that were not needed to be. These objects were converted back and the apologies were sent.
A strategy that prevents small providers from self-managing "their" domains is inacceptable for us, as well. Stupid enough, that only DENIC members can modify or register domain names. Now, all information should be unchangeable for others than them? Why?
In other countries and the internet as a whole, decentralization means deregulation. Maybe, that it is needed that .de domains and data has to leave the RIPE's main database. But does this also mean that handling has to be different or principalized? I say no.
-- Best regards,
Dipl.-Inform. Jens H|nerberg T: +49-30-39909070 Logivision GmbH F: +49-30-39909079 Alt-Moabit 96c E: info@logivision.de 10559 Berlin W: www.logivision.de Germany
Best regards, -- Andrei Robachevsky DB Group Manager RIPE NCC
Protection of unmaintained person objects referenced from *.de domains was essential because the setup of DENIC database was planned to be done in two phases: first moving domain objects, and then migrating person/role objects.
Yes, I now realize why this was done. I'm not sure I would have done it this way, but what's done is done (cross-database references doesn't strike me as a bright idea -- I would have waited until a complete database was in place at DENIC). However, it appears that the data in the RIPE database has undergone a considerable amount of decay since it was initially submitted. This has over time caused some of the pointers (nic handles) to be used where they shouldn't have been. In particular, I have seen "DENIC-P" pasted on person objects where I'm quite positive that the referenced person have absolutely nothing whatsoever to do with any domains under .DE. I've noticed this because I've lately been cleaning up the person objects which used to be referenced from the .NO domain objects, and a number of them have now become protected (where they weren't before). I don't know exactly what has caused this data decay; I'm quite positive that the .NO domain registry has always allocated new nic handles using "AUTO-xx" from the day that feature was available. Regards, - Håvard
Havard.Eidnes@runit.sintef.no wrote:
Protection of unmaintained person objects referenced from *.de domains was essential because the setup of DENIC database was planned to be done in two phases: first moving domain objects, and then migrating person/role objects.
Yes, I now realize why this was done. I'm not sure I would have done it this way, but what's done is done (cross-database references doesn't strike me as a bright idea -- I would have waited until a complete database was in place at DENIC).
However, it appears that the data in the RIPE database has undergone a considerable amount of decay since it was initially submitted. This has over time caused some of the pointers (nic handles) to be used where they shouldn't have been.
In particular, I have seen "DENIC-P" pasted on person objects where I'm quite positive that the referenced person have absolutely nothing whatsoever to do with any domains under .DE. I've noticed this because I've lately been cleaning up the person objects which used to be referenced from the .NO domain objects, and a number of them have now become protected (where they weren't before).
Håvard kindly supplied us with some examples of such nic-handles so we could look what happened. Those person objects that bear "mnt-by: DENIC-P" attribute were referenced from *.de domain objects before the latter were migrated. (We still keep *.de domains on our backup server so we were able to check this).
I don't know exactly what has caused this data decay; I'm quite positive that the .NO domain registry has always allocated new nic handles using "AUTO-xx" from the day that feature was available.
Regards,
- Håvard
Regards, Andrei -- Andrei Robachevsky DB Group Manager RIPE NCC
Håvard kindly supplied us with some examples of such nic-handles so we could look what happened. Those person objects that bear "mnt-by: DENIC-P" attribute were referenced from *.de domain objects before the latter were migrated. (We still keep *.de domains on our backup server so we were able to check this).
Yes, I expected that. However, it is my claim that almost all the references I sent you are in fact *not* reflecting the actual real-world situation, and that these references are therefore in all probability erroneous. That was what I meant when I said that the data in the RIPE DB has decayed. - Håvard
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.
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). ....and what if a handle is deleted from one DB but not from the other? Once
Hello! the handle # is re-assigned, the owner of a domain depends on the server you ask. 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
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). ....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.
Which by the way is what we have in Italy thanks to IT-NIC... So it looks this is the "standard" way ... but it being standard doesn't make it less braindead!! Bye, Andrea
On Thu, 29 Jun 100, Sebastian Willing wrote:
....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.
And how should this happen?
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).
Why? The .de objects are only in the denic db at this point, so no inconsistencies can arise. Besides, where's the problem? I can set up my own whois db and put myself in as the owner of microsoft.de or whatever, but no-one will care because everybody knows that the authoritive db is whois.denic.de - ----------------------------------------------------------------- - n@work Internet Informationssysteme GmbH Tel +49 40 23880900 Spaldingstrasse 160d Fax +49 40 23880929 20097 Hamburg, Germany http://www.work.de/
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?
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? 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@iphh.de ICQ #38955239
Michael Holzt wrote:
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.
That ones easy, it should never have been used for this info RIPE is the rIPe repository not the domains authority. The only domains that are in there are the reverse domains for very good reasons. The RIPE DB was seen as an easy route to a publicly accessable system with minimum effort, the fact these domains are now going away will take the strain off a system which was never 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. Regards Stephen Burley UUNET EMEA Hostmaster
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).
And then the past changes of the DeNIC to set unmaintained Handles under their own Maintainer DENIC-P is abusive usage of the ripe database in my eyes. They had no permission to change our handles and the change made no sense, as the DeNIC won't support maintainers in their own database as mentioned above.
Why has this mess had to happen?
-- Mit freundlichen Gr|_en / with kind regards
Michael Holzt
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. 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. 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. 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.
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.
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. -- With kind regards Michael Holzt
On Thu, 29 Jun 2000, Michael Holzt wrote:
Perhaps it wasn't designed for this usage, but it was clearly the best system we ever had for domain registry. You could use the same person handles for a number of top level domains which reduced the work in a great
Yes and once upon a time you could use RIPE handles in .com domains... More centralization isn't always a good thing. I would want the "central internet database" you propose to be run by NSI for example, or for that matter, any US entity. - ----------------------------------------------------------------- - n@work Internet Informationssysteme GmbH Tel +49 40 23880900 Spaldingstrasse 160d Fax +49 40 23880929 20097 Hamburg, Germany http://www.work.de/
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.
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.
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.
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.
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 Stephen Burley UUNET EMEA Hostmaster
-- With kind regards
Michael Holzt
Ppl, look, why do I need to have in my mailbox this spam about .de domains??? At least in .ee it's of no interest! Stop sending cc:'s to local-ir@ripe.net, move to private! rgds -- Konstantin Barinov, Senior Network Manager INFONET AS, http://infonet.ee, sbr@infonet.ee On Thu, 29 Jun 2000, Stephen Burley wrote:
Michael Holzt wrote:
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.
That ones easy, it should never have been used for this info RIPE is the rIPe repository not the domains authority. The only domains that are in there are the reverse domains for very good reasons. The RIPE DB was seen as an easy route to a publicly accessable system with minimum effort, the fact these domains are now going away will take the strain off a system which was never 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.
Regards Stephen Burley UUNET EMEA Hostmaster
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).
And then the past changes of the DeNIC to set unmaintained Handles under their own Maintainer DENIC-P is abusive usage of the ripe database in my eyes. They had no permission to change our handles and the change made no sense, as the DeNIC won't support maintainers in their own database as mentioned above.
Why has this mess had to happen?
-- Mit freundlichen Gr|_en / with kind regards
Michael Holzt
On Thu, 29 Jun 2000, Michael Holzt wrote:
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.
No, it is not. It will greatly help with the consistency of Person objects. Several of our customers have several RIPE Handles - Just because each is mnt-by a different provider.
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).
OBVIOUSLY since the Person handles have not yet been migrated, the person data in denic's database is not authoritive.
And then the past changes of the DeNIC to set unmaintained Handles under their own Maintainer DENIC-P is abusive usage of the ripe database in my eyes. They had no permission to change our handles and the change made no sense, as the DeNIC won't support maintainers in their own database as mentioned above.
So WHY did you NOT set your own maintainer before Denic did so? I seem to remember quite clearly that there was advanced warning of this. You do realize that a person without a maintainer can be changed by ANYBODY? This is a serious security risk and could lead to the loss of domains, etc.
Why has this mess had to happen?
Maybe because people like you don't pay attention until after the fact...? Best wishes, Nils Jeppe - ----------------------------------------------------------------- - n@work Internet Informationssysteme GmbH Tel +49 40 23880900 Spaldingstrasse 160d Fax +49 40 23880929 20097 Hamburg, Germany http://www.work.de/
On Fri, Jun 30, 2000 at 11:32:53AM +0200, Nils Jeppe wrote:
It will greatly help with the consistency of Person objects. Several of our customers have several RIPE Handles - Just because each is mnt-by a different provider.
AFAIK this will not change es DENIC-handles will be tied to DENIC-members, too. Correct me if I'm wrong, please.
OBVIOUSLY since the Person handles have not yet been migrated, the person data in denic's database is not authoritive.
But it gets delivered to querying clients. Without any information about the data being non-authoritative and people should query RIPE.
So WHY did you NOT set your own maintainer before Denic did so?
Thats another question. What DENIC did I would call "hijacking". Not everyone knows the DENIC-P password.
You do realize that a person without a maintainer can be changed by ANYBODY?
You do realize that he's not able to change his data anymore but DENIC?
This is a serious security risk and could lead to the loss of domains, etc.
DENIC is not responsible for the security of RIPE person/role objects. This is plain insolent. Do you think CRYPT-PW are secure? C'mon... Do you think DENICs methods to "protect" things are secure? NOW we can use PGP-AUTH to protect our data. Best regards, Daniel -- Entire Systems Network Operations Center noc@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
Hi, must be a really stupid conversion procedure ... A large part here in east germany has a leading zero at the ZIP-Code - nice that these zeros where removed ... role: Hostmaster Webmatic address: Webmatic Kommunikations GmbH address: Weissenfelser Str. 46a address: 6217 Merseburg address: DE e-mail: hostmaster@webmatic.de nic-hdl: WMT1-RIPE changed: test@nowhere.denic.de 20000321 source: DENIC Regards, Thomas. Thorsten Schreiner wrote:
henning.brauer@bsmail.de wrote:
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????
Hi,
another nice thing: We just got an error message, saying that DENIC tried to CHANGE a RIPE-HANDLE we protected by "mnt-by"...
btw: whois.nic.de doesn't respond to whois-queries at the moment :-)
I think they want to become a BIG player... but actually can't right now.
Bye, Thorsten
-- mailto:ths@salink.net | Thorsten Schreiner http://www.salink.net | SaLink Netzwerkgesellschaft mbH tel: +49 681 93 47 51 | Im Stadtwald, Geb. 30 fax: +49 681 93 47 55 | 66123 Saarbruecken
-- ------------------------------------------------------------ Thomas Krause Webmatic Kommunikations GmbH Tel: +49 3461 336630 ------------------------------------------------------------
must be a really stupid conversion procedure ... A large part here in east germany has a leading zero at the ZIP-Code - nice that these zeros where removed ... I just count all errors made and cannot do anything more
Thomas Krause wrote To Thorsten Schreiner: than shaking my head. This is absolutely professional. NOT! What about this `test@nowhere.denic.de' changed lines anywhere too? ciao -- Philipp Buehler, aka fIpS | sysfive.com GmbH | BOfH | NUCH | <double-p> %SYSTEM-F-TOOEARLY, please contact your sysadmin at a sensible time. Artificial Intelligence stands no chance against Natural Stupidity.
And where are the mnt-by objects? Ralf On Thu, 29 Jun 2000, henning.brauer@bsmail.de shaped the electrons to say:
Date: Thu, 29 Jun 2000 13:23:11 +0200 From: henning.brauer@bsmail.de To: lir-wg@ripe.net, db-wg@ripe.net, local-ir@ripe.net Subject: 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@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@ripe.net, db-wg@ripe.net, local-ir@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@ripe.net.
-- Filippo Portera
------------ ein Unternehmen der SHE Informationstechnologie AG ----------- Ralf Naegele _/_/_/ _/ _/ _/_/_/ SHE Kommunikations-Systeme GmbH _/ _/ _/ _/ Phon: +49 621 52 00 0 Donnersbergweg 3 _/_/ _/_/_/ _/_/ Fax: +49 621 52 00 551 D-67059 Ludwigshafen _/ _/ _/ _/ Mail: ralf.naegele@she.net Xlink-PoP LU/MA/HD/KL/DA _/_/_/ _/ _/ _/_/_/ http://www.she.net/ -------------------------- Security is our business ----------------------- No HTML or WORD in Mails. HTML is for WEB, Word is for Micro$oft.
participants (17)
-
Andrea Campi
-
Andrei Robachevsky
-
Daniel Roesen
-
Havard.Eidnes@runit.sintef.no
-
henning.brauer@bsmail.de
-
Jens Huenerberg
-
Konstantin Barinov
-
Michael Holzt
-
Nils Jeppe
-
Philipp Buehler
-
Ralf Naegele
-
Randy Bush
-
Sascha E. Pollok
-
Sebastian Willing
-
Stephen Burley
-
Thomas Krause
-
Thorsten Schreiner