From camin at ripe.net Tue Feb 7 15:16:38 2017 From: camin at ripe.net (Chris Amin) Date: Tue, 7 Feb 2017 15:16:38 +0100 Subject: [atlas] Querying popular domains with RIPE Atlas Message-ID: Dear colleagues, As you are probably aware, DNSMON* and RIPE Atlas built-in** measurements are often used when analysing outages and other issues with important DNS services, particularly the root zone servers. These measurements do not provide a direct indication of the impact on actual end-user experience because they involve directly querying authoritative name servers, thereby ignoring the effects of having multiple authoritative name servers as well as caching local recursive resolvers. To improve upon our DNS monitoring, we will initiate two built-in DNS measurements from all RIPE Atlas probes that use the probes' default resolvers instead of authoritative name servers. The first measurement will query for random top-level domains with the intention of avoiding caches and therefore hitting at least one root name server. The second measurement will query for popular domain names, with the intention of hitting caches where appropriate and getting an idea of the true impact on users. As a starting point for the second measurement, we will use a recent snapshot of the global top 50 visited sites according to the Alexa top sites list***, which combines unique visitors and individual page views in its calculations. Probes will cycle through these domains, querying for a different A record every 10 minutes. Since DNS queries containing these domains will be made from every connected RIPE Atlas probe, we would like to ask for feedback on whether querying the DNS for any of these domains could pose legal or political problems for probe hosts in certain parts of the world. I have also included the next 25 most popular domains below, which will be used to fill any gaps caused by removing items from the main list. Kind regards, Chris Amin RIPE NCC * https://atlas.ripe.net/dnsmon/ ** https://atlas.ripe.net/docs/built-in/ *** https://en.wikipedia.org/w/index.php?title=List_of_most_popular_websites&oldid=762455912 Provisional 50 domains to query =============================== google.com. youtube.com. facebook.com. baidu.com. wikipedia.org. yahoo.com. google.co.in. amazon.com. qq.com. google.co.jp. live.com. taobao.com. vk.com. twitter.com. instagram.com. hao123.com. sohu.com. sina.com.cn. reddit.com. google.de. linkedin.com. tmall.com. yahoo.co.jp. weibo.com. google.fr. 360.cn. google.co.uk. google.ru. google.com.br. yandex.ru. ebay.com. bing.com. msn.com. google.it. soso.com. t.co. wordpress.com. google.es. microsoft.com. tumblr.com. aliexpress.com. blogspot.com. netflix.com. amazon.co.jp. ok.ru. google.com.hk. stackoverflow.com. google.ca. google.com.mx. imgur.com. Next 25 most popular domains, excluding pornography =================================================== apple.com. Naver.com. mail.ru. imdb.com. popads.net. onclickads.net. office.com. google.co.kr. github.com. pinterest.com. paypal.com. tianya.cn. google.com.tw. google.com.tr. google.com.au. diply.com. amazon.de. google.co.id. microsoftonline.com. onclckds.com. twitch.tv. adobe.com. amazon.co.uk. wikia.com. cnzz.com. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From colinj at mx5.org.uk Tue Feb 7 15:52:10 2017 From: colinj at mx5.org.uk (Colin Johnston) Date: Tue, 7 Feb 2017 14:52:10 +0000 Subject: [atlas] Querying popular domains with RIPE Atlas In-Reply-To: References: Message-ID: should be fine from uk perspective, note you need to be careful about dos protection issues when probes behind provider mobile nat Colin > On 7 Feb 2017, at 14:16, Chris Amin wrote: > > Dear colleagues, > > As you are probably aware, DNSMON* and RIPE Atlas built-in** > measurements are often used when analysing outages and other issues with > important DNS services, particularly the root zone servers. These > measurements do not provide a direct indication of the impact on actual > end-user experience because they involve directly querying authoritative > name servers, thereby ignoring the effects of having multiple > authoritative name servers as well as caching local recursive resolvers. > > To improve upon our DNS monitoring, we will initiate two built-in DNS > measurements from all RIPE Atlas probes that use the probes' default > resolvers instead of authoritative name servers. The first measurement > will query for random top-level domains with the intention of avoiding > caches and therefore hitting at least one root name server. The second > measurement will query for popular domain names, with the intention of > hitting caches where appropriate and getting an idea of the true impact > on users. > > As a starting point for the second measurement, we will use a recent > snapshot of the global top 50 visited sites according to the Alexa top > sites list***, which combines unique visitors and individual page views > in its calculations. Probes will cycle through these domains, querying > for a different A record every 10 minutes. > > Since DNS queries containing these domains will be made from every > connected RIPE Atlas probe, we would like to ask for feedback on whether > querying the DNS for any of these domains could pose legal or political > problems for probe hosts in certain parts of the world. I have also > included the next 25 most popular domains below, which will be used to > fill any gaps caused by removing items from the main list. > > Kind regards, > Chris Amin > RIPE NCC > > * https://atlas.ripe.net/dnsmon/ > ** https://atlas.ripe.net/docs/built-in/ > *** > https://en.wikipedia.org/w/index.php?title=List_of_most_popular_websites&oldid=762455912 > > Provisional 50 domains to query > =============================== > google.com. > youtube.com. > facebook.com. > baidu.com. > wikipedia.org. > yahoo.com. > google.co.in. > amazon.com. > qq.com. > google.co.jp. > live.com. > taobao.com. > vk.com. > twitter.com. > instagram.com. > hao123.com. > sohu.com. > sina.com.cn. > reddit.com. > google.de. > linkedin.com. > tmall.com. > yahoo.co.jp. > weibo.com. > google.fr. > 360.cn. > google.co.uk. > google.ru. > google.com.br. > yandex.ru. > ebay.com. > bing.com. > msn.com. > google.it. > soso.com. > t.co. > wordpress.com. > google.es. > microsoft.com. > tumblr.com. > aliexpress.com. > blogspot.com. > netflix.com. > amazon.co.jp. > ok.ru. > google.com.hk. > stackoverflow.com. > google.ca. > google.com.mx. > imgur.com. > > Next 25 most popular domains, excluding pornography > =================================================== > apple.com. > Naver.com. > mail.ru. > imdb.com. > popads.net. > onclickads.net. > office.com. > google.co.kr. > github.com. > pinterest.com. > paypal.com. > tianya.cn. > google.com.tw. > google.com.tr. > google.com.au. > diply.com. > amazon.de. > google.co.id. > microsoftonline.com. > onclckds.com. > twitch.tv. > adobe.com. > amazon.co.uk. > wikia.com. > cnzz.com. > From roberto.nunziato at gmail.com Fri Feb 10 10:26:54 2017 From: roberto.nunziato at gmail.com (Roberto Nunziato) Date: Fri, 10 Feb 2017 10:26:54 +0100 Subject: [atlas] Streaming API, endTime parameter is ignored Message-ID: <3155650B-6E12-4C2E-A6D1-3C7D5CCAABCE@gmail.com> Hello everybody, I am an Italian student and I am working with the RIPE Atlas Streaming API. I am trying to replay events that have happened in the past, so I am using the optional parameter endTime in the code below. Now, the stream starts at the specified time but it never ends. Am I doing anything wrong? Is this a bug? var socket = io(?https://atlas-stream.ripe.net :443? , {path: ?/stream/socket.io ?}); startTime = 1486256400 //05-02-17 h: 01:00GMT endTime = 1486258200 //05-02-17 h: 01:30GMT socket.emit(?atlas_subscribe?, {stream_type: ?result?, startTime: startTime, endTime: endTime, msm: 1962548}); Best, Roberto Nunziato -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcandela at ripe.net Fri Feb 10 10:43:56 2017 From: mcandela at ripe.net (Massimo Candela) Date: Fri, 10 Feb 2017 10:43:56 +0100 Subject: [atlas] Streaming API, endTime parameter is ignored In-Reply-To: <3155650B-6E12-4C2E-A6D1-3C7D5CCAABCE@gmail.com> References: <3155650B-6E12-4C2E-A6D1-3C7D5CCAABCE@gmail.com> Message-ID: <1BEB4C46-D010-44E2-9CAF-B849A4AB1F93@ripe.net> Hi Roberto, We are checking your case. You will receive an answer soon. Thanks for your email. Ciao, Massimo > On 10 Feb 2017, at 10:26, Roberto Nunziato wrote: > > Hello everybody, > > I am an Italian student and I am working with the RIPE Atlas Streaming API. > I am trying to replay events that have happened in the past, so I am using > the optional parameter endTime in the code below. > > Now, the stream starts at the specified time but it never ends. > Am I doing anything wrong? Is this a bug? > > var socket = io(?https://atlas-stream.ripe.net :443? , {path: ?/stream/socket.io ?}); > startTime = 1486256400 //05-02-17 h: 01:00GMT > endTime = 1486258200 //05-02-17 h: 01:30GMT > socket.emit(?atlas_subscribe?, {stream_type: ?result?, startTime: startTime, endTime: endTime, msm: 1962548}); > > Best, > Roberto Nunziato -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcandela at ripe.net Fri Feb 10 11:55:15 2017 From: mcandela at ripe.net (Massimo Candela) Date: Fri, 10 Feb 2017 11:55:15 +0100 Subject: [atlas] Streaming API, endTime parameter is ignored In-Reply-To: <3155650B-6E12-4C2E-A6D1-3C7D5CCAABCE@gmail.com> References: <3155650B-6E12-4C2E-A6D1-3C7D5CCAABCE@gmail.com> Message-ID: <0336A356-5B4E-44DF-9522-0C271CA71E0F@ripe.net> Hi Roberto, Our fault, endTime has been deprecated in favour of stopTime** but we didn?t update the documentation correctly. It will be updated with the next deployment, shortly. If you set an endTime it will be ignored and you will keep getting measurement results. On the error subscription you should receive a warning asking you to switch to stopTime instead. Sorry for the inconvenience ** this is because stopTime and endTime were not used consistently before among our APIs/tools. Now everything should be stopTime. Ciao, Massimo > On 10 Feb 2017, at 10:26, Roberto Nunziato wrote: > > Hello everybody, > > I am an Italian student and I am working with the RIPE Atlas Streaming API. > I am trying to replay events that have happened in the past, so I am using > the optional parameter endTime in the code below. > > Now, the stream starts at the specified time but it never ends. > Am I doing anything wrong? Is this a bug? > > var socket = io(?https://atlas-stream.ripe.net :443? , {path: ?/stream/socket.io ?}); > startTime = 1486256400 //05-02-17 h: 01:00GMT > endTime = 1486258200 //05-02-17 h: 01:30GMT > socket.emit(?atlas_subscribe?, {stream_type: ?result?, startTime: startTime, endTime: endTime, msm: 1962548}); > > Best, > Roberto Nunziato -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.nunziato at gmail.com Fri Feb 10 12:12:31 2017 From: roberto.nunziato at gmail.com (Roberto Nunziato) Date: Fri, 10 Feb 2017 12:12:31 +0100 Subject: [atlas] Streaming API, endTime parameter is ignored In-Reply-To: <0336A356-5B4E-44DF-9522-0C271CA71E0F@ripe.net> References: <3155650B-6E12-4C2E-A6D1-3C7D5CCAABCE@gmail.com> <0336A356-5B4E-44DF-9522-0C271CA71E0F@ripe.net> Message-ID: Hi Massimo, now it works all properly :) Thank you very much for your help. Ciao, Roberto Nunziato > Il giorno 10 feb 2017, alle ore 11:55, Massimo Candela ha scritto: > > Hi Roberto, > > Our fault, endTime has been deprecated in favour of stopTime** but we didn?t update the documentation correctly. It will be updated with the next deployment, shortly. > > If you set an endTime it will be ignored and you will keep getting measurement results. > On the error subscription you should receive a warning asking you to switch to stopTime instead. > > Sorry for the inconvenience > > ** this is because stopTime and endTime were not used consistently before among our APIs/tools. Now everything should be stopTime. > > Ciao, > Massimo > >> On 10 Feb 2017, at 10:26, Roberto Nunziato > wrote: >> >> Hello everybody, >> >> I am an Italian student and I am working with the RIPE Atlas Streaming API. >> I am trying to replay events that have happened in the past, so I am using >> the optional parameter endTime in the code below. >> >> Now, the stream starts at the specified time but it never ends. >> Am I doing anything wrong? Is this a bug? >> >> var socket = io(?https://atlas-stream.ripe.net :443? , {path: ?/stream/socket.io ?}); >> startTime = 1486256400 //05-02-17 h: 01:00GMT >> endTime = 1486258200 //05-02-17 h: 01:30GMT >> socket.emit(?atlas_subscribe?, {stream_type: ?result?, startTime: startTime, endTime: endTime, msm: 1962548}); >> >> Best, >> Roberto Nunziato > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mir at ripe.net Wed Feb 15 11:55:17 2017 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 15 Feb 2017 11:55:17 +0100 Subject: [atlas] New on RIPE Labs: Update on RIPE Atlas Probe Lifetimes Message-ID: Dear colleagues, Please find an update on the status of RIPE Atlas probe connection times on RIPE Labs: https://labs.ripe.net/Members/wilhelm/update-on-atlas-probe-lifetimes Kind regards, Mirjam Kuhne RIPE NCC From BECHA at ripe.net Thu Feb 16 11:30:31 2017 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 16 Feb 2017 11:30:31 +0100 Subject: [atlas] Reminder: Ten Days Left to Apply for "DNS Measurements Hackathon" In-Reply-To: References: Message-ID: Dear colleagues, The fifth RIPE NCC hackathon will take place on Thursday and Friday, 20-21 April 2017, in Amsterdam. Apply online: https://atlas.ripe.net/hackathon/dns-measurements/#!application-form *The application deadline is 26 February 2017* Find out more in this RIPE Labs article: https://labs.ripe.net/Members/alun_davies/dns-measurements-hackathon-2017 Regards, Vesna Manojlovic RIPE NCC Community Builder From hsalgado at nic.cl Tue Feb 21 15:16:20 2017 From: hsalgado at nic.cl (Hugo =?iso-8859-1?Q?Salgado-Hern=E1ndez?=) Date: Tue, 21 Feb 2017 11:16:20 -0300 Subject: [atlas] Querying popular domains with RIPE Atlas In-Reply-To: References: Message-ID: <20170221141620.GE2239@vulcano.intra.nic.cl> Dear Chris. It seems fine from my perspective. The second measurement should be answered by resolver's cache, being top-resolved names. But what are you thinking on the first measurement? I'd try to reduce to a minimun sending random queries to root servers, an infrastructure frequently abused :( Also for the benefit of transparency and politeness you could prepend some string on the form "ripe-atlas-test-measurement.." Best, Hugo On 14:52 07/02, Colin Johnston wrote: > should be fine from uk perspective, note you need to be careful about dos protection issues when probes behind provider mobile nat > > Colin > > > On 7 Feb 2017, at 14:16, Chris Amin wrote: > > > > Dear colleagues, > > > > As you are probably aware, DNSMON* and RIPE Atlas built-in** > > measurements are often used when analysing outages and other issues with > > important DNS services, particularly the root zone servers. These > > measurements do not provide a direct indication of the impact on actual > > end-user experience because they involve directly querying authoritative > > name servers, thereby ignoring the effects of having multiple > > authoritative name servers as well as caching local recursive resolvers. > > > > To improve upon our DNS monitoring, we will initiate two built-in DNS > > measurements from all RIPE Atlas probes that use the probes' default > > resolvers instead of authoritative name servers. The first measurement > > will query for random top-level domains with the intention of avoiding > > caches and therefore hitting at least one root name server. The second > > measurement will query for popular domain names, with the intention of > > hitting caches where appropriate and getting an idea of the true impact > > on users. > > > > As a starting point for the second measurement, we will use a recent > > snapshot of the global top 50 visited sites according to the Alexa top > > sites list***, which combines unique visitors and individual page views > > in its calculations. Probes will cycle through these domains, querying > > for a different A record every 10 minutes. > > > > Since DNS queries containing these domains will be made from every > > connected RIPE Atlas probe, we would like to ask for feedback on whether > > querying the DNS for any of these domains could pose legal or political > > problems for probe hosts in certain parts of the world. I have also > > included the next 25 most popular domains below, which will be used to > > fill any gaps caused by removing items from the main list. > > > > Kind regards, > > Chris Amin > > RIPE NCC > > > > * https://atlas.ripe.net/dnsmon/ > > ** https://atlas.ripe.net/docs/built-in/ > > *** > > https://en.wikipedia.org/w/index.php?title=List_of_most_popular_websites&oldid=762455912 > > > > Provisional 50 domains to query > > =============================== > > google.com. > > youtube.com. > > facebook.com. > > baidu.com. > > wikipedia.org. > > yahoo.com. > > google.co.in. > > amazon.com. > > qq.com. > > google.co.jp. > > live.com. > > taobao.com. > > vk.com. > > twitter.com. > > instagram.com. > > hao123.com. > > sohu.com. > > sina.com.cn. > > reddit.com. > > google.de. > > linkedin.com. > > tmall.com. > > yahoo.co.jp. > > weibo.com. > > google.fr. > > 360.cn. > > google.co.uk. > > google.ru. > > google.com.br. > > yandex.ru. > > ebay.com. > > bing.com. > > msn.com. > > google.it. > > soso.com. > > t.co. > > wordpress.com. > > google.es. > > microsoft.com. > > tumblr.com. > > aliexpress.com. > > blogspot.com. > > netflix.com. > > amazon.co.jp. > > ok.ru. > > google.com.hk. > > stackoverflow.com. > > google.ca. > > google.com.mx. > > imgur.com. > > > > Next 25 most popular domains, excluding pornography > > =================================================== > > apple.com. > > Naver.com. > > mail.ru. > > imdb.com. > > popads.net. > > onclickads.net. > > office.com. > > google.co.kr. > > github.com. > > pinterest.com. > > paypal.com. > > tianya.cn. > > google.com.tw. > > google.com.tr. > > google.com.au. > > diply.com. > > amazon.de. > > google.co.id. > > microsoftonline.com. > > onclckds.com. > > twitch.tv. > > adobe.com. > > amazon.co.uk. > > wikia.com. > > cnzz.com. > > > > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From camin at ripe.net Tue Feb 21 15:34:05 2017 From: camin at ripe.net (Chris Amin) Date: Tue, 21 Feb 2017 15:34:05 +0100 Subject: [atlas] Querying popular domains with RIPE Atlas In-Reply-To: <20170221141620.GE2239@vulcano.intra.nic.cl> References: <20170221141620.GE2239@vulcano.intra.nic.cl> Message-ID: Hi Hugo, On 21/02/2017 15:16, Hugo Salgado-Hern?ndez wrote: > Dear Chris. > It seems fine from my perspective. The second measurement should > be answered by resolver's cache, being top-resolved names. > > But what are you thinking on the first measurement? I'd try to > reduce to a minimun sending random queries to root servers, an > infrastructure frequently abused :( Also for the benefit of > transparency and politeness you could prepend some string on > the form "ripe-atlas-test-measurement.." The intention of the first measurement is to check the actual reachability of the root zone name servers from probe resolvers. This is a measurement which was requested by the K-Root operations team within the RIPE NCC, and is intended to show the reachability of the root zone servers in general given issues with a particular root letter. These measurements will indeed be constructed in a way similar to how you suggested: .atlas.ripe.net.. Kind regards, Chris Amin RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From stanish.stanishev at vivacom.bg Wed Feb 22 13:37:51 2017 From: stanish.stanishev at vivacom.bg (Stanish Stanishev) Date: Wed, 22 Feb 2017 13:37:51 +0100 Subject: [atlas] Atlas anchor Error message in the Bootlog Message-ID: Hello, I've installed the software on our Atlas anchor, however I noticed the following error message in the Boot Log: Error adding default gateway 213.91.165.187 for eth0. (213.91.165.187 is the IP addr assigned as def GW, eth0 is connected to the router and it is Up) Has anyone faced this issue ? I've sent an email to atlas at ripe.net for troubleshooting assistance but nobody has replied so far. Thanks Stanish Sent via RIPE Forum -- https://www.ripe.net/participate/mail/forum From anandb at ripe.net Wed Feb 22 13:48:42 2017 From: anandb at ripe.net (Anand Buddhdev) Date: Wed, 22 Feb 2017 13:48:42 +0100 Subject: [atlas] Atlas anchor Error message in the Bootlog In-Reply-To: References: Message-ID: <893b03d1-d5b1-9b8a-4fa4-bedffb5b6f54@ripe.net> Hi Stanish, We have received your ticket, and one of my colleagues is looking at it. Our apologies for not letting you know that we were working on it. We will send you a response very soon. Please give us some time to examine the issue and find out what is wrong. Regards, Anand Buddhdev RIPE NCC On 22/02/2017 13:37, Stanish Stanishev wrote: > Hello, > > I've installed the software on our Atlas anchor, however I noticed the following error message in the Boot Log: > > Error adding default gateway 213.91.165.187 for eth0. > (213.91.165.187 is the IP addr assigned as def GW, eth0 is connected to the router and it is Up) > > Has anyone faced this issue ? > > I've sent an email to atlas at ripe.net for troubleshooting assistance but nobody has replied so far. > > Thanks > Stanish From Stanish.Stanishev at vivacom.bg Wed Feb 22 13:50:42 2017 From: Stanish.Stanishev at vivacom.bg (Stanish Stanishev) Date: Wed, 22 Feb 2017 12:50:42 +0000 Subject: [atlas] Atlas anchor Error message in the Bootlog In-Reply-To: <893b03d1-d5b1-9b8a-4fa4-bedffb5b6f54@ripe.net> References: <893b03d1-d5b1-9b8a-4fa4-bedffb5b6f54@ripe.net> Message-ID: Hi Anand, Thank you so much for the prompt answer. I've started to worry why nobody responds to my emails :) Kind Regards Stanish -----Original Message----- From: Anand Buddhdev [mailto:anandb at ripe.net] Sent: Wednesday, February 22, 2017 2:49 PM To: Stanish Stanishev ; ripe-atlas at ripe.net Subject: Re: [atlas] Atlas anchor Error message in the Bootlog Hi Stanish, We have received your ticket, and one of my colleagues is looking at it. Our apologies for not letting you know that we were working on it. We will send you a response very soon. Please give us some time to examine the issue and find out what is wrong. Regards, Anand Buddhdev RIPE NCC On 22/02/2017 13:37, Stanish Stanishev wrote: > Hello, > > I've installed the software on our Atlas anchor, however I noticed the following error message in the Boot Log: > > Error adding default gateway 213.91.165.187 for eth0. > (213.91.165.187 is the IP addr assigned as def GW, eth0 is connected > to the router and it is Up) > > Has anyone faced this issue ? > > I've sent an email to atlas at ripe.net for troubleshooting assistance but nobody has replied so far. > > Thanks > Stanish From mgalante at ripe.net Thu Feb 23 15:04:53 2017 From: mgalante at ripe.net (Michela Galante) Date: Thu, 23 Feb 2017 15:04:53 +0100 Subject: [atlas] 250 RIPE Atlas Anchors now online! Message-ID: Dear colleagues, Thanks to nineteen new RIPE Atlas Anchors being activated over the last three months, we have now reached an important milestone: 250 anchors online! Congratulations to anchor 250 hosted by Mogul Service and Support LLC in Ulaanbaatar, Mongolia and to APNIC for sponsoring it! These are the other anchors that have become active since our last announcement in November: - nl-ede-as12859, hosted by BIT in Ede, Netherlands - de-tua-as21413, hosted by envia TEL GmbH in Taucha, Germany - de-ham-as12731, hosted by IPHH Internet Port Hamburg GmbH in Hamburg, Germany (replaces older hardware) - py-slo-as27733, hosted by IXpy (sponsored by LACNIC) in San Lorenzo, Paraguay - uk-did-as786, hosted by Jisc in Didcot, United Kingdom - Two anchors hosted by Rabobank: nl-bst-as8211 in Best and nl-bxt-as8211 in Boxtel, Netherlands - nz-wlg-as9834, hosted by Trade Me in Wellington, New Zealand - lt-vno-as21412, hosted by CGATES in Vilnius, Lithuania - de-ber-as25291, hosted by SysEleven GmbH in Berlin, Germany (replaces older hardware) - us-bcb-as1312, hosted by Virginia Tech Transportation Institute in Blacksburg, United States - Two anchors hosted by Elisa Obj: fi-hel-as6667 in Helsinki and fi-tmp-as719 in Tampere, Finland - lu-ezt-as2602, hosted by Fondation RESTENA in Esch-sur-Alzette, Luxembourg (replaces older hardware) - de-kae-as8560, hosted by 1&1 Internet SE in Karlsruhe, Germany - fr-par-as5377, hosted by Marlink Enterprise AS in Paris, France - fr-tls-as39405, hosted by FULLSAVE in Toulouse, France - nl-ams-as286, hosted by KPN Eurorings B.V. in Amsterdam, Netherlands - mm-rgn-as132167, hosted by Ooredoo Myanmar (sponsored by APNIC) in Yangon, Myanmar (IPv4-only anchor) - fr-ilm-as57119, hosted by NAITWAYS in Issy, France - us-lxa-as8560, hosted by 1&1 Internet Inc. in Lenexa, United States You can find the full list of anchors, a map of their locations, a list of the hosting organisations and more information about RIPE Atlas Anchors online: https://atlas.ripe.net/anchors/list/ Interested in hosting a RIPE Atlas Anchor? Learn more: https://atlas.ripe.net/get-involved/become-an-anchor-host/ There are several organisations that want to host a RIPE Atlas Anchor but don?t have the necessary funding. Find out more about the RIPE NCC campaign to sponsor 15 RIPE Atlas Anchors https://labs.ripe.net/Members/alun_davies/campaign-to-sponsor-15-ripe-atlas-anchors We would also like to remind you about our ongoing cooperation with APNIC, LACNIC, AFRINIC and ISOC: thanks to their help we are getting more geographical diversity to the measurement data. If your organisation is in their region contact us at and we will get you in touch with them! And don?t forget to let us know by contacting us at if you?re doing something interesting with RIPE Atlas data - we always want to hear about your use cases, research and experiences! Regards, Michela Galante RIPE NCC -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From kyle.schomp at gmail.com Thu Feb 23 22:40:41 2017 From: kyle.schomp at gmail.com (Kyle Schomp) Date: Thu, 23 Feb 2017 16:40:41 -0500 Subject: [atlas] CHAOS DNS queries Message-ID: Hi all, For chaos txt queries, the only qnames that ripe atlas currently allows are: "hostname.bind", "id.server", "version.bind", "version.server". This seems like an unnecessary limitation to me as I've used chaos txt many times in the past for various dynamic records. I'm wondering what other peoples thoughts are on this restriction. Is this a problem for anyone else? Perhaps if there is enough community interest, the ripe atlas devs might decide to remove the restriction. Thanks! -kyle -------------- next part -------------- An HTML attachment was scrubbed... URL: From magicsata at gmail.com Mon Feb 27 14:58:55 2017 From: magicsata at gmail.com (Alistair Mackenzie) Date: Mon, 27 Feb 2017 13:58:55 +0000 Subject: [atlas] Probe lights Message-ID: Hi, I'm not sure if I'm missing something but there doesn't seem to be a guide on what the lights mean nor even how to read the SOS messages coming from the probe. I've tried resetting the USB drive and I can write to it with my laptop so I don't suspect this is the problem. Is there any information on how to diagnose this probe? Thanks, Alistair -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Mon Feb 27 15:07:40 2017 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 27 Feb 2017 15:07:40 +0100 Subject: [atlas] Probe lights In-Reply-To: References: Message-ID: On 2017-02-27 14:58, Alistair Mackenzie wrote: > Hi, > > I'm not sure if I'm missing something but there doesn't seem to be a guide > on what the lights mean nor even how to read the SOS messages coming from > the probe. > > I've tried resetting the USB drive and I can write to it with my laptop so I > don't suspect this is the problem. > > Is there any information on how to diagnose this probe? > > Thanks, > Alistair Hi, This provides info on the lights: https://atlas.ripe.net/about/faq/#what-do-the-lights-on-the-side-of-the-probe-mean For anything else: the various probe status page tabs (network, status/beta) provide more info about what may have gone wrong. Regards, Robert