May 2013 - Test - lists.nanog.org

ipp.gov and Google DNS (8.8.8.8)
by Josh Galvez 31 May '13

31 May '13

Google Public DNS (8.8.8.8, 8.8.4.4) is failing to resolve ipp.gov, returning a SERVFAIL. Other DNS servers seem to resolve this just fine (ie. OpenDNS) If I use dig +trace, I get appropriate results all the way down. DNSSEC seems to be validating properly. http://dnssec-debugger.verisignlabs.com/ipp.gov http://dnsviz.net/d/ipp.gov/dnssec/ Is there any one here from Google that can help with this? See dig results and traceroutes below. -Josh $ dig @8.8.8.8 ipp.gov soa +trace ; <<>> DiG 9.8.3-P4 <<>> @8.8.8.8 ipp.gov soa +trace ; (1 server found) ;; global options: +cmd . 2209 IN NS e.root-servers.net. . 2209 IN NS h.root-servers.net. . 2209 IN NS d.root-servers.net. . 2209 IN NS i.root-servers.net. . 2209 IN NS k.root-servers.net. . 2209 IN NS j.root-servers.net. . 2209 IN NS l.root-servers.net. . 2209 IN NS a.root-servers.net. . 2209 IN NS b.root-servers.net. . 2209 IN NS c.root-servers.net. . 2209 IN NS f.root-servers.net. . 2209 IN NS g.root-servers.net. . 2209 IN NS m.root-servers.net. ;; Received 228 bytes from 8.8.8.8#53(8.8.8.8) in 1218 ms gov. 172800 IN NS a.gov-servers.net. gov. 172800 IN NS b.gov-servers.net. ;; Received 132 bytes from 128.63.2.53#53(128.63.2.53) in 113 ms ipp.gov. 86400 IN NS ns1.federalreserve.org. ipp.gov. 86400 IN NS ns2.federalreserve.org. ipp.gov. 86400 IN NS ns3.federalreserve.org. ;; Received 97 bytes from 69.36.157.30#53(69.36.157.30) in 375 ms ipp.gov. 30 IN SOA ns1.federalreserve.org. dns.ids.frb.org. 5 1200 1800 1209600 21600 ipp.gov. 30 IN NS ns1.federalreserve.org. ipp.gov. 30 IN NS ns3.federalreserve.org. ipp.gov. 30 IN NS ns2.federalreserve.org. ;; Received 193 bytes from 199.169.208.138#53(199.169.208.138) in 40 ms $ dig @8.8.8.8 ipp.gov soa ; <<>> DiG 9.8.3-P4 <<>> @8.8.8.8 ipp.gov soa ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17671 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;ipp.gov. IN SOA ;; Query time: 3353 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Thu May 30 14:55:08 2013 ;; MSG SIZE rcvd: 25 $ traceroute 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 40 byte packets 1 ve1003.mpls1.core.prco.etv.net (66.111.113.1) 5.989 ms 0.534 ms 0.222 ms 2 interface-74-214-233-10 (74.214.233.10) 5.205 ms 2.618 ms 2.615 ms 3 te-8-3.car2.SaltLakeCity1.Level3.net (4.53.42.153) 146.414 ms 178.280 ms 3.753 ms 4 ae-11-11.car1.SaltLakeCity1.Level3.net (4.69.133.121) 30.170 ms 33.988 ms 40.203 ms 5 * * * 6 ae-91-91.csw4.LosAngeles1.Level3.net (4.69.137.14) 30.178 ms 30.058 ms ae-81-81.csw3.LosAngeles1.Level3.net (4.69.137.10) 30.047 ms 7 * * * 8 GOOGLE-INC.edge1.LosAngeles9.Level3.net (4.53.228.6) 30.293 ms 29.913 ms 29.950 ms 9 216.239.46.40 (216.239.46.40) 30.129 ms 64.233.174.238 (64.233.174.238) 86.755 ms 216.239.46.40 (216.239.46.40) 30.164 ms 10 64.233.174.192 (64.233.174.192) 67.074 ms 64.233.174.188 (64.233.174.188) 30.725 ms 64.233.174.186 (64.233.174.186) 46.088 ms 11 72.14.239.153 (72.14.239.153) 42.234 ms 72.14.239.159 (72.14.239.159) 42.772 ms 72.14.239.160 (72.14.239.160) 43.318 ms 12 64.233.174.129 (64.233.174.129) 41.513 ms 41.510 ms 64.233.174.131 (64.233.174.131) 42.157 ms 13 * * * 14 google-public-dns-a.google.com (8.8.8.8) 42.258 ms 42.423 ms 42.408 ms $ traceroute 8.8.4.4 traceroute to 8.8.4.4 (8.8.4.4), 64 hops max, 40 byte packets 1 ve1003.mpls1.core.prco.etv.net (66.111.113.1) 0.287 ms 0.290 ms 0.175 ms 2 interface-74-214-233-10 (74.214.233.10) 7.919 ms 2.576 ms 2.687 ms 3 te-8-3.car2.SaltLakeCity1.Level3.net (4.53.42.153) 2.848 ms 2.767 ms 2.758 ms 4 ae-11-11.car1.SaltLakeCity1.Level3.net (4.69.133.121) 30.160 ms 30.289 ms 30.147 ms 5 * * * 6 ae-81-81.csw3.LosAngeles1.Level3.net (4.69.137.10) 30.222 ms ae-61-61.csw1.LosAngeles1.Level3.net (4.69.137.2) 30.070 ms 30.220 ms 7 * * * 8 GOOGLE-INC.edge1.LosAngeles9.Level3.net (4.53.228.6) 30.086 ms 30.301 ms 30.325 ms 9 64.233.174.238 (64.233.174.238) 30.178 ms 30.228 ms 216.239.46.40 (216.239.46.40) 30.440 ms 10 64.233.174.192 (64.233.174.192) 30.392 ms 64.233.174.190 (64.233.174.190) 30.564 ms 72.14.238.0 (72.14.238.0) 42.441 ms 11 72.14.239.155 (72.14.239.155) 41.626 ms 42.002 ms 72.14.239.157 (72.14.239.157) 42.397 ms 12 216.239.48.167 (216.239.48.167) 41.958 ms 64.233.174.131 (64.233.174.131) 42.470 ms 216.239.48.167 (216.239.48.167) 42.106 ms 13 * * * 14 google-public-dns-b.google.com (8.8.4.4) 41.619 ms 41.725 ms 41.527 ms

5 6

Verizon NY (LEC) prior notification
by Christopher J. Pilkington 31 May '13

31 May '13

Is anyone aware of a method to "mark" or "flag" certain services with Verizon NY (the LEC) as critical, such that changes aren't made to the services without prior notification? I know it's a lot to ask of Verizon. We experienced an outage on a number of PRI that were rehomed to another switch without our knowledge. The PRIs worked great outbound, but our customer noticed when all the DIDs stopped working. (They forgot to move the DIDs from old switch.) Thanks, -cjp

5 6

IANA AS Numbers registry update
by Selina Harrington 30 May '13

30 May '13

The IANA AS Numbers registry has been updated to reflect the allocation of 1 block to ARIN in 2013-05-30: 62464-63487 You can find the IANA AS Numbers registry at: http://www.iana.org/assignments/as-numbers/as-numbers.xml Regards, Selina Harrington ******************************************* Internet Assigned Numbers Authority (IANA) Internet Corporation for Assigned Names & Numbers 12025 Waterfront Drive, Suite 300 Los Angeles, CA 90094 Phone: +1 310 301 5800 Fax: +1-310-823-8649 *******************************************

1 0

Mail contact needed at CenturyLink.com
by Jay Ashworth 30 May '13

30 May '13

The Outages list is receiving hard bounces from *some* email address hosted at Qwest/Centurylink. Alas, the bounce message comes from "qwestrsp(a)centurylink.com", and neither the headers nor the message body *identifies the invalid address*. This does not seem to conform with best practices. :-) If you're in responsible charge of that mail service, could you please contact me off-list, that we might track down who it is, and maybe modify your bouncer to properly include the bounced address? (Side note: what error messages are generate by *code you've written*, folks, that don't include parameters because "they should be obvious to the sender"?) All replies off list, please, this is cross-posted[1]. Cheers, -- jra [1] Why? Because I'm not trying to fix only my own problem. -- Jay R. Ashworth Baylink jra(a)baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA #natog +1 727 647 1274

1 1

why does dail-up or pppoe access always has session-timeout ?
by Joe 30 May '13

30 May '13

hi. a question obsessed me for a long time. "why my pppoe connection to internet has a max session time, even if every thing goes ok? " In our DSL access network , max session timeout is set to 4 days, this parameter is sent to BAS by radius server after finishing authenticating procedure. As I know, beside us some other service providers also applied this parameter to pppoe session, the parameter varies from 48 hours to 96 hours. Reading documents of BAS, we found this is default value for session-time on BAS, that means even if radius server does not response BAS with session-timeout attribute BAS will cut pppoe session after sometime. so , why does those BAS designer or protocol designer set such a parameter for pppoe access ? should anyone do me a favor on explaining this ? regards Joe

6 5

Fwd: ICANN News Alert -- Security Studies on the Use of Non-Delegated TLDs, and Dotless Names
by Joly MacFie 29 May '13

29 May '13

FYI, since this has been a topic here. ---------- Forwarded message ---------- http://www.icann.org/en/news/announcements/announcement-28may13-en.htm ________________________________ Security Studies on the Use of Non-Delegated TLDs, and Dotless Names 28 May 2013 ICANN's mission and core values call to preserve and enhance the operational stability, reliability, security, and global interoperability of the Internet. In pursuing these goals and following the direction of its Board of Directors as well as the advice of the Security and Stability Advisory Committee, ICANN is announcing two studies regarding: 1) the use of non-delegated TLDs and 2) potential risks related to dotless domain names. On 31 January 2013, ICANN security team received the SAC 057: SSAC Advisory on Internal Name Certificates. On 18 May, the ICANN Board directed staff to commission a study on the use of TLDs that are not currently delegated at the root level of the public DNS in enterprises. Today, ICANN is announcing that a study has been commissioned on the potential security impacts of the applied-for new-gTLD strings in relation to namespace collisions with non-delegated TLDs that may be in use in private namespaces including their use in X.509 digital certificates. As part of this study, the expert study team will develop a framework for assessing the risk level and classify the risk level for the strings as identified in the study. The report will also provide options for ICANN as to how to mitigate the various risks and will describe the pros and cons of the options. On 23 February 2012, the SSAC published the SAC 053: SSAC Report on Dotless Domains. A domain name that consists of a single label is referred to as a "dotless domain name". Use of dotless names could provide potential innovations to the domain name industry and new gTLD applicants, but their use also raises usability, functionality, security and stability concerns as described in the SSAC report. On 23 June 2012, the ICANN Board directed staff to consult with the relevant communities regarding implementation of the recommendations in SAC 053 and to provide a briefing paper for the Board, detailing the issues and options available to mitigate such issues. During the period of August to September 2012, a public comment period was held regarding the SAC 053 report. The public comment period made clear that dotless domain names are a subject of active discussion in the ICANN community, that no clear conclusion could be drawn, and that a greater effort to identify and explore solutions to the concerns raised before implementing SAC 053 recommendations could be useful. Today, ICANN is announcing that it has commissioned a study on the potential risks related to dotless domain names based on SAC 053 report. The study report will identify and describe the potential risks that dotless names raise with particular focus on those related to security and stability. The report will also provide options for ICANN as to how to mitigate the various risks and will describe the pros and cons of the options. In both cases ICANN intends to deliver the study teams findings before the ICANN 47th meeting in Durban, South Africa. -- --------------------------------------------------------------- Joly MacFie 218 565 9365 Skype:punkcast WWWhatsup NYC - http://wwwhatsup.com http://pinstand.com - http://punkcast.com VP (Admin) - ISOC-NY - http://isoc-ny.org -------------------------------------------------------------- -

1 0

GoDaddy contact?
by Yunhong Gu 28 May '13

28 May '13

Hello, I wonder if there is anyone from GoDaddy on this list. I am trying to debug a problem between Google Public DNS and some GoDaddy name servers. Please contact me directly at guu(a)google.com. Thanks, Yunhong

2 2

Paraguay International Connectivity Questions
by Dan Carlton 28 May '13

28 May '13

Looking for some information regarding international connectivity from Paraguay. We are looking to start up a new business down there and we were told that the international connections from Paraguay are not reliable and all of the only external connections from there have go through Argentina. I would assume this would apply to Public Internet as well as private networks (MPLS, etc.). - Is this true? - Does anyone have a map of the external connections from there, similar to the submarine map <http://www.submarinecablemap.com/>? - Or other data (BGP routing tables that would show traffic transiting via Brazil or Bolivia)? - Is the international connectivity really that bad down there?

1 0

Geoip lookup
by shawn wilson 27 May '13

27 May '13

What's the best way to find the networks in a country? I was thinking of writing some perl with Net::Whois::ARIN or some such module and loop through the block. But I think I'll have to be smarter than just a simple loop not to get blocked and I figure I'm not the first to want to do this. I've noticed some paid databases out there. They don't cost much but are they even worth what they charge? Ie, countryipblocks.net doesn't list quite a few addresses from a country I've looked at blocking. Isn't this information free from the different *NICs anyway? This is probably two questions: a program that smartly looks for country's blocks in a block and are GeoIP services worth anything?

13 23

Inventory and workflow management systems
by vijay gill 26 May '13

26 May '13

What software solution do people use for inventory management for things like riser/conduit drawdown, fiber inventory, physical topology store, CLR/DLR, x-connect, contracts, port inventory, etc. Any experiences in integrating workflow into those packages for work orders, modeling, drawdown levels, etc. /vijay

10 13