From sbras at ripe.net Mon Sep 4 14:23:08 2017 From: sbras at ripe.net (Sandra Bras) Date: Mon, 4 Sep 2017 14:23:08 +0200 Subject: [atlas] [Training] Launching RIPE NCC::Educa - Online Learning Event Message-ID: <341CC4BB-531F-45F6-9FF8-79A3ED1FBBA5@ripe.net> Dear colleagues, The RIPE NCC has a new way to dive deep into a topic without having to travel or leave your desk. RIPE NCC::Educa are free, online learning events that bring industry experts together to share insight, expertise and best practice with those that want more in-depth knowledge on a particular subject. Our first event focuses on RIPE Atlas on Thursday, 5 October from 8:00 - 13:00 UTC. Reserve your place here: https://www.ripe.net/support/training/ripe-ncc-educa You can join us for one session, multiple sessions or the full programme. We?re updating the agenda constantly, so be sure to check here for the latest additions: https://www.ripe.net/support/training/ripe-ncc-educa/agenda For more information on RIPE NCC::Educa, check out our RIPE Labs article: https://labs.ripe.net/Members/sandra_bras/introducing-ripe-ncc-educa If you have any questions, please get in touch with us: > Warm regards, Sandra Br?s E-Learning Program Manager RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From ljsong at biigroup.cn Tue Sep 5 05:33:23 2017 From: ljsong at biigroup.cn (=?gb2312?B?RGF2ZXkgU29uZyjLzsHWvaEp?=) Date: Tue, 5 Sep 2017 11:33:23 +0800 Subject: [atlas] Can Atlas probe handle Truncated response ? Message-ID: <00a601d325f7$bb1bafa0$31530ee0$@cn>+AD2175B888603648 Hi folks, I once setup a measurement of DNS UDP to see if the number of timeout increase due to large response. The answer is yes. But I wonder if the timeout is no answer after three times of retries or also includes TCP fallback. Is it true that the probe in DNS UDP measurement will not use TCP to retry even after it receives a truncated response. Best regards, Davey -------------- next part -------------- An HTML attachment was scrubbed... URL: From max.muehlbronner at 42com.com Wed Sep 6 12:49:42 2017 From: max.muehlbronner at 42com.com (=?iso-8859-1?Q?Max_M=FChlbronner?=) Date: Wed, 6 Sep 2017 10:49:42 +0000 Subject: [atlas] Is there a problem with ctr-ams07 right now? Message-ID: Hi, my probe is online (ping) and it shows SOS messages (reboots - This probe probably last rebooted on 2017-07-06 12:23:08) on the probe page. Disconnected since 59 minutes. Is this a general problem, e.g. of the controller or is it just my probe? Does someone see similar problems right now? BR Max M. -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Wed Sep 6 12:52:41 2017 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 6 Sep 2017 12:52:41 +0200 Subject: [atlas] Is there a problem with ctr-ams07 right now? In-Reply-To: References: Message-ID: <28ca1fd9-3668-5a6b-1756-5d8f2ff36ba1@ripe.net> On 2017-09-06 12:49, Max M?hlbronner wrote: > Hi, > > > my probe is online (ping) and it shows SOS messages (reboots - This > probe probably last rebooted on 2017-07-06 12:23:08) on the probe page. > Disconnected since 59 minutes. > > > Is this a general problem, e.g. of the controller or is it just my > probe? Does someone see similar problems right now? > > > > BR > > > > Max M. > Hello, ams07 is being upgraded right now (so is ams09), as part of the ongoing work I announced recently. The probes should be back shortly. Regards, Robert From max.muehlbronner at 42com.com Wed Sep 6 12:56:28 2017 From: max.muehlbronner at 42com.com (=?Windows-1252?Q?Max_M=FChlbronner?=) Date: Wed, 6 Sep 2017 10:56:28 +0000 Subject: [atlas] Is there a problem with ctr-ams07 right now? In-Reply-To: <28ca1fd9-3668-5a6b-1756-5d8f2ff36ba1@ripe.net> References: , <28ca1fd9-3668-5a6b-1756-5d8f2ff36ba1@ripe.net> Message-ID: Thanks very much for the quick feedback, i guess i missed the announcement. BR Max M. ________________________________ Von: Robert Kisteleki Gesendet: Mittwoch, 6. September 2017 12:52:41 An: Max M?hlbronner; ripe-atlas at ripe.net Betreff: Re: [atlas] Is there a problem with ctr-ams07 right now? On 2017-09-06 12:49, Max M?hlbronner wrote: > Hi, > > > my probe is online (ping) and it shows SOS messages (reboots - This > probe probably last rebooted on 2017-07-06 12:23:08) on the probe page. > Disconnected since 59 minutes. > > > Is this a general problem, e.g. of the controller or is it just my > probe? Does someone see similar problems right now? > > > > BR > > > > Max M. > Hello, ams07 is being upgraded right now (so is ams09), as part of the ongoing work I announced recently. The probes should be back shortly. Regards, Robert -------------- next part -------------- An HTML attachment was scrubbed... URL: From ripe-atlas at johnbond.org Wed Sep 6 17:28:46 2017 From: ripe-atlas at johnbond.org (ripe-atlas at johnbond.org) Date: Wed, 6 Sep 2017 16:28:46 +0100 Subject: [atlas] Infrastructure upgrades In-Reply-To: <64f2ebb7-a396-1997-c9cf-a96894ec08e0@ripe.net> References: <64f2ebb7-a396-1997-c9cf-a96894ec08e0@ripe.net> Message-ID: <9F952F65-5905-4B93-BEFB-00D0867D8F08@johnbond.org> Hello Robert, I just wanted to confirm that this work is why we see missing data in DNSMON for a number of the anchors Thanks John > On Aug 24, 2017, at 3:47 PM, Robert Kisteleki wrote: > > Dear all, > > Yesterday we began infrastructure (OS) upgrades on our controllers. As a > consequence each probe will be disconnected for an hour or two. This can > trigger notifications, if you have that configured to a sensitive enough > setting. > > Regards, > Robert Kisteleki > RIPE NCC > > From camin at ripe.net Wed Sep 6 17:57:59 2017 From: camin at ripe.net (Chris Amin) Date: Wed, 6 Sep 2017 17:57:59 +0200 Subject: [atlas] Infrastructure upgrades In-Reply-To: <9F952F65-5905-4B93-BEFB-00D0867D8F08@johnbond.org> References: <64f2ebb7-a396-1997-c9cf-a96894ec08e0@ripe.net> <9F952F65-5905-4B93-BEFB-00D0867D8F08@johnbond.org> Message-ID: <1422e156-832c-9998-35cb-1e3fe937425e@ripe.net> Dear John, You are correct, we worked on one of the anchor controllers today and we have identified an issue that caused more of an impact than expected. We are in the process of fixing this: you should already see some of the broken anchors stabilizing, and you can expect to see the remaining ones fixed shortly. We'll provide an update when everything is back to normal. Regards, Chris On 06/09/2017 17:28, ripe-atlas at johnbond.org wrote: > Hello Robert, > > I just wanted to confirm that this work is why we see missing data in DNSMON for a number of the anchors > > Thanks John > >> On Aug 24, 2017, at 3:47 PM, Robert Kisteleki wrote: >> >> Dear all, >> >> Yesterday we began infrastructure (OS) upgrades on our controllers. As a >> consequence each probe will be disconnected for an hour or two. This can >> trigger notifications, if you have that configured to a sensitive enough >> setting. >> >> Regards, >> Robert Kisteleki >> RIPE NCC >> >> > > > From ripe-atlas at johnbond.org Wed Sep 6 18:00:48 2017 From: ripe-atlas at johnbond.org (ripe-atlas at johnbond.org) Date: Wed, 6 Sep 2017 17:00:48 +0100 Subject: [atlas] Infrastructure upgrades In-Reply-To: <1422e156-832c-9998-35cb-1e3fe937425e@ripe.net> References: <64f2ebb7-a396-1997-c9cf-a96894ec08e0@ripe.net> <9F952F65-5905-4B93-BEFB-00D0867D8F08@johnbond.org> <1422e156-832c-9998-35cb-1e3fe937425e@ripe.net> Message-ID: <8CE1A7BD-E561-44A8-86E2-F24B9F2E48C8@johnbond.org> Hi Chris, Thanks for the quick response and yes I have already started to see some recoveries Cheers John From colinj at mx5.org.uk Wed Sep 6 18:14:27 2017 From: colinj at mx5.org.uk (Colin Johnston) Date: Wed, 6 Sep 2017 17:14:27 +0100 Subject: [atlas] Is there a problem with ctr-ams07 right now? In-Reply-To: <28ca1fd9-3668-5a6b-1756-5d8f2ff36ba1@ripe.net> References: <28ca1fd9-3668-5a6b-1756-5d8f2ff36ba1@ripe.net> Message-ID: seems fine from uk now https://atlas.ripe.net/probes/2317/#!tab-builtins Colin > On 6 Sep 2017, at 11:52, Robert Kisteleki wrote: > > > > On 2017-09-06 12:49, Max M?hlbronner wrote: >> Hi, >> >> >> my probe is online (ping) and it shows SOS messages (reboots - This >> probe probably last rebooted on 2017-07-06 12:23:08) on the probe page. >> Disconnected since 59 minutes. >> >> >> Is this a general problem, e.g. of the controller or is it just my >> probe? Does someone see similar problems right now? >> >> >> >> BR >> >> >> >> Max M. >> > > Hello, > > ams07 is being upgraded right now (so is ams09), as part of the ongoing > work I announced recently. The probes should be back shortly. > > Regards, > Robert > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Wed Sep 6 18:40:37 2017 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 6 Sep 2017 18:40:37 +0200 Subject: [atlas] Infrastructure upgrades In-Reply-To: <64f2ebb7-a396-1997-c9cf-a96894ec08e0@ripe.net> References: <64f2ebb7-a396-1997-c9cf-a96894ec08e0@ripe.net> Message-ID: On 2017-08-24 16:47, Robert Kisteleki wrote: > Dear all, > > Yesterday we began infrastructure (OS) upgrades on our controllers. As a > consequence each probe will be disconnected for an hour or two. This can > trigger notifications, if you have that configured to a sensitive enough > setting. > > Regards, > Robert Kisteleki > RIPE NCC Hello, Short update: a few users have contacted us (some publicly, as you have seen) to note their probe is disconnected -- which is / was because of this ongoing work. As this seems to be a nuisance to some, we devised a method that will only affect (i.e. disconnect) probes for a few minutes. It's somewhat more work on our end, but the end user satisfaction justifies the extra effort :-) Regards, Robert From adavies at ripe.net Mon Sep 11 15:54:45 2017 From: adavies at ripe.net (Alun Davies) Date: Mon, 11 Sep 2017 15:54:45 +0200 Subject: [atlas] RIPE Atlas v3 Anchor Hardware Message-ID: Dear all, The RIPE NCC has chosen a new model for the RIPE Atlas v3 Anchors. The hardware we finally opted for is the PC Engines APU2. As well as being cheaper than the previous generation of anchors, this model meets the majority of requirements we laid out for the next generation of anchors. To be clear, given that there are still a couple of minor logistical details to resolve, we are still keeping applications on hold for the time being. That said, we look set to meet our September deadline to resume shipping of RIPE Atlas anchors. For more information and future updates, please read our article on RIPE Labs: https://labs.ripe.net/Members/alun_davies/the-next-generation-of-ripe-atlas-anchors Kind regards, Alun Davies Comms RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From colinj at mx5.org.uk Mon Sep 11 16:23:24 2017 From: colinj at mx5.org.uk (Colin Johnston) Date: Mon, 11 Sep 2017 15:23:24 +0100 Subject: [atlas] RIPE Atlas v3 Anchor Hardware In-Reply-To: References: Message-ID: <216B5D6B-29A1-4CE2-96B3-0FD1FA69AEFC@mx5.org.uk> I thought at first I was a lost sheep talking about vm probes and vm anchors but seems some people made comments in same vain on weblink below as well Any reason why vm images and/or docker not considered ? Colin Johnston > On 11 Sep 2017, at 14:54, Alun Davies wrote: > > Dear all, > > The RIPE NCC has chosen a new model for the RIPE Atlas v3 Anchors. The hardware we finally opted for is the PC Engines APU2. As well as being cheaper than the previous generation of anchors, this model meets the majority of requirements we laid out for the next generation of anchors. > > To be clear, given that there are still a couple of minor logistical details to resolve, we are still keeping applications on hold for the time being. That said, we look set to meet our September deadline to resume shipping of RIPE Atlas anchors. > > For more information and future updates, please read our article on RIPE Labs: > > https://labs.ripe.net/Members/alun_davies/the-next-generation-of-ripe-atlas-anchors > > Kind regards, > > Alun Davies > Comms > RIPE NCC > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From romeo.zwart at ripe.net Tue Sep 12 12:48:53 2017 From: romeo.zwart at ripe.net (Romeo Zwart) Date: Tue, 12 Sep 2017 12:48:53 +0200 Subject: [atlas] IPv6 issues with ATLAS and DNSMON Message-ID: dear all, Due to a human error on our side, there have been problems with IPv6 connectivity to/from many of our servers, including atlas anchors since approximately 9:30 UTC this morning. The problem has been corrected and systems are recovering, but you may still see some problems in RIPE Atlas and DNSMON. We're still investigating the full impact of the problem and will have more information at a later stage. We apologise for any inconvenience. Romeo Zwart From romeo.zwart at ripe.net Tue Sep 12 14:10:49 2017 From: romeo.zwart at ripe.net (Romeo Zwart) Date: Tue, 12 Sep 2017 14:10:49 +0200 Subject: [atlas] IPv6 issues with ATLAS and DNSMON In-Reply-To: References: Message-ID: <1db42dd4-5a3f-83c8-45fa-607b1dc45272@ripe.net> On 17/09/12 12:48 , Romeo Zwart wrote: > dear all, > > Due to a human error on our side, there have been problems with IPv6 > connectivity to/from many of our servers, including atlas anchors since > approximately 9:30 UTC this morning. The problem has been corrected and > systems are recovering, but you may still see some problems in RIPE > Atlas and DNSMON. FYI, atlas and DNSMON have recovered at approximately 10:30 UTC. > We're still investigating the full impact of the problem and will have > more information at a later stage. We've just published a short problem report at https://www.ripe.net/support/service-announcements/ipv6-connectivity-issues-for-multiple-services Again, apologies for the inconvenience this has caused. Romeo > We apologise for any inconvenience. > > Romeo Zwart > > From bryan at digitalocean.com Tue Sep 12 16:18:05 2017 From: bryan at digitalocean.com (Bryan Socha) Date: Tue, 12 Sep 2017 10:18:05 -0400 Subject: [atlas] RIPE Atlas v3 Anchor Hardware In-Reply-To: References: Message-ID: I'm very happy about the ability for 10G. 1G ports on our network are non-existent. Bryan Socha Network Engineer bryan at digitalocean.com ------------------------------ We're Hiring! | @digitalocean On Mon, Sep 11, 2017 at 9:54 AM, Alun Davies wrote: > Dear all, > > The RIPE NCC has chosen a new model for the RIPE Atlas v3 Anchors. The > hardware we finally opted for is the PC Engines APU2. As well as being > cheaper than the previous generation of anchors, this model meets the > majority of requirements we laid out for the next generation of anchors. > > To be clear, given that there are still a couple of minor logistical > details to resolve, we are still keeping applications on hold for the time > being. That said, we look set to meet our September deadline to resume > shipping of RIPE Atlas anchors. > For more information and future updates, please read our article on RIPE > Labs: > > https://labs.ripe.net/Members/alun_davies/the-next- > generation-of-ripe-atlas-anchors > > Kind regards, > > Alun Davies > Comms > RIPE NCC > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bortzmeyer at nic.fr Tue Sep 12 17:19:39 2017 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 12 Sep 2017 17:19:39 +0200 Subject: [atlas] Can Atlas probe handle Truncated response ? In-Reply-To: <00a601d325f7$bb1bafa0$31530ee0$@cn> References: <00a601d325f7$bb1bafa0$31530ee0$@cn> Message-ID: <20170912151939.d3m343675ots35a6@nic.fr> On Tue, Sep 05, 2017 at 11:33:23AM +0800, Davey Song wrote a message of 102 lines which said: > I once setup a measurement of DNS UDP to see if the number of > timeout increase due to large response. The answer is yes. But I > wonder if the timeout is no answer after three times of retries or > also includes TCP fallback. The Atlas DNS test apparently tries only once, and, by default, does not fallback to TCP. (Source: tcpdump.) I don't think tou can ask for several tests. (Source: ) From philip.homburg at ripe.net Tue Sep 12 17:24:39 2017 From: philip.homburg at ripe.net (Philip Homburg) Date: Tue, 12 Sep 2017 17:24:39 +0200 Subject: [atlas] Can Atlas probe handle Truncated response ? In-Reply-To: <20170912151939.d3m343675ots35a6@nic.fr> References: <00a601d325f7$bb1bafa0$31530ee0$@cn> <20170912151939.d3m343675ots35a6@nic.fr> Message-ID: <9e4ef919-38fa-50ab-95e0-031b2d39e2d8@ripe.net> On 2017/09/12 17:19 , Stephane Bortzmeyer wrote: > I don't think tou can ask for several tests. (Source: > ) There is a retry option hidden somewhere in the docs. "[dns] retry (integer): Number of times to retry," Philip From david.manouchehri at thaw.systems Tue Sep 12 18:53:52 2017 From: david.manouchehri at thaw.systems (David Manouchehri) Date: Tue, 12 Sep 2017 12:53:52 -0400 Subject: [atlas] RIPE Atlas v3 Anchor Hardware In-Reply-To: References: Message-ID: Unless I'm missing something, 10G will still require an extra mini-PCIe adapter for a 10GbE NIC. The PC Engines APU2 only has 1GbE ports and no full size PCIe slots. This is probably too late to suggest, but the new the Intel Atom C3000 (Denverton) series would have been perfect as an Atlas Anchor. Supermicro has 10GbE boards with QuickAssist for under $500 USD. The Marvell MacchiatoBIN ($300 USD) is another 10GbE option, although it does require a lot more tinkering to get DPDK running. https://github.com/MarvellEmbeddedProcessors/dpdk-marvell/issues/1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mir at ripe.net Mon Sep 18 13:47:50 2017 From: mir at ripe.net (Mirjam Kuehne) Date: Mon, 18 Sep 2017 13:47:50 +0200 Subject: [atlas] New on RIPE Labs: PoE-ing a RIPE Atlas Probe Message-ID: Dear colleagues, In this new RIPE Labs article Geert Jan de Groot explains how to "PoE" a RIPE Atlas Probe: https://labs.ripe.net/Members/geert_jan_de_groot/poe-ing-the-ripe-atlas-probe Kind regards, Mirjam Kuhne RIPE NCC From mir at ripe.net Wed Sep 27 15:24:49 2017 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 27 Sep 2017 15:24:49 +0200 Subject: [atlas] New on RIPE Labs: Measuring your Web Server Reachability with TCP Ping Message-ID: <897bee6a-a4ef-f8f4-6fca-4d46c51b8977@ripe.net> Dear colleagues, HTTP measurements from RIPE Atlas probes are only possible towards RIPE Atlas anchors. However, when it comes to measuring the connectivity and latency of web servers on the network level, an alternative exists, which we call TCP Ping: a traceroute with special options that mimic the TCP handshake that takes place when an HTTP connection is established. In this RIPE Labs article we compare the results of large scale HTTP and TCP Ping measurements: https://labs.ripe.net/Members/wilhelm/measuring-your-web-server-reachability-with-tcp-ping Kind regards, Mirjam Kuhne RIPE NCC From adavies at ripe.net Thu Sep 28 14:18:12 2017 From: adavies at ripe.net (Alun Davies) Date: Thu, 28 Sep 2017 14:18:12 +0200 Subject: [atlas] New RIPE Labs article on RIPE Atlas v3 Anchors Message-ID: <27E678F0-C9CC-4F88-B5B3-F5B02A69E9A6@ripe.net> Dear colleagues, In this RIPE Labs article the RIPE NCC looks into hardware specifications and logistics for the next generation of RIPE Atlas anchors: https://labs.ripe.net/Members/alun_davies/introducing-ripe-atlas-v3-anchors Best regards, Alun Davies RIPE NCC From gert at space.net Thu Sep 28 14:22:26 2017 From: gert at space.net (Gert Doering) Date: Thu, 28 Sep 2017 14:22:26 +0200 Subject: [atlas] New RIPE Labs article on RIPE Atlas v3 Anchors In-Reply-To: <27E678F0-C9CC-4F88-B5B3-F5B02A69E9A6@ripe.net> References: <27E678F0-C9CC-4F88-B5B3-F5B02A69E9A6@ripe.net> Message-ID: <20170928122226.GC45648@Space.Net> Hi, On Thu, Sep 28, 2017 at 02:18:12PM +0200, Alun Davies wrote: > In this RIPE Labs article the RIPE NCC looks into hardware specifications and logistics for the next generation of RIPE Atlas anchors: > > https://labs.ripe.net/Members/alun_davies/introducing-ripe-atlas-v3-anchors Cool. Do you have current plans for upgrading the v2 hardware? I seem to remember that there was an initial "maximum supported lifetime" set for these to avoid the TTM issue ("10+ year old boxes still having to be supported")... Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From romeo.zwart at ripe.net Fri Sep 29 14:15:46 2017 From: romeo.zwart at ripe.net (Romeo Zwart) Date: Fri, 29 Sep 2017 14:15:46 +0200 Subject: [atlas] New RIPE Labs article on RIPE Atlas v3 Anchors In-Reply-To: <20170928122226.GC45648@Space.Net> References: <27E678F0-C9CC-4F88-B5B3-F5B02A69E9A6@ripe.net> <20170928122226.GC45648@Space.Net> Message-ID: Hi Gert, On 17/09/28 14:22 , Gert Doering wrote: > Hi, > > On Thu, Sep 28, 2017 at 02:18:12PM +0200, Alun Davies wrote: >> In this RIPE Labs article the RIPE NCC looks into hardware specifications and logistics for the next generation of RIPE Atlas anchors: >> >> https://labs.ripe.net/Members/alun_davies/introducing-ripe-atlas-v3-anchors > > Cool. > > Do you have current plans for upgrading the v2 hardware? As was mentioned in the Labs article, we continue to fully support the v2 hardware and there are no plans currently to replace or phase out v2 anchors. In many cases these systems will continue to work fine for a longer time and there are currently no requirements on the side of the Atlas project that would lead us to phasing them out. > I seem to remember > that there was an initial "maximum supported lifetime" set for these to > avoid the TTM issue ("10+ year old boxes still having to be supported")... We may come to a point in future, when we are unable to further support the remaining v2 anchors. When that happens we will of course announce that well in advance so that hosts can plan for replacements if they would want to. Hope this clarifies things. Please let me know if you have further questions. Kind regards, Romeo > > Gert Doering > -- NetMaster > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 841 bytes Desc: OpenPGP digital signature URL: From gert at space.net Fri Sep 29 14:54:03 2017 From: gert at space.net (Gert Doering) Date: Fri, 29 Sep 2017 14:54:03 +0200 Subject: [atlas] New RIPE Labs article on RIPE Atlas v3 Anchors In-Reply-To: References: <27E678F0-C9CC-4F88-B5B3-F5B02A69E9A6@ripe.net> <20170928122226.GC45648@Space.Net> Message-ID: <20170929125403.GT45648@Space.Net> Hi, On Fri, Sep 29, 2017 at 02:15:46PM +0200, Romeo Zwart wrote: > > I seem to remember > > that there was an initial "maximum supported lifetime" set for these to > > avoid the TTM issue ("10+ year old boxes still having to be supported")... > > We may come to a point in future, when we are unable to further support > the remaining v2 anchors. When that happens we will of course announce > that well in advance so that hosts can plan for replacements if they > would want to. Works for me :-) - thanks. Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From baptiste.jonglez at imag.fr Fri Sep 29 14:56:12 2017 From: baptiste.jonglez at imag.fr (Baptiste Jonglez) Date: Fri, 29 Sep 2017 14:56:12 +0200 Subject: [atlas] List of Atlas probes subjected to DNS traffic interception (MITM) Message-ID: <20170929125612.du5dqw3ssmju7pje@imag.fr> Hi, I am looking for a list of Atlas probes that suffer from DNS traffic interception, to exclude them from my measurements. What I mean by "traffic interception" is that DNS queries from the probe to a third-party DNS server do not reach the server, but are intercepted and answered by a middle-box instead. I started building this list myself, but it's a long and potentially error-prone process. It seems that the "DNS Root Instances" map could be used for that purpose, because DNS traffic interception shows up as if the probe was contacting an "Unknown" root instance. To get the list of probes, I ended up using an URL like the following, showing probes for all possible "unknown" root instance hostnames: https://atlas.ripe.net/results/maps/root-instances/?server=1&question=10300&af=4&filter=&show_only=dns1.com2com.ru%2Cnl1.dnscrypt.eu ... However, there seems to be a limit on the size of the URL so I cannot get all probes, and they are just displayed on the map without any obvious way to get the raw list of probes instead. Is there a way to get the raw list of probes from this map? Or has anybody already done this classification work independently? I also looked for DNS-related tags on probes, but could not find anything useful. Thanks, Baptiste -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From mir at ripe.net Fri Sep 29 15:33:04 2017 From: mir at ripe.net (Mirjam Kuehne) Date: Fri, 29 Sep 2017 15:33:04 +0200 Subject: [atlas] New on RIPE Labs: Celebrating 10, 000 Active RIPE Atlas Probes Message-ID: <6276cc73-0a7c-b52e-9b19-9d5e8f81c25d@ripe.net> Dear colleagues, In August 2017, just short of seven years after RIPE Atlas was launched, the number of connected RIPE Atlas probes hit 10,000. Thank you all for making this happen! Find some more details and an overview of recent developments on RIPE Labs: https://labs.ripe.net/Members/alun_davies/celebrating-10000-active-ripe-atlas-probes Kind regards, Mirjam Kuhne RIPE NCC From bortzmeyer at nic.fr Fri Sep 29 15:45:08 2017 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 29 Sep 2017 15:45:08 +0200 Subject: [atlas] List of Atlas probes subjected to DNS traffic interception (MITM) In-Reply-To: <20170929125612.du5dqw3ssmju7pje@imag.fr> References: <20170929125612.du5dqw3ssmju7pje@imag.fr> Message-ID: <20170929134508.GA17728@laperouse.bortzmeyer.org> On Fri, Sep 29, 2017 at 02:56:12PM +0200, Baptiste Jonglez wrote a message of 56 lines which said: > What I mean by "traffic interception" is that DNS queries from the > probe to a third-party DNS server do not reach the server, but are > intercepted and answered by a middle-box instead. Many interceptors (for instance the GFC) do so only when the request matches some criteria. "Intercepting" is not all-or-nothing. > It seems that the "DNS Root Instances" map could be used for that purpose, > because DNS traffic interception shows up as if the probe was contacting > an "Unknown" root instance. There are many rogue root instances (with anycast, it can be difficult to be sure of talking to a real root) so a strange instance is not always DNS interception. > I also looked for DNS-related tags on probes, but could not find > anything useful. System tag "clean DNS" would certainly be useful but, as the two examples above show, it is difficult to define precisely. From giovane.moura at sidn.nl Fri Sep 29 15:55:21 2017 From: giovane.moura at sidn.nl (Giovane C. M. Moura) Date: Fri, 29 Sep 2017 15:55:21 +0200 Subject: [atlas] List of Atlas probes subjected to DNS traffic interception (MITM) In-Reply-To: <20170929125612.du5dqw3ssmju7pje@imag.fr> References: <20170929125612.du5dqw3ssmju7pje@imag.fr> Message-ID: Hi Baptiste > It seems that the "DNS Root Instances" map could be used for that purpose, > because DNS traffic interception shows up as if the probe was contacting > an "Unknown" root instance. To get the list of probes, I ended up using > an URL like the following, showing probes for all possible "unknown" root > instance hostnames: You're right. We've done the same in a study on the Roots[1]. On that time, we found 74 probes with this issue. > Or has > anybody already done this classification work independently? Root Servers return a standard answer for chaos queries. So you can use the Ripe measurements to the roots for that. Lemme illustrate that with B-Root. B-Root CHAOS IPv4 measurement is https://atlas.ripe.net/measurements/10310. The chaos answer should either be b*-lax or b*-mia (it has two anycast sites, Miami and LA). Here's how you can do it: 1. Download part of the dataset from the measurement on B-root (https://atlas.ripe.net/measurements/10310/#!download). Start with the last 30 min or so. 2. Parse the json and extract the answers [2], you'll need to decode the abuf field [3] 3. See which probes do not give the standard answers (b*-mia or b*-lax). Another indicator I found is that usually is that hijacked probes tend to have *very short RTTs*. Imagine a probe in Eastern Europe connecting on b-root in LA with a RTT of 3ms.... just physically impossible. So by coupling the chaos answers with rtt you'll be fine. Heads-up: be aware that the list of hijacked probes may change as probes can change their locations, or ISPs change their configurations. So make sure you use the right time frame you're interested. good luck, /giovane [1] https://www.sidnlabs.nl/downloads/papers-reports/imc2016.pdf [2] https://github.com/RIPE-NCC/ripe.atlas.sagan [3] https://atlas.ripe.net/docs/code/#decoding_dns_abuf From baptiste.jonglez at imag.fr Fri Sep 29 16:37:04 2017 From: baptiste.jonglez at imag.fr (Baptiste Jonglez) Date: Fri, 29 Sep 2017 16:37:04 +0200 Subject: [atlas] List of Atlas probes subjected to DNS traffic interception (MITM) In-Reply-To: References: <20170929125612.du5dqw3ssmju7pje@imag.fr> Message-ID: <20170929143704.iir7onpp5a56p23v@imag.fr> Hi Giovane, On Fri, Sep 29, 2017 at 03:55:21PM +0200, Giovane C. M. Moura wrote: > > It seems that the "DNS Root Instances" map could be used for that purpose, > > because DNS traffic interception shows up as if the probe was contacting > > an "Unknown" root instance. To get the list of probes, I ended up using > > an URL like the following, showing probes for all possible "unknown" root > > instance hostnames: > > You're right. We've done the same in a study on the Roots[1]. > On that time, we found 74 probes with this issue. Thanks for the pointer! Quoting the relevant part of your IMC paper: Moreover, we also discard measurements of a few VPs where traffic to a root appears to be served by third parties. We identify hijacking in 74 VPs (less than 1%) by the combination of a CHAOS reply that does not match that letter?s known patterns and unusually short RTTs (less than 7 ms), following prior work [23]. Did you discard probes that match *both* criteria, or just one of the criteria? In my preliminary experiments I did notice the very low RTT, but just filtering on unusual CHAOS replies seemed to be enough. > > Or has > > anybody already done this classification work independently? > > Root Servers return a standard answer for chaos queries. So you can use the > Ripe measurements to the roots for that. > > Lemme illustrate that with B-Root. B-Root CHAOS IPv4 measurement is > https://atlas.ripe.net/measurements/10310. > > The chaos answer should either be b*-lax or b*-mia (it has two anycast > sites, Miami and LA). I was running UDM towards a public resolver to perform CHAOS queries, but re-using the root measurements is quite clever, thanks for the idea! > Here's how you can do it: > > 1. Download part of the dataset from the measurement on B-root > (https://atlas.ripe.net/measurements/10310/#!download). Start with the last > 30 min or so. > > 2. Parse the json and extract the answers [2], you'll need to decode the > abuf field [3] > > 3. See which probes do not give the standard answers (b*-mia or b*-lax). > > Another indicator I found is that usually is that hijacked probes tend to > have *very short RTTs*. Imagine a probe in Eastern Europe connecting on > b-root in LA with a RTT of 3ms.... just physically impossible. So by > coupling the chaos answers with rtt you'll be fine. > > Heads-up: be aware that the list of hijacked probes may change as probes can > change their locations, or ISPs change their configurations. So make sure > you use the right time frame you're interested. > > good luck, > > /giovane > > [1] https://www.sidnlabs.nl/downloads/papers-reports/imc2016.pdf > [2] https://github.com/RIPE-NCC/ripe.atlas.sagan > [3] https://atlas.ripe.net/docs/code/#decoding_dns_abuf > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From insomniac at slackware.it Fri Sep 29 16:42:37 2017 From: insomniac at slackware.it (Andrea Barberio) Date: Fri, 29 Sep 2017 16:42:37 +0200 (CEST) Subject: [atlas] List of Atlas probes subjected to DNS traffic interception (MITM) In-Reply-To: <20170929125612.du5dqw3ssmju7pje@imag.fr> References: <20170929125612.du5dqw3ssmju7pje@imag.fr> Message-ID: <1318111903.259907.1506696157575.JavaMail.zimbra@slackware.it> Have you also looked at this project from the last RIPE DNS hackaton? https://recdnsfp.github.io/ Follow-up at https://www.ietf.org/proceedings/99/slides/slides-99-maprg-fingerprint-based-detection-of-dns-hijacks-using-ripe-atlas-01.pdf Cheers, Andrea ----- Original Message ----- From: "Baptiste Jonglez" To: ripe-atlas at ripe.net Sent: Friday, September 29, 2017 1:56:12 PM Subject: [atlas] List of Atlas probes subjected to DNS traffic interception (MITM) Hi, I am looking for a list of Atlas probes that suffer from DNS traffic interception, to exclude them from my measurements. What I mean by "traffic interception" is that DNS queries from the probe to a third-party DNS server do not reach the server, but are intercepted and answered by a middle-box instead. I started building this list myself, but it's a long and potentially error-prone process. It seems that the "DNS Root Instances" map could be used for that purpose, because DNS traffic interception shows up as if the probe was contacting an "Unknown" root instance. To get the list of probes, I ended up using an URL like the following, showing probes for all possible "unknown" root instance hostnames: https://atlas.ripe.net/results/maps/root-instances/?server=1&question=10300&af=4&filter=&show_only=dns1.com2com.ru%2Cnl1.dnscrypt.eu ... However, there seems to be a limit on the size of the URL so I cannot get all probes, and they are just displayed on the map without any obvious way to get the raw list of probes instead. Is there a way to get the raw list of probes from this map? Or has anybody already done this classification work independently? I also looked for DNS-related tags on probes, but could not find anything useful. Thanks, Baptiste From baptiste.jonglez at imag.fr Fri Sep 29 16:53:25 2017 From: baptiste.jonglez at imag.fr (Baptiste Jonglez) Date: Fri, 29 Sep 2017 16:53:25 +0200 Subject: [atlas] List of Atlas probes subjected to DNS traffic interception (MITM) In-Reply-To: <1318111903.259907.1506696157575.JavaMail.zimbra@slackware.it> References: <20170929125612.du5dqw3ssmju7pje@imag.fr> <1318111903.259907.1506696157575.JavaMail.zimbra@slackware.it> Message-ID: <20170929145324.ut4mx35i4twgyg3o@imag.fr> On Fri, Sep 29, 2017 at 04:42:37PM +0200, Andrea Barberio wrote: > Have you also looked at this project from the last RIPE DNS hackaton? https://recdnsfp.github.io/ > > Follow-up at https://www.ietf.org/proceedings/99/slides/slides-99-maprg-fingerprint-based-detection-of-dns-hijacks-using-ripe-atlas-01.pdf Yes, I had a look thanks to Vesna: it's interesting but too elaborate for my needs! The goal here is just to filter out "misbehaving" probes, and Giovane's method is simple and effective for this. Thanks, Baptiste > ----- Original Message ----- > From: "Baptiste Jonglez" > To: ripe-atlas at ripe.net > Sent: Friday, September 29, 2017 1:56:12 PM > Subject: [atlas] List of Atlas probes subjected to DNS traffic interception (MITM) > > Hi, > > I am looking for a list of Atlas probes that suffer from DNS traffic > interception, to exclude them from my measurements. What I mean by > "traffic interception" is that DNS queries from the probe to a third-party > DNS server do not reach the server, but are intercepted and answered by a > middle-box instead. > > I started building this list myself, but it's a long and potentially > error-prone process. > > It seems that the "DNS Root Instances" map could be used for that purpose, > because DNS traffic interception shows up as if the probe was contacting > an "Unknown" root instance. To get the list of probes, I ended up using > an URL like the following, showing probes for all possible "unknown" root > instance hostnames: > > https://atlas.ripe.net/results/maps/root-instances/?server=1&question=10300&af=4&filter=&show_only=dns1.com2com.ru%2Cnl1.dnscrypt.eu ... > > However, there seems to be a limit on the size of the URL so I cannot get > all probes, and they are just displayed on the map without any obvious way > to get the raw list of probes instead. > > Is there a way to get the raw list of probes from this map? Or has > anybody already done this classification work independently? I also > looked for DNS-related tags on probes, but could not find anything useful. > > Thanks, > Baptiste -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From giovane.moura at sidn.nl Fri Sep 29 17:00:01 2017 From: giovane.moura at sidn.nl (Giovane C. M. Moura) Date: Fri, 29 Sep 2017 17:00:01 +0200 Subject: [atlas] List of Atlas probes subjected to DNS traffic interception (MITM) In-Reply-To: <20170929143704.iir7onpp5a56p23v@imag.fr> References: <20170929125612.du5dqw3ssmju7pje@imag.fr> <20170929143704.iir7onpp5a56p23v@imag.fr> Message-ID: <542a628a-7d7c-a58f-05e5-faaf6fd05340@sidn.nl> > Did you discard probes that match *both* criteria, or just one of the > criteria? In my preliminary experiments I did notice the very low RTT, > but just filtering on unusual CHAOS replies seemed to be enough. We only used chaos queries, since RTT suggests it but does not confirm it The thing is that the most roots are configured with IP anycast, so the same IP is shared among machines across the globe, meaning that the RTT varies depend on the relationship between the networks of the probe and the roots. What we did is not to run only for B-root, but for all letters (13 in total). That's what did, to double check.Reference 46 in the paper gives you measurement IDs for the other root letters. > I was running UDM towards a public resolver to perform CHAOS queries, but > re-using the root measurements is quite clever, thanks for the idea! Sure thing. The cool thing about these chaos measurements to the Roots is that they are "built-in" measurement. That means it uses *all* atlas probes, so you're covered. /giovane