From bortzmeyer at nic.fr Sat Aug 1 17:35:55 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sat, 1 Aug 2015 17:35:55 +0200 Subject: [atlas] Strange certificates at probe 17009 Message-ID: <20150801153555.GA14530@sources.org> Probe #17009, located in Bangkok, when asked to perform a "sslcert" measurement, always retrieve a certificate whose expiration date is 2024-10-31, whatever the target is. There is probably a man-in-the-middle before the probe... -------------- next part -------------- Certificate: Data: Version: 3 (0x2) Serial Number: 16:6f:aa:9a:16:a8:d6:52 Signature Algorithm: sha1WithRSAEncryption Issuer: CN=FG100D3G14809409, O=Fortinet Ltd. Validity Not Before: Oct 31 06:52:35 2014 GMT Not After : Oct 31 06:52:35 2024 GMT Subject: CN=FG100D3G14809409, O=Fortinet Ltd. Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:a1:12:0d:5f:82:81:8d:96:b6:62:d6:69:fb:2b: 42:a4:b6:59:24:dc:f2:67:7d:ff:50:ac:14:85:a6: 1d:bf:c8:ba:38:49:40:26:ef:24:77:85:20:59:c3: 29:34:95:f2:f8:f7:d9:89:ff:dc:05:0d:71:8c:60: c6:f3:a6:9b:13:21:8e:46:f3:bc:5e:5f:04:32:a4: 71:10:0a:6b:ae:d9:02:9d:f5:ad:3b:0a:f5:01:b3: 17:33:05:4b:86:a1:fb:72:6b:cb:81:32:4f:dd:d7: af:86:d0:a6:8a:b5:47:d6:e8:ee:1b:2f:a4:a1:ba: 67:c3:f3:0d:23:f6:86:10:72:56:36:0d:73:4b:98: 45:5c:0d:46:2a:6a:61:b1:c3:77:6a:6c:ac:1b:ab: 2a:ab:80:cc:3e:dd:f9:26:60:22:f5:8f:e8:ac:91: b3:8e:0e:79:a5:7d:f2:d0:f1:5b:85:f4:5c:65:8c: 42:b5:5a:28:5f:18:39:12:2c:28:90:42:a3:dc:23: a9:05:61:96:8d:88:74:82:2e:00:81:f2:2c:1c:e8: d6:6d:51:be:86:44:9b:c7:1f:09:c5:86:84:36:ec: 04:c7:a8:6d:a2:4d:e1:01:cc:b3:b1:a3:70:b4:37: b1:30:7f:37:78:5b:fd:83:de:97:de:78:8a:1c:08: e4:35 Exponent: 65537 (0x10001) Signature Algorithm: sha1WithRSAEncryption 6a:02:14:83:7e:53:ba:11:33:99:73:c0:9b:4a:30:aa:f9:d3: 6f:8d:35:66:ee:ef:26:39:f8:3b:a6:31:1e:1b:33:1f:99:0d: fa:54:f3:d4:a1:77:8c:e6:ff:c7:96:e7:3b:0a:d5:ef:95:8d: c4:f3:aa:63:e8:1e:8a:c6:4c:06:58:27:d8:c3:bd:e2:e1:6e: a7:64:48:f6:aa:4a:55:07:48:c4:8f:ea:79:b9:f6:e0:f5:f6: bb:14:2e:7e:07:49:f5:57:5f:a2:40:38:32:51:ef:40:5c:a5: dd:d8:e6:f3:f9:3f:30:fc:7f:47:5a:95:da:bd:2d:db:63:ab: d5:9e:33:12:18:9e:db:4f:b1:97:da:9f:30:11:f2:f8:97:89: de:cc:ee:aa:90:44:4b:da:e1:56:fb:e5:37:31:03:99:67:78: c6:26:03:bd:4c:e6:c9:19:89:6b:7f:e7:6f:f0:34:d5:e5:50: cb:16:46:8e:0e:c4:48:1a:02:28:f8:f7:60:7f:23:24:f4:08: d2:e5:ad:07:d5:9c:70:8f:ac:a6:6b:8d:33:fa:e5:6c:5b:b0: 7d:34:fe:c5:2b:45:b2:ca:69:bb:59:cd:70:78:b5:f4:66:dc: 16:bc:48:9a:ee:07:c4:2a:de:90:21:5c:09:63:f5:ad:84:ca: 90:ee:6d:2b -----BEGIN CERTIFICATE----- MIIC5jCCAc6gAwIBAgIIFm+qmhao1lIwDQYJKoZIhvcNAQEFBQAwMzEZMBcGA1UE AxMQRkcxMDBEM0cxNDgwOTQwOTEWMBQGA1UEChMNRm9ydGluZXQgTHRkLjAeFw0x NDEwMzEwNjUyMzVaFw0yNDEwMzEwNjUyMzVaMDMxGTAXBgNVBAMTEEZHMTAwRDNH MTQ4MDk0MDkxFjAUBgNVBAoTDUZvcnRpbmV0IEx0ZC4wggEiMA0GCSqGSIb3DQEB AQUAA4IBDwAwggEKAoIBAQChEg1fgoGNlrZi1mn7K0Kktlkk3PJnff9QrBSFph2/ yLo4SUAm7yR3hSBZwyk0lfL499mJ/9wFDXGMYMbzppsTIY5G87xeXwQypHEQCmuu 2QKd9a07CvUBsxczBUuGoftya8uBMk/d16+G0KaKtUfW6O4bL6ShumfD8w0j9oYQ clY2DXNLmEVcDUYqamGxw3dqbKwbqyqrgMw+3fkmYCL1j+iskbOODnmlffLQ8VuF 9FxljEK1WihfGDkSLCiQQqPcI6kFYZaNiHSCLgCB8iwc6NZtUb6GRJvHHwnFhoQ2 7ATHqG2iTeEBzLOxo3C0N7Ewfzd4W/2D3pfeeIocCOQ1AgMBAAEwDQYJKoZIhvcN AQEFBQADggEBAGoCFIN+U7oRM5lzwJtKMKr502+NNWbu7yY5+DumMR4bMx+ZDfpU 89Shd4zm/8eW5zsK1e+VjcTzqmPoHorGTAZYJ9jDveLhbqdkSPaqSlUHSMSP6nm5 9uD19rsULn4HSfVXX6JAODJR70Bcpd3Y5vP5PzD8f0daldq9Ldtjq9WeMxIYnttP sZfanzAR8viXid7M7qqQREva4Vb75TcxA5lneMYmA71M5skZiWt/52/wNNXlUMsW Ro4OxEgaAij492B/IyT0CNLlrQfVnHCPrKZrjTP65WxbsH00/sUrRbLKabtZzXB4 tfRm3Ba8SJruB8Qq3pAhXAlj9a2EypDubSs= -----END CERTIFICATE----- From andrewbosch at comcast.net Sat Aug 1 18:31:21 2015 From: andrewbosch at comcast.net (Andrew Bosch) Date: Sat, 1 Aug 2015 11:31:21 -0500 Subject: [atlas] Strange certificates at probe 17009 In-Reply-To: <20150801153555.GA14530@sources.org> References: <20150801153555.GA14530@sources.org> Message-ID: <007d01d0cc77$7ff324c0$7fd96e40$@comcast.net> The Fortinet name in the certificate suggests a firewall or proxy that is intercepting traffic from the probe. -----Original Message----- From: ripe-atlas [mailto:ripe-atlas-bounces at ripe.net] On Behalf Of Stephane Bortzmeyer Sent: Saturday, August 1, 2015 10:36 AM To: ripe-atlas at ripe.net Subject: [atlas] Strange certificates at probe 17009 Probe #17009, located in Bangkok, when asked to perform a "sslcert" measurement, always retrieve a certificate whose expiration date is 2024-10-31, whatever the target is. There is probably a man-in-the-middle before the probe... From sajal83 at gmail.com Sat Aug 1 19:36:14 2015 From: sajal83 at gmail.com (Sajal Kayan) Date: Sat, 01 Aug 2015 17:36:14 +0000 Subject: [atlas] Strange certificates at probe 17009 In-Reply-To: <007d01d0cc77$7ff324c0$7fd96e40$@comcast.net> References: <20150801153555.GA14530@sources.org> <007d01d0cc77$7ff324c0$7fd96e40$@comcast.net> Message-ID: This ISP (True Internet - AS7470 and AS17552 ) already intercepts http traffic using transparent proxy since quite some time. There were rumours recently that Thai ISPs would start intercepting https and making users install their TLS certificate. But I have not seen any evidence of it personally, nor have I heard of anyone who got certificate hijacked while browsing.... So its likely a proxy in the probe host's local network. On Sat, Aug 1, 2015 at 11:36 PM Andrew Bosch wrote: > The Fortinet name in the certificate suggests a firewall or proxy that is > intercepting traffic from the probe. > > > -----Original Message----- > From: ripe-atlas [mailto:ripe-atlas-bounces at ripe.net] On Behalf Of > Stephane > Bortzmeyer > Sent: Saturday, August 1, 2015 10:36 AM > To: ripe-atlas at ripe.net > Subject: [atlas] Strange certificates at probe 17009 > > Probe #17009, located in Bangkok, when asked to perform a "sslcert" > measurement, always retrieve a certificate whose expiration date is > 2024-10-31, whatever the target is. There is probably a > man-in-the-middle before the probe... > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karsten_thomann at linfre.de Sat Aug 1 21:49:37 2015 From: karsten_thomann at linfre.de (Karsten Thomann) Date: Sat, 01 Aug 2015 19:49:37 +0000 Subject: [atlas] Strange certificates at probe 17009 In-Reply-To: References: <20150801153555.GA14530@sources.org> <007d01d0cc77$7ff324c0$7fd96e40$@comcast.net> Message-ID: <2225939.4ifk2xkdZU@linne> Am Samstag, 1. August 2015, 17:36:14 schrieb Sajal Kayan: >.... So its likely a proxy in the probe host's local > network. Yep, as a Fortigate 100D is to small to be used in Carrier networks and I think a carrier based solution wouldn't use the self generated certificate of the device... > On Sat, Aug 1, 2015 at 11:36 PM Andrew Bosch > > wrote: > > The Fortinet name in the certificate suggests a firewall or proxy that is > > intercepting traffic from the probe. > > > > > > -----Original Message----- > > From: ripe-atlas [mailto:ripe-atlas-bounces at ripe.net] On Behalf Of > > Stephane > > Bortzmeyer > > Sent: Saturday, August 1, 2015 10:36 AM > > To: ripe-atlas at ripe.net > > Subject: [atlas] Strange certificates at probe 17009 > > > > Probe #17009, located in Bangkok, when asked to perform a "sslcert" > > measurement, always retrieve a certificate whose expiration date is > > 2024-10-31, whatever the target is. There is probably a > > man-in-the-middle before the probe... -------------- next part -------------- An HTML attachment was scrubbed... URL: From sarah.wassermann at student.ulg.ac.be Tue Aug 4 10:48:07 2015 From: sarah.wassermann at student.ulg.ac.be (sarah.wassermann at student.ulg.ac.be) Date: Tue, 4 Aug 2015 10:48:07 +0200 (CEST) Subject: [atlas] [User Defined Measurements] status settings In-Reply-To: <782459940.81823.1438677857870.JavaMail.root@student.ulg.ac.be> Message-ID: <1879139873.82649.1438678086991.JavaMail.root@student.ulg.ac.be> Hi, In the context of a research internship, I am automatising tools to check whether measurements have finished or not. Could you please tell me what the different status settings are? In the docs, only "scheduled", "ongoing" and "stopped" are indicated, but for 2 of my measurements I came across the status "failed" and "no suitable probes". Thank you very much in advance for your help! Sarah Wassermann From dquinn at ripe.net Tue Aug 4 11:27:47 2015 From: dquinn at ripe.net (Daniel Quinn) Date: Tue, 4 Aug 2015 11:27:47 +0200 Subject: [atlas] [User Defined Measurements] status settings In-Reply-To: <1879139873.82649.1438678086991.JavaMail.root@student.ulg.ac.be> References: <1879139873.82649.1438678086991.JavaMail.root@student.ulg.ac.be> Message-ID: <55C08593.90300@ripe.net> In the context of your research, you could view ?failed? and ?no suitable probes? as finished, but here is a complete list of possible measurement statuses: * *Specified*: the measurement has been defined and sent to our infrastructure to be relayed to the probes. * *Scheduled*: The measurement has been relayed to the probes. If the start time is immediate, this status doesn?t last very long. * *Ongoing*: The measurement is running on available probes. * *Stopped*: The measurement was stopped either on schedule, by the user requesting an early stop. * *Forced to Stop*: The measurement was killed prematurely due to a lack of available credits. * *No suitable probes*: The measurement cannot currently be executed as defined due to a lack of available probes. This may be because you asked to use probes that don?t exist (for example, probes in an AS in which there are no probes) or because all of the probes you requested were too busy to take on new jobs. This latter scenario is very rare however. * *Failed*: If a probe never actually runs a single measurement over the duration of the specified start/stop time (typically due to a lack of available probes), it will be marked as |Failed| once the stop time has been reached. In other words, |Specified|, |Scheduled|, |Ongoing|, and |No suitable probes| are statuses potentially assigned to running measurements (or at least those who may return results at some point), while |Stopped|, |Forced to Stop|, and |Failed| are statuses assigned to measurements that will not be returning any more results. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From joachim at tingvold.com Tue Aug 4 19:15:13 2015 From: joachim at tingvold.com (Joachim Tingvold) Date: Tue, 04 Aug 2015 19:15:13 +0200 Subject: [atlas] Your RIPE Atlas Probe (ID: 17523) is not connected to our network In-Reply-To: <20150802234038.4673.89069@janus.atlas.ripe.net> References: <20150802234038.4673.89069@janus.atlas.ripe.net> Message-ID: On 3 Aug 2015, at 1:40, RIPE Atlas wrote: > We have noticed that your probe (#17523 with description SHL46-jocke) > is not connected to our infrastructure and has been disconnected since > 2015-07-26 23:39 UTC. Hi, Having some issues getting my probe to work in an v6-only environment. Doing only SLAAC (and no v4) made it unable to connect (which makes kinda sense). Made it connect temporarily via v4 so that I could set static v6-address and DNS. Waited a while, then removed v4. I could see it on the ND-table of my router, and it even replied to ping on the static v6 address I assigned it. However, it still showed up as "offline" on the Atlas portal. After some mocking around, it now seems to be in some kind of stale status (the switchport doesn't even learn the MAC address of the probe). Any takers? (-: -- Joachim From philip.homburg at ripe.net Wed Aug 5 17:38:43 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 5 Aug 2015 17:38:43 +0200 Subject: [atlas] Your RIPE Atlas Probe (ID: 17523) is not connected to our network In-Reply-To: References: <20150802234038.4673.89069@janus.atlas.ripe.net> Message-ID: <55C22E03.4030401@ripe.net> Hi Joachim, On 2015/08/04 19:15 , Joachim Tingvold wrote: > Having some issues getting my probe to work in an v6-only environment. > > Doing only SLAAC (and no v4) made it unable to connect (which makes > kinda sense). Made it connect temporarily via v4 so that I could set > static v6-address and DNS. Waited a while, then removed v4. I could see > it on the ND-table of my router, and it even replied to ping on the > static v6 address I assigned it. However, it still showed up as > "offline" on the Atlas portal. > > After some mocking around, it now seems to be in some kind of stale > status (the switchport doesn't even learn the MAC address of the probe). Probes can be IPv6-only for a while now. They pick up DNS servers from Routing Advertisements. Even without DNS, a probe should continue trying to contact the reg. servers. Your probe last contacted reg. servers on July 26. In one instance you gave it an IPv6 DNS resolver. The second time that was no longer there. I have no idea what else happened to the probe. Philip From woeber at cc.univie.ac.at Thu Aug 6 12:44:42 2015 From: woeber at cc.univie.ac.at (Wilfried Woeber) Date: Thu, 06 Aug 2015 12:44:42 +0200 Subject: [atlas] Case sensitive DNS queries from the probe In-Reply-To: <55B8D34E.8010604@ripe.net> References: <55B8D34E.8010604@ripe.net> Message-ID: <55C33A9A.5020708@cc.univie.ac.at> Hi Philip, thanks for the explanation! Is there any intelligence available about the percentage (or type) of responders answering with the "correct" camel case? Thanks, Wilfried On 2015-07-29 15:21, Philip Homburg wrote: > On 2015/07/29 15:13 , Yang Yu wrote: > > Looking through DNS queries log I saw tons of queries from the probe >> for case sensitive names. Can someone please enlighten me what the >> possible use cases are? >> >> query: wWw.FacebOOK.COm IN A > > Many years ago there was a proposal for stub resolvers to perform case > mangling in DNS requests to obtain increased protection against spoofing > attacks. > > This never became popular but is implemented in the stub resolver in > libevent, which is used by the measurement code on the probes. > > Then net effect is that probes will send these types of queries whenever > the measurement code needs to look up a DNS name to obtain a target's IP > address. > > Philip From philip.homburg at ripe.net Thu Aug 6 14:25:38 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 6 Aug 2015 14:25:38 +0200 Subject: [atlas] Case sensitive DNS queries from the probe In-Reply-To: <55C33A9A.5020708@cc.univie.ac.at> References: <55B8D34E.8010604@ripe.net> <55C33A9A.5020708@cc.univie.ac.at> Message-ID: <55C35242.3090102@ripe.net> Hi Wilfried, On 2015/08/06 12:44 , Wilfried Woeber wrote: > Is there any intelligence available about the percentage (or type) of responders > answering with the "correct" camel case? I'm running measurement 1666409 which asks for 'WwW.rIpE.nEt.'. In addition it sets the DO flag. Looking at a download of 'latest', I got the following results: Total number of probes: 8267 Total number of perfect probes: 6780 Total number of probes with bad Qname: 320 Total number of probes with FORMERR: 447 Total number of probes with REFUSED: 74 Total number of probes with SERVFAIL: 15 Total number of probes with no answers: 5 Total number of probes with EDNS0 in Answer: 86 Total number of probes with no result (timeout): 609 So 8267 probes are active and 6780 returned the correct results for all of their resolvers. The other statistics are per resolver. So a single probe may trigger more than one error. I'm surprised by the high number of FORMERRs. Finding EDNS0 records in the Answer section is also fascinating. >From other statistics, we find that about 300 probes cannot perform HTTP measurements due to DNS lookup failures. Philip From fearghas at gmail.com Thu Aug 6 14:43:01 2015 From: fearghas at gmail.com (Fearghas Mckay) Date: Thu, 6 Aug 2015 13:43:01 +0100 Subject: [atlas] Case sensitive DNS queries from the probe In-Reply-To: <55C35242.3090102@ripe.net> References: <55B8D34E.8010604@ripe.net> <55C33A9A.5020708@cc.univie.ac.at> <55C35242.3090102@ripe.net> Message-ID: <684B5959-91E2-41C3-972B-6D0847535F24@gmail.com> Phillip > On 6 Aug 2015, at 13:25, Philip Homburg wrote: > > From other statistics, we find that about 300 probes cannot perform HTTP > measurements due to DNS lookup failures. Is there a process to tell probe owners that they have issues like that ? f From philip.homburg at ripe.net Thu Aug 6 14:57:04 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 6 Aug 2015 14:57:04 +0200 Subject: [atlas] Case sensitive DNS queries from the probe In-Reply-To: <684B5959-91E2-41C3-972B-6D0847535F24@gmail.com> References: <55B8D34E.8010604@ripe.net> <55C33A9A.5020708@cc.univie.ac.at> <55C35242.3090102@ripe.net> <684B5959-91E2-41C3-972B-6D0847535F24@gmail.com> Message-ID: <55C359A0.4060507@ripe.net> On 2015/08/06 14:43 , Fearghas Mckay wrote: > Is there a process to tell probe owners that they have issues like that ? For the DNS issue, we have a system tag 'Resolver Mangles Case'. But that depends on the probe host looking at the probe page. It is not clear when and how often we should mail probe hosts. Though in theory we could add these kinds of issues to the monthly probe status report. Philip From fearghas at gmail.com Thu Aug 6 15:12:27 2015 From: fearghas at gmail.com (Fearghas Mckay) Date: Thu, 6 Aug 2015 14:12:27 +0100 Subject: [atlas] Case sensitive DNS queries from the probe In-Reply-To: <55C359A0.4060507@ripe.net> References: <55B8D34E.8010604@ripe.net> <55C33A9A.5020708@cc.univie.ac.at> <55C35242.3090102@ripe.net> <684B5959-91E2-41C3-972B-6D0847535F24@gmail.com> <55C359A0.4060507@ripe.net> Message-ID: > On 6 Aug 2015, at 13:57, Philip Homburg wrote: > > For the DNS issue, we have a system tag 'Resolver Mangles Case'. But > that depends on the probe host looking at the probe page. > and knowing that things like that might be published there :-) > It is not clear when and how often we should mail probe hosts. Though in > theory we could add these kinds of issues to the monthly probe status > report. Doing this would be useful IMO, I certainly glance over them for the overview of how things are behaving. f From astracha at ripe.net Thu Aug 6 16:20:53 2015 From: astracha at ripe.net (Alastair Strachan) Date: Thu, 6 Aug 2015 16:20:53 +0200 Subject: [atlas] ViewQwest, (Singapore) has joined RIPE Atlas Anchors Message-ID: <3E40C48B-B350-426A-8AC2-F054F376DE5D@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called sg-sin-as18106 and is hosted by ViewQwest in Singapore Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, RIPE Atlas Team RIPE NCC atlas at ripe.net -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2613 bytes Desc: not available URL: From colinj at mx5.org.uk Thu Aug 6 16:56:44 2015 From: colinj at mx5.org.uk (Colin Johnston) Date: Thu, 6 Aug 2015 15:56:44 +0100 Subject: [atlas] Case sensitive DNS queries from the probe In-Reply-To: References: <55B8D34E.8010604@ripe.net> <55C33A9A.5020708@cc.univie.ac.at> <55C35242.3090102@ripe.net> <684B5959-91E2-41C3-972B-6D0847535F24@gmail.com> <55C359A0.4060507@ripe.net> Message-ID: <493F8FD3-CED9-4337-96BC-83418EAF27CB@mx5.org.uk> would be great to have this info, happy to help to debug problems with dns connectivity if my isp is affected as well on mass scale, i hope not :) Colin > On 6 Aug 2015, at 14:12, Fearghas Mckay wrote: > > >> On 6 Aug 2015, at 13:57, Philip Homburg wrote: >> >> For the DNS issue, we have a system tag 'Resolver Mangles Case'. But >> that depends on the probe host looking at the probe page. >> > > and knowing that things like that might be published there :-) > >> It is not clear when and how often we should mail probe hosts. Though in >> theory we could add these kinds of issues to the monthly probe status >> report. > > Doing this would be useful IMO, I certainly glance over them for the overview of how things are behaving. > > f > > From philip.homburg at ripe.net Thu Aug 6 17:05:30 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Thu, 6 Aug 2015 17:05:30 +0200 Subject: [atlas] Case sensitive DNS queries from the probe In-Reply-To: <493F8FD3-CED9-4337-96BC-83418EAF27CB@mx5.org.uk> References: <55B8D34E.8010604@ripe.net> <55C33A9A.5020708@cc.univie.ac.at> <55C35242.3090102@ripe.net> <684B5959-91E2-41C3-972B-6D0847535F24@gmail.com> <55C359A0.4060507@ripe.net> <493F8FD3-CED9-4337-96BC-83418EAF27CB@mx5.org.uk> Message-ID: <55C377BA.9030107@ripe.net> On 2015/08/06 16:56 , Colin Johnston wrote: > would be great to have this info, happy to help to debug problems with dns connectivity if my isp is affected as well on mass scale, i hope not :) You should be able to get a list of probes that mangle case in DNS from the probe archive API. https://atlas.ripe.net/docs/rest/#probe-archive Philip From John_Brzozowski at Cable.Comcast.com Thu Aug 6 18:24:45 2015 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Thu, 6 Aug 2015 16:24:45 +0000 Subject: [atlas] DNS over IPv6 Message-ID: Apologies if this is documented some where. Does the RIPE atlas probes explicitly measure/test DNS over IPv6? Also do DNS measurements look at recursion over IPv6 as well? Specifically I am interested in hearing more about how authoritative DNS servers (including root) behave with regards to DNS over IPv6. Thanks, John ========================================= John Jason Brzozowski Comcast Cable p) 484-962-0060 w) www.comcast6.net e) john_brzozowski at cable.comcast.com ========================================= From daniel.karrenberg at ripe.net Thu Aug 6 20:31:30 2015 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Thu, 6 Aug 2015 20:31:30 +0200 Subject: [atlas] DNS over IPv6 In-Reply-To: References: Message-ID: <55C3A802.7040007@ripe.net> On 6.08.15 18:24 , Brzozowski, John wrote: > Apologies if this is documented some where. https://atlas.ripe.net/docs/udm/ > Does the RIPE atlas probes> explicitly measure/test DNS over IPv6? When specifying a measurement you can set the address family (IPv4 or IPv6). > Also do DNS measurements look at> recursion over IPv6 as well? Yes. Of course the way recursion is done is up to the recursive resolvers .... > Specifically I am interested in hearing more> about how authoritative DNS servers (including root) behave with regards> to DNS over IPv6. https://atlas.ripe.net/dnsmon/?dnsmon.session.color_range_pls=0-66-66-99-100&dnsmon.session.exclude-errors=true&dnsmon.type=zone-servers&dnsmon.zone=root&dnsmon.startTime=1438834200&dnsmon.endTime=1438863000&dnsmon.ipVersion=6 Choose TLDs, time-frames, transport protocol ..... from the GUI. > Thanks, Pleasure. For this once as all that is easy to find ... ;-) Daniel From John_Brzozowski at Cable.Comcast.com Thu Aug 6 22:16:41 2015 From: John_Brzozowski at Cable.Comcast.com (Brzozowski, John) Date: Thu, 6 Aug 2015 20:16:41 +0000 Subject: [atlas] DNS over IPv6 In-Reply-To: <55C3A802.7040007@ripe.net> References: <55C3A802.7040007@ripe.net> Message-ID: Thanks, John ========================================= John Jason Brzozowski Comcast Cable p) 484-962-0060 w) www.comcast6.net e) john_brzozowski at cable.comcast.com ========================================= -----Original Message----- From: Daniel Karrenberg Date: Thursday, August 6, 2015 at 12:31 To: John Jason Brzozowski Cc: "ripe-atlas at ripe.net" Subject: Re: [atlas] DNS over IPv6 > > >On 6.08.15 18:24 , Brzozowski, John wrote: >> Apologies if this is documented some where. > >https://atlas.ripe.net/docs/udm/ > >> Does the RIPE atlas probes> explicitly measure/test DNS over IPv6? > >When specifying a measurement you can set the address family (IPv4 or >IPv6). > >> Also do DNS measurements look at> recursion over IPv6 as well? > >Yes. Of course the way recursion is done is up to the recursive >resolvers .... > >> Specifically I am interested in hearing more> about how authoritative >DNS servers (including root) behave with regards> to DNS over IPv6. > >https://atlas.ripe.net/dnsmon/?dnsmon.session.color_range_pls=0-66-66-99-1 >00&dnsmon.session.exclude-errors=true&dnsmon.type=zone-servers&dnsmon.zone >=root&dnsmon.startTime=1438834200&dnsmon.endTime=1438863000&dnsmon.ipVersi >on=6 > >Choose TLDs, time-frames, transport protocol ..... from the GUI. > > >> Thanks, > >Pleasure. For this once as all that is easy to find ... ;-) > >Daniel From emile.aben at ripe.net Fri Aug 7 06:26:52 2015 From: emile.aben at ripe.net (Emile Aben) Date: Fri, 07 Aug 2015 06:26:52 +0200 Subject: [atlas] Case sensitive DNS queries from the probe In-Reply-To: <55C377BA.9030107@ripe.net> References: <55B8D34E.8010604@ripe.net> <55C33A9A.5020708@cc.univie.ac.at> <55C35242.3090102@ripe.net> <684B5959-91E2-41C3-972B-6D0847535F24@gmail.com> <55C359A0.4060507@ripe.net> <493F8FD3-CED9-4337-96BC-83418EAF27CB@mx5.org.uk> <55C377BA.9030107@ripe.net> Message-ID: <55C4338C.4070705@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fearghas, Colin, others, On 06/08/15 17:05, Philip Homburg wrote: > On 2015/08/06 16:56 , Colin Johnston wrote: >> would be great to have this info, happy to help to debug problems >> with dns connectivity if my isp is affected as well on mass >> scale, i hope not :) How about having a single overview page per probe with various things that could be wrong with the probe? Some things that could be on that page: - - DNS mangling (could include a detailed description of what was wrong exactly per resolver used) - - IPv6 configured but not working - - path MTU issues - - SSL measurement results different from all other probes (hints at an MiTM) etc. Monthly probe reports could have a link to that page in case something is wrong. cheers, Emile -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVxDOJAAoJEKxthF6wloMOrGsP/26w+jtoqnIWDRtbS7F8Gp1E iBM7qSXJ2BrC7WNYnqObLcQHnFw2OTOf/lOSwu/O/9pBS7PcWGctqJdulSl7l3hU w938XyJv3yS1eQnxTNZ2/83Lj+vMHl5p/WA740aPTVmCDLP3TKvbh4Ziwk331Czh ZTRVObt1eOerV6hsMsUYBMCAMQp0PMIJ15RZSIqmDwVCYhOxuoKYVjrofwvcM9E+ 2oM5MNT4mWQQatrfqjNSEehTV4b4TJkPUQuJ3El5qtzdO65LQeSCkrMR326cTNrq QOTK2Ry3E3+UWDvc/XeomJR2RPZEgOafdgjwRAIawF9uNS4CtTqrWd6Fuci0V84v wCdUbXTc52zJi+pPc1lrtLfk1RxdPyYSlX+dzvtY8OI1PLApglZDUfUIRYcWM2jb aovrbDKb14iCtFjkeuObsWGJcWxoAXxqG/Pis695cmGley+uJyGP+HCLvBWohXKa t3irnu2uyBxYSz3a7pGD/BsolRczSBP3IzRE3hYUeh717t7pYLGAosv8r0zQBLsE qxM1p/9hJ5aOK/CEYGckqGDEHzmMt8LMlcsUgSrYKfRCvuFy5afvpSXFKlYrhZDt EB8rl73MXJ9tyVJhxy3tK8Vhm1u5O0N7XvWiK6mSAEMt+boMT6wacX2rm4Mtw73Z rQhH6BID9VU5q/ccIupL =4Hz9 -----END PGP SIGNATURE----- From fearghas at gmail.com Fri Aug 7 10:03:19 2015 From: fearghas at gmail.com (Fearghas Mckay) Date: Fri, 7 Aug 2015 09:03:19 +0100 Subject: [atlas] Case sensitive DNS queries from the probe In-Reply-To: <55C4338C.4070705@ripe.net> References: <55B8D34E.8010604@ripe.net> <55C33A9A.5020708@cc.univie.ac.at> <55C35242.3090102@ripe.net> <684B5959-91E2-41C3-972B-6D0847535F24@gmail.com> <55C359A0.4060507@ripe.net> <493F8FD3-CED9-4337-96BC-83418EAF27CB@mx5.org.uk> <55C377BA.9030107@ripe.net> <55C4338C.4070705@ripe.net> Message-ID: <81DFFA13-98CC-49D8-96B2-FA865C7B3B18@gmail.com> Emile > On 7 Aug 2015, at 05:26, Emile Aben wrote: > > How about having a single overview page per probe with various things > that could be wrong with the probe? That would be truly excellent Emile! :-) f From d.baeza at tvt-datos.es Fri Aug 7 10:08:44 2015 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Fri, 7 Aug 2015 10:08:44 +0200 Subject: [atlas] I root server - IPv6 Message-ID: <55C4678C.9050002@tvt-datos.es> Hello all! Do you guys have problems reaching i.root-servers.net on IPv6? https://stat.ripe.net/m/widget/atlas-ping-measurements#w.mode=condensed&w.measurement_id=2005&w.probe_id=17365 Regards, -- Daniel Baeza Centro de Observaci?n de Red Dpto. Red y Sistemas Television Costa Blanca S.L. Telf. 966.190.847 | Fax. 965.074.390 http://www.tvt.es | http://www.tvt-datos.es Correo: d.baeza at tvt-datos.es -- [Atenci?n] La informaci?n contenida en este e-mail es confidencial, privilegiada y est? dirigida exclusivamente a su destinatario. Cualquier revisi?n, difusi?n, distribuci?n o copiado de este mensaje sin autorizaci?n del propietario est? prohibido. Si ha recibido este e-mail por error por favor b?rrelo y env?e un mensaje al remitente. [Disclaimer] The information contained in this e-mail is privileged and confidential and is intended only for its addressee. Any review, dissemination, distribution or copying of this e-mail is prohibited. If you have received it in error please delete the original message and e-mail us. (!) El medio ambiente es responsabilidad de todos. Imprime este mail si es absolutamente necesario. From colinj at mx5.org.uk Fri Aug 7 10:11:12 2015 From: colinj at mx5.org.uk (Colin Johnston) Date: Fri, 7 Aug 2015 09:11:12 +0100 Subject: [atlas] any news on ripe atlas vm probe image development In-Reply-To: <81DFFA13-98CC-49D8-96B2-FA865C7B3B18@gmail.com> References: <55B8D34E.8010604@ripe.net> <55C33A9A.5020708@cc.univie.ac.at> <55C35242.3090102@ripe.net> <684B5959-91E2-41C3-972B-6D0847535F24@gmail.com> <55C359A0.4060507@ripe.net> <493F8FD3-CED9-4337-96BC-83418EAF27CB@mx5.org.uk> <55C377BA.9030107@ripe.net> <55C4338C.4070705@ripe.net> <81DFFA13-98CC-49D8-96B2-FA865C7B3B18@gmail.com> Message-ID: hi all, any news of ripe atlas vm probe image development would be useful to monitor vm clouds in major data centres colin Sent from my iPhone From robert at ripe.net Fri Aug 7 11:22:43 2015 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 07 Aug 2015 11:22:43 +0200 Subject: [atlas] I root server - IPv6 In-Reply-To: <55C4678C.9050002@tvt-datos.es> References: <55C4678C.9050002@tvt-datos.es> Message-ID: <55C478E3.5020907@ripe.net> On 2015-08-07 10:08, Daniel Baeza (Red y Sistemas TVT) wrote: > Hello all! > > Do you guys have problems reaching i.root-servers.net on IPv6? > > https://stat.ripe.net/m/widget/atlas-ping-measurements#w.mode=condensed&w.measurement_id=2005&w.probe_id=17365 > > > Regards, That's a particular probe having issues -- most probes are fine: https://atlas.ripe.net/results/maps/rtt-fixed/?measurement=2005&filter= or even: https://atlas.ripe.net/results/maps/root-instances/?server=5&question=10300&af=6&filter= Cheers, Robert From inigo at infornografia.net Fri Aug 7 11:39:14 2015 From: inigo at infornografia.net (=?UTF-8?Q?I=C3=B1igo_Ortiz_de_Urbina?=) Date: Fri, 7 Aug 2015 11:39:14 +0200 Subject: [atlas] I root server - IPv6 In-Reply-To: <55C478E3.5020907@ripe.net> References: <55C4678C.9050002@tvt-datos.es> <55C478E3.5020907@ripe.net> Message-ID: Hola Daniel DNSMON [1][2] also offers good coverage of the root. Instead of using the regular RIPE Atlas probes, it leverages the anchors, which provide more stable connectivity and better uptime. I recommend you adjust the "Colour range" settings for the thresholds that make sense to you. You can also get a more detailed, per-anchor and address family view of the results by clicking on the server names on the left of the visualisation. Interestingly, the anchor hosted by LACNIC (uy-mvd-as28000) can reach I-root over IPv6 just fine, but has 100% packet loss over v4. HTH! I?igo [1] https://atlas.ripe.net/dnsmon/ [2] https://atlas.ripe.net/dnsmon/group/i-root On Fri, Aug 7, 2015 at 11:22 AM, Robert Kisteleki wrote: > On 2015-08-07 10:08, Daniel Baeza (Red y Sistemas TVT) wrote: >> Hello all! >> >> Do you guys have problems reaching i.root-servers.net on IPv6? >> >> https://stat.ripe.net/m/widget/atlas-ping-measurements#w.mode=condensed&w.measurement_id=2005&w.probe_id=17365 >> >> >> Regards, > > That's a particular probe having issues -- most probes are fine: > > https://atlas.ripe.net/results/maps/rtt-fixed/?measurement=2005&filter= > > or even: > > https://atlas.ripe.net/results/maps/root-instances/?server=5&question=10300&af=6&filter= > > Cheers, > Robert > -- "If you want to go fast, go alone. If you want to go far, go together." From pvlaar at afilias.info Fri Aug 7 16:17:39 2015 From: pvlaar at afilias.info (Paul Vlaar) Date: Fri, 07 Aug 2015 16:17:39 +0200 Subject: [atlas] selecting probes based on place/city? Message-ID: <55C4BE03.7030100@afilias.info> Hi all, I was wondering if anyone managed to come up with a method of getting a probe selection via the API that is based on city. The web interface allows this, by searching for "place", which is subsequently handled by the Google Maps API (I think), and which then comes back with a number of probes on the map, in that given place. However I need this in the API, which only allows to select probes based on "area, country, prefix, asn". What I'm currently trying to come up with is a way to map, more or less, onto the list of ICANN specified probing locations for their DNS tests. This list is published here: https://tld-monitor.icann.org/nodes.csv I've been trying to go by the ASNs that the listed locations have their IP space in, but that frequently gives me a negative result (no probes present). The same for the prefixes themselves, of course. And just going by the enclosing country code is fine for a small place like Luxembourg, but not for a big country like Canada. So if anyone has any ideas on how to achieve this in a dynamic way (so as not to have to manually build and maintain a list of probes), I'd be very interested in hearing about that. Thank you, Paul Vlaar From robert at ripe.net Fri Aug 7 16:35:48 2015 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 07 Aug 2015 16:35:48 +0200 Subject: [atlas] selecting probes based on place/city? In-Reply-To: <55C4BE03.7030100@afilias.info> References: <55C4BE03.7030100@afilias.info> Message-ID: <55C4C244.8030600@ripe.net> Hi, > I was wondering if anyone managed to come up with a method of getting a > probe selection via the API that is based on city. The web interface > allows this, by searching for "place", which is subsequently handled by > the Google Maps API (I think), and which then comes back with a number > of probes on the map, in that given place. However I need this in the > API, which only allows to select probes based on "area, country, prefix, > asn". I suspect we'll never be able to fulfill *all* the various wishes about how probe selection should work when scheduling a measurements ("I want to use blue probes, but not the square ones, and only three per ASN, selected by largest distance from the most sparse population of cats" kind). So we have a decent set of features directly supported by the measurement API, and ... > So if anyone has any ideas on how to achieve this in a dynamic way (so > as not to have to manually build and maintain a list of probes), I'd be > very interested in hearing about that. ... the next best thing is to use the probe API to make a probe ID selection, and supply that ID list to the measurement API. The probe API is pretty flexible, can do country selection as well as geocenter+radius or geographic bounding box. So I guess it can be of use here. See https://atlas.ripe.net/docs/rest/#probe, also the example section. Hope this helps, Robert From emile.aben at ripe.net Fri Aug 7 16:46:16 2015 From: emile.aben at ripe.net (Emile Aben) Date: Fri, 07 Aug 2015 16:46:16 +0200 Subject: [atlas] selecting probes based on place/city? In-Reply-To: <55C4BE03.7030100@afilias.info> References: <55C4BE03.7030100@afilias.info> Message-ID: <55C4C4B8.8090704@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/08/15 16:17, Paul Vlaar wrote: > Hi all, > > I was wondering if anyone managed to come up with a method of > getting a probe selection via the API that is based on city. The > web interface allows this, by searching for "place", which is > subsequently handled by the Google Maps API (I think), and which > then comes back with a number of probes on the map, in that given > place. However I need this in the API, which only allows to select > probes based on "area, country, prefix, asn". > > What I'm currently trying to come up with is a way to map, more or > less, onto the list of ICANN specified probing locations for their > DNS tests. This list is published here: > > https://tld-monitor.icann.org/nodes.csv > > I've been trying to go by the ASNs that the listed locations have > their IP space in, but that frequently gives me a negative result > (no probes present). The same for the prefixes themselves, of > course. And just going by the enclosing country code is fine for a > small place like Luxembourg, but not for a big country like > Canada. > > So if anyone has any ideas on how to achieve this in a dynamic way > (so as not to have to manually build and maintain a list of > probes), I'd be very interested in hearing about that. I do have code to do the selection part of the process, that can automate the selection of probes, if it helps I can put it on Github? e1000$./select_probes.py -h usage: select_probes.py [-h] [-v] [-l LOCSTRING] [-p POINT] [-r RADIUS] [-n NUMBER] [-f FIELDS] [-a MAXPERAS] [-d] optional arguments: -h, --help show this help message and exit -v, --verbosity -l LOCSTRING, --locstring LOCSTRING location string, ie 'Amsterdam,NL' -p POINT, --point POINT location as ,-string, ie '48.45,9.16' -r RADIUS, --radius RADIUS radius (km) within which to select probes -n NUMBER, --number NUMBER number of probes requested -f FIELDS, --fields FIELDS comma separated list of fields to return (output is tsv) -a MAXPERAS, --maxperas MAXPERAS maximum no. of probes per IPv4 source AS -d, --includedownprobes include probes that are down (default: don't include these) e1000$./select_probes.py -l "Maastricht,NL" -r 20 -f id,asn_v4 14648 9143 11917 9143 16979 61956 438 9143 20036 12392 18396 12392 13308 9143 13656 12392 16243 9143 cheers, Emile > > Thank you, > > Paul Vlaar > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVxMS2AAoJEKxthF6wloMOSCQQAMOcb+t+kq0MMrO1HsvtAfRa g6C+Z/O3VA/gOKNhlvsQvmYmHxfa4tFxu2kqP2r43SCe48JGQwKDeOHCF7pCaeL8 lxmw7gXZauX3G9bGPwPCTOJNhAdnDT2u/XhCZLf9KLuhfllHNLFgR0FRmDe6z/Gu yp/4JBfcPNJux/QGmy8ps0JFxCYovY6OeiNtPq04qWitE+cMDqHhK8PiBD53MUl9 cntoK9aNTfiozvtvhtFLpm7vcv1kpWcB/t7L2L03P+vfeceFTbXY0TR7/4lnXVH5 3Rdz6iZqBMCiuoE43+vI38nku8jtS3kiPsAsqYqkJiZQBjh9j7oYfQCu0+EbDVAW G7GeBqvAm2T+1Lko/2rZpqorfmuu72WYT2/s4TwsMYMlsID7tB7EEeSo/Txzhsd8 l6HqEO+S6c+cVW8CaOL7zheUdgezaLK69FFHFrCiIAVZ1CSI8SirhAyQei8HAAh+ yyS4cpx/yPEqIeG0hZL1Z+KhPSmQoxLSnx8TIcUyBCCufWNclYjLGo/rcxxYU7z7 r2vGjT7Arx62o5+53nzLt8wThwZVR0oyysZoC0GzRJxFu/lAGWCyWs3GC3TGjukF BuoibQzH1RFm6mxyz+ypqQTzx+7eTmklcPgLPkesQA26TqXTN33G/n1hQecb74mX FyzWMfw78vEHcGvSXs2Z =EFxL -----END PGP SIGNATURE----- From pvlaar at afilias.info Fri Aug 7 17:21:31 2015 From: pvlaar at afilias.info (Paul Vlaar) Date: Fri, 07 Aug 2015 17:21:31 +0200 Subject: [atlas] selecting probes based on place/city? In-Reply-To: <55C4C244.8030600@ripe.net> References: <55C4BE03.7030100@afilias.info> <55C4C244.8030600@ripe.net> Message-ID: <55C4CCFB.7040305@afilias.info> Robert, On 7/8/15 4:35 PM, Robert Kisteleki wrote: > ... the next best thing is to use the probe API to make a probe ID > selection, and supply that ID list to the measurement API. The probe API is > pretty flexible, can do country selection as well as geocenter+radius or > geographic bounding box. So I guess it can be of use here. > > See https://atlas.ripe.net/docs/rest/#probe, also the example section. Thanks for pointing me to that. I've just tried one of the examples listed: https://atlas.ripe.net/api/v1/probe/?country_code=de&is_public=true&fields=location,address_v4 However, I don't see the human readable location string show up in the results. Perhaps I'm reading over it? ~paul From pvlaar at afilias.info Fri Aug 7 17:22:58 2015 From: pvlaar at afilias.info (Paul Vlaar) Date: Fri, 07 Aug 2015 17:22:58 +0200 Subject: [atlas] selecting probes based on place/city? In-Reply-To: <55C4C4B8.8090704@ripe.net> References: <55C4BE03.7030100@afilias.info> <55C4C4B8.8090704@ripe.net> Message-ID: <55C4CD52.3090206@afilias.info> Hi Emile, On 7/8/15 4:46 PM, Emile Aben wrote: > I do have code to do the selection part of the process, that can > automate the selection of probes, if it helps I can put it on Github? this looks great, I would love to be able to use your tool. If you can place it on Github, that would be very helpful. Otherwise, perhaps you can provide me a download link, or send it to me directly? ~paul From emile.aben at ripe.net Fri Aug 7 21:44:52 2015 From: emile.aben at ripe.net (Emile Aben) Date: Fri, 07 Aug 2015 21:44:52 +0200 Subject: [atlas] selecting probes based on place/city? In-Reply-To: <55C4CD52.3090206@afilias.info> References: <55C4BE03.7030100@afilias.info> <55C4C4B8.8090704@ripe.net> <55C4CD52.3090206@afilias.info> Message-ID: <55C50AB4.4080500@ripe.net> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/08/15 17:22, Paul Vlaar wrote: > Hi Emile, > > On 7/8/15 4:46 PM, Emile Aben wrote: >> I do have code to do the selection part of the process, that can >> automate the selection of probes, if it helps I can put it on >> Github? > > this looks great, I would love to be able to use your tool. If you > can place it on Github, that would be very helpful. Otherwise, > perhaps you can provide me a download link, or send it to me > directly? https://github.com/emileaben/ripeatlas-probe-geoselect Only tested on my local laptop, so YMMV cheers, Emile -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJVxQqxAAoJEKxthF6wloMOhToP/jZoIBDFHEBvKGWH8/L/uMbM yxaRYC0iED9YzPODiNKp/JyLeI6/XuGQJhMBzkXo7pflZLQvWSApUfJADcUO6AeS t+y3MZqJ9zJOz+dMlAqx9VLsk3DBZiwzdHs9qk2SgWYpCDoCnDDwyZQ/bs57fd3F opaitLaiI/VE1X8TbYRL/BK32GKuSj069VgqJ/FT1tYv/l09t5KhmvkqIKe8d/y4 dXxPiD/DhLTKJdxJpfTnMPVjhgywCWhAJUnr8GA4bkuxdFqULvu/xxDPN66Itl9M H2UcIYl9BkPM9sMfGAKtE25Xz2gs4+0UXCCvpjNKHqqA5LbGbv++WTUoNFkcY8th gzxtxj1k1/54+osZkjlj53G8z0ngOy3+f6kj7JNW5iP6kezotp8ijHnCOaubdwvU ASb1G5KbetV99gzq/SYSck2jn8MsYYkuvJVOStADLp5+QRmY6FJZqUaw4tjL52Zf TkU5PTxkl1F36pFlB0C1o404WCKQbva0RL9B8Y/V555uwVlKVAmiwvoSxeXiSxYO 8rPm53Xdro6Zu0HpvdU7fNgU29rIo2DEqD3n/L5IFUMyckfBJQuBRYVUzU2RnbRk o/u5kL+6sDJUzONNgHY9JJQx2sgRJgfcRCL/vPWG64mczYNlOe82aPtclrC3Jbj5 UeIfyYAwnJEPA2MS+TR7 =YOFe -----END PGP SIGNATURE----- From bortzmeyer at nic.fr Sat Aug 8 12:46:03 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sat, 8 Aug 2015 12:46:03 +0200 Subject: [atlas] selecting probes based on place/city? In-Reply-To: <55C50AB4.4080500@ripe.net> References: <55C4BE03.7030100@afilias.info> <55C4C4B8.8090704@ripe.net> <55C4CD52.3090206@afilias.info> <55C50AB4.4080500@ripe.net> Message-ID: <20150808104603.GA25884@laperouse.bortzmeyer.org> On Fri, Aug 07, 2015 at 09:44:52PM +0200, Emile Aben wrote a message of 40 lines which said: > https://github.com/emileaben/ripeatlas-probe-geoselect Thanks, but to avoid long searches on Github, could the people who contribute fork instead and send Pull Requests? From bortzmeyer at nic.fr Sat Aug 8 22:40:41 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Sat, 8 Aug 2015 22:40:41 +0200 Subject: [atlas] Public documentation of probes problems (Was: Case sensitive DNS queries from the probe In-Reply-To: <55C4338C.4070705@ripe.net> References: <55B8D34E.8010604@ripe.net> <55C33A9A.5020708@cc.univie.ac.at> <55C35242.3090102@ripe.net> <684B5959-91E2-41C3-972B-6D0847535F24@gmail.com> <55C359A0.4060507@ripe.net> <493F8FD3-CED9-4337-96BC-83418EAF27CB@mx5.org.uk> <55C377BA.9030107@ripe.net> <55C4338C.4070705@ripe.net> Message-ID: <20150808204041.GA4273@laperouse.bortzmeyer.org> On Fri, Aug 07, 2015 at 06:26:52AM +0200, Emile Aben wrote a message of 46 lines which said: > How about having a single overview page per probe with various things > that could be wrong with the probe? Yes. > Some things that could be on that page: > - - DNS mangling (could include a detailed description of what was wrong > exactly per resolver used) Probes using a broken DNS resolver. For instance, both 17072 and 18606 are configured to use a DNS resolver which replies REFUSED to every query. From pvlaar at afilias.info Mon Aug 10 11:59:47 2015 From: pvlaar at afilias.info (Paul Vlaar) Date: Mon, 10 Aug 2015 11:59:47 +0200 Subject: [atlas] one-off UDMs more expensive? Message-ID: <55C87613.6030805@afilias.info> As I go through the web interface to setup a UDM I notice the following: For the same DNS measurement, when I specify an interval of 24 hours between samples, the total daily cost comes to 10. When however I specify this to be a one-off sample, the cost then doubles to 20. This doesn't seem to make sense to me. Is there a special reason for one-off measurements to be twice as expensive? ~paul -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2015-08-10 at 10.04.32 AM.png Type: image/png Size: 153824 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2015-08-10 at 10.02.54 AM.png Type: image/png Size: 139348 bytes Desc: not available URL: From robert at ripe.net Mon Aug 10 13:30:52 2015 From: robert at ripe.net (Robert Kisteleki) Date: Mon, 10 Aug 2015 13:30:52 +0200 Subject: [atlas] one-off UDMs more expensive? In-Reply-To: <55C87613.6030805@afilias.info> References: <55C87613.6030805@afilias.info> Message-ID: <55C88B6C.2050002@ripe.net> On 2015-08-10 11:59, Paul Vlaar wrote: > As I go through the web interface to setup a UDM I notice the following: > > For the same DNS measurement, when I specify an interval of 24 hours > between samples, the total daily cost comes to 10. When however I > specify this to be a one-off sample, the cost then doubles to 20. Cost for one-off measurements is indeed twice the amount of the regular ones. This is documented at https://atlas.ripe.net/docs/credits/ > This doesn't seem to make sense to me. Is there a special reason for > one-off measurements to be twice as expensive? One-offs are more expensive for the system to execute: they need immediate scheduling and result delivery is done with priority for example, so they cost more. Regards, Robert > ~paul > From pvlaar at afilias.info Mon Aug 10 13:48:56 2015 From: pvlaar at afilias.info (Paul Vlaar) Date: Mon, 10 Aug 2015 13:48:56 +0200 Subject: [atlas] one-off UDMs more expensive? In-Reply-To: <55C88B6C.2050002@ripe.net> References: <55C87613.6030805@afilias.info> <55C88B6C.2050002@ripe.net> Message-ID: <55C88FA8.50309@afilias.info> On 10/8/15 1:30 PM, Robert Kisteleki wrote: > One-offs are more expensive for the system to execute: they need immediate > scheduling and result delivery is done with priority for example, so they > cost more. Aha, in that case, I would love to see the possibility to request one-off measurements that do not require to be immediately scheduled, and for which result delivery is not done with any priority over periodical ones. Alternatively, I could also just create a regular periodical UDM and specify a stop time in the near future, in order to save credits upon doing measurements that need to be run only once. Trying that gives me an interesting result though: I can't place the stop time within 2 hours of the current time, is that to be expected? ~paul From d.baeza at tvt-datos.es Wed Aug 12 14:17:03 2015 From: d.baeza at tvt-datos.es (Daniel Baeza (Red y Sistemas TVT)) Date: Wed, 12 Aug 2015 14:17:03 +0200 Subject: [atlas] Promote the use of IRC Message-ID: <55CB393F.1080905@tvt-datos.es> Hi all, Yesterday, I've started a discussion in the member list about promoting the use of IRC instead of Mail List for some kind of discussions, chit chat, etc. Not much members answered, but all who did said yes. The goal is to have, at least, one channel per mail list, but not limited to only that. For this list, an #atlas channel will be created and administrated by the WG Chairs. We want to use the actual RIPE IRC Server plus Network Services and some more irc servers linked to the Ripe one. What do you think? Regards, --Daniel From emil at emilstahl.dk Wed Aug 12 14:20:24 2015 From: emil at emilstahl.dk (Emil Stahl Pedersen) Date: Wed, 12 Aug 2015 05:20:24 -0700 (PDT) Subject: [atlas] Promote the use of IRC In-Reply-To: <55CB393F.1080905@tvt-datos.es> References: <55CB393F.1080905@tvt-datos.es> Message-ID: <1439382024283.8b8c7ef9@Nodemailer> Have you considered Slack? Best regards,Emil Stahl Pedersen On onsdag, aug. 12, 2015 at 2:18 PM, Daniel Baeza (Red y Sistemas TVT) , wrote: Hi all, Yesterday, I've started a discussion in the member list about promoting the use of IRC instead of Mail List for some kind of discussions, chit chat, etc. Not much members answered, but all who did said yes. The goal is to have, at least, one channel per mail list, but not limited to only that. For this list, an #atlas channel will be created and administrated by the WG Chairs. We want to use the actual RIPE IRC Server plus Network Services and some more irc servers linked to the Ripe one. What do you think? Regards, --Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert at ripe.net Wed Aug 12 14:53:29 2015 From: robert at ripe.net (Robert Kisteleki) Date: Wed, 12 Aug 2015 14:53:29 +0200 Subject: [atlas] Promote the use of IRC In-Reply-To: <55CB393F.1080905@tvt-datos.es> References: <55CB393F.1080905@tvt-datos.es> Message-ID: <55CB41C9.4050308@ripe.net> Hi, I'd think that if such a thing is indeed made, XMPP/Jabber is more state of the art than IRC. Jabber rooms can also have persistence/memory, so missed previous messages can be seen after one logs in -- there's no need for a bot to sit in all the time and record. Cheers, Robert On 2015-08-12 14:17, Daniel Baeza (Red y Sistemas TVT) wrote: > Hi all, > > Yesterday, I've started a discussion in the member list about promoting the > use of IRC instead of Mail List for some kind of discussions, chit chat, etc. > > Not much members answered, but all who did said yes. > > The goal is to have, at least, one channel per mail list, but not limited to > only that. > > For this list, an #atlas channel will be created and administrated by the WG > Chairs. > > We want to use the actual RIPE IRC Server plus Network Services and some > more irc servers linked to the Ripe one. > > What do you think? > > Regards, > > --Daniel > > From emil at emilstahl.dk Wed Aug 12 15:05:01 2015 From: emil at emilstahl.dk (Emil Stahl Pedersen) Date: Wed, 12 Aug 2015 15:05:01 +0200 Subject: [atlas] Promote the use of IRC In-Reply-To: References: <55CB393F.1080905@tvt-datos.es> <1439382024283.8b8c7ef9@Nodemailer> Message-ID: Cool. I did not know that. FWIW WordPress has replaced IRC with Slack. When compiling a list of things people liked about our existing options, it was obvious that Slack was all of that and more, including: - Open for everyone - Friendly user interface - Easy asynchronous conversation - iOS and Android apps - Powerful customization abilities - Excellent search https://make.wordpress.org/chat/ ?Best regards, Emil Stahl Pedersen On Wed, Aug 12, 2015 at 2:57 PM, Jelle Herold wrote: > > On 12 Aug 2015, at 14:20, Emil Stahl Pedersen wrote: > > Have you considered Slack? > > > FWIW, http://www.mattermost.org/ is an open source Slack clone > > Best, > Jelle. > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jelle at defekt.nl Wed Aug 12 14:57:47 2015 From: jelle at defekt.nl (Jelle Herold) Date: Wed, 12 Aug 2015 14:57:47 +0200 Subject: [atlas] Promote the use of IRC In-Reply-To: <1439382024283.8b8c7ef9@Nodemailer> References: <55CB393F.1080905@tvt-datos.es> <1439382024283.8b8c7ef9@Nodemailer> Message-ID: > On 12 Aug 2015, at 14:20, Emil Stahl Pedersen wrote: > > Have you considered Slack? FWIW, http://www.mattermost.org/ is an open source Slack clone Best, Jelle. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rm at romanrm.net Wed Aug 12 16:09:35 2015 From: rm at romanrm.net (Roman Mamedov) Date: Wed, 12 Aug 2015 19:09:35 +0500 Subject: [atlas] Promote the use of IRC In-Reply-To: <55CB393F.1080905@tvt-datos.es> References: <55CB393F.1080905@tvt-datos.es> Message-ID: <20150812190935.5d3a1bb2@natsu> On Wed, 12 Aug 2015 14:17:03 +0200 "Daniel Baeza (Red y Sistemas TVT)" wrote: > Yesterday, I've started a discussion in the member list about promoting > the use of IRC instead of Mail List for some kind of discussions, chit > chat, etc. > > Not much members answered, but all who did said yes. > > The goal is to have, at least, one channel per mail list, but not > limited to only that. > > For this list, an #atlas channel will be created and administrated by > the WG Chairs. > > We want to use the actual RIPE IRC Server plus Network Services and some > more irc servers linked to the Ripe one. > > What do you think? I would suggest using the Freenode IRC network and just create a channel there, many developers and sysadmins already hang out at Freenode (370 users in #ipv6, 970 in #networking), I bet some Atlas users are there too. It's very simple to join one more channel on an existing network you're already on, but a much higher amount of hassle to create a new connection profile in the IRC client for a new network, then register a username there, etc. -- With respect, Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: not available URL: From jon.brewer at gmail.com Thu Aug 13 00:16:01 2015 From: jon.brewer at gmail.com (Jonathan Brewer) Date: Thu, 13 Aug 2015 10:16:01 +1200 Subject: [atlas] Promote the use of IRC In-Reply-To: <1439382024283.8b8c7ef9@Nodemailer> References: <55CB393F.1080905@tvt-datos.es> <1439382024283.8b8c7ef9@Nodemailer> Message-ID: I'm unlikely to go back to IRC. I would participate if it were a Slack channel. For those who do not want to use Slack, there are XMMP gateways for it. On 13 August 2015 at 00:20, Emil Stahl Pedersen wrote: > Have you considered Slack? > > > Best regards, > Emil Stahl Pedersen > > On onsdag, aug. 12, 2015 at 2:18 PM, Daniel Baeza (Red y Sistemas TVT) < > d.baeza at tvt-datos.es>, wrote: > >> Hi all, >> >> Yesterday, I've started a discussion in the member list about promoting >> the use of IRC instead of Mail List for some kind of discussions, chit >> chat, etc. >> >> Not much members answered, but all who did said yes. >> >> The goal is to have, at least, one channel per mail list, but not >> limited to only that. >> >> For this list, an #atlas channel will be created and administrated by >> the WG Chairs. >> >> We want to use the actual RIPE IRC Server plus Network Services and some >> more irc servers linked to the Ripe one. >> >> What do you think? >> >> Regards, >> >> --Daniel >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From listclient at sokolov.eu.org Thu Aug 13 03:08:12 2015 From: listclient at sokolov.eu.org (Daniel AJ Sokolov) Date: Wed, 12 Aug 2015 22:08:12 -0300 Subject: [atlas] Promote the use of IRC In-Reply-To: <55CB393F.1080905@tvt-datos.es> References: <55CB393F.1080905@tvt-datos.es> Message-ID: <55CBEDFC.4070409@sokolov.eu.org> On 2015-08-12 at 09:17, Daniel Baeza (Red y Sistemas TVT) wrote: > > Yesterday, I've started a discussion in the member list about promoting > the use of IRC instead of Mail List for some kind of discussions, chit > chat, etc. Yet another communications channel? Thank you, but, no, thank you. Daniel AJ From yang.yu.list at gmail.com Thu Aug 13 22:41:34 2015 From: yang.yu.list at gmail.com (Yang Yu) Date: Thu, 13 Aug 2015 15:41:34 -0500 Subject: [atlas] Excluding probes by user defined tag not working Message-ID: Hello, When I use New Set - wizard to select probes, the exclusion by tag does not work with user tags. Even though the user tag was recognized (I chose it from the drop down menu), the particular probe was still selected. For example, I excluded user tag SDFJLKFWEO from measurement 2312281, but probe 10240 was still selected. Thanks. Yang From bortzmeyer at nic.fr Fri Aug 14 00:02:21 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Fri, 14 Aug 2015 00:02:21 +0200 Subject: [atlas] Excluding probes by user defined tag not working In-Reply-To: References: Message-ID: <20150813220220.GA4051@laperouse.bortzmeyer.org> On Thu, Aug 13, 2015 at 03:41:34PM -0500, Yang Yu wrote a message of 13 lines which said: > When I use New Set - wizard to select probes, the exclusion by tag > does not work with user tags. Even though the user tag was > recognized (I chose it from the drop down menu), the particular > probe was still selected. > > For example, I excluded user tag SDFJLKFWEO from measurement > 2312281, but probe 10240 was still selected. I tried from the API and the results are strange. Some existing user tags are not recognized: {'definitions': [{'target': '192.134.5.5', 'af': 4, 'packets': 3, 'type': 'ping', 'is_oneoff': True, 'description': 'Ping 192.134.5.5'}], 'probes': [{'requested': 3, 'type': 'area', 'value': 'WW', 'tags': {'exclude': ['sdfjlkfweo']}}]} => RIPEAtlas.RequestSubmissionError: Status 400, reason "{"error":{"message":"tags_exclude: Select a valid choice. sdfjlkfweo is not one of the available choices.","code":104}}" But other tags are accepted: {'definitions': [{'target': '192.134.5.5', 'af': 4, 'packets': 3, 'type': 'ping', 'is_oneoff': True, 'description': 'Ping 192.134.5.5'}], 'probes': [{'requested': 3, 'type': 'area', 'value': 'WW', 'tags': {'exclude': ['home']}}]} => Measurement #2312797 From colin at spakka.net Fri Aug 14 11:29:26 2015 From: colin at spakka.net (Colin Petrie) Date: Fri, 14 Aug 2015 11:29:26 +0200 Subject: [atlas] Promote the use of IRC In-Reply-To: <55CB393F.1080905@tvt-datos.es> References: <55CB393F.1080905@tvt-datos.es> Message-ID: <55CDB4F6.4040407@spakka.net> On 12/08/15 14:17, Daniel Baeza (Red y Sistemas TVT) wrote: > We want to use the actual RIPE IRC Server plus Network Services and some > more irc servers linked to the Ripe one. > > What do you think? Please, no IRC. If something like this is wanted, use something from this century, which actually has features. XMPP would be my preferred option. Cheers, Colin From robert at ripe.net Fri Aug 14 11:48:52 2015 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 14 Aug 2015 11:48:52 +0200 Subject: [atlas] Excluding probes by user defined tag not working In-Reply-To: <20150813220220.GA4051@laperouse.bortzmeyer.org> References: <20150813220220.GA4051@laperouse.bortzmeyer.org> Message-ID: <55CDB984.5040302@ripe.net> Hello Yang, Stephane, >> For example, I excluded user tag SDFJLKFWEO from measurement >> 2312281, but probe 10240 was still selected. > > I tried from the API and the results are strange. Some existing user > tags are not recognized: Indeed you've found something that we can and will improve, but in general the system behaves as expected. Let me explain. Users can tag their probes with anything they like, we have no restrictions here. However, only the "approved" tags show up to other users, and only these can be used in the measurement API (besides the system tags, but that's not a part of this discussion). Stephane used the API, which properly accepted the tag "home" but rejected the tag "sdfjlkfweo". This is expected and the error was correct and descriptive. Yang discovered two small bugs in the UI: * The tag suggestion feature should only offer approved tags -- but it offers all of them at the moment. This is not a big problem, but also not the desired behaviour. * The measurement UI refuses to make a measurement with an unapproved tag (in fact the underlying API does, as described above) -- but it fails to warn the user about this, instead it shows the form again, with all data pre-filled *except* the probe tag in question. If the user is not eagle-eyed and submits the form again (with no apparent changes), the system happily accepts this and makes a measurement, but without that tag exclusion/inclusion clause. Thank you for reporting these issues, they have already been fixed. Regards, Robert From BECHA at ripe.net Tue Aug 18 14:05:35 2015 From: BECHA at ripe.net (Vesna Manojlovic) Date: Tue, 18 Aug 2015 14:05:35 +0200 Subject: [atlas] Next week: webinar on "Advanced RIPE Atlas Usage" In-Reply-To: <5582DBCC.4070906@ripe.net> References: <5582DBCC.4070906@ripe.net> Message-ID: <55D31F8F.8030408@ripe.net> Dear colleagues, there are two more dates available for you to register for the webinar "Advanced RIPE Atlas Usage", aiming to teach network operators how to use RIPE Atlas measurements for network monitoring and troubleshooting: 27th August & 17th September. https://www.ripe.net/support/training/learn-online/webinars/advanced-ripe-atlas-usage-webinar This is part of the series of interactive on-line learning sessions, that give you the opportunity to learn and interact with trainers without leaving your desk, as well as for hands-on practice, and to get your questions answered by developers. Learn how to: - Use RIPE Atlas measurements for network monitoring and troubleshooting - Use API calls for measurement creation - Integrate RIPE Atlas with existing monitoring systems Webinars start at 11:30 UTC, and take about one hour. Register now at: https://www.ripe.net/support/training/learn-online/webinars Web-registration is *only* possible for LIRs (RIPE NCC members). If you are interested but to not have "Reg-ID", please email training @ ripe.net and say which date you would like to be registered for. We look forward to seeing you online. Kind regards, Vesna Manojlovic RIPE NCC From mm at 42com.com Tue Aug 18 14:38:20 2015 From: mm at 42com.com (=?UTF-8?B?TWF4IE3DvGhsYnJvbm5lcg==?=) Date: Tue, 18 Aug 2015 14:38:20 +0200 Subject: [atlas] Next week: webinar on "Advanced RIPE Atlas Usage" In-Reply-To: <55D31F8F.8030408@ripe.net> References: <5582DBCC.4070906@ripe.net> <55D31F8F.8030408@ripe.net> Message-ID: <55D3273C.4010705@42com.com> Hi, noob question, how can i find the RegID which is required to register for the webinar? (Shame on me...) I was not able to find our RegID although we are a LIR. Message says: "Please type a valid regid. You can find the list of members here." Best Regards Max M. On 18.08.2015 14:05, Vesna Manojlovic wrote: > Dear colleagues, > > there are two more dates available for you to register for the webinar > "Advanced RIPE Atlas Usage", aiming to teach network operators how to > use RIPE Atlas measurements for network monitoring and troubleshooting: > > 27th August & 17th September. > > https://www.ripe.net/support/training/learn-online/webinars/advanced-ripe-atlas-usage-webinar > > > This is part of the series of interactive on-line learning sessions, > that give you the opportunity to learn and interact with trainers > without leaving your desk, as well as for hands-on practice, and > to get your questions answered by developers. > > Learn how to: > - Use RIPE Atlas measurements for network monitoring and troubleshooting > - Use API calls for measurement creation > - Integrate RIPE Atlas with existing monitoring systems > > Webinars start at 11:30 UTC, and take about one hour. > > Register now at: > https://www.ripe.net/support/training/learn-online/webinars > > Web-registration is *only* possible for LIRs (RIPE NCC members). > > If you are interested but to not have "Reg-ID", please email training > @ ripe.net and say which date you would like to be registered for. > > We look forward to seeing you online. > > Kind regards, > Vesna Manojlovic > RIPE NCC > > bitte unverz?glich telefonisch oder per E-Mail. From eject.in.ua at gmail.com Tue Aug 18 16:39:53 2015 From: eject.in.ua at gmail.com (Evgeniy Sudyr) Date: Tue, 18 Aug 2015 16:39:53 +0200 Subject: [atlas] Next week: webinar on "Advanced RIPE Atlas Usage" In-Reply-To: <55D3273C.4010705@42com.com> References: <5582DBCC.4070906@ripe.net> <55D31F8F.8030408@ripe.net> <55D3273C.4010705@42com.com> Message-ID: Max, Looks RIPE trainings (by original design) are available for members (LIRs), but Vesna said at the very end of her mail: > If you are interested but to not have "Reg-ID", please email training @ ripe.net and say which date you would like to be registered for. --- Regards, Evgeniy Sudyr On Tue, Aug 18, 2015 at 2:38 PM, Max M?hlbronner wrote: > Hi, > > noob question, how can i find the RegID which is required to register for > the webinar? (Shame on me...) > > I was not able to find our RegID although we are a LIR. Message says: > "Please type a valid regid. You can find the list of members here." > > > > Best Regards > > > Max M. > > > > On 18.08.2015 14:05, Vesna Manojlovic wrote: >> >> Dear colleagues, >> >> there are two more dates available for you to register for the webinar >> "Advanced RIPE Atlas Usage", aiming to teach network operators how to use >> RIPE Atlas measurements for network monitoring and troubleshooting: >> >> 27th August & 17th September. >> >> >> https://www.ripe.net/support/training/learn-online/webinars/advanced-ripe-atlas-usage-webinar >> >> This is part of the series of interactive on-line learning sessions, >> that give you the opportunity to learn and interact with trainers >> without leaving your desk, as well as for hands-on practice, and >> to get your questions answered by developers. >> >> Learn how to: >> - Use RIPE Atlas measurements for network monitoring and troubleshooting >> - Use API calls for measurement creation >> - Integrate RIPE Atlas with existing monitoring systems >> >> Webinars start at 11:30 UTC, and take about one hour. >> >> Register now at: >> https://www.ripe.net/support/training/learn-online/webinars >> >> Web-registration is *only* possible for LIRs (RIPE NCC members). >> >> If you are interested but to not have "Reg-ID", please email training @ >> ripe.net and say which date you would like to be registered for. >> >> We look forward to seeing you online. >> >> Kind regards, >> Vesna Manojlovic >> RIPE NCC >> >> bitte unverz?glich telefonisch oder per E-Mail. > > -- -- With regards, Eugene Sudyr From pablo.cuello at gmail.com Tue Aug 18 16:48:37 2015 From: pablo.cuello at gmail.com (Pablo Cuello) Date: Tue, 18 Aug 2015 11:48:37 -0300 Subject: [atlas] Next week: webinar on "Advanced RIPE Atlas Usage" In-Reply-To: References: <5582DBCC.4070906@ripe.net> <55D31F8F.8030408@ripe.net> <55D3273C.4010705@42com.com> Message-ID: Es el jueves de la semana que viene a eso de 8:30 (11:30 UTC), si les parece mando un email para pedir que nos incluyan. Saludos Pablo On Tue, Aug 18, 2015 at 11:39 AM, Evgeniy Sudyr wrote: > Max, > > Looks RIPE trainings (by original design) are available for members > (LIRs), but Vesna said at the very end of her mail: > > > If you are interested but to not have "Reg-ID", please email training @ > ripe.net and say which date you would like to be registered for. > > --- > Regards, > Evgeniy Sudyr > > On Tue, Aug 18, 2015 at 2:38 PM, Max M?hlbronner wrote: > > Hi, > > > > noob question, how can i find the RegID which is required to register for > > the webinar? (Shame on me...) > > > > I was not able to find our RegID although we are a LIR. Message says: > > "Please type a valid regid. You can find the list of members here." > > > > > > > > Best Regards > > > > > > Max M. > > > > > > > > On 18.08.2015 14:05, Vesna Manojlovic wrote: > >> > >> Dear colleagues, > >> > >> there are two more dates available for you to register for the webinar > >> "Advanced RIPE Atlas Usage", aiming to teach network operators how to > use > >> RIPE Atlas measurements for network monitoring and troubleshooting: > >> > >> 27th August & 17th September. > >> > >> > >> > https://www.ripe.net/support/training/learn-online/webinars/advanced-ripe-atlas-usage-webinar > >> > >> This is part of the series of interactive on-line learning sessions, > >> that give you the opportunity to learn and interact with trainers > >> without leaving your desk, as well as for hands-on practice, and > >> to get your questions answered by developers. > >> > >> Learn how to: > >> - Use RIPE Atlas measurements for network monitoring and troubleshooting > >> - Use API calls for measurement creation > >> - Integrate RIPE Atlas with existing monitoring systems > >> > >> Webinars start at 11:30 UTC, and take about one hour. > >> > >> Register now at: > >> https://www.ripe.net/support/training/learn-online/webinars > >> > >> Web-registration is *only* possible for LIRs (RIPE NCC members). > >> > >> If you are interested but to not have "Reg-ID", please email training @ > >> ripe.net and say which date you would like to be registered for. > >> > >> We look forward to seeing you online. > >> > >> Kind regards, > >> Vesna Manojlovic > >> RIPE NCC > >> > >> bitte unverz?glich telefonisch oder per E-Mail. > > > > > > > > -- > -- > With regards, > Eugene Sudyr > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mm at 42com.com Tue Aug 18 16:49:29 2015 From: mm at 42com.com (=?UTF-8?B?TWF4IE3DvGhsYnJvbm5lcg==?=) Date: Tue, 18 Aug 2015 16:49:29 +0200 Subject: [atlas] Next week: webinar on "Advanced RIPE Atlas Usage" In-Reply-To: References: <5582DBCC.4070906@ripe.net> <55D31F8F.8030408@ripe.net> <55D3273C.4010705@42com.com> Message-ID: <55D345F9.1040201@42com.com> Hi, thanks, i know and of course we are a LIR. I already got the RegID from Vesna (already tried the right one but did not enter lower-case...). But thanks again! BR Max M. On 18.08.2015 16:39, Evgeniy Sudyr wrote: > Max, > > Looks RIPE trainings (by original design) are available for members > (LIRs), but Vesna said at the very end of her mail: > >> If you are interested but to not have "Reg-ID", please email training @ ripe.net and say which date you would like to be registered for. > --- > Regards, > Evgeniy Sudyr > > On Tue, Aug 18, 2015 at 2:38 PM, Max M?hlbronner wrote: >> Hi, >> >> noob question, how can i find the RegID which is required to register for >> the webinar? (Shame on me...) >> >> I was not able to find our RegID although we are a LIR. Message says: >> "Please type a valid regid. You can find the list of members here." >> >> >> >> Best Regards >> >> >> Max M. >> >> >> >> On 18.08.2015 14:05, Vesna Manojlovic wrote: >>> Dear colleagues, >>> >>> there are two more dates available for you to register for the webinar >>> "Advanced RIPE Atlas Usage", aiming to teach network operators how to use >>> RIPE Atlas measurements for network monitoring and troubleshooting: >>> >>> 27th August & 17th September. >>> >>> >>> https://www.ripe.net/support/training/learn-online/webinars/advanced-ripe-atlas-usage-webinar >>> >>> This is part of the series of interactive on-line learning sessions, >>> that give you the opportunity to learn and interact with trainers >>> without leaving your desk, as well as for hands-on practice, and >>> to get your questions answered by developers. >>> >>> Learn how to: >>> - Use RIPE Atlas measurements for network monitoring and troubleshooting >>> - Use API calls for measurement creation >>> - Integrate RIPE Atlas with existing monitoring systems >>> >>> Webinars start at 11:30 UTC, and take about one hour. >>> >>> Register now at: >>> https://www.ripe.net/support/training/learn-online/webinars >>> >>> Web-registration is *only* possible for LIRs (RIPE NCC members). >>> >>> If you are interested but to not have "Reg-ID", please email training @ >>> ripe.net and say which date you would like to be registered for. >>> >>> We look forward to seeing you online. >>> >>> Kind regards, >>> Vesna Manojlovic >>> RIPE NCC >>> >>> bitte unverz?glich telefonisch oder per E-Mail. >> > > From woeber at cc.univie.ac.at Wed Aug 19 16:47:10 2015 From: woeber at cc.univie.ac.at (Wilfried Woeber) Date: Wed, 19 Aug 2015 16:47:10 +0200 Subject: [atlas] Case sensitive DNS queries from the probe In-Reply-To: <55C35242.3090102@ripe.net> References: <55B8D34E.8010604@ripe.net> <55C33A9A.5020708@cc.univie.ac.at> <55C35242.3090102@ripe.net> Message-ID: <55D496EE.50003@cc.univie.ac.at> Thanks Philip, interesting! But this is maybe just one side of the coin. For UDMs, where the target(s) are specified as FQDN, would the various interfaces preserve the case that would eventually be shipped to the stub resolver, or is this done "automatically" anyway. Apologies if I am missing something :-) Thanks, Wilfried On 2015-08-06 14:25, Philip Homburg wrote: > Hi Wilfried, > > On 2015/08/06 12:44 , Wilfried Woeber wrote: >> Is there any intelligence available about the percentage (or type) of responders >> answering with the "correct" camel case? > > I'm running measurement 1666409 which asks for 'WwW.rIpE.nEt.'. In > addition it sets the DO flag. > > Looking at a download of 'latest', I got the following results: > Total number of probes: 8267 > Total number of perfect probes: 6780 > Total number of probes with bad Qname: 320 > Total number of probes with FORMERR: 447 > Total number of probes with REFUSED: 74 > Total number of probes with SERVFAIL: 15 > Total number of probes with no answers: 5 > Total number of probes with EDNS0 in Answer: 86 > Total number of probes with no result (timeout): 609 > > So 8267 probes are active and 6780 returned the correct results for all > of their resolvers. > > The other statistics are per resolver. So a single probe may trigger > more than one error. I'm surprised by the high number of FORMERRs. > Finding EDNS0 records in the Answer section is also fascinating. > > From other statistics, we find that about 300 probes cannot perform HTTP > measurements due to DNS lookup failures. > > Philip > > From philip.homburg at ripe.net Wed Aug 19 16:58:18 2015 From: philip.homburg at ripe.net (Philip Homburg) Date: Wed, 19 Aug 2015 16:58:18 +0200 Subject: [atlas] Case sensitive DNS queries from the probe In-Reply-To: <55D496EE.50003@cc.univie.ac.at> References: <55B8D34E.8010604@ripe.net> <55C33A9A.5020708@cc.univie.ac.at> <55C35242.3090102@ripe.net> <55D496EE.50003@cc.univie.ac.at> Message-ID: <55D4998A.7080308@ripe.net> Hi Wilfried, Quick mental counting suggests that there are 3 different options: 1) if resolve-on-probe is not set, the target is resolved by the Atlas backend and the probe only gets the IP address. The (glibc) stub resolver on CentOS does not do any case mangling. 2) if resolve-on-probe is set then the probe resolves the target using the stub resolver in libevent. This stub resolver mangles the case. 3) for DNS measurements, the domain name parameter is used as is. However the target of the measurement is subject to case 1 or 2. Philip From mgalante at ripe.net Thu Aug 20 16:40:15 2015 From: mgalante at ripe.net (Michela Galante) Date: Thu, 20 Aug 2015 16:40:15 +0200 Subject: [atlas] Afilias (US, Ashburn and Los Angeles) have joined RIPE Atlas anchors Message-ID: <1BA029F3-1D0E-4EE5-88D3-51A904005054@ripe.net> Dear RIPE Atlas users, We're happy to announce that two more RIPE Atlas anchors have joined the network and are now available as targets for probe hosts conducting their own user-defined measurements. The new anchors, both hosted by Afilias in United States, are: us-qas-as393246, in Ashburn (Virginia) us-lax-as63403, in Los Angeles (California) Congratulations to Afilias for their second and third anchor online! Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards these anchors from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, RIPE Atlas Team RIPE NCC atlas at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2612 bytes Desc: not available URL: From elane at ripe.net Fri Aug 21 16:08:49 2015 From: elane at ripe.net (Eamonn Lane) Date: Fri, 21 Aug 2015 16:08:49 +0200 Subject: [atlas] : Afilias, Ashburn, VA 20147, United States has joined RIPE Atlas anchors Message-ID: <35C7D047-70DD-49F5-813D-FC9776EDDEF1@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called us-qas-as393246 and is hosted by Afilias, Ashburn, VA 20147, United States. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, RIPE Atlas Team RIPE NCC atlas at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2598 bytes Desc: not available URL: From elane at ripe.net Fri Aug 21 16:11:42 2015 From: elane at ripe.net (Eamonn Lane) Date: Fri, 21 Aug 2015 16:11:42 +0200 Subject: [atlas] Afilias, Los Angeles, CA, United States has joined RIPE Atlas anchors Message-ID: <8032800F-F55D-40AC-916C-01309FA908C0@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called us-lax-as63403 and is hosted by Los Angeles, CA, United States. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind regards, RIPE Atlas Team RIPE NCC atlas at ripe.net -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2598 bytes Desc: not available URL: From me at anuragbhatia.com Sat Aug 22 23:42:16 2015 From: me at anuragbhatia.com (Anurag Bhatia) Date: Sun, 23 Aug 2015 03:12:16 +0530 Subject: [atlas] Question about "location setting" of RIPE Atlas Message-ID: I have been hosting one of RIPE probes and recently I have switched over my ISP. Basically my previous ISP provider was regular ISP network with full L3 PoPs nearby but in my new setup I have got a point to point to a city 900km away and getting IP transit over there. Now under such case, I am "technically" customer of that network. Should I still keep my location as I have current one or better update it to that new location 900km away? The latency of course is low (as it is provisioned on fiber and hence just 20ms roundtrip) but I think it will confuse off stats if anyone considers to use this probe for any data in my region. What you all think? Can someone recommend on correct location? Thanks. -- Anurag Bhatia anuragbhatia.com PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom at hetmer.cz Sun Aug 23 00:10:48 2015 From: tom at hetmer.cz (=?UTF-8?B?VG9tw6HFoSBIZXRtZXI=?=) Date: Sun, 23 Aug 2015 00:10:48 +0200 Subject: [atlas] Question about "location setting" of RIPE Atlas Message-ID: Hi, I'd use the simplest logical interpretation and enter the actual physical location no matter if the actual interconnect is right there, 900 km away or transmitted from a satellite. Also, if you placed it to that location 900km away you wouldn't skew the results for your own town, but anyone measuring the latency there would see a +20ms difference from reality, so that doesn't improve anything. Many networks are large and complex, such as an ADSL for a whole country being connected to the net via a local MPLS network via a central point at one main location - should you use that one for all the probes in the country? Of course not, you enter wherever the endpoint is. If you'd like however, you can mention your specific configuration in the probe details. That's my personal view on this, others might differ. Regards Tom?? Hetmer 2015-08-22 23:42 GMT+02:00 Anurag Bhatia : > I have been hosting one of RIPE probes and recently I have switched over my > ISP. > > > Basically my previous ISP provider was regular ISP network with full L3 PoPs > nearby but in my new setup I have got a point to point to a city 900km away > and getting IP transit over there. > > > Now under such case, I am "technically" customer of that network. Should I > still keep my location as I have current one or better update it to that new > location 900km away? > > > The latency of course is low (as it is provisioned on fiber and hence just > 20ms roundtrip) but I think it will confuse off stats if anyone considers to > use this probe for any data in my region. > > > What you all think? Can someone recommend on correct location? > > > > Thanks. > > -- > > > Anurag Bhatia > anuragbhatia.com > > > PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 From inigo at infornografia.net Sun Aug 23 12:50:46 2015 From: inigo at infornografia.net (=?UTF-8?Q?I=C3=B1igo_Ortiz_de_Urbina?=) Date: Sun, 23 Aug 2015 12:50:46 +0200 Subject: [atlas] Question about "location setting" of RIPE Atlas In-Reply-To: References: Message-ID: On Sat, Aug 22, 2015 at 11:42 PM, Anurag Bhatia wrote: > What you all think? Can someone recommend on correct location? I for one would leave the location intact and add an additional tag (point-to-point?) to your probe. You can do so by clicking the "Edit" link under "My Probe" section. While at it, you may also consider checking the "Fibre" tag too :-) -- "If you want to go fast, go alone. If you want to go far, go together." From daniel.karrenberg at ripe.net Mon Aug 24 09:41:16 2015 From: daniel.karrenberg at ripe.net (Daniel Karrenberg) Date: Mon, 24 Aug 2015 09:41:16 +0200 Subject: [atlas] Question about "location setting" of RIPE Atlas In-Reply-To: References: Message-ID: <55DACA9C.40207@ripe.net> Anurag, thanks for the good question. Please set the location as the physical location of the probe itself. We need a common definition for this. If we all over-think and fudge this, the data will become meaningless. Also Inigo's suggestions are good ones. Daniel On 22.08.15 23:42 , Anurag Bhatia wrote: > I have been hosting one of RIPE probes and recently I have switched over > my ISP. > > > Basically my previous ISP provider was regular ISP network with full L3 > PoPs nearby but in my new setup I have got a point to point to a city > 900km away and getting IP transit over there. > > > Now under such case, I am "technically" customer of that network. Should > I still keep my location as I have current one or better update it to > that new location 900km away? > > > The latency of course is low (as it is provisioned on fiber and hence > just 20ms roundtrip) but I think it will confuse off stats if anyone > considers to use this probe for any data in my region. > > > What you all think? Can someone recommend on correct location? > > > > Thanks. > > -- > > > Anurag Bhatia > anuragbhatia.com > > > PGP Key Fingerprint: 3115 677D 2E94 B696 651B 870C C06D D524 245E 58E2 From bortzmeyer at nic.fr Tue Aug 25 10:23:55 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 25 Aug 2015 10:23:55 +0200 Subject: [atlas] X.509 certificate monitoring Message-ID: <20150825082355.GA29024@nic.fr> I do not find a lot of examples of X.509 certificate retrieving and analysis? I just committed which is useful for me when watching certificate expiration for anycasted sites (where the cert retrieved depends on the probe). Any other examples? And by the way, do not hesitate to submit your scripts to (fork and pull request, or open an issue with the attached script). From jacques at lavignotte.org Tue Aug 25 13:50:21 2015 From: jacques at lavignotte.org (Jacques Lav!gnotte.) Date: Tue, 25 Aug 2015 13:50:21 +0200 Subject: [atlas] Missing module Message-ID: <55DC567D.8000900@lavignotte.org> Hello, I am trying to run Stephane's B. resolv-name.py and I get : import RIPEAtlas ImportError: No module named RIPEAtlas I can't figure out where to get this module. Any help ? Jacques -- GnuPg : C8F5B1E3 WeUsePGP Because privacy matters http://weusepgp.info/ From bortzmeyer at nic.fr Tue Aug 25 14:04:58 2015 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 25 Aug 2015 14:04:58 +0200 Subject: [atlas] Missing module In-Reply-To: <55DC567D.8000900@lavignotte.org> References: <55DC567D.8000900@lavignotte.org> Message-ID: <20150825120458.GA25461@nic.fr> On Tue, Aug 25, 2015 at 01:50:21PM +0200, Jacques Lav!gnotte. wrote a message of 17 lines which said: > import RIPEAtlas > ImportError: No module named RIPEAtlas > > I can't figure out where to get this module. Same place :-) https://github.com/RIPE-Atlas-Community/ripe-atlas-community-contrib From jacques at lavignotte.org Wed Aug 26 00:59:34 2015 From: jacques at lavignotte.org (Jacques Lav!gnotte.) Date: Wed, 26 Aug 2015 00:59:34 +0200 Subject: [atlas] Missing module In-Reply-To: <55DC567D.8000900@lavignotte.org> References: <55DC567D.8000900@lavignotte.org> Message-ID: <55DCF356.9000708@lavignotte.org> 25/08/2015 14:04, Stephane Bortzmeyer a ?crit : > Same place > > https://github.com/RIPE-Atlas-Community/ripe-atlas-community-contrib Got it ! Maintenant : RIPEAtlas.RequestSubmissionError: Status 403, reason "{"detail":"Authentication credentials were not provided."}" J'ai une sonde chez moi et un compte mais je ne vois rien qui me les donne ces credentials ??? J. -- GnuPg : C8F5B1E3 WeUsePGP Because privacy matters http://weusepgp.info/ From alarig at grifon.fr Wed Aug 26 01:15:01 2015 From: alarig at grifon.fr (Alarig Le Lay) Date: Wed, 26 Aug 2015 01:15:01 +0200 Subject: [atlas] Missing module In-Reply-To: <55DCF356.9000708@lavignotte.org> References: <55DC567D.8000900@lavignotte.org> <55DCF356.9000708@lavignotte.org> Message-ID: <20150825231501.GH14320@drscott.swordarmor.fr> On Wed Aug 26 00:59:34 2015, Jacques Lav!gnotte. wrote: > J'ai une sonde chez moi et un compte mais je ne vois rien qui me les > donne ces credentials ??? I think that you don?t have API keys. You can get it at https://atlas.ripe.net/keys/. -- Alarig -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From lhestina at ripe.net Fri Aug 28 17:27:14 2015 From: lhestina at ripe.net (Lia Hestina) Date: Fri, 28 Aug 2015 17:27:14 +0200 Subject: [atlas] Telus (CA) has joined RIPE Atlas anchors Message-ID: <7CABFA6A-06F0-4945-8FF1-62F92A417EA9@ripe.net> Dear RIPE Atlas users, We're happy to announce that another RIPE Atlas anchor has joined the network and is now available as a target for probe hosts conducting their own user-defined measurements. The new anchor is called ca-van-as852 and it is hosted by TELUS in Vancouver, Canada. Anchoring measurements (ping, ping6, traceroute and traceroute6) are scheduled towards this anchor from all the other anchors as well as several hundred probes, providing a continual overview of regional reachability. Results of these measurements are available as raw data in JSON format, and visualised on the map and "seismograph" with many configurable features. You can access the anchoring measurements for all anchors at: https://atlas.ripe.net/anchors/list/ Learn more about RIPE Atlas anchors at: https://atlas.ripe.net/about/anchors/ Thank you for participating in RIPE Atlas! Kind Regards, RIPE Atlas Team atlas at ripe.net -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2608 bytes Desc: not available URL: