- Test - lists.nanog.org

Re: On the control of the Internet.
by Larry Sheldon 13 Jun '10

13 Jun '10

On 6/13/2010 14:59, Joe Greco wrote: >>>> How about the case where the master zone file has be amputated and the >>>> secondaries can no longer get updates? Mea culpa. That was suppose to say "How about the case where the master zone file has beEN amputated and the secondaries can no longer get updates? My apologies. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml

3 3

Re: On the control of the Internet.
by Alexander Harrowell 13 Jun '10

13 Jun '10

I'll bet that is a political statement, against list rules. Larry is currently making up a really high percentage of list traffic and this is beginning to annoy. L "Larry Sheldon" <LarrySheldon(a)cox.net> wrote: >On 6/13/2010 15:54, Joe Greco wrote: > >> If we want to be pedantic, Sony this year announced that it is shutting >> down its production of floppy disks by next year. Of course, the choice >> of "floppy disk" is irrelevant, and I'm guessing you know it. If your >> devices are more comfortable with CD-ROM or USB MicroSD readers, then by >> all means. > >I certainly hoped that that was the case, but not very long ago I read a >current "Emergency Recovery Plan" that depended on 9-track 1600BPI round >reel tapes in a shop that had not had a drive like that for ten years. > > >> Long before NANOG, there was actually a time that some of us hauled >> around things like USENET on magnetic media, because it was simply the >> highest bandwidth yet cheapest method to haul large amounts of data >> around the city, back when a Telebit Trailblazer was still vaguely able >> to cope with a USENET feed - and for a little while thereafter. > >Wide Band Truck was a major component of plans long ago. > >And I wish I had a nickel for every round-real tape in Anvil case I >escorted through airports. > >> If your network has been so thoroughly taken over that you cannot hope >> to get a file from a computer that does have a floppy over to your DNS >> server, you have Much Bigger Problems to begin with... > >And that is the issue I was trying to raise. > >> Our monitoring systems are definitely able to detect when connectivity >> goes away. What happens if and when that happens is generally left up >> to a human to decide. The sorts of brokenness that one might potentially >> discover if the government were to corrupt connectivity is much more >> complex than simple on/off; I feel comfortable saying that the best plan >> is to have diversity of resources and some in-depth knowledge, since that >> also serves normal engineering needs well. > >I'll bet you think The Stimulus created jobs. > >-- >Somebody should have said: >A democracy is two wolves and a lamb voting on what to have for dinner. > >Freedom under a constitutional republic is a well armed lamb contesting >the vote. > >Requiescas in pace o email >Ex turpi causa non oritur actio >Eppure si rinfresca > >ICBM Targeting Information: http://tinyurl.com/4sqczs >http://tinyurl.com/7tp8ml > > > -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

1 0

Re: On the control of the Internet.
by Larry Sheldon 13 Jun '10

13 Jun '10

On 6/13/2010 14:59, Joe Greco wrote: > What happens? The master zone simply doesn't get updated until someone > FedEx's a floppy. You know, some of us made these sorts of contingency > plans long ago, back in days when the Internet actually wasn't all that > reliable, and it wasn't completely unthinkable to be off the air for at > least 24 hours. Interesting plan. I've got a Gateway computer down stairs that can write a 3.5 inch floppy and a Micron tower (running Windows 2000 the last time it was powered up) that can write 5 inch floppies. When I left active administration in 2003, out of 30 or so machines running BIND I can't recall one that has a floppy drive of any sort. > It's not that rough, these days, to install some monitoring to make sure > that your zones are up to date on the secondaries and that they resolve > names correctly; some operators used to even get really super-freakazoid > and do zone transfers back to allow verification. Here, we draw the line > at checking the SOA's for consistency and checking one other beacon record > for resolvability. That's clearly not a solution aimed at warning about > non-transferable zones; it raises some interesting questions. Think maybe > I'll go asking on dnsops what, if anything, people do to monitor. "monitor" implies connectivity. The OP was about the possibility that the government would deny you connectivity. Please try to stay n topic. -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml

