193.in-addr.arpa block delegation procedures (draft)
Folks, It seems that the delegation of the 193.in-addr.arpa domain will take place during the root zone update of today. In order to be able to delegate class C blocks in this zone, we have drafted some procedures for this. Please read the paper below and comment within one week. We will finalize this paper next week, and then start delegating blocks of Cs in the domain. Cheers, -Marten Guidelines for the delegation of class C blocks in the 193.in-addr.arpa domain Marten Terpstra March 1993 1.0 Introduction This document describes the procedures for the delegation of authority of zones in the 193.in-addr.arpa domain. As of March 16th 1993 the RIPE NCC has been delegated the authority for the 193.in-addr.arpa domain from the root. Due to the fact that in the 193.x.y address space blocks of 256 class C network numbers are further delegated to local registries and national registries, the possibility exists to also delegate the zone for these blocks in the 193.in-addr.arpa domain. This document describes some guidelines and procedures for this type of delegation. A bit more explained With the assignment of class C network numbers following the CIDR (RFC 1338) model, in which large chunks of the address space are delegated to one region, and within that region blocks of class C network numbers are delegated to service providers and national registries, some hierarchy in the address space is created, similar to the hierarchy in the domain name space. Due to this hierarchy the reverse Domain Name System mapping can also be delegated in a similar model as used for the normal Domain Name System. For instance, the RIPE NCC has been delegated the complete class C address space starting with 193. It is therefore possible to delegate the 193.in-addr.arpa domain completely to the RIPE NCC, in stead of each and every reverse mapping in the 193.in-addr.arpa domain to be registered with the INTERNIC. This implies that all 193.in-addr.arpa resistrations will be done by the RIPE NCC. Even better, since service providers receive complete class C network blocks from the RIPE NCC, the RIPE NCC can delegate the reverse registrations for such complete blocks to these local registries. This implies that customers of these service providers no longer have to register their reverse domain mapping with the root, but the service provider have authority over that part of the reverse mapping. This decreases the workload on the INTERNIC and the RIPE NCC, and at the same time increase the service a provider can offer its customers and response times for such additions. However there are some things that need to be examined a bit more closely to avoid confusion and inconsistencies. These issues are covered in the next section. Procedures 1. A secondary nameserver at ns.ripe.net is mandatory for all blocks of class C network numbers delegated in the 193.in-addr.arpa domain. 2. Because of the increasing importance of correct reverse address mapping, for all delegated blocks a good set of secondaries must be defined. There should be at least 2 nameservers for all blocks delegated, excluding the RIPE NCC secondary. 3. All reverse servers for blocks must be reachable from the whole of the Internet. In short, all servers must meet similar connectivity requirements as top-level domain servers. 4. Running the reverse server for class C blocks does not imply that one controls that part of the reverse domain, it only implies that one administers that part of the reverse domain. 5. Before adding individual nets, the administrator of a reverse domain must check wether all servers to be added for these nets are indeed setup properly. 6. There are some serious implications when a customer of a service provider that uses address space out of the service provider class C blocks, moves to another service provider. The service provider cannot force its ex-customer to change network addresses, and will have to continue to provide the appropriate delegation records for reverse mapping of these addresses, even though it is no longer a customer of his. Above procedures are defined to ensure the necessary high availability for the 193 reverse domains, and to minimize confusion. The NCC will ensure fast 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 delegation of reverse zones from the registries to individual organisations.
It seems that the delegation of the 193.in-addr.arpa domain will take place during the root zone update of today. In order to be able to delegate class C blocks in this zone, we have drafted some procedures for this.
Good!
Please read the paper below and comment within one week. We will finalize this paper next week, and then start delegating blocks of Cs in the domain.
The paper looks just fine. My only comment is that perhaps there are a few things left unsaid? Anyway, I am left with the following questions: - how do one request delegation of a subdomain of 193.in-addr.arpa. Contact hostmaster@ripe.net with a free-form text message, or should we bother to create a form? - 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)? Regards, - H}vard
Please read the paper below and comment within one week. We will finalize this paper next week, and then start delegating blocks of Cs in the domain.
The paper looks just fine. My only comment is that perhaps there are a few things left unsaid? Anyway, I am left with the following questions:
- how do one request delegation of a subdomain of 193.in-addr.arpa. Contact hostmaster@ripe.net with a free-form text message, or should we bother to create a form?
- 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)?
Regards,
- H}vard
I had the same questions in my mind while reading the paper. I have thought some answers: 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. 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. Please note that I am using the zone-c tag in a network template: this is presently not allowed by the RIPE db rules, but I think we need to precisely qualify this kind of contact information. ---------- ---------- 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 ---------- ----------
[Comments from Havard] * - how do one request delegation of a subdomain of 193.in-addr.arpa. * Contact hostmaster@ripe.net 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@ripe.net 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@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) [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@nic.ddn.mil 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
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 ---------- ----------
bonito@nis.garr.it (Antonio_Blasco Bonito) writes: * Uhmmm, may be I'm wrong but I see some inconsistencies in your consideration * 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 vi * ce * > versa) * * Here you are saying to use rev-srv which is a network tag in the database. * * > 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 consist * ent. * * In this case the decision should be to avoid the usage of rev-srv network ta * gs * 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. Yes and no inconsistent. I was just brainstorming a bit here, and since it would be nice for some people to have the delegated blocks in the database I was looking for a way to include them in the database. I do NOT want to suggest here that all the rev-srv fields should be changed by sending in in-addr,arpa domains for individual nets, just for the blocks. This might be a bit confusing. I am just looking for possibilities that are both easy and clear ... -Marten
Yes and no inconsistent. I was just brainstorming a bit here, and since it would be nice for some people to have the delegated blocks in the database I was looking for a way to include them in the database. I do NOT want to suggest here that all the rev-srv fields should be changed by sending in in-addr,arpa domains for individual nets, just for the blocks. This might be a bit confusing. I am just looking for possibilities that are both easy and clear ...
-Marten
OK, but at least we have to decide about 193.something networks. Either we use rev-srv network tags or we use nserver domain tags. Using both is certainly tedious and confusing. ---------- ---------- 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 ---------- ----------
bonito@nis.garr.it (Antonio_Blasco Bonito) writes: * > Yes and no inconsistent. I was just brainstorming a bit here, and since it * > would be nice for some people to have the delegated blocks in the database * I * > was looking for a way to include them in the database. I do NOT want to * > suggest here that all the rev-srv fields should be changed by sending in * > in-addr,arpa domains for individual nets, just for the blocks. This might * be * > a bit confusing. I am just looking for possibilities that are both easy an * d * > clear ... * > * > -Marten * * OK, but at least we have to decide about 193.something networks. * Either we use rev-srv network tags or we use nserver domain tags. * Using both is certainly tedious and confusing. Blasco, I agree and I do not agree here (maybe I should make up my mind ;-) I agree that using both can be confusing, but they are used for different purposes. I would not like to see individual nets as in-addr.arpa domains in the database, because that information is superfluous in my view. There are no delegated blocks in the database yet, so I kind of like the idea of putting them (and only them) as in-addr.arpa domains in the db. The only ones that have to deal with these domains are registries, who I hope are not too easily confused. I could be wrong here. Anyone else with bright ideas ? Another thing would be to create YADO (Yet Another Database Object) for delegated blocks only, but I do not quite like that idea either. -Marten
bonito@nis.garr.it (Antonio_Blasco Bonito) writes: * > Yes and no inconsistent. I was just brainstorming a bit here, and since it * > would be nice for some people to have the delegated blocks in the database * I * > was looking for a way to include them in the database. I do NOT want to * > suggest here that all the rev-srv fields should be changed by sending in * > in-addr,arpa domains for individual nets, just for the blocks. This might * be * > a bit confusing. I am just looking for possibilities that are both easy an * d * > clear ... * > * > -Marten * * OK, but at least we have to decide about 193.something networks. * Either we use rev-srv network tags or we use nserver domain tags. * Using both is certainly tedious and confusing.
Blasco,
I agree and I do not agree here (maybe I should make up my mind ;-) I agree that using both can be confusing, but they are used for different purposes. I would not like to see individual nets as in-addr.arpa domains in 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. - when using inetnum entries and rev-srv tags an important information is missing: the zone-contact.
There are no delegated blocks in the database yet, so I kind of like the idea of putting them (and only them) as in-addr.arpa domains in the db. The only ones that have to deal with these domains are registries, who I hope are not too easily confused.
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.
I could be wrong here. Anyone else with bright ideas ?
I don't think is a bright idea, but at this point I'm in favour of definining rev-srv tags obsolete and use only in-addr.arpa domains at any level.
Another thing would be to create YADO (Yet Another Database Object) for delegated blocks only, but I do not quite like that idea either.
me too. ---------- ---------- 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 ---------- ----------
bonito@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
participants (1)
-
bonito＠nis.garr.it -
Havard Eidnes -
Marten Terpstra