North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: ARIN co-located nameserver problem
> >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 [email protected] > LAN/WAN/UNIX/NT/TCPIP http://www.av8.com > ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ >
|