2 3

Re: On the control of the Internet.
by Larry Sheldon 13 Jun '10

13 Jun '10

On 6/13/2010 14:59, Joe Greco wrote: > Yes, but unreachability is basically only a problem for those who have > failed to design and plan for it. You can engineer for unreachability. > You're a lot more screwed if we start talking about government mandates > and the contents of your zone. I meant to ask in my original posting: http://volokh.com/2010/06/13/32843/ What happens when the US shuts down part of its part? Depends on what part it shut down, of course. But what are the available boundaries for the parts in question? If we don't know what will be ordered shutdown and what the boundaries of the shutdown area will be are there engineering concerns that can not be foreseen and economically provided-for? -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml

2 1

Re: On the control of the Internet.
by Larry Sheldon 13 Jun '10

13 Jun '10

As so often happens, I forgot to note what my client picked up for a return address. This is the first of several items that I meant to send to the list. My apologies to Mr Greco. On 6/13/2010 14:17, Larry Sheldon wrote: > On 6/13/2010 14:07, Joe Greco wrote: >>> On 6/13/2010 08:47, Valdis.Kletnieks(a)vt.edu wrote: >>>> On Sun, 13 Jun 2010 00:21:49 CDT, Larry Sheldon said: >>>> >>>>> For example--what happens when name-service information for a part that >>>>> is not shutdown comes from a part that is? >>>> >>>> It's always been a BCP good idea to have your DNS have secondaries in another >>>> non-fate-sharing AS, even though everybody from Microsoft on down seems >>>> to feel the need to rediscover this. >>> >>> How about if the source database (not the relevant zone file, but the >>> collection of data on some computer from which a zone file is created. >> >> How about [...] is /what/? Unavailable? The zone files are still in >> place. Not really a problem in the overall scheme of things; I realize >> that some people have engineered things so that this will be a problem, >> but that's a choice. > > Yeah, it is a choice to keep the source data in a database (think DHCP > system or something) WHERE IT MAKES OPERATIONAL SENSE TO SO. > > What happens if that source data can no longer be transferred to the > master zone file located on the DNS server placed somewhere else WHERE > IT MAKES OPERATIONAL SENSE TO SO, and the network is severed between them? > >>> How about the case where the master zone file has be amputated and the >>> secondaries can no longer get updates? >> >> I'm not sure what "amputated" means here, but considering the case where >> the master itself is amputated, and the secondaries can no longer update, >> generally speaking, you log into the secondaries and twiddle their configs >> to make them masters. This requires some planning, preparedness, and >> procedures, but is in no way a crisis, unless you've failed to do the >> planning, have failed to prepare, and haven't followed your procedures. > > Amputated = severed = cut off = disconnected = no longer able to > communicate with not to be communicated with. > > Did not see that that was going to be so hard to understand. > > Should have known better, I guess. > >> How that works in the case where a government mandates something specific >> happens within your zone file is of course debatable, but possibly more >> back towards the original topic. > > > Uhhhhh....actually that WAS the original topic. > -- Somebody should have said: A democracy is two wolves and a lamb voting on what to have for dinner. Freedom under a constitutional republic is a well armed lamb contesting the vote. Requiescas in pace o email Ex turpi causa non oritur actio Eppure si rinfresca ICBM Targeting Information: http://tinyurl.com/4sqczs http://tinyurl.com/7tp8ml

1 0

Upcoming Improvements to ARIN's Directory Service
by Mark Kosters 12 Jun '10

12 Jun '10

