[ga] [ppml] INADDR access should be axfr off all the INADDR DNS servers(WAS) A proposal to modify proposal 2003-9 (WHOIS and INADDR access)

[Joe Baptista <baptista@dot-god.com>]

Frankly I think restricting access to the INADDR zone is lunacy.  What if
all the INADDR servers are under attack and reverse resolution goes
offline.  Would it not be nice if ISP's had the option of slaving the
zone via axfr.

Of course the zone is now a mess.  And I did not give permission nor have
any of the legacy ipv4 allocations been given an opportunity to comment.

It was my understanding that our reverse resolution was IN-ADDR.arpa.  Now
I find out we no longer have our allocation listed in the IN-ADDR.arpa
zone.  Instead in one case we now are listed in the 199.IN-ADDR.arpa zone.
and so on and so forth.  It seems that arin has taken over our zones
without our permission, consent or knowledge.  I never agreed to this when
we applied for our direct allocations.  Does anyone know.  What are the
legal ramification of the RIR taking over legacy IN-ADDR.arpa zones.  Was
there a policy covering this?

In any case dividing the IN-ADDR.arpa into zones controlled by the RIR is
not in my opinion good policy.  In order to avoid disaster in case of
attack against the IN-ADDR.arpa zone it would be prudent for isp's to have
the ability to slave the zone.  but the way it's now divided up is a
nighmare to anyone since you have to slave bits and pieces of it and that
provided the RIR's have axfr turned on, and you know which zones you want
to slave and which RIR carries it.  What nonsense.

I personally used to slave IN-ADDR.arpa and now i can't anymore since it
no longer provides the security needed to avoid a potential attach againt
the IN-ADDR.arpa servers.  The RIR being in the middle have messed it up.

regards
joe baptista

Joe Baptista - only at www.baptista.god

another useless fact ....
A bolt of lightning can strike the Earth with a force as great as 100
million volts.

On Tue, 10 Jun 2003, Owen DeLong wrote:

