- Test - lists.nanog.org

Re: validating reachability via an ISP
by Andy Litzinger 04 Apr '18

04 Apr '18

Hi Alex, Thanks for the link to the qrator API. The get-all-paths is interesting and the output does seem to show exactly the type of data I'm looking for. Is there some place on the site that lists who Qrator peers with to get your data? I searched through the site and couldn't find it. I'm trying to get an idea of the breadth of data and whether i can comfortably rely on it giving me a global view. Also, how do I authorize programmatic requests to the API? I created a user and can use it to run the queries from the web page, but I don't see how to use it directly with the API. thanks! -andy On Thu, Mar 29, 2018 at 8:23 AM, Alexander Azimov <aa(a)qrator.net> wrote: > Hi Andy, > > You can use Qrator.Radar API: https://api.radar.qrator.net/. > The get-all-paths method will return the set of active paths for selected > prefix. > > PS: I'm sorry if you receive this message two times, something funny is > happening with my emails on NANOG mailing list. > > 2018-03-29 18:09 GMT+03:00 Alexander Azimov <aa(a)qrator.net>: > >> Hi Andy, >> >> You can use Qrator.Radar API: https://api.radar.qrator.net/. >> The get-all-paths method will return the set of active paths for selected >> prefix. >> >> >> 2018-03-29 2:22 GMT+03:00 Andy Litzinger <andy.litzinger.lists(a)gmail.com> >> : >> >>> Hi all, >>> I have an enterprise network and do not provide transit. In one of our >>> datacenters we have our own prefixes and rely on two ISPs as BGP >>> neighbors >>> to provide global reachability for our prefixes. One is a large regional >>> provider and the other is a large global provider. >>> >>> Recently we took our link to the global provider offline to perform >>> maintenance on our router. Nearly immediately we were hit with alerts >>> that >>> our prefix was unreachable and BGPMon alerted that nearly 80 AS's noted >>> our >>> route had been withdrawn. We were not unreachable from every AS, but we >>> certainly were from some of the largest. >>> >>> The root cause is that the our prefix is not being adequately >>> re-distributed globally by the regional ISP. This is unexpected and we >>> are >>> working through this with them now. >>> >>> My question is, how can I monitor global reachability for a prefix via >>> this >>> or any specific provider I use over time? Are there various >>> route-servers >>> I can programmatically query for my prefix and get results that include >>> AS >>> paths? Then I could verify that an "acceptable" number of paths exist >>> that >>> include the AS of the all the ISPs I rely upon. And what would an >>> "acceptable" number of alternate paths be? >>> >>> >>> thanks in advance, >>> -andy >>> >> >> >> >> -- >> | Alexander Azimov | HLL l QRATOR >> | tel.: +7 499 241 81 92 >> | mob.: +7 915 360 08 86 >> | skype: mitradir >> | mailto: aa(a)qrator.net >> | visit: www.qrator.net >> > > > > -- > | Alexander Azimov | HLL l QRATOR > | tel.: +7 499 241 81 92 > | mob.: +7 915 360 08 86 > | skype: mitradir > | mailto: aa(a)qrator.net > | visit: www.qrator.net >

1 0

Re: Yet another Quadruple DNS?
by Scott Weeks 03 Apr '18

03 Apr '18

--- bortzmeyer(a)nic.fr wrote: From: Stephane Bortzmeyer <bortzmeyer(a)nic.fr> Rich Kulawiec <rsk(a)gsp.org> wrote a message of 10 lines which said: > Watch what you wish for: you might get it. The number of > attack/abuse vectors (and the severity of their consequences for > security and privacy) involved in doing auto-update may rival those > involved in not doing auto-update. Also, there is the risk of getting updates that will disable some features, if there is a change in the commercial strategy of the vendor <https://boingboing.net/2016/09/19/hp-detonates-its-timebomb-pri.html>. All these risks are documented in RFC 8240, a highly recommended reading. ------------------------------------------- Regarding the HP example story, won't natural attrition fix this? My stuff has been in storage for well over a year for various reasons and if I pull out my HP printer (which has non-HP cartridges) and it does this to me, I surely won't get another one. I'm also sure I'd be the norm on this as it would anger other non-technical HP customers, as well. (I was on the fence with HP anyway as they try to take over my equipment too much) scott ps. Who knows, I don't let my printer talk outside my network anyway, so maybe I didn't get the update.

1 0

COX contact
by Dennis Burgess 03 Apr '18

03 Apr '18

Can I get a network engineer from COX to give me a call or email me please :) I have a routing issue that I need taken a look at.. Dennis Burgess, Mikrotik Certified Trainer Author of "Learn RouterOS- Second Edition" Link Technologies, Inc -- Mikrotik & WISP Support Services Office: 314-735-0270 Website: http://www.linktechs.net<http://www.linktechs.net/> Create Wireless Coverage's with www.towercoverage.com

1 0

Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE
by Jeremy L. Gaddis 03 Apr '18

03 Apr '18

Greetings, If anyone at 7018 wants to pass a message along to the correct folks, please let them know that Cloudflare's new public DNS service (1.1.1.1) is completely unusable for at least some of AT&T's customers. There is apparently a bug with some CPE (including the 5268AC). From behind such CPE, the services at 1.1.1.1 are completely unreachable, whether via (ICMP) ping, DNS, or HTTPS. Using the 5268AC's web-based diagnostic tools, pinging 1.1.1.1 returns the following results: ping successful: icmp seq:0, time=2.364 ms ping successful: icmp seq:1, time=1.085 ms ping successful: icmp seq:2, time=1.160 ms ping successful: icmp seq:3, time=1.245 ms ping successful: icmp seq:4, time=0.739 ms RTTs to the CPE's default gateway are, at minimum, ~20 ms. A traceroute (using the same web-based diagnostic tool built-in to the CPE) reports, simply: traceroute 1.1.1.1 with: 64 bytes of data 1: 1.1.1.1(1dot1dot1dot1.cloudflare-dns.com), time=0 ms I haven't bothered to report this to AT&T through the standard customer support channels (for reasons that should be obvious to anyone who has ever called AT&T's consumer/residential technical support) but if anyone at AT&T wants to pass the info along to the appropriate group, it would certainly be appreciated. Thanks, -Jeremy -- Jeremy L. Gaddis "The total budget at all receivers for solving senders' problems is $0. If you want them to accept your mail and manage it the way you want, send it the way the spec says to." --John Levine

38 52

Re: New DNS Service
by Rod Beck 03 Apr '18

03 Apr '18

And any consensus regarding the service? My layman question is how does this provide privacy? The routers still need to know the IP address of the far end point. I would assume that it would be easy to deduce the domain name from the IP address. - R. ________________________________ From: Andy Ringsmuth <andy(a)andyring.com> Sent: Tuesday, April 3, 2018 4:03 PM To: Rod Beck Cc: nanog(a)nanog.org Subject: Re: New DNS Service > On Apr 3, 2018, at 8:55 AM, Rod Beck <rod.beck(a)unitedcablecompany.com> wrote: > > https://techxplore.com/news/2018-04-dns-privacy.html [https://3c1703fe8d.site.internapcdn.net/newman/gfx/news/hires/2018/dnsservi…]<https://techxplore.com/news/2018-04-dns-privacy.html> DNS service announced, puts privacy first<https://techxplore.com/news/2018-04-dns-privacy.html> techxplore.com A new service that is offering privacy protection when you browse the web was announced Sunday. The security company Cloudflare is delivering a consumer DNS service called 1.1.1.1. > > > Not associated with Cloudflare in any way. > > > Regards, > > > Roderick. > Mildly interesting but very much old news. The new Cloudflare DNS has been discussed extensively right here on NANOG for the last few days. -Andy

4 3

Yet another Quadruple DNS?
by Payam Poursaied 03 Apr '18

03 Apr '18

dig google.com @1.1.1.1 Cloudflare? Didn't find any news around it

44 88

New DNS Service
by Rod Beck 03 Apr '18

