At 02:17 PM 12/8/1998 -0800, Michael Dillon wrote:
On Tue, 8 Dec 1998 prue@ISI.EDU wrote:
...Presumably in this case, you are responsible for that nameserver and therefore the /32 should be SWIP'd to you.
so well, that Paul decides to sell this as a service to many small/medium size ISP's, running it on a single server. Now one /32 is the name server for multiple networks. So the registration system must be able to deal with that. This is not an unreasonable scenario.
In this case Paul would not SWIP the /32 at all since he maintains the responsibility for the server. Presumably then he would handle the registration of the nameserver address with ARIN and the original problem would not occur since the registration application is coming from the entity with administrative control over the IP address in question.
But if he hasn't been SWIP'd the address for his server, then ARIN won't let him assign his machine as a nameserver for inverse mapping. This might be the case if he just buys a machine and colocates it somewhere else. There is no reason to assume that management of the server also implies management of the address (address space) used by the server. (or vice versa). Whats important is that you manage the machine, and the address space whose in-addr zone you plan to service. Basically, I think one is trying to prevent lame delegations, and manage address space so that one can find out who is authoritative for it. I think there are two pieces of information that are necessary: 1) responsibility for the address space whose in-addr zone is to be serviced. Indicated by the address space coordinator 2) responsibility for the server that is to provide DNS service. Indicated by the name/handle of the server and the host coordinator. ARIN has inserted a third requirement, that I think is probably unnecessary: 3) responsibility for the address space which includes the address of the nameserver. The third requirement only works for those that put nameservers in their own address space, and doesn't seem to add anything to the goals of preventing lame delegations or address space coordination. --Dean ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
In this case Paul would not SWIP the /32 at all since he maintains the responsibility for the server. Presumably then he would handle the registration of the nameserver address with ARIN and the original problem would not occur since the registration application is coming from the entity with administrative control over the IP address in question.
But if he hasn't been SWIP'd the address for his server, then ARIN won't let him assign his machine as a nameserver for inverse mapping. This might be the case if he just buys a machine and colocates it somewhere else.
There is no reason to assume that management of the server also implies management of the address (address space) used by the server. (or vice versa). Whats important is that you manage the machine, and the address space whose in-addr zone you plan to service.
Basically, I think one is trying to prevent lame delegations, and manage address space so that one can find out who is authoritative for it. I think there are two pieces of information that are necessary:
1) responsibility for the address space whose in-addr zone is to be serviced. Indicated by the address space coordinator
2) responsibility for the server that is to provide DNS service. Indicated by the name/handle of the server and the host coordinator.
ARIN has inserted a third requirement, that I think is probably unnecessary:
3) responsibility for the address space which includes the address of the nameserver.
The third requirement only works for those that put nameservers in their own address space, and doesn't seem to add anything to the goals of preventing lame delegations or address space coordination.
Dean...we added this requirement a while ago after Jon Postel/IANA came to us about the number of unassigned and incorrect IP numbers being used on in-addr entries. Up to now, it hasn't been an issue but you do have a valid point so we'll review the policy and adjust it in a way to allow for exceptions like yours. Kim
--Dean
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Plain Aviation, Inc dean@av8.com LAN/WAN/UNIX/NT/TCPIP http://www.av8.com ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
participants (2)
-
Dean Anderson -
Kim Hubbard