Hi: I've recently noticed some discussion here on alt.roots. A topic of some interest to me. Don Stokes wishes they would go away, however i know they are here to stay. The ALT.ROOTS started as an experiment. The question was could the root be removed from DOC USG control (Department of Commerce, United States Government) and is it possible to expend namespace - and if so - what are the technical limitations. The experiment is now over. The ALT.ROOTS or expanded namespace works very well and the technical limitations to the growth of the root file are no different then the technical limitations seen at the .com zone file level. Now the ALT.ROOTS are experiencing a social experiment which seems to be working. They are co-ordinating the allocation of namespace in a reasonably open fashion. Some commercial ventures in fact now offer expanded root services. Certainly there have been some problems - but the expanded namespace is evolving at a rapid pace and i anticipate in excess of one million top level domains by next year. Much of this is due to various european ISP's who are activily co-ordinating local government resources to establish claims to namespace for specific and general purpose top level domains. I would actively encourage any ISP in NZ to participate. However - I advise some precautions when selecting a root provider or in listing your tlds on various root services. I speak from experience. I recently took control and shutdown about 80% of all root service traffic to the Open Root Server Confederation (ORSC). This affected organizations like znet.com - a large ISP in California, various University of California computer labs and sites, including the university president's office. Other affected parties included some ISP called Grasshoppernet, most of croatia (yes - i mean the country), and the Ministry of Education for the Grand Dutchy of Luxemburge. There were many others but these were the most interesting I found in my logs. My decision to shut down the roots was due mainly to bad planning on the part of the root operator. We enterted into an agreement with a Diebold Incorporated to provide arpa (network) infrastructure. During the period that Diebold used the arpas they made arrangements with the ORSC root operator to establish two roots on our networks. When our agreement expired we relocated our networks and examined them for traffic. We found alot of dns traffic for the old ORSC roots. As some of you may know - once a root is established it becomes a permanent fixture on the internet. Roots are pointed to using their internet protocol addresses. This put us in a sticky position. We were now in control of every answer to every question by every user attached to our infrastructure. As some of you may know a root service is a trusted service and the abuse of this trust can result in violation of a networks integrity. Our immediate concern was the what if question. What if a hacker who knew our sites once carried a root server - and understood the power of root - decided to break in and take over the root. They could essentially redirect traffic while capturing user password, names, addresses, credit card information - etc. etc. etc. This is a scary position to be left in and i'm sure you can all appreciate that. So as to avoid any potential liability we collapsed the root and redirected users attempting to access port 80 on any host to one web page which provided them with assistance on reconfiguring their computers or networks. So in picking a root I think it is very important to find one in which the infrastructure is captured by the root operator. This means that the IP numbers used to identify the root are stable and under the administrative control of the root operator - or secured by legal agreement. Many ALT.ROOT lack this. The ORSC has no legal obligation in place to provide service, they are not for profit, the ALTERNIC was established by a known felon and operate some of their infrastructure on @Home IP addresses, the OPENNIC is the same with network hardware addresses being outside their immediate control. So with roots operating on @Home infrastructure the possibility that an old but still active root can fall into the wrong hands is an uncomfortable probability. There is only one commercial root service - the largest of which is pacificroot and they have captured infrastructure. CINICS in france is building infrastructure for french governments and associations at various levels. So the push is on and the momentum unleashed. The only question is who do you trust when you don't have a report card on the players. And I include the USG root system in that question of trust. They have the same power to redirect users as I had when I made the decision to close down portions of the ORSC root infrastructure. And I find that power to be scarier in the hands of one government entity then i do in the hands of a nauty hacker. Those of you who want to explore alt roots can find more data at the Independent Root Operator's Network http://root-dns.org/ regards joe baptista The dot.GOD Registry, Limited The Executive Plaza, Suite 908 150 West 51st Street Tel: 1 (208) 330-4173 Manhattan Island NYC 10019 USA Fax: 1 (208) 293-9773 --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
Would all kooks please take the time to read the charter for this list, and note that "vehicle for anti-icann or split-root rhetoric" is not on the list of appropriate content matter. Pointing no fingers, obviously, since that would be rude. obOperationalContent: 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 --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
let's try not to change the subject - we must remain topical. On Sun, 17 Jun 2001, Joe Abley wrote:
Would all kooks please take the time to read the charter for this list, and note that "vehicle for anti-icann or split-root rhetoric" is not on the list of appropriate content matter. Pointing no fingers, obviously, since that would be rude.
I think you missed the point. The question in using roots has nothing to do with icann. Roots at this time are popping up everywhere. And roots can be used to take over your network. So the question is how do we inform isp's of the inherint danger in using unstable root systems. I speak mainly here of the existing ALT.ROOT infrastructure - much of which is bad. icann is the least of our concerns. my only reference to the usg was with respect to the issue of trust. if nations today knew the power of the root to intercept traffic - alot of them would be setting up their own root infrastructures. and i speak from experience having myself intercepted the ORSC root. As I said before in my prior message we intercepted all queries to port 80 and redirected them to one host where they all got a standard message. now i don't like to make claims without providing some proof. so here are my httpd logs for the period of jun 11 - 12 when i redirected traffic. the logs show you were they were coming from and what url they were trying to reach. http://www.pccf.net/correspondence/committee/tcpdump/httpd-access.log.gz As you can see all it takes is a redirect to a proxy for a few well known locations and the world is in the palm of your hands. this sort of power concerns me being placed in the wrong hands as the roots (any root) are perfect tools to assist in surveilance. So the trust issue here is a major factor which definately affects isp's world wide. You might want to look at what's been happening in australia. the aboriginals there are setting up their own root for that very reason of trust. they first trust each other - then they move on to trusting other roots based on existing relationships. I hope i've clarified my position and the issues. regards joe baptista The dot.GOD Registry, Limited The Executive Plaza, Suite 908 150 West 51st Street Tel: 1 (208) 330-4173 Manhattan Island NYC 10019 USA Fax: 1 (208) 293-9773 --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
That's it, I'm crossposting this to rec.guns and alt.karl.maldens.nose now. -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 On Sun, 17 Jun 2001, Joe Abley wrote:
Would all kooks please take the time to read the charter for this list, and note that "vehicle for anti-icann or split-root rhetoric" is not on the list of appropriate content matter. Pointing no fingers, obviously, since that would be rude.
obOperationalContent:
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 --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
--------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
obOperationalContent:
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.
I'm not sure how contacting them will avoid breakage, as you have to first jusify to them who don't use the stuff why you should be able to continue to do zone transfers. At least one doesnt have to learn buffoonz speak to justify it now. Bob Gray can probably be persuaded with a good brand of beer. Peter Mott Chief Enthusiast 2day.com -/- --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
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
Andy Linton
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.
Um. In December 1999, after a long consultation with stakeholders, a policy was written and approved by ISOCNZ allowing for controlled access to zone downloads for non-marketing purposes. Why exactly this wasn't implemented promptly at the technical level by Domainz/ISOCNZ isn't my place to say. However, I fail to see how the intention to implement said policy (prompted by the imminent removal of the only server providing uncontrolled zone downloads) should have in turn prompted a review of the policy only 18 months later. What's worse, it would appear that this round has failed to consult anywhere near as widely as previously, especially since stakeholder comment was taken seriously last time. The phrase, "shooting from the hip," springs to mind. -- don --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
On Mon, 18 Jun 2001, Don Stokes wrote:
Andy Linton
wrote: 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.
Um. In December 1999, after a long consultation with stakeholders, a policy was written and approved by ISOCNZ allowing for controlled access to zone downloads for non-marketing purposes.
And that policy has now been changed and circulated. It can be revisited if there are operational reasons why this will break the correct operation of the DNS.
Why exactly this wasn't implemented promptly at the technical level by Domainz/ISOCNZ isn't my place to say. However, I fail to see how the
Can I ask who provides the technical know how to Domainz for this area then? I thought it was you.
intention to implement said policy (prompted by the imminent removal of the only server providing uncontrolled zone downloads) should have in turn prompted a review of the policy only 18 months later. What's worse, it would appear that this round has failed to consult anywhere near as widely as previously, especially since stakeholder comment was taken seriously last time.
The phrase, "shooting from the hip," springs to mind.
So you'd have us consult extensively with Verio, Easynet Belgium, 210-54-238-239.dialup.xtra.co.nz about their need to pull this data. We have not said that the data will not be available. We have said that it will not be available from the nz servers by AXFR. My posting said: 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. What's the problem? --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
Andy Linton
What's the problem?
The problem is that you've ruled more or less by fiat that a policy brought about by wide consultation (and that you personally were party to) is to be thrown out and replaced with a new one. I don't have a problem with the outcome. I have a big problem with the process. -- don --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
If anyone's interested to read more about !Dr Joe Baptista's views on the alternative r00ts, aim your newsreaders at alt.fan.joe-baptista ;-) -- Regards, Juha PGP fingerprint: B7E1 CC52 5FCA 9756 B502 10C8 4CD8 B066 12F3 9544 On Sun, 17 Jun 2001, !Dr. Joe Baptista wrote: --------- To unsubscribe from nznog, send email to majordomo(a)list.waikato.ac.nz where the body of your message reads: unsubscribe nznog
participants (6)
-
!Dr. Joe Baptista
-
Andy Linton
-
Don Stokes
-
Joe Abley
-
Juha Saarinen
-
Peter Mott