03 Apr '18

https://techxplore.com/news/2018-04-dns-privacy.html Not associated with Cloudflare in any way. Regards, Roderick. Roderick Beck Director of Global Sales United Cable Company www.unitedcablecompany.com<http://www.unitedcablecompany.com> New York City & Budapest rod.beck(a)unitedcablecompany.com 36-30-859-5144 [1467221477350_image005.png]

2 1

From Nov 2017...
by Robert Mathews (OSIA) 03 Apr '18

03 Apr '18

To be clear..... *DNS resolver 9.9.9.9 will check requests against IBM threat database* *Group Co-founded by City of London Police promises 'no snooping on your requests'* By Richard Chirgwin 20 Nov 2017 at 06:58 The Register (UK) <https://forums.theregister.co.uk/forum/1/2017/11/20/quad9_secure_private_dn…>https://www.theregister.co.uk/2017/11/20/quad9_secure_private_dns_resolver/

5 10

whoami.akamai.net and public DNS node replies
by Anurag Bhatia 02 Apr '18

02 Apr '18

Hello everyone, Anyone using whoami.akamai.net? I have used it quite a while especially with large anycast players because they tend to have customer facing (anycast) IPs and internet facing unicast IPs to reach to outside world. Thus for say 8.8.8.8 while query may be local to my country (India), I saw that Google was using unicast IP from their Singapore location (as per IPs published here <https://developers.google.com/speed/public-dns/faq> in their FAQ). dig @8.8.8.8 whoami.akamai.net used to give that IP. >From last few weeks, I see results are pretty inconsistent and just makes no sense whatsoever. E.g 5 consecutive queries to 8.8.8.8 asking whoami.akamai.net where Akamai should return me IP of recursor from where query came: dig @8.8.8.8 whoami.akamai.net a +short 103.252.111.59 dig @8.8.8.8 whoami.akamai.net a +short 118.185.164.42 dig @8.8.8.8 whoami.akamai.net a +short 118.185.164.42 dig @8.8.8.8 whoami.akamai.net a +short 14.139.241.214 dig @8.8.8.8 whoami.akamai.net a +short 103.252.111.59 This does not make sense since none of those unicast IPs belongs to Google. I see similar result for any other open DNS service like Cisco's OpenDNS: dig @208.67.222.222 whoami.akamai.net a +short 14.139.240.146 dig @208.67.222.222 whoami.akamai.net a +short 103.252.111.156 dig @208.67.222.222 whoami.akamai.net a +short 14.139.240.157 dig @208.67.222.222 whoami.akamai.net a +short 14.139.240.157 Is anyone aware of any issues in the way whoami.akamai.net works? dig +trace whoami.akamai.net gives me back my unicast IP which is logical considering fact that +trace tends to use local DNS recursor within the machine. This gives an impression that probably TTL is too high and recursors are caching reply which they are not supposed to. But at the same time, I do not see the logic of getting non-Google IPs when querying via 8.8.8.8. ;; QUESTION SECTION: ;whoami.akamai.net. IN A ;; ANSWER SECTION: whoami.akamai.net. 180 IN A 103.252.111.173 I think in past TTL used to be very low to avoid caching for it. Anyone with ideas on what's going on? -- Anurag Bhatia anuragbhatia.com

2 1

Network Info Anonymizer
by Spencer Fraint 02 Apr '18

02 Apr '18

Sharing network configuration files (e.g. to get help debugging) can be quite tricky because they contain sensitive information. At the same time, simply removing the sensitive information (e.g. removing or changing all IP addresses) removes important structure from the files, defeating the purpose of sharing. We created Netconan to help. Netconan is an open source Python tool that anonymizes sensitive network information from text files, while preserving important structure. For example: it can take in router configuration files and remove passwords and anonymize IP addresses, while preserving IP address relationships (prefixes/subnets that matched before anonymization will still match after anonymization). Check it out on PyPI (https://pypi.python.org/pypi/netconan/) or GitHub ( https://github.com/intentionet/netconan) and let us know what you think! Thanks, Spencer

1 0