Uhmmm, may be I'm wrong but I see some inconsistencies in your considerations:
* - How will the domain administrators for the subdomains of 193.in-addr.arpa * be made aware of a desire to have delegation installed for a subdomain? * There was some talk about doing this semi-automatically with the nic when * a RIPE network registration form was sent in to ripe-dbm@ripe.net or * assign@ripe.net, could this be used here (in addition to other means)?
In fact we have the following in mind. For blocks that are not yet delegated, we intend to use the information people supply in the "rev-srv:" field to update the 193.in-addr.arpa domain. For blocks that have been delegated, the people that have been assigned class C nets from such a block should be made aware that reverse registration should be done by either the NCC is the local registry does NOT run the delegated block, or by the local registry. We could look into extending our "rev-srv:" program to notify maintainers of blocks in 193.in-addr.arpa if the information in the database has changed. They could then update their zones if needed. This however does imply that the "rev-srv:" field becomes authoritative for reverse mapping (and not vice versa)
Here you are saying to use rev-srv which is a network tag in the database.
[Suggestions from Blasco]
* 2a. The names of the reverse nameserver which are delegated by RIPE-NCC * to act as authoritative servers for a 256-class C block are sent * to the RIPE-NCC and registered in the RIPE db using a template * like this: * * inetnum: 193.x.0.0 (where x is the block number) * <administravia> * zone-c: <person> * rev-srv: <first server name> * rev-srv: <second server name> * rev-srv: ns.ripe.net * * as soon as the Local IR receives from RIPE-NCC a new block to * administer.
I do not quite like this idea. 193.x.0.0 is a normal class C network number that just could be used (although we recommend not to do so) and I hate having information in the database with "some special meaning you have to know". The other thing would be to just have an extra entry for the complete block in the database (so you would get two answers if you queried a network inside the block), but that I do not like because you are not responsible for individual nets inside the block... If you really want to put it in the database, why not send in an object like:
domain: 204.193.in-addr.arpa descr: blah zone-c: <person> nserver: <first server> nserver: <second server> nserver: ns.ripe.net ....
It is a domain, so why not pick the right object for it ?
Here you say that the nserver (domain tag) should be used. What you say is right, so I can agree to use domains in the database to give reverse servers information but then we should always use them to be consistent. In this case the decision should be to avoid the usage of rev-srv network tags in the future and to use nserver domain tag instead for each network regardless of being it class B, single or block class C. Moreover it makes no sense to register reverse servers for a block of class C because the DNS doesn't have any knowledge of blocks: any nameserver manager has to register every single network in a block in the DNS. If we adopt this way of registering reverse-servers it would be wise to issue a recommendation to convert old rev-srv network tags into domain entries with nserver tags. ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito@nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 ---------- ----------