> OK... I guess I'll throw my hat in the ring here...
>
> I think that the IN-ADDR data should be provided.  If ARIN staff feels
> a policy is needed, then I think two things have happened...
>
> 	1.	ARIN staff has become too policy focused.  IN-ADDR can
> 		be easily mapped by repeatedly hitting the DNS servers
> 		and there are no privacy issues with it.  The data should
> 		simply be made available.  As such, I hope this will provide
> 		the impetus for RichardJ to get whatever approvals are
> 		necessary from ARIN Management/BOD to make this happen without
> 		policy.
>
> 	2.	We have discovered the need for additional clarification to
> 		the ARIN staff of what should and should not require
> 		formal public policies to accomplish.
>
> Personally, I think that the ARIN IN-ADDR zone file(s) should be made
> available
> via FTP and/or HTTP and that should be the end of it.
>
> However, I am not diametrically opposed to applying the same AUP to WHOIS
> and IN-ADDR.  I think it is policy overkill, but, it's certainly better
> than not having the IN-ADDR information available at all.
>
> Owen
>
>
> --On Tuesday, June 10, 2003 4:39 AM -0600 John Brown <john@chagres.net>
> wrote:
>
> > On Tue, Jun 10, 2003 at 12:44:26AM -0700, william@elan.net wrote:
> >>
> >> Fine, lets get ARIN to listen and provide the data for all other /8
> >> blocks!
> >
> > I think that is an over statment, and certainly not something I'm asking
> > for. ARIN was clearly specifide and not the other RIR's.  For them they
> > each have their proper venue, and its not here.
> >
> >
> >>
> >> Still the question is do we need a policy for this? If we do should it
> >> actually require authentication similar to bulk whois to get the data or
> >> is current system of getting it by ftp enough?
> >
> > Based on email from ARIN staff last fall, they used to provide the data
> > upon request, but started refusing the data until there was a policy in
> > place.
> >
> > The ARIN AC (post my resignation) did not feel it was something in their
> > scope as defined by the board.  THe board has said that the AC is to
> > deal with clear and crisp IP allocation policies only.   I think even
> > the whois is not within their view based on the direction from the board.
> >
> >
> >>
> >> In my opinion adding in-addr to bulk-whois proposal is both not
> >> approriate as whois data is a lot more complex and has rather specific
> >> privacy issues, its unnecessory and it sounds bad as far as you wrote it
> >> (i.e. what you  proposed - "arin whois inaddr aup").
> >
> > I agree, WHOIS is more complex and has privacy issues.  Hence the IN-ADDR
> > should be an easy issue to deal with.
> >
> > I don't believe I used those words you are attributing to me.  Please
> > correct or quote correctly....
> >
> > What I stated is that access to the whois  OR  inaddr carried with it the
> > same level of restrictions and conditions.  This would be more protection
> > for the IN-ADDR and continue to protect the whois data.
> >
> >
> >
> >> First I think we need to ask ARIN if they are willing to get all the
> >> inaddr data out on their ftp site on their own based on current polices
> >> and procedures (they do after all provide entire ASN list including all
> >> those ASNs they inherited from Internic, so why is it so different for
> >> inaddr?). If they do not want to do it, then propose a simple policy:
> >> "ARIN will provide public access to complete INADDR data for all ip
> >> blocks in its database for public download by ftp"
> >
> > Well todate ARIN has refused to provide IN-ADDR lacking a policy.  I can
> > dig up the email from ARIN staff issued last fall, if needed.
> >
> > Agreed they have the ASN data, the IN-ADDR seems easy as well since they
> > have to gen the zone for their NS set anyway.
> >
> > Personally I believe that ARIN should have an AUP for this data.
> >
> > John Brown
> >
> >>
> >> > > -----Original Message-----
> >> > > From: owner-ppml@arin.net [mailto:owner-ppml@arin.net] On
> >> > > Behalf Of william@elan.net
> >> > > Sent: Monday, June 09, 2003 11:44 PM
> >> > > To: John M. Brown
> >> > > Cc: ppml@arin.net
> >> > > Subject: Re: [ppml] A proposal to modify proposal 2003-9
> >> > > (WHOIS and INADDR access)
> >> > >
> >> > >
> >> > > Why do you need policy for providing in-addr data as bulk? I
> >> > > think ARIN
> >> > > already provides this all publicly as it, see
> >> > > ftp://ftp.arin.net/pub/zones
> >> > >
> >> > > Do you need something more then
> >> > > that?
> >> > >
> >> > > On Mon, 9 Jun 2003, John M. Brown wrote:
> >> > >
> >> > > > 3. A policy for bulk WHOIS and or ARIN INADDR access will
> >> > > be published
> >> > > > on
> >> > > >    ARIN website as follows:
> >> > > >
> >> > > > "Access to the entire WHOIS or ARIN INADDR database or
> >> > > large portion
> >> > > > of
> >> > > > it may be obtained by any organization or individual
> >> > > provided that this
> >> > > > organization or individual agrees in writing to ARIN WHOIS/INADDR
> >> > > > Acceptable
> >> > > > Use Policy. WHOIS or ARIN INADDR data provided under bulk
> >> > > WHOIS access
> >> > > > will not include any information that is marked as private.
> >> > > >
> >> > > > Access to WHOIS/INADDR data may be by way of:
> >> > > >
> >> > > > Individual WHOIS/DNS queries
> >> > > >
> >> > > > FTP or other type of download
> >> > > >
> >> > > > Hard media distribution (such as CDROM)
> >> > > >
> >> > > >
> >> > > > -----
> >> > > >
> >> > > > Given that ARIN now has policy  2002-1 Lame In-addr,
> >> > > providing access
> >> > > > to the in-addr view that ARIN has would be useful for the internet
> >> > > > operational and research community, and help reduce lame
> >> > > issues.  This
> >> > > > access would allow service providers access to the IN-ADDR tree
> >> > > > and  allow them to self verify what deligations they are listed as
> >> > > > authoritative for.  It would allow the research community a better
> >> > > > source of data for research and other activities.
> >> > > >
> >> > > >
> >> > > > respectfully,
> >> > > >
> >> > > > john brown
> >> > >
> >>
>
>
>

--
This message was passed to you via the ga@dnso.org list.
Send mail to majordomo@dnso.org to unsubscribe
("unsubscribe ga" in the body of the message).
Archives at http://www.dnso.org/archives.html