...... Still, there are the issues of the DNS versus the DB, but I feel that others are already dealing with that one ;-) In the previous discussion concerning DNS and RIPE database coherence, I think that we should try to keep separate different issues (DNS and RIPE dbm). 1) We have a system designed to deal with addressing, naming servers, etc. the DNS. We should concentrate on this system for this purpose. It should be considered the real source of information for the data it as been designed to deal with. So, the place were I can find the information about servers, addresses, etc. is in the DNS. Well, DNS has been designed to be managed in a decentralized way. This is a very good point but it has a very bad point: in general it contains lots of errors and inconsistencies. Conclusion: we should invest in tools to detect such errors and notify the administrators concerned. There are some of these tools available in the archive of RIPE. Anyway, I, as an administrator, would prefer to have a single point of focus for stating which are the servers running authoritative for my domain or for the reverse mapping of my network and that is the DNS, nothing more. 2) We have the RIPE database: this is a very good tool to deal with some administrative data. Well, lets use it for this purpose. Anyway, we should avoid to have to deal manually with DUPLICATE data. So, we should avoid to have information about servers and addresses of those servers in the RIPE dbm. My suggestion is: use the RIPE dbm to deal * only * with those informations that cannot be effectively registered in the DNS. If we decide to maintain in the RIPE dbm information about DNS servers, those fields should be automatically updated from the DNS on a (for example) monthly basis. And its semantics should be seen as "the vison about this subject that the tools of the RIPE NCC have been able to extract from the DNS some XXX days ago". I do not believe on centralized repositories and management unless I have no other way to avoid it. I do not believe in consistency maintained mannually by hundreds (thousands ?) of administrators. Jose'