Re: 193.in-addr.arpa block delegation procedures (draft)
[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 (2)
-
bonito＠nis.garr.it -
Marten Terpstra