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/[email protected]/
193.in-addr.arpa block delegation procedures (draft)
- Previous message (by thread): 193.in-addr.arpa block delegation procedures (draft)
- Next message (by thread): 193.in-addr.arpa block delegation procedures (draft)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Marten Terpstra
Marten.Terpstra at ripe.net
Fri Mar 19 15:19:25 CET 1993
bonito at nis.garr.it (Antonio_Blasco Bonito) writes: * > * > the database, because that information is superfluous in my view. * * Maybe, but: * - some individual net has already been registered in ripe db as in-addr.arpa * domain and you have no way to avoid that, I guess. Noop, if people have the need to send in in-addr.arpa domains for individual nets, please do so. No way we can and will avoid that ... * - when using inetnum entries and rev-srv tags an important information * is missing: the zone-contact. This is even more confusing if you ask me. Because the zone-c would only have a meaning relative to the rev-srv fields, not to the inetnum itself. I bet you a lot of people will fill in wrong information here, or simply not even understand what to put in here. * What you are suggesting is to store in the database only one level * of delegation (between RIPE-NCC and local registries). OK but the registries * need to further delegate reverse resolution. If the ripe db cannot store * the information about individual nets, local registries have to use * some other tool, likely to be different for each registry. In my opinion the rev-srv entry is enough information to store. Do you really want to generate an extra object for the reverse domains, where all the information (except the zone-c) is already in the inetnum object. You are of course free to do so. * > Another thing would be to create YADO (Yet Another Database Object) for * > delegated blocks only, but I do not quite like that idea either. After some in-house discussion here we would like to following: - requests for delegation of a block in 193.in-addr.arpa should be done by sending in the xxx.193.in-addr.arpa domain object to HOSTMASTER. - we will then forward all entries that are already in the 193.in-addr.arpa zone that belong to this block - we will check that the existing entries are put into the delegated zone. - we will delegate authority, and pass object to the database - we will forward any request for reverse registration inside this block to the zone-c for this reverse block. The question about zone-c in the inetnum object and/or removing the rev-srv field and replace it by an individual net.block.193.in-addr.arpa domain is something for the database and dns working group. We really would like to get the block delegation going. If noone has strong objections against the above procedure for block delegation (not the net things), I will update the document and send out a new version later today (probably tonight). -Marten
- Previous message (by thread): 193.in-addr.arpa block delegation procedures (draft)
- Next message (by thread): 193.in-addr.arpa block delegation procedures (draft)
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[ db-wg Archives ]