ARIN co-located nameserver problem
Dean Anderson
consolidating nameservers for a new customer, and want to make our
nameservers authoritative for the in-addr maps.
We have a nameserver co-located at Empire Net in Nashua, NH. We do this
because we don't want to have nameservice fail if our own internet
connection goes down. Needless to say, Empire.net isn't responsible for
our address space, nor our domains, nor the management of this machine.
The machine at empire.net is currently authoritative for in-addr zones for
other address space, and changing nameserver IP addresses previously has
not been problematic.
ARIN is now enforcing a policy of registering nameservers by IP address
instead of by name as Internic and other registeries do (and did prior to
ARIN).
ARIN says that the IP address of the nameserver 208.223.51.250 does not
belong to us (it belongs to Empire.net)--and therefore they can't put
through a change to our inverse map for address space that we are
coordinator of. We only have one address for one colocated machine. ARIN
says it (one IP address) must be SWIP'ed to us before the changes will be
allowed. ?!?
This hasn't been a problem until now apparently because ARIN never
previously enforced this policy.
So, does anyone else have a similar situation where nameservers are
colocated somewhere else? I'm pretty sure this is the case, so this is a
heads up that you will have problems with updating IN-ADDR info.
What about this policy of ARIN's--Do people think ARIN should be
registering nameservers by name or by IP address? To make this work in
general, one would need to SWIP single IP addresses.
--Dean
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Plain Aviation, Inc de...@av8.com
LAN/WAN/UNIX/NT/TCPIP http://www.av8.com
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Michael Dillon
> What about this policy of ARIN's--Do people think ARIN should be
> registering nameservers by name or by IP address? To make this work in
> general, one would need to SWIP single IP addresses.
There was a discussion about what should be SWIP'd in Seattle and it
seemed that the conclusion was that SWIP policy should not be based on
block size. Instead it should be based upon whether or not network
operators need to know who is responsible for the network using that
block. Presumably in this case, you are responsible for that nameserver
and therefore the /32 should be SWIP'd to you. This does not mean that all
/32 assignments should be SWIP'd, just the occasional special ones like a
nameserver located on someone else's network.
--
Michael Dillon - E-mail: mic...@memra.com
Check the website for my Internet World articles - http://www.memra.com
Michael Dillon
> >...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.
pr...@isi.edu
>...Presumably in this case, you are responsible for that nameserver
>and therefore the /32 should be SWIP'd to you.
I do not see this as a valid assumption. It may well be that you don't
want to be bothered with DNS maintenance or you don't trust your own
network engineers to do DNS right and that you want to pay, say Paul
Vixie, to do your DNS for you. His name and the quality of his DNS
knowledge will add credulity to your network service. This works out
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.
Walt Prue
Dean Anderson
>> >and therefore the /32 should be SWIP'd to you.
>
>> 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.
>
>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.
Wayne
> On Tue, 8 Dec 1998, Dean Anderson wrote:
>
>> What about this policy of ARIN's--Do people think ARIN should be
>> registering nameservers by name or by IP address? To make this work in
>> general, one would need to SWIP single IP addresses.
>
> There was a discussion about what should be SWIP'd in Seattle and it
> seemed that the conclusion was that SWIP policy should not be based on
> block size. Instead it should be based upon whether or not network
> operators need to know who is responsible for the network using that
> block. Presumably in this case, you are responsible for that nameserver
> and therefore the /32 should be SWIP'd to you. This does not mean that all
> /32 assignments should be SWIP'd, just the occasional special ones like a
> nameserver located on someone else's network.
That makes no sense.
It's really not ARIN's business what address space a nameserver lives on.
ARIN should be attaching IN-ADDR records to a NIC handle, and the owner of
that NIC handle should be able to change the host's name and IP address
inside that NIC whatever they want.
Kim Hubbard
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
Randy Bush
arin is delegating. a delegator has the obligation to the community to see
that the delegatee's nameservice is correctly done.
randy
Dean Anderson
--Dean
>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
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Karl Denninger
BUT THAT IS ALL.
The authoritative answer for a zone, and request from the contact to change
the delegation to the new server (which returns authority) is IT.
Anything else isn't "responsibility" - it is punitive and potentially a lot
of other things I'd rather not say.
--
--
Karl Denninger (ka...@denninger.net) http://www.mcs.net/~karl
I ain't even *authorized* to speak for anyone other than myself, so give
up now on trying to associate my words with any particular organization.