From adavies at ripe.net Wed Nov 1 09:45:40 2017 From: adavies at ripe.net (Alun Davies) Date: Wed, 1 Nov 2017 09:45:40 +0100 Subject: [atlas] New vendor for RIPE Atlas v3 anchors Message-ID: <2BD9981E-46CC-4FD0-AF85-40E3FEE6F773@ripe.net> Dear all, Meconet, the latest addition to our list of vendors for RIPE Atlas v3 anchors, is offering the new anchor hardware fully assembled with 3 years warranty. The RIPE Atlas anchor from Meconet comes in a 19? chassis with integrated power supply: https://shop.meconet.de/a/117330?language=en Whilst Meconet is currently the only one offering the device fully assembled, there are other vendors listed on the following page: https://atlas.ripe.net/get-involved/become-an-anchor-host/ Updated information on the latest generation of RIPE Atlas anchors can be found in the following RIPE Labs article: https://labs.ripe.net/Members/alun_davies/introducing-ripe-atlas-v3-anchors Best regards, Alun Davies RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tim.Chown at jisc.ac.uk Wed Nov 1 11:39:34 2017 From: Tim.Chown at jisc.ac.uk (Tim Chown) Date: Wed, 1 Nov 2017 10:39:34 +0000 Subject: [atlas] New vendor for RIPE Atlas v3 anchors In-Reply-To: <2BD9981E-46CC-4FD0-AF85-40E3FEE6F773@ripe.net> References: <2BD9981E-46CC-4FD0-AF85-40E3FEE6F773@ripe.net> Message-ID: <00F3CE89-E297-4EEE-989E-3003AC13C886@jisc.ac.uk> Hi, > On 1 Nov 2017, at 08:45, Alun Davies wrote: > > Dear all, > Meconet, the latest addition to our list of vendors for RIPE Atlas v3 anchors, is offering the new anchor hardware fully assembled with 3 years warranty. The RIPE Atlas anchor from Meconet comes in a 19? chassis with integrated power supply: > > https://shop.meconet.de/a/117330?language=en That?s pretty nice, not far short of half the price of the previous system. > Whilst Meconet is currently the only one offering the device fully assembled, there are other vendors listed on the following page: > > https://atlas.ripe.net/get-involved/become-an-anchor-host/ > > Updated information on the latest generation of RIPE Atlas anchors can be found in the following RIPE Labs article: > > https://labs.ripe.net/Members/alun_davies/introducing-ripe-atlas-v3-anchors Many thanks for the update. Best wishes, Tim From bryan at digitalocean.com Tue Nov 7 21:52:58 2017 From: bryan at digitalocean.com (Bryan Socha) Date: Tue, 7 Nov 2017 15:52:58 -0500 Subject: [atlas] New vendor for RIPE Atlas v3 anchors In-Reply-To: <2BD9981E-46CC-4FD0-AF85-40E3FEE6F773@ripe.net> References: <2BD9981E-46CC-4FD0-AF85-40E3FEE6F773@ripe.net> Message-ID: Doesn't this version support 10G in some way? Is there a vendor who is offering it with 10G or at least in a case you could add it yourself after? Bryan Socha Network Engineer bryan at digitalocean.com ________________________________ We're Hiring! | @digitalocean On Wed, Nov 1, 2017 at 4:45 AM, Alun Davies wrote: > Dear all, > > Meconet, the latest addition to our list of vendors for RIPE Atlas v3 > anchors, is offering the new anchor hardware fully assembled with 3 years > warranty. The RIPE Atlas anchor from Meconet comes in a 19? chassis with > integrated power supply: > > https://shop.meconet.de/a/117330?language=en > > Whilst Meconet is currently the only one offering the device fully > assembled, there are other vendors listed on the following page: > > https://atlas.ripe.net/get-involved/become-an-anchor-host/ > > Updated information on the latest generation of RIPE Atlas anchors can be > found in the following RIPE Labs article: > > https://labs.ripe.net/Members/alun_davies/introducing-ripe-atlas-v3-anchors > > Best regards, > Alun Davies > RIPE NCC From jared at puck.nether.net Fri Nov 10 03:31:57 2017 From: jared at puck.nether.net (Jared Mauch) Date: Thu, 9 Nov 2017 21:31:57 -0500 Subject: [atlas] Odd queries from probe Message-ID: While doing some debugging of my home network, I noticed some odd queries from the probe, namely this one: 02:28:36.921622 IP6 fe80::a2f3:c1ff:fec4:479f.51123 > 2001:558:feed::2.53: 23808+ A? 12920.atlas.ripe.net.b61065696c194ac3. (55) Is this some captive portal/wildcarding detection, or perhaps some other software issue? curious, - Jared From robert at ripe.net Fri Nov 10 09:51:53 2017 From: robert at ripe.net (Robert Kisteleki) Date: Fri, 10 Nov 2017 09:51:53 +0100 Subject: [atlas] Odd queries from probe In-Reply-To: References: Message-ID: <66feca47-20a2-1110-5076-df84d75cf9e7@ripe.net> On 2017-11-10 03:31, Jared Mauch wrote: > While doing some debugging of my home network, I noticed some odd queries from the probe, namely this one: > > 02:28:36.921622 IP6 fe80::a2f3:c1ff:fec4:479f.51123 > 2001:558:feed::2.53: 23808+ A? 12920.atlas.ripe.net.b61065696c194ac3. (55) > > Is this some captive portal/wildcarding detection, or perhaps some other software issue? > > curious, > > - Jared Hi, This offers explanation about the queries you see: https://labs.ripe.net/Members/chris_amin/new-ripe-atlas-root-zone-dns-measurements Regards, Robert From me at tom.glass Sun Nov 12 12:47:54 2017 From: me at tom.glass (Tom Glass) Date: Sun, 12 Nov 2017 11:47:54 +0000 Subject: [atlas] Atlas Measurements Message-ID: <2109-5a083500-1-607edd80@124404955> Hello all, Hope you are having a great weekend. I just stopped by to ask if you guys would know where/if I can add new probes to an existing measurement. A new probe has appeared in the area we are monitoring and I was hoping there was a way of adding it without recreating the measurement?? Cheers, all, Tom -------------- next part -------------- An HTML attachment was scrubbed... URL: From vnaumov at ripe.net Mon Nov 13 08:03:37 2017 From: vnaumov at ripe.net (Viktor Naumov) Date: Mon, 13 Nov 2017 08:03:37 +0100 Subject: [atlas] Atlas Measurements In-Reply-To: <2109-5a083500-1-607edd80@124404955> References: <2109-5a083500-1-607edd80@124404955> Message-ID: Hi Tom, You can do it only using API at the moment. https://atlas.ripe.net/docs/api/v2/manual/ The endpoint is https://atlas.ripe.net/api/v2/measurements//participation-request/ wbr /vty On 11/12/17 12:47 PM, Tom Glass wrote: > Hello all, > > Hope you are having a great weekend. I just stopped by to ask if you > guys would know where/if I can add new probes to an existing > measurement. A new probe has appeared in the area we are monitoring > and I was hoping there was a way of adding it without recreating the > measurement? > > Cheers, all, > Tom From bortzmeyer at nic.fr Mon Nov 13 10:10:25 2017 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Mon, 13 Nov 2017 17:10:25 +0800 Subject: [atlas] Recent TLS supported by probes? Message-ID: <20171113091025.GA27784@laperouse.bortzmeyer.org> I cannot get the certificate for (measurement #10174881): "alert" is "{u'description': 40, u'level': 2}". It works with other, more "mainstream", HTTPS sites (see #10174883). I suspect this is because the probes don't handle the recent TLS stuff. Can anyone confirm or infirm? From philip.homburg at ripe.net Mon Nov 13 11:15:09 2017 From: philip.homburg at ripe.net (Philip Homburg) Date: Mon, 13 Nov 2017 11:15:09 +0100 Subject: [atlas] Recent TLS supported by probes? In-Reply-To: <20171113091025.GA27784@laperouse.bortzmeyer.org> References: <20171113091025.GA27784@laperouse.bortzmeyer.org> Message-ID: Hi Stephane, On 2017/11/13 10:10 , Stephane Bortzmeyer wrote: > I cannot get the certificate for > (measurement #10174881): "alert" is "{u'description': 40, u'level': > 2}". > > It works with other, more "mainstream", HTTPS sites (see #10174883). I > suspect this is because the probes don't handle the recent TLS > stuff. Can anyone confirm or infirm? The only issue I'm aware of is SNI. We added that in 4780. SNI or no SNI doesn't seem to make a difference to dns-resolver.yeti.eu.org Hmm, looking at the list of ciphers that the measurement code sends, I can see how it can fail if somebody applies a rather script security policy. I'll create a ticket to add improved ciphers. Philip From mir at ripe.net Mon Nov 13 16:12:56 2017 From: mir at ripe.net (Mirjam Kuehne) Date: Mon, 13 Nov 2017 16:12:56 +0100 Subject: [atlas] New on RIPE Labs: Verfploeter: Broad and Load-aware Anycast Mapping In-Reply-To: References: Message-ID: <8c197f24-17fd-250e-2190-261de831a907@ripe.net> Dear colleagues, Here is a summary of a research paper written by Wes Hardaker, Wouter de Vries and Ricardo Schmidt: Verfploeter: Broad and Load-aware Anycast Mapping IP anycast provides DNS operators and CDNs with automatic fail-over and reduced latency by breaking the Internet into catchments, each served by a different anycast site. https://labs.ripe.net/Members/wouter_de_vries/verfploeter-broad-and-load-aware-anycast-mapping Kind regards, Mirjam K?hne RIPE NCC From cs at fnx.li Mon Nov 13 16:50:03 2017 From: cs at fnx.li (=?UTF-8?Q?Christian_Schr=c3=b6tter?=) Date: Mon, 13 Nov 2017 16:50:03 +0100 Subject: [atlas] =?utf-8?q?Probe_disconnected_=E2=80=93_cold_reboot_requir?= =?utf-8?q?ed_=28ctr-ams08=29?= Message-ID: Hello Atlas-Users! Do you have any problems with your probes today? Mine disconnected two times in the last ~15 hours and never came back online. Internet is stable and SD-card looks ok. I had to force a cold restart to get it back online. Strange thing, it's the first time in two years. Old uptime was 99 days... :-/ -- With kind regards, Christian Schr?tter From bortzmeyer at nic.fr Tue Nov 14 01:57:43 2017 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Tue, 14 Nov 2017 08:57:43 +0800 Subject: [atlas] A Go library to talk to RIPE Atlas Message-ID: <20171114005743.GA19079@laperouse.bortzmeyer.org> https://blog.keltia.net/2017/11/13/ripe-atlas-is-usable-dot-dot-dot/ [Still a bit rough...] From eject.in.ua at gmail.com Tue Nov 14 17:06:49 2017 From: eject.in.ua at gmail.com (Evgeniy Sudyr) Date: Tue, 14 Nov 2017 17:06:49 +0100 Subject: [atlas] Running RIPE probe VM Message-ID: Hello All, I'm interesting for running RIPE probe on VM or Docker container. Any chance to get this idea real? -- With regards, Eugene Sudyr From me at tom.glass Tue Nov 14 17:14:09 2017 From: me at tom.glass (Tom Glass) Date: Tue, 14 Nov 2017 16:14:09 +0000 Subject: [atlas] Running RIPE probe VM In-Reply-To: References: Message-ID: Hello, Atlas did a good review on this https://labs.ripe.net/Members/suzanne_taylor_muzzin/exploring-the-idea-of-ripe-atlas-virtual-probes I agree virtual probes save costs but there is other risks as highlighted, you can in theory convert the software on the probe to a VM however it would likely involve dismantling the probe and I'm pretty sure RIPE Atlas would be happy. For each virtual probe you would need a physical so pretty pointless. Luckily they don't use a lot of power or space and easily fit in racks, cupboards or even down the back of your sofa depending on where your router is. Anyway hope this helps. Regards, Tom ?Sent from Blue ? On 14 Nov 2017, 16:07, at 16:07, Evgeniy Sudyr wrote: >Hello All, > >I'm interesting for running RIPE probe on VM or Docker container. Any >chance to get this idea real? > >-- >With regards, >Eugene Sudyr -------------- next part -------------- An HTML attachment was scrubbed... URL: From me at tom.glass Tue Nov 14 17:16:02 2017 From: me at tom.glass (Tom Glass) Date: Tue, 14 Nov 2017 16:16:02 +0000 Subject: [atlas] Running RIPE probe VM In-Reply-To: References: Message-ID: <56bce31b-edf5-476d-900d-20b8efb24fb7@tom.glass> **wouldn't be happy ?Sent from Blue ? On 14 Nov 2017, 16:15, at 16:15, Tom Glass wrote: >Hello, > >Atlas did a good review on this >https://labs.ripe.net/Members/suzanne_taylor_muzzin/exploring-the-idea-of-ripe-atlas-virtual-probes > >I agree virtual probes save costs but there is other risks as >highlighted, you can in theory convert the software on the probe to a >VM however it would likely involve dismantling the probe and I'm pretty >sure RIPE Atlas would be happy. For each virtual probe you would need a >physical so pretty pointless. > >Luckily they don't use a lot of power or space and easily fit in racks, >cupboards or even down the back of your sofa depending on where your >router is. > >Anyway hope this helps. > >Regards, >Tom > >?Sent from Blue ? > >On 14 Nov 2017, 16:07, at 16:07, Evgeniy Sudyr >wrote: >>Hello All, >> >>I'm interesting for running RIPE probe on VM or Docker container. Any >>chance to get this idea real? >> >>-- >>With regards, >>Eugene Sudyr -------------- next part -------------- An HTML attachment was scrubbed... URL: From cpetrie at ripe.net Wed Nov 15 04:32:07 2017 From: cpetrie at ripe.net (Colin Petrie) Date: Wed, 15 Nov 2017 11:32:07 +0800 Subject: [atlas] New vendor for RIPE Atlas v3 anchors In-Reply-To: References: <2BD9981E-46CC-4FD0-AF85-40E3FEE6F773@ripe.net> Message-ID: <3ba9d38d-269d-e3fc-a13a-88af50962feb@ripe.net> On 08/11/2017 04:52, Bryan Socha wrote: > Doesn't this version support 10G in some way? Is there a vendor who > is offering it with 10G or at least in a case you could add it > yourself after? Hi Bryan, Quick answer: no, it doesn't support 10G. In our different board evaluations, we found that requiring support for 10G conflicts with the desire to make the box cheaper and easily available. Getting a PCIe slot on cheap embedded boards is not common - they usually support miniPCIe instead. Longer answer: we did look, though :) There are two options: 1) the APU3a2/4 models have a PCIe slot option, but you'd need to order it as a custom board option, and get a case made that supports it. We could not find any existing cases that would support an extra card, or any current vendors who sell the board with the PCIe slot option. 2) It might be possible to use a miniPCIe-to-PCIe extender, to borrow a 1x PCIe lane from one of the miniPCIe slots and present it on a full-size PCIe card slot. We actually did try this, but could not figure out how to make it work. And you'd still need a case that supports a card. In the end we decided it was not wothwhile, since we wanted a model that was easily available worldwide from multiple suppliers. Kind Regards, Colin -- Colin Petrie Systems Engineer RIPE NCC From mir at ripe.net Wed Nov 15 15:53:23 2017 From: mir at ripe.net (Mirjam Kuehne) Date: Wed, 15 Nov 2017 15:53:23 +0100 Subject: [atlas] New on RIPE Labs: RIPE Atlas on the Go Message-ID: Dear colleagues, Ollivier Robert just released a tool that provides access to the RIPE Atlas API in Go. Please find more details on RIPE Labs: https://labs.ripe.net/Members/ollivier_robert/ripe-atlas-on-the-go Kind regards, Mirjam K?hne RIPE NCC From eduardo.duarte at dns.pt Wed Nov 22 19:27:42 2017 From: eduardo.duarte at dns.pt (Eduardo Duarte) Date: Wed, 22 Nov 2017 18:27:42 +0000 Subject: [atlas] Trying to measure Quad9 latency Message-ID: Hi all, After the recent launch of the Quad9 service I try to discover if it had a best response time them my actual resolver, that is google public DNS. To do this I launch a comparing measurement using atlas that would run during one day to the same address from the probes in my ISP. The address that I was trying has a very high TTL so I was expecting to always hit the cache of the servers and them get a good comparison base. I know that there are other factors involve in server response time but to my home connection I fill that this where enough. When I got the results from the measurement they were not what I expected.... The measurements to Quad9 had high value of REFUSAL. Does any one as a clue why??? The measurement result is available at https://atlas.ripe.net/measurements/10269508 Best regards, -- Eduardo Duarte Gest?o e Desenvolvimento de Projetos l Project Development Management ? *DNS.PT* Rua Latino Coelho, n.? 13, 5.? piso | 1050-132 Lisboa | Portugal Tel: (+351) 211 308 200??Fax: (+351) 211 312 720 dns.pt | dnssec.pt | 3em1.pt | facebook.com/dns.pt | pt.linkedin.com/in/dnspt ? Aviso de Confidencialidade/Disclaimer: Este e-mail foi escrito de acordo com o novo acordo ortogr?fico. Esta mensagem ? exclusivamente destinada ao seu destinat?rio, podendo conter informa??o CONFIDENCIAL, cuja divulga??o est? expressamente vedada nos termos da lei. Caso tenha recepcionado indevidamente esta mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta via devendo apagar o seu conte?do de imediato. This message is intended exclusively for its addressee. It may contain CONFIDENTIAL information protected by law. If this message has been received by error, please notify us via e-mail and delete it immediately. [ Antes de imprimir esta mensagem pense no ambiente. Before printing this message, think about environment ] -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4634 bytes Desc: S/MIME Cryptographic Signature URL: From bortzmeyer at nic.fr Wed Nov 22 20:05:15 2017 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 22 Nov 2017 20:05:15 +0100 Subject: [atlas] Trying to measure Quad9 latency In-Reply-To: References: Message-ID: <20171122190515.tuquthog3qt3pyn2@nic.fr> On Wed, Nov 22, 2017 at 06:27:42PM +0000, Eduardo Duarte wrote a message of 289 lines which said: > When I got the results from the measurement they were not what I > expected.... The measurements to Quad9 had high value of REFUSAL. You did not set the RD (Recursion Desired) bit. Most resolvers refuse these queries, to avoid cache snooping. Compare with #10290443, which have: Recursion desired True From baptiste.jonglez at imag.fr Thu Nov 23 00:14:36 2017 From: baptiste.jonglez at imag.fr (Baptiste Jonglez) Date: Thu, 23 Nov 2017 00:14:36 +0100 Subject: [atlas] Trying to measure Quad9 latency In-Reply-To: References: Message-ID: <20171122231436.GB11585@imag.fr> Hi, On 22-11-17, Eduardo Duarte wrote: > Hi all, > > After the recent launch of the Quad9 service I try to discover if it had > a best response time them my actual resolver, that is google public DNS. > > To do this I launch a comparing measurement using atlas that would run > during one day to the same address from the probes in my ISP. > The address that I was trying has a very high TTL so I was expecting to > always hit the cache of the servers and them get a good comparison base. > I know that there are other factors involve in server response time but > to my home connection I fill that this where enough. Instead of asking for a regular name, you can query a special name like "version.bind" in the CHAOS class. These queries are always answered directly, so it simulates a 100% cache hit and allows you to measure the RTT towards a resolver. To test with dig: $ dig @9.9.9.9 CH version.bind TXT See https://atlas.ripe.net/measurements/9740262/ for a real measurement using this technique. Baptiste > > When I got the results from the measurement they were not what I > expected.... The measurements to Quad9 had high value of REFUSAL. > > Does any one as a clue why??? > > The measurement result is available at > https://atlas.ripe.net/measurements/10269508 > > Best regards, -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From eduardo.duarte at dns.pt Thu Nov 23 00:54:42 2017 From: eduardo.duarte at dns.pt (Eduardo Duarte) Date: Wed, 22 Nov 2017 23:54:42 +0000 Subject: [atlas] Trying to measure Quad9 latency In-Reply-To: <20171122231436.GB11585@imag.fr> References: <20171122231436.GB11585@imag.fr> Message-ID: <9769bcdf-b7e8-4b4f-e121-5341bfbac832@dns.pt> Hi! Thank you for the pointers Stephane and Baptiste! Already running new measures! Best regards, Eduardo Duarte Gest?o e Desenvolvimento de Projetos l Project Development Management ? *DNS.PT* Rua Latino Coelho, n.? 13, 5.? piso | 1050-132 Lisboa | Portugal Tel: (+351) 211 308 200??Fax: (+351) 211 312 720 dns.pt | dnssec.pt | 3em1.pt | facebook.com/dns.pt | pt.linkedin.com/in/dnspt ? Aviso de Confidencialidade/Disclaimer: Este e-mail foi escrito de acordo com o novo acordo ortogr?fico. Esta mensagem ? exclusivamente destinada ao seu destinat?rio, podendo conter informa??o CONFIDENCIAL, cuja divulga??o est? expressamente vedada nos termos da lei. Caso tenha recepcionado indevidamente esta mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta via devendo apagar o seu conte?do de imediato. This message is intended exclusively for its addressee. It may contain CONFIDENTIAL information protected by law. If this message has been received by error, please notify us via e-mail and delete it immediately. [ Antes de imprimir esta mensagem pense no ambiente. Before printing this message, think about environment ] Baptiste Jonglez wrote on 22-11-2017 23:14: > Hi, > > On 22-11-17, Eduardo Duarte wrote: >> Hi all, >> >> After the recent launch of the Quad9 service I try to discover if it had >> a best response time them my actual resolver, that is google public DNS. >> >> To do this I launch a comparing measurement using atlas that would run >> during one day to the same address from the probes in my ISP. >> The address that I was trying has a very high TTL so I was expecting to >> always hit the cache of the servers and them get a good comparison base. >> I know that there are other factors involve in server response time but >> to my home connection I fill that this where enough. > Instead of asking for a regular name, you can query a special name like > "version.bind" in the CHAOS class. These queries are always answered > directly, so it simulates a 100% cache hit and allows you to measure the > RTT towards a resolver. > > To test with dig: > > $ dig @9.9.9.9 CH version.bind TXT > > See https://atlas.ripe.net/measurements/9740262/ for a real measurement > using this technique. > > Baptiste > >> When I got the results from the measurement they were not what I >> expected.... The measurements to Quad9 had high value of REFUSAL. >> >> Does any one as a clue why??? >> >> The measurement result is available at >> https://atlas.ripe.net/measurements/10269508 >> >> Best regards, > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signature URL: From jared at puck.nether.net Thu Nov 23 02:23:48 2017 From: jared at puck.nether.net (Jared Mauch) Date: Wed, 22 Nov 2017 20:23:48 -0500 Subject: [atlas] Trying to measure Quad9 latency In-Reply-To: <20171122190515.tuquthog3qt3pyn2@nic.fr> References: <20171122190515.tuquthog3qt3pyn2@nic.fr> Message-ID: > On Nov 22, 2017, at 2:05 PM, Stephane Bortzmeyer wrote: > > On Wed, Nov 22, 2017 at 06:27:42PM +0000, > Eduardo Duarte wrote > a message of 289 lines which said: > >> When I got the results from the measurement they were not what I >> expected.... The measurements to Quad9 had high value of REFUSAL. > > You did not set the RD (Recursion Desired) bit. Most resolvers refuse > these queries, to avoid cache snooping. > > Compare with #10290443, which have: > > Recursion desired True I also created this measurement, which is a ping one to measure latency to identify what countries receive a poor response. https://atlas.ripe.net/measurements/10291137/#!probes - jared From michael.meier at fau.de Thu Nov 23 09:56:02 2017 From: michael.meier at fau.de (Michael Meier) Date: Thu, 23 Nov 2017 09:56:02 +0100 Subject: [atlas] Trying to measure Quad9 latency In-Reply-To: References: <20171122190515.tuquthog3qt3pyn2@nic.fr> Message-ID: <3e083c24-2f21-58ce-cf4c-01c1dd07bd8e@fau.de> On 11/23/2017 02:23 AM, Jared Mauch wrote: > I also created this measurement, which is a ping one to measure latency to identify what countries receive a poor response. > https://atlas.ripe.net/measurements/10291137/#!probes All those measurements will only show part of the story though: Quad9 seem to do some _extremely_ weird nonsense. We were measuring ICMP-latency just from different machines on the same subnet and saw _huge_ differences in the responses: > rtt min/avg/max/mdev = 15.088/15.202/15.366/0.155 ms > rtt min/avg/max/mdev = 4.066/4.134/4.265/0.106 ms Those times are reproducible, a machine will always get the same 15 or 10 or 4 ms ping. So their anycasted 9.9.9.9 seems to internally redirect queries based on source-IP-hash, and if you're unlucky, they redirect you to a server at the other end of the continent, that has a latency that is worse than if you used a DNS in another european country. What this means for your measurement is that if your probes IP changed it might suddenly get a response time that is worse by a factor, even if it was still on the exact same network. -- Michael Meier, Zentrale Systeme Friedrich-Alexander-Universitaet Erlangen-Nuernberg Regionales Rechenzentrum Erlangen Martensstrasse 1, 91058 Erlangen, Germany Tel.: +49 9131 85-28973, Fax: +49 9131 302941 michael.meier at fau.de www.rrze.fau.de From BECHA at ripe.net Thu Nov 23 11:13:04 2017 From: BECHA at ripe.net (Vesna Manojlovic) Date: Thu, 23 Nov 2017 11:13:04 +0100 Subject: [atlas] Trying to measure Quad9 latency In-Reply-To: <9769bcdf-b7e8-4b4f-e121-5341bfbac832@dns.pt> References: <20171122231436.GB11585@imag.fr> <9769bcdf-b7e8-4b4f-e121-5341bfbac832@dns.pt> Message-ID: <52c195e9-848c-585c-5325-cc9be32aafc9@ripe.net> Hi all, this is all very interesting, and I'd appreciate it if one or more of you would like to share your findings with the rest of the community - for example, by describing your method & conclusions in the RIPE Labs article. Thanks, Vesna On 23/11/2017 00:54, Eduardo Duarte wrote: > Hi! > > Thank you for the pointers Stephane and Baptiste! Already running new > measures! > > Best regards, > Eduardo Duarte -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: OpenPGP digital signature URL: From bortzmeyer at nic.fr Thu Nov 23 17:31:53 2017 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Thu, 23 Nov 2017 17:31:53 +0100 Subject: [atlas] Trying to measure Quad9 latency In-Reply-To: <3e083c24-2f21-58ce-cf4c-01c1dd07bd8e@fau.de> References: <20171122190515.tuquthog3qt3pyn2@nic.fr> <3e083c24-2f21-58ce-cf4c-01c1dd07bd8e@fau.de> Message-ID: <20171123163153.GA25963@laperouse.bortzmeyer.org> On Thu, Nov 23, 2017 at 09:56:02AM +0100, Michael Meier wrote a message of 29 lines which said: > Quad9 seem to do some _extremely_ weird nonsense. > We were measuring ICMP-latency just from different machines on the same > subnet and saw _huge_ differences in the responses: Well, a DNS server does not HAVE TO handle ICMP like you want/expect. If you want the RTT of a DNS server, send it DNS requests. From dikshie at gmail.com Sat Nov 25 06:12:06 2017 From: dikshie at gmail.com (dikshie) Date: Sat, 25 Nov 2017 14:12:06 +0900 Subject: [atlas] dig +trace equivalency Message-ID: Hi, I use to use +trace option in dig command. Is there any same function equivalency in Atlas's DNS measurement tool? Thank you in advance. -- -dikshie- From adavies at ripe.net Mon Nov 27 09:39:00 2017 From: adavies at ripe.net (Alun Davies) Date: Mon, 27 Nov 2017 09:39:00 +0100 Subject: [atlas] New on RIPE Labs: Last sponsored RIPE Atlas anchors for 2017 Message-ID: <19256069-4833-4295-B3F6-BCB9703BC91D@ripe.net> Dear colleagues, New on RIPE Labs, read all about the last phase of the RIPE NCC?s 2017 campaign to sponsor fifteen RIPE Atlas anchors: https://labs.ripe.net/Members/alun_davies/last-sponsored-ripe-atlas-anchors-for-2017 Kind regards, Alun Davies RIPE NCC -------------- next part -------------- An HTML attachment was scrubbed... URL: From enrico.ardizzoni at unife.it Tue Nov 28 22:57:25 2017 From: enrico.ardizzoni at unife.it (Enrico Ardizzoni) Date: Tue, 28 Nov 2017 22:57:25 +0100 Subject: [atlas] Trying to measure Quad9 latency In-Reply-To: <3e083c24-2f21-58ce-cf4c-01c1dd07bd8e@fau.de> References: <20171122190515.tuquthog3qt3pyn2@nic.fr> <3e083c24-2f21-58ce-cf4c-01c1dd07bd8e@fau.de> Message-ID: 2017-11-23 9:56 GMT+01:00 Michael Meier : > > Those times are reproducible, a machine will always get the same 15 or > 10 or 4 ms ping. So their anycasted 9.9.9.9 seems to internally redirect > queries based on source-IP-hash, and if you're unlucky, they redirect > you to a server at the other end of the continent, that has a latency > that is worse than if you used a DNS in another european country. Hi All, I think Quad9 uses round robin dns with server pools (3?) behind 9.9.9.9 anycast address: My findigs: $ for i in $(seq 0 9); do echo -n "$i "; dig +short @9.9.9.9 hostname.bind txt CH; sleep 3; done 0 "res300.ams.rrdns.pch.net" 1 "res300.ams.rrdns.pch.net" 2 "res100.ams.rrdns.pch.net" 3 "res200.ams.rrdns.pch.net" 4 "res200.ams.rrdns.pch.net" 5 "res200.ams.rrdns.pch.net" 6 "res300.ams.rrdns.pch.net" 7 "res200.ams.rrdns.pch.net" 8 "res300.ams.rrdns.pch.net" 9 "res300.ams.rrdns.pch.net" ... Quand9 dns server are not created equal: $ for i in $(seq 0 9); do echo -n "$i "; dig +short @9.9.9.9 version.bind txt CH; sleep 3; done 0 "Q9-U-5.0" 1 "Q9-P-5.0" 2 "Q9-U-5.0" 3 "Q9-P-5.0" 4 "Q9-P-5.0" 5 "Q9-U-5.0" 6 "Q9-P-5.0" 7 "Q9-P-5.0" 8 "Q9-P-5.0" 9 "Q9-P-5.0" E. -- | ENRICO ARDIZZONI | Responsabile Ufficio Reti e Sistemi | Universit? degli Studi di Ferrara -------------- next part -------------- An HTML attachment was scrubbed... URL: From giovane.moura at sidn.nl Wed Nov 29 07:57:24 2017 From: giovane.moura at sidn.nl (Giovane C. M. Moura) Date: Wed, 29 Nov 2017 07:57:24 +0100 Subject: [atlas] Trying to measure Quad9 latency In-Reply-To: References: <20171122190515.tuquthog3qt3pyn2@nic.fr> <3e083c24-2f21-58ce-cf4c-01c1dd07bd8e@fau.de> Message-ID: Hi, I think there may be some confusion here. Let me try to clarify a bit. * For RTT measurements, use DNS queries (ICMP may get lower priority). > I think Quad9 uses round robin dns with server pools (3?) behind 9.9.9.9 > anycast address:? > > My findigs:? > > $ for i in $(seq 0 9); do echo -n "$i "; dig +short @9.9.9.9 > hostname.bind txt CH; sleep 3; done > > ?0 "res300.ams.rrdns.pch.net " > ?1 "res300.ams.rrdns.pch.net " > ?2 "res100.ams.rrdns.pch.net " > ?3 "res200.ams.rrdns.pch.net " > ?4 "res200.ams.rrdns.pch.net " > ?5 "res200.ams.rrdns.pch.net " > ?6 "res300.ams.rrdns.pch.net " > ?7 "res200.ams.rrdns.pch.net " > ?8 "res300.ams.rrdns.pch.net " > ?9 "res300.ams.rrdns.pch.net " Typically anycast services are build as in Figure 1[1]: a anycast service (such as Quad9) is distributed across sites. In your example, the site is AMS. On each site, they may use a load balancer that sends the queries (section 3.5 on [1]) to individual servers (res100, res200, and res300 in this case). How, from your measurements, you reach AMS all the time. You can not control for that, because that is what BGP does: matches you the "closest" site (closest meaning in terms of BGP distance between you and quad9). If you want to see other anycast sites from Quad9, you'll need to measure from other vantage points (using Atlas for example). And anycast is quite stable during normal operations[2]: once you reach a site, you'll tend to stick to it -- unless there's a DDoS or routing manipulations, as in [1]. > ... Quand9? dns server are not created equal: > > $ for i in $(seq 0 9); do echo -n "$i "; dig +short @9.9.9.9 > version.bind txt CH; sleep 3; done > Diversity of version , maybe. For resiliency. /giovane [1] https://www.isi.edu/~johnh/PAPERS/Moura16b.pdf [2] https://www.isi.edu/%7ejohnh/PAPERS/Wei17b.pdf From bortzmeyer at nic.fr Wed Nov 29 08:27:21 2017 From: bortzmeyer at nic.fr (Stephane Bortzmeyer) Date: Wed, 29 Nov 2017 08:27:21 +0100 Subject: [atlas] dig +trace equivalency In-Reply-To: References: Message-ID: <20171129072721.axtgh544ybvz2id2@nic.fr> On Sat, Nov 25, 2017 at 02:12:06PM +0900, dikshie wrote a message of 11 lines which said: > I use to use +trace option in dig command. > Is there any same function equivalency in Atlas's DNS measurement tool? dig +trace is not very reliable, and does not work with all resolvers. And, no, I don't think there is an equivalent for the Atlas probes. It would require some resolver-like logic in the probe. From shane at time-travellers.org Wed Nov 29 09:24:00 2017 From: shane at time-travellers.org (Shane Kerr) Date: Wed, 29 Nov 2017 08:24:00 +0000 Subject: [atlas] dig +trace equivalency In-Reply-To: <20171129072721.axtgh544ybvz2id2@nic.fr> References: <20171129072721.axtgh544ybvz2id2@nic.fr> Message-ID: All, Stephane Bortzmeyer: > On Sat, Nov 25, 2017 at 02:12:06PM +0900, > dikshie wrote > a message of 11 lines which said: > >> I use to use +trace option in dig command. >> Is there any same function equivalency in Atlas's DNS measurement tool? > > dig +trace is not very reliable, and does not work with all > resolvers. And, no, I don't think there is an equivalent for the Atlas > probes. It would require some resolver-like logic in the probe. It is in principle possible to simulate resolver-like logic without updating the probe. In fact, I worked on a team to do just that at a RIPE Atlas Hackathon a couple years ago. You can see the results on GitHub here: https://github.com/shane-kerr/ripe-atlas-shrugd This was just a hack, but the technique should be usable to do something similar to "dig +trace". Cheers, -- Shane From dikshie at gmail.com Wed Nov 29 10:14:46 2017 From: dikshie at gmail.com (dikshie) Date: Wed, 29 Nov 2017 18:14:46 +0900 Subject: [atlas] dig +trace equivalency In-Reply-To: <20171129072721.axtgh544ybvz2id2@nic.fr> References: <20171129072721.axtgh544ybvz2id2@nic.fr> Message-ID: Hi, On Wed, Nov 29, 2017 at 4:27 PM, Stephane Bortzmeyer wrote: > > dig +trace is not very reliable, and does not work with all > resolvers. And, no, I don't think there is an equivalent for the Atlas > probes. It would require some resolver-like logic in the probe. I see. Previously, I thought using nsid is enough but I found nsid information from my target dns servers are not reliable. There is no way for me to identify the servers. (looks like the dns server operator must fix the nsid text). Best Regards, -- -dikshie- From dikshie at gmail.com Wed Nov 29 10:16:52 2017 From: dikshie at gmail.com (dikshie) Date: Wed, 29 Nov 2017 18:16:52 +0900 Subject: [atlas] dig +trace equivalency In-Reply-To: References: <20171129072721.axtgh544ybvz2id2@nic.fr> Message-ID: Hi, On Wed, Nov 29, 2017 at 5:24 PM, Shane Kerr wrote: > > It is in principle possible to simulate resolver-like logic without > updating the probe. In fact, I worked on a team to do just that at a > RIPE Atlas Hackathon a couple years ago. You can see the results on > GitHub here: > > https://github.com/shane-kerr/ripe-atlas-shrugd > > This was just a hack, but the technique should be usable to do something > similar to "dig +trace". Thank you for the pointer to your hackathon project. I will take a look later this weekend. Best Regards, Dikshie From mail at timwattenberg.de Thu Nov 30 20:27:53 2017 From: mail at timwattenberg.de (Tim Wattenberg) Date: Thu, 30 Nov 2017 20:27:53 +0100 Subject: [atlas] Effect of "Resolve on Probe"-option Message-ID: <531ABB2A-F7CD-4482-A3F7-9C8EF9C5E0DF@timwattenberg.de> Hi everyone, I think I don?t quite understand the effect of the ?Resolve on Probe? option when creating a measurement. The form says it forces the probe to do DNS resolution, the API reference says that it indicates that a name should be resolved (using DNS) on the probe otherwise it will be resolved on the RIPE Atlas servers. Could someone explain what this means for example if I have a simple measurement for querying the A record of a given domain via the probe?s resolvers? Thanks, Tim