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

[John M. Brown]

AXFR is not the answer, and I wouldn't support that process.

Daily FTP access to .gz is just fine.  As long as the
data is whats being loaded towards arin's NS's

john brown


> -----Original Message-----
> From: owner-ppml at arin.net [mailto:owner-ppml at arin.net] On 
> Behalf Of Alec H. Peterson
> Sent: Tuesday, June 10, 2003 11:24 AM
> To: Joe Baptista; ARIN Public Policy List ppml
> Subject: Re: [ppml] INADDR access should be axfr off all the 
> INADDR DNS servers (WAS) A proposal to modify proposal 2003-9 
> (WHOIS and INADDR access)
> 
> 
> AXFR places far more load on a DNS server than an FTP 
> download places on an 
> FTP server.
> 
> When a DNS server serves an AXFR request, it has to build what it is 
> sending on the fly, out of the copy that it has in its 
> database (be that 
> database in-core or somwhere else).  All an FTP server needs 
> to do is read 
> the data off of disk and spew it out a TCP socket.
> 
> This is why the various large TLDs do not provide access to 
> their zones via 
> AXFR.  FTP (or HTTP or whatever) is a far more efficient 
> method to serve a 
> large chunk of data.
> 
> Alec
> 
> --On Tuesday, June 10, 2003 12:32 -0400 Joe Baptista 
> <baptista at dot-god.com> 
> wrote:
> 
> >
> > 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.
> 
> 
> 
> --
> Alec H. Peterson -- ahp at hilander.com
> Chief Technology Officer
> Catbird Networks, http://www.catbird.com
>