Re: in-addr.arpa zone data in RIPE database

[Daniel Karrenberg <]

  > jalm@localhost (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