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