ARIN co-located nameserver problem

Kim Hubbard kimh at arin.net
Wed Dec 9 19:31:01 UTC 1998


> >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 at av8.com
>            LAN/WAN/UNIX/NT/TCPIP          http://www.av8.com
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 




More information about the NANOG mailing list