Re: in-addr.arpa zone data in RIPE database
...... 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'
jalm@spirou.puug.pt (Jose Legatheaux Martins) writes:
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.
Fully agree and the proposal is to use the RIPE DB for this in Eurpe.
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.
Of course there is a chicken and egg problem here. In order to use the DNS for anything, the appropriate NS RRs have to be put in somewhere. One has to keep a record of which NS RRs go where. Currently in-addr.arpa is centralised and this means that we need a centralised registry.
My suggestion is: use the RIPE dbm to deal * only * with those informations that cannot be effectively registered in the DNS.
Wholeheartedly agree. Remember I proposed to get rid of the domain object in the RIPE DB? Well I was told that there is some information in those objects that connot be represented in the DNS. So we kept it.
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.
See "chicken and egg" above.
I do not believe on centralized repositories and management unless I have no other way to avoid it.
In general you are right.
I do not believe in consistency maintained mannually by hundreds (thousands ?) of administrators.
That's why you are right only "in general". Daniel
participants (2)
-
Daniel Karrenberg -
jalm＠spirou.puug.pt