May 2016 - Test - lists.nanog.org

craigslist.com admin
by Dennis Burgess 03 Jun '16

03 Jun '16

Looking for a craigslist.com admin to connect with offlist about a block :) [DennisBurgessSignature] www.linktechs.net<http://www.linktechs.net/> - 314-735-0270 x103 - dmburgess(a)linktechs.net<mailto:dmburgess@linktechs.net>

8 8

Public DNS64
by Tim Durack 01 Jun '16

01 Jun '16

Anyone know of a reliable public DNS64 service? Would be cool if Google added a Public DNS64 service, then I could point the NAT64 prefix at appropriately placed boxes in my network. Why? Other people are better than me at running DNS resolvers :-) -- Tim:>

10 21

PeeringDB ?
by Marco Paesani 01 Jun '16

01 Jun '16

Whats happened totady at PeeringDB web site ? Kind regards, Marco Paesani Skype: mpaesani Mobile: +39 348 6019349 Success depends on the right choice ! Email: marco(a)paesani.it

3 5

Akamai Geolocation
by Bryn Sadler 31 May '16

31 May '16

Hi all, anyone on-list from Akamai that could help out with a Geolocation issue our customers are experiencing? We tried the support channels on the website. Many thanks, Bryn Sadler Chief Technical Officer T: +44 (0)20 3102 5254 M: +44 (0)7872 684 671 C: +1 (347) 558 2133 W: essensys.tech The content of this email is confidential. If you are not the addressee, you may not distribute, copy or disclose any part of it. If you receive this message in error, please delete this from your system and notify the sender immediately by reply. essensys Ltd | 1 Triton Square Regents Place London NW1 3DX | Registration No. 05959557 essensys Inc | 450 7th Avenue Suite 2407 New York NY 10123 Please consider the environment when reading this email and only print a copy if you think it's really necessary.

1 0

Re: CALEA
by shawn wilson 31 May '16

31 May '16

The OP is also asking someone to register a throwaway email, subscribe, and respond "yes" so that the owner can't be tracked to their employer. That's kind of a steep ask for something that's almost moot. On May 9, 2016 23:16, "Greg Sowell" <greg(a)gregsowell.com> wrote: I haven't had a request in ages...back then all of the links worked. On May 9, 2016 3:02 PM, "Jeremy Austin" <jhaustin(a)gmail.com> wrote: > On Thu, May 5, 2016 at 4:43 PM, Justin Wilson <lists(a)mtin.net> wrote: > > > What is the community hearing about CALEA? > > > > Crickets? > > > -- > Jeremy Austin > > (907) 895-2311 > (907) 803-5422 > jhaustin(a)gmail.com > > Heritage NetWorks > Whitestone Power & Communications > Vertical Broadband, LLC > > Schedule a meeting: http://doodle.com/jermudgeon >

10 14

EDNS compliance of servers for the Alexa Top 1M
by Mark Andrews 31 May '16

31 May '16