Hi This was posted on arin-announce this morning as many of you may be interested: ARIN is pleased to announce that it plans to deploy an improved Whois service called Whois-RWS on 26 June 2010. Included in the deployment are the following services that provide the general public with access to ARIN's registration data. * a RESTful Web Service (RWS) * a NICNAME/WHOIS port 43 service * a user-friendly web site (http://whois.arin.net) A demo of this service has been available since October 2009. The demonstration service will be available at http://whoisrws-demo.arin.net until the production service is deployed on 26 June 2010. When using Whois-RWS you will notice some differences in behavior for certain queries and corresponding result sets on the NICNAME/WHOIS port 43 service. ARIN will make a separate announcement on 11 June when it publishes detailed documentation on these differences along with the demonstration service update. ARIN continues to welcome community participation on the Whois-RWS mailing list, and we invite you to subscribe and share your thoughts and suggestions at: http://lists.arin.net/mailman/listinfo/arin-whoisrws More detailed information on these changes and other future features that may impact the community at ARIN is available at: https://www.arin.net/features/ Regards, Mark Kosters Chief Technical Officer American Registry for Internet Numbers (ARIN)

9 13

Please report issues with i.root-servers.net
by Lindqvist Kurt Erik 12 Jun '10

12 Jun '10

All, Renesys has since a few days had a blog post at http://www.renesys.com/blog/2010/06/two-strikes-i-root.shtml. On the 9th I urged them to provide us with any data if they are seeing incorrect responses from NAY i.root-servers.net instance, and share that with noc(a)netnod.se. I have so far received a single email from Renesys on friday morning CET time. That email did not contain any data or further information. I asked to share that email with the Nanog list as Renesys will apparently share some results on studies of the i.root-servers.net in Beijing. I have no insight into what these findings, and Renesys did not respond to my request to see them before hand. As of today Renesys have updated their blog post with data that seems to indicate that they have seen incorrect responses from an i.root-servers.net instance. This is the first report of such responses since we re-activated our anycast node in Beijing, and we only saw this by monitoring the comments field to he blog post. At the time of re-activating the node we did test from all locations we could find and queried the i.root-servers.net node in Beijing, and we did not see any incorrect responses. Now, I would request that you all *please* report operational issues with i.root-servers.netm or in case you see any behavior you do not expect to noc(a)netnod.se. Unfortunately noone from us will attend the upcoming Nanog meeting, and I can't from the agenda see when the presentation is due. I am happy to answer any questions directly though, and I will try and read Renesys results as soon as they are published. In the mean time, as we are dealing what is potentially an operational problem, please report any issues to us. To provide some background, I will share some of my responses to the Renesys email on friday - although I admit they are taken out of context I think they do provide some general background information that might be worth sharing. --- As I wrote in my response to your blogpost, the node in China has ALWAYS been globally reachable (what ever that means. In our terminology it means we are not exporting the prefixes with no-export, so the prefixes propagates as far as our peers advertise them). --- As to the above, many countries tamper with DNS responses so I have no way of assuring anyone that a packet that traverses many countries, many regulations and many networks owners are ever tampered with. In the case where queries to our node in Beijing was seen to respond with incorrect responses, we have obviously been in discussions with our hosts for the node in Beijing and they have as we understand it been in discussions with many of the networks in China. What we understand from these discussions, the occurrence of these incorrect responses for queries sent to i.root-servers.net was a mistake. I have no insight into why or how the mistake happened, but we have been assured it won't be possible for it to happen again. That said - let me again stress that neither we nor anyone else, can assure that packets on the Internet does not get tampered with along the path. What we can do is to deploy mechanisms that will detect this tampering at the application layer, for example DNSSEC. --- Kurt Erik Lindqvist CEO Netnod

1 0

Large number of IPv6 bogons with spoofed ASpath
by Andree Toonk 12 Jun '10

12 Jun '10

Hi List Yesterday I noticed a large number of 'bogon' IPv6 announcement. I think it was about a 100 different (IPv6) bogon prefixes [1] [2] being announced from a what looks a variety of origin ASns. Being the administrator of one of these ASns, I'm quite confident that we were not actually announcing this prefix (f006:9000::/24). Looking more carefully at the data. it looks like the Origin AS / ASpaths are spoofed. I suspect it's just one person/organization somewhere in AS174 or AS3257 network which is announcing these bogons prepending it with different ASns. Does anyone have an idea what this could be? Someone doing some kind of an experiment? I summarized my observations here: http://bgpmon.net/blog/?p=299 If anyone has more info about this, please let me know as I am interested to learn more about this. Thanks, Andree [1] http://www.bgpmon.net/showbogons.php?inet=6 [2] http://bit.ly/cH1INE

2 1

Verizon contact
by Randy McAnally 12 Jun '10

12 Jun '10

Anyone with a Verizon network engineering contact on the list? There's a bad router/link in Reston, VA for the past 36 hours that we're having a real heck of a time trying to route around. Hoping we can get someone at Verizon to take a look at things. -- Randy

1 0

BGP Update Report
by cidr-report＠potaroo.net 11 Jun '10

11 Jun '10

BGP Update Report Interval: 03-Jun-10 -to- 10-Jun-10 (7 days) Observation Point: BGP Peering with AS131072 TOP 20 Unstable Origin AS Rank ASN Upds % Upds/Pfx AS-Name 1 - AS30890 83244 6.6% 192.2 -- EVOLVA Evolva Telecom s.r.l. 2 - AS7132 57977 4.6% 5.2 -- SBIS-AS - AT&T Internet Services 3 - AS9829 17721 1.4% 50.5 -- BSNL-NIB National Internet Backbone 4 - AS14420 13403 1.1% 28.9 -- CORPORACION NACIONAL DE TELECOMUNICACIONES CNT S.A. 5 - AS45464 12085 0.9% 318.0 -- NEXTWEB-AS-AP Room 201, TGU Bldg 6 - AS32528 11673 0.9% 2918.2 -- ABBOTT Abbot Labs 7 - AS10474 10210 0.8% 352.1 -- NETACTIVE 8 - AS44475 7925 0.6% 247.7 -- TIADOLI-AS SC Tiadoli Company SRL 9 - AS17894 6804 0.5% 324.0 -- APMI-AS-AP AyalaPort Makati, Inc. / Data Center Operator 10 - AS28477 6717 0.5% 671.7 -- Universidad Autonoma del Esstado de Morelos 11 - AS35931 6713 0.5% 2237.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 12 - AS30969 6527 0.5% 120.9 -- 13 - AS37204 6516 0.5% 651.6 -- TELONE 14 - AS25620 6393 0.5% 60.3 -- COTAS LTDA. 15 - AS41852 6242 0.5% 328.5 -- EXPERTNET-AS S.C. EXPERTNET S.R.L. 16 - AS39543 6222 0.5% 259.2 -- TENNET-AS SC TENNET TELECOM SRL 17 - AS4538 5916 0.5% 100.3 -- ERX-CERNET-BKB China Education and Research Network Center 18 - AS3816 5832 0.5% 138.9 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 19 - AS5800 5814 0.5% 28.8 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 20 - AS48838 5733 0.5% 212.3 -- EUROLAN-ASN Eurolan Solutions SRL TOP 20 Unstable Origin AS (Updates per announced prefix) Rank ASN Upds % Upds/Pfx AS-Name 1 - AS48861 4430 0.3% 4430.0 -- APAGA "Apaga Technologies" CJSC AS 2 - AS32528 11673 0.9% 2918.2 -- ABBOTT Abbot Labs 3 - AS35931 6713 0.5% 2237.7 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 4 - AS21271 1214 0.1% 1214.0 -- SOTELMABGP 5 - AS30402 2282 0.2% 1141.0 -- HARRIS - Harris Interactive Inc. 6 - AS27873 1113 0.1% 1113.0 -- Compañia Goly, S.A. 7 - AS11613 820 0.1% 820.0 -- U-SAVE - U-Save Auto Rental of America, Inc. 8 - AS19174 3511 0.3% 702.2 -- CNC-USA - China Netcom (USA) Operations Ltd. 9 - AS28477 6717 0.5% 671.7 -- Universidad Autonoma del Esstado de Morelos 10 - AS37204 6516 0.5% 651.6 -- TELONE 11 - AS12445 1233 0.1% 616.5 -- SPIDERNET-AS Selene s.p.a. 12 - AS31496 992 0.1% 496.0 -- ATNET-AS ATNET Autonomous System 13 - AS5058 493 0.0% 493.0 -- NRL-EXP - Naval Research Laboratory 14 - AS11081 3711 0.3% 463.9 -- United Telecommunication Services (UTS) 15 - AS27762 3144 0.2% 449.1 -- Conet N.V. 16 - AS28052 442 0.0% 442.0 -- Arte Radiotelevisivo Argentino 17 - AS50980 1611 0.1% 402.8 -- BITINFO BitInfo Centar, Mladenovac, Serbia 18 - AS10445 2334 0.2% 389.0 -- HTG - Huntleigh Telcom 19 - AS45865 377 0.0% 377.0 -- LAWSON-PH 9th Floor Net2 Center 28th St cor 3rd Ave 20 - AS30372 753 0.1% 376.5 -- SBS-NEWARK-CA - SIEMENS BUSINESS SERVICES TOP 20 Unstable Prefixes Rank Prefix Upds % Origin AS -- AS Name 1 - 196.2.16.0/24 10070 0.7% AS10474 -- NETACTIVE 2 - 200.13.36.0/24 6676 0.5% AS28477 -- Universidad Autonoma del Esstado de Morelos 3 - 130.36.34.0/24 5823 0.4% AS32528 -- ABBOTT Abbot Labs 4 - 130.36.35.0/24 5819 0.4% AS32528 -- ABBOTT Abbot Labs 5 - 58.207.96.0/19 5540 0.4% AS4538 -- ERX-CERNET-BKB China Education and Research Network Center 6 - 190.65.228.0/22 5361 0.4% AS3816 -- COLOMBIA TELECOMUNICACIONES S.A. ESP 7 - 195.88.66.0/23 4430 0.3% AS48861 -- APAGA "Apaga Technologies" CJSC AS 8 - 143.138.107.0/24 3945 0.3% AS747 -- TAEGU-AS - Headquarters, USAISC 9 - 198.140.43.0/24 3922 0.3% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 10 - 66.102.247.0/24 3426 0.2% AS19174 -- CNC-USA - China Netcom (USA) Operations Ltd. 11 - 206.184.16.0/24 3032 0.2% AS174 -- COGENT Cogent/PSI 12 - 63.211.68.0/22 2756 0.2% AS35931 -- ARCHIPELAGO - ARCHIPELAGO HOLDINGS INC 13 - 202.92.235.0/24 2130 0.2% AS9498 -- BBIL-AP BHARTI Airtel Ltd. 14 - 196.27.108.0/22 2101 0.2% AS30969 -- 15 - 188.187.184.0/24 2100 0.2% AS41786 -- ERTH-YOLA-AS CJSC "Company "ER-Telecom" Yoshkar-Ola 16 - 98.159.128.0/24 1735 0.1% AS18910 -- BIG-SANDY-BROADBAND-INC - Big Sandy Broadband Inc 17 - 196.29.32.0/21 1449 0.1% AS37204 -- TELONE 18 - 180.233.225.0/24 1407 0.1% AS38680 -- CMBHK-AS-KR CMB 19 - 205.91.160.0/20 1309 0.1% AS5976 -- DNIC-ASBLK-05800-06055 - DoD Network Information Center 20 - 196.4.80.0/24 1235 0.1% AS37204 -- TELONE Details at http://bgpupdates.potaroo.net ------------------------------------ Copies of this report are mailed to: nanog(a)merit.edu eof-list(a)ripe.net apops(a)apops.net routing-wg(a)ripe.net afnog(a)afnog.org

1 0