......
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'
