Re: 193.in-addr.arpa block delegation procedures (draft)

[Marten Terpstra <]

[Comments from Havard]

 *  - how do one request delegation of a subdomain of 193.in-addr.arpa.
 *    Contact hostmaster@localhost with a free-form text message, or should we
 *    bother to create a form?

Ahh, no extra forms please !!!
All we need to know is class C block, and all the servers. I do not think we
need another form for that ... Please just contact hostmaster@localhost with
the needed information. We will be able to parse it ;-) Or maybe the
suggestions below ...


 *  - 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@localhost or
 *    assign@localhost, 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)

[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 ?

 * 7.  Usually the registration of reverse servers for individual class C nets
 *     or class C subblocks is done by the service provider who is administering
 *     the whole 256-class C block who in turn notifies the RIPE-NCC sending
 *     an updated network template for inclusion in the RIPE db.
 *     However should the RIPE-NCC receive any template for a single class C net
 *     or subblock not from the service provider, they must forward the template
 *     to the authoritative zone-c for the 256-class C block.

Totally agree. We will not "overrule" delegations by putting them directly in
193.in-addr.arpa, like we expect hostmaster@localhost to do the same. We
will of course forward such requests.

I will update the document with regard to the last point, and the other point
if we can each agreement on the "how to notify I want a block delegated". An
object like above could be used as a request for delegation of a block.

-Marten