On Sun, 17 Jun 2001, Joe Abley wrote:
I hear that Domainz are planning to make some changes to the implemented zone transfer policy for (some) of the nameservers which report authoritative for nz and her immediate children. If you make use of zone transfers for these zones, it might be worthwhile contacting them so you can plan to avoid breakage.
Joe is correct that some changes are in the offing for the NZ nameservers. ns99.waikato.ac.nz is due to be phased out of service and the ISOCNZ Technical Committee (1) have taken the opportunity to examine the policy on zone transfers of the .nz domains. We have considered a number of things in reaching our decision to discontinue the transfer of the zones by AXFR from the NZ nameservers. We have looked at the recommendations of RFC 2870 - Root Name Server Operational Requirements (ftp://ftp.isi.edu/in-notes/rfc2870.txt). It seems to us that as this RFC lays down a number of principles for the stable operation of the root nameservers then we could do a lot worse that use these principles for the .nz servers. In our reading of RFC 2870 we have piped it through sed -e '/s/[Rr]oot/.nz/g': The relevant section of the RFC seems to be: 2.7 Root servers SHOULD NOT answer AXFR, or other zone transfer, queries from clients other than other root servers. This restriction is intended to, among other things, prevent unnecessary load on the root servers as advice has been heard such as "To avoid having a corruptible cache, make your server a stealth secondary for the root zone." The root servers MAY put the root zone up for ftp or other access on one or more less critical servers. We have chosen to go with this advice. There is provision to make the zone information available via other means if there is a need for it. We would be happy to hear from those who feel they need to do this. You can be reasonably confident that requests which revolve around constructing lists for spammers will get a less than favourable hearing. These recommendations in RFC 2870 are not new. This RFC obsoletes RFC 2010 (October 1996) which also strongly recommended against permitting these zone transfers. Note the use of the words "no operational reason" below: 2.10. Zone transfer access control. The name server shall be configured so that outbound zone transfers are permitted only to destinations on the server's local networks, and to whichever networks the zone master designates for remote debugging purposes. Rationale: Zone transfers can present a significant load on a name server, especially if several transfers are started simultaneously against the same server. There is no operational reason to allow anyone outside the name server's and zone's administrators to transfer the entire zone. So who does this high handed draconian decision affect? Over the last couple of weeks here's the list of those who pulled the zones and how often. (Some of these people weren't able to configure their nameservers with a reverse which should probably exclude them automatically anyway). You can draw your own conclusions as to why many of these people want a copy. 15 216.167.107.187: Verio, Inc. (NET-VRIO-216-167-000) 8005 South Chester Street Englewood, CO 80112 US 15 212.53.64.232 (netbackup.netnames.com): 15 203.97.78.44 (ns2.acld.clix.net.nz): 15 203.97.78.43 (ns1.acld.clix.net.nz): 15 194.88.77.159 (office-gw.fulham.vi.net): 15 130.216.191.1 (net.auckland.ac.nz): 15 130.216.1.1 (net.auckland.ac.nz): 14 62.22.70.6 (gs01.inetbc.net): 8 216.122.167.112 (cumom.lightrealm.com): 6 206.229.36.51: THOMSON & THOMSON (NETBLK-SPRINT-CEE520-1) 500 VICTORY ROAD NORTH QUINCY, MA 02171 US 2 210.55.214.252 (ip210-55-214-252.maxnet.co.nz): 2 210.55.12.134 (fe0-1-akcr2.strongnet.co.nz): 2 210.48.127.49 (kupe.searchnz.co.nz): 2 203.79.66.69 (203-79-66-69.adsl-wns.paradise.net.nz): 2 202.146.247.78: inetnum: 202.146.224.0 - 202.146.247.255 netname: CENTRIN country: ID descr: Centrin Internet Service Provider descr: Indonesia country: ID 2 200.27.164.196: AT&T Chile Internet S.A (NETBLK-CUSTOMERATT-NET164) Avenida Vitacura 2939,Piso 8 Santiago, CL 1 24.22.135.74 (cj503300-b.indpdnce1.mo.home.com): 1 24.160.154.125 (cs160154-125.satx.rr.com): 1 216.72.55.5: TVCable LTDA (NETBLK-TVCABLE2) Carrera 11#94-76 Bogata, CO 1 216.15.197.2 (ghostweb.net): 1 213.193.174.44: netname: EASYNET-BE-ADSL descr: Easynet Belgium descr: ADSL Pools country: BE 1 211.75.58.234: netname: HINET-TW country: TW descr: CHTD, Chunghwa Telecom Co.,Ltd. descr: Data-Bldg.6F, No.21, Sec.21, Hsin-Yi Rd. descr: Taipei Taiwan 100 country: TW 1 210.9.182.34 (cartman.sinewave.com.au): 1 210.54.238.239 (210-54-238-239.dialup.xtra.co.nz): 1 210.14.222.2: netname: JITONG-GZ-CN country: CN descr: JI Tong Communications Co., Ltd. descr: 28th Floor, Electronic Tower descr: 27 Wanshou Road descr: Haidian District descr: Beijing 100846 country: CN 1 203.97.8.4 (zion.iserve.net.nz): 1 195.92.95.61 (ariston.netcraft.com): 1 195.6.9.28 (xlp2.ort.fr): 1 195.102.46.82: netname: STFNET36-47 descr: Staffordshire University descr: Halls access country: GB 1 194.192.186.150 (ns2.dk-hostmaster.dk): 1 194.153.227.49: netname: CRISTALSOFT descr: Alba Iulia,Eroilor descr: street, no.11 descr: Romania country: RO 1 161.184.138.133 (edtn006737.hs.telusplanet.net): 1 160.124.112.114: Olivetti Systems & Networks Africa (Pty) Ltd. (NET-OLIVE-SA) PO Box 4158 Johannesburg 2001 ZA 1 137.189.20.201 (ccpca4.cclab.cuhk.edu.hk): ------------------ 1) ISOCNZ Technical Committee Simon Blake Mark Davies Mark Harris John Hine Andy Linton John Vorstermans David Zanetti --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog