in-addr.arpa zone data in RIPE database
Daniel Karrenberg Daniel.Karrenberg at ripe.net
Wed Mar 3 12:18:35 CET 1993
> jalm at 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
[ lir-wg Archives ]