If you are a Alexa Top 1M entry or host the DNS for a Alexa Top 1M entry you should be paying attention. I'm focusing here on unknown EDNS option handling as ISC is about to release a version of named which will exercise these errors in your nameservers. BIND 9.11.0 will ship with EDNS COOKIE enabled by default (RFC 7873) which will appear to be a unknown EDNS option to servers that do not understand it. RFC 6891 states that unknown EDNS options should be ignored but that is not always the case. These answers are all for servers that nominally support EDNS. You can test your servers via https://ednscomp.isc.org Mark 232270 ednsopt=noopt Servers that only respond with a EDNS response if something else is in the EDNS query (DO=1, a known EDNS option e.g. ECS or NSID present). 220083 ednsopt=timeout The firewall is dropping queries with EDNS options present. THIS WILL CAUSE INTERMITTENT LOOKUP FAILURES. This stupidity needs to be fixed along with dropping queries due to unknown EDNS versions, unknown EDNS/DNS flags and unknown query types. 64945 ednsopt=formerr,echoed,nosoa Failed to ignore the EDNS option. This results in EDNS being disabled for the server and additional queries being made. If it is serving a signed zone this may result in PERMANENT lookup failures if all the available servers for the zone exibit this error. 30917 ednsopt=echoed This is a benign failure for DNS COOKIES but could result in errors for other options. 2142 ednsopt=noopt,nosoa This is similar to ednsopt=noopt but no SOA record was returned which may result in answers being treated as NOERROR,NODATA when they shouldn't be. 1490 ednsopt=nosoa No SOA record was returned which may result in answers being treated as NOERROR,NODATA when they shouldn't be. 774 ednsopt=badvers,nosoa BADVERS is supposed to be for EDNS version negotiation. Named will treat the server as not supporting EDNS. This results in additional queries being made. If it is serving a signed zone this may result in PERMANENT lookup failures if all the available servers for the zone exibit this error. 106 ednsopt=echoed,nosoa No SOA record was returned which may result in answers being treated as NOERROR,NODATA when they shouldn't be. The echoed EDNS option is benign for DNS COOKIES but could result in errors for other options. 93 ednsopt=servfail,noopt,nosoa Possible a false positive due to the plain DNS query timing out or the server returning SERVFAIL. If the later this is unrecoverable and will result in lookup failures. 69 ednsopt=badversion Absolutely bizarre response as the EDNS version was non 0. Probably a proxy which is not EDNS version aware. 68 ednsopt=status,nosoa Unknown RCODE returned. 54 ednsopt=badversion,echoed Absolutely bizarre response as the EDNS version was non 0. Probably a proxy which is not EDNS version aware. 20 ednsopt=refused,nosoa Possible a false positive due to the plain DNS query timing out or the server returning REFUSED. If the later this is unrecoverable and will result in lookup failures. 14 ednsopt=status,noopt,nosoa Unknown RCODE returned. 14 ednsopt=formerr,nosoa This is similar to ednsopt=formerr,echoed,nosoa above. 13 ednsopt=nxdomain Possible a false positive due to the plain DNS query timing out or the server returning NXDOMAIN. If the later this is unrecoverable and will result in lookup failures. 9 ednsopt=servfail,nosoa This is similar to ednsopt=servfail,echoed,nosoa above. 6 ednsopt=formerr,echoed This is similar to ednsopt=formerr,echoed,nosoa above. 3 ednsopt=nxdomain,echoed,nosoa 2 ednsopt=nxdomain,noopt 1 ednsopt=refused,noopt,nosoa 1 ednsopt=formerr,badversion,echoed,nosoa -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka(a)isc.org

1 0

NANOG 67 closing social
by Mike Joseph 29 May '16

29 May '16

Sending this to the list as well as Betty, in case anyone on the PC has more details: I've noticed on the NANOG 67 agenda that there's a social scheduled for Wednesday night, which I think is odd since we (almost) never have any social or other events after conference closing. In fact, I noticed something very similar on a version of the NANOG 66 agenda and then it was revised a week or two before the conference. So, the question is pose is: *Is this an error on the NANOG 67 agenda, or are we really having a social on the last night?* -MJ

2 1

VOIP Monitoring Solution
by segs 29 May '16

29 May '16

Hi All, I Am on the lookout for a solution that can monitor IP phones in use on the network. The solution should have -- a very intuitive GUI -- detailed reporting mechanism. --- send basic commands like restart to the phones ---- monitor number of active calls on the call manager ---- monitor status of trunks > --- can show visual details of two ip phones in an active call --- show details of call quality. The environment in question is using Cisco Call manager BE7k and cisco Ip phones. Thanks in advance. Segun Rufai

2 1

Global/distributed IXP operators?
by Daniel Rohan 29 May '16

29 May '16

If there are any operators working at distributed/global IXPs and wouldn't mind having their brains picked regarding design questions, would you make yourselves known to me (on or off-list is fine). Thanks, Dan

3 2

Re: NIST NTP servers
by B F 29 May '16

29 May '16

All, Thanks very much for all the replies. Extremely helpful. "...ask someone what time it is and they'll tell you how to build a watch." Luckily I got both. Ed -------- Original message -------- From: Lamar Owen <lowen(a)pari.edu> Date: 5/14/2016 10:27 AM (GMT-05:00) To: NANOG <nanog(a)nanog.org> Subject: Re: NIST NTP servers On 05/13/2016 04:38 PM, Mel Beckman wrote: > But another key consideration beyond accuracy is the reliability of a server's GPS constellation view. If you can lose GPS sync for an hour or more (not uncommon in terrain-locked locations), the NTP time will go free-running and could drift quite a bit. You need an OCXO to minimize that drift to acceptable levels. While this is drifting a bit off-topic for NANOG (and drifting into the topic range for time-nuts(a)febo.com) I'll just add one more thing to this. The Hold time (when the oscillator is free-running) is a very important consideration, especially, as you say, when terrain is an issue. For us it is even more important, as the 10MHz output from the timing rack is used as a site-wide frequency standard. Of course, you never discipline a cesium PRS, but the rubidium secondary is disciplined by circuitry in the SSU2000. Back in the days of common backbone delivery over SONET discussion of cesium standards would have been on-topic, as some SONET gear (Nortel Optera for instance) needs a master clock; especially if you were delivering channelized circuits or interfacing with customers and telcos with DS3 or even DS1 circuits or DS0 fractions within them. Ethernet is far more forgiving.

1 0