This archive is retained to ensure existing URLs remain functional. It will not contain any emails sent to this mailing list after July 1, 2024. For all messages, including those sent before and after this date, please visit the new location of the archive at https://mailman.ripe.net/archives/list/db-wg@ripe.net/
Blocks in 193.in-addr.arpa domain document
- Previous message (by thread): Blocks in 193.in-addr.arpa domain document
- Next message (by thread): Blocks in 193.in-addr.arpa domain document
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Marten Terpstra
Marten.Terpstra at ripe.net
Wed Mar 24 12:03:09 CET 1993
bonito at nis.garr.it (Antonio_Blasco Bonito) writes: * > * * Sorry, but I think the document is still missing some detail. * Altough implicit I think it should clearly say that delegation can be * done either for each single class-C net or for a 256-block. Unfortunately * no delegation is possible for smaller blocks. No need to be sorry, this is what comment periods are for ;-) I will only put in that this document deals with the 256 class C delegation. As you can make up from the title, this only deals with blocks delegations, not with single C delegations. We have to write a short document how we handle single class C delegations (probably just a description that we will use the rev-srv fields. * > 8. The registration of the reverse zones for individual class C networks * > will usually be done by the registry administering the class C block * > this network has been assigned from. The registry will make the * > necessary changes to the zone, and update the network objects in the * > RIPE database for these networks, to reflect the correct "rev-srv" * > fields. In case the RIPE NCC receives a request for the reverse zone of * > an individual class C network out of a block that has been delegated, * > the request will be forwarded to the zone contact for this reverse * > block. * OK, but it is not said how the RIPE-NCC should receive (in a network templat * e?) * a request for a network belonging to a block which has not been delegated to * any local registry and what happens then. * Suppose you get: * inetnum: 193.204.64.0 - 193.204.67.0 * <administrativia> * rev-srv: <server1> * rev-srv: <server2> * But server1 and server2 only have data for 64.204.193.in-addr.arpa. because * the remaining three nets in the block are not yet active. * What will you do? My gut feeling would be we add them anyway. If the nets are not yet active, there is probably no need to do reverse lookups anyway, so noone would notice. On the other hand this would clash with the constraint that we would like to see all servers working before we add them ... I think we can put some intelligence in the rev-srv field to DNS record generator to get around these things. Daniel ? * > Above procedures are defined to ensure the necessary high availability for * > the 193 reverse domains, and to minimize confusion. The NCC will ensure fa * st * > repsonse times for addition requests, and will in principle update the * > 193.in-addr.arpa domain at least once per working day. * > * > The NCC also suggests that similar procedures are set up for the delegatio * n * > of reverse zones from the registries to individual organisations. * I think this sentence should be expanded/clarified: no block delegation is * possible from a local registry to individual organization, only single * networks are under a 256-block. OK, has been changed to: The NCC also suggests that similar procedures are set up for the delegation of reverse zones for individual class C networks from the registries to individual organisations.
- Previous message (by thread): Blocks in 193.in-addr.arpa domain document
- Next message (by thread): Blocks in 193.in-addr.arpa domain document
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]