- ripe-atlas - mailman.ripe.net

Support for arbitrary DNS queries
by Shumon Huque 26 Dec '15

26 Dec '15

I'd like to request the ability to have RIPE Atlas probes be able to issue DNS queries for arbitrary record types, and have that capability exposed in the API. I'm particularly interested in newer DANE record types like TLSA, OPENPGPKEY, SMIMEA, etc but a general purpose mechanism would be useful. Is this feasible? Are others interested in this capability? Thanks! Shumon Huque

11 19

13 new zones added to DNSMON
by Vesna Manojlovic 22 Dec '15

22 Dec '15

2 2

DNS measurement failed
by Maciej Andziński 16 Dec '15

16 Dec '15

Hi, Since yesterday I've been encountering a problem, many of the DNS measurements end with "failed" status. It happens for every measurement that tries to query 8.8.8.8, 8.8.4.4 or when using "Use the Probe's Resolver(s)" feature. However, everything works fine when querying a-dns.pl (194.181.87.156) server. Sample measurements: 3082732 3083505 3083581 Do you observe any issues related to the lack of available probes / exceeded limits? Many greetings, Maciej Andziński, NASK

3 4

Number of packets now ignored for ICMP tests?
by Stephane Bortzmeyer 16 Dec '15

16 Dec '15

I asked just one packet: {'definitions': [{'description': 'Ping 2001:67c:217c:6::2 from AS #3215', 'af': 6, 'packets': 1, 'type': 'ping', 'is_oneoff': True, 'target': '2001:67c:217c:6::2'}], 'probes': [{'requested': 500, 'type': 'asn', 'value': '3215', 'tags': {'include': ['system-ipv6-works']}}]} But, for the nine probes that were selected, I got 27 tests, which is the default of 3 packets per probe. Strange. Measurement #3083491

2 2

[request] AD bit in DNS query
by Maciej Andziński 15 Dec '15

15 Dec '15

Hi, Apropos of the discussion about arbitrary QTYPE in DNS measurement, I would like to make a request for another small improvement. It would be nice if a probe had the ability to send a DNS query with AD bit set. Such query would be useful in some cases (for instance when using "Use the Probe's Resolver(s)" feature) and would reduce data volume. According to RFC6840 section 5.7: 5.7. Setting the AD Bit on Queries The semantics of the Authentic Data (AD) bit in the query were previously undefined. Section 4.6 of [RFC4035] instructed resolvers to always clear the AD bit when composing queries. This document defines setting the AD bit in a query as a signal indicating that the requester understands and is interested in the value of the AD bit in the response. This allows a requester to indicate that it understands the AD bit without also requesting DNSSEC data via the DO bit. Many greetings, Maciej Andziński, NASK

1 0

more than 10 concurrent measurements to the same target
by Klaus Darilion 12 Dec '15

12 Dec '15

Hi! When scheduling checks I often get the error: "We do not allow more than 10 concurrent measurements to the same target." Imo this is not correct. Yes, I do schedule more then 10 measurements to the same target, but they are not concurrent. They are sequential - one ofter the other. Thus, it would be great if this check could be fixed to consider start and stop times. Thanks Klaus

4 4

DNSmon "not indicative of what happens to normal traffic" claims the root ops
by Stephane Bortzmeyer 11 Dec '15

11 Dec '15

http://root-servers.org/news/events-of-20151130.txt

6 11

Probe Address Discovery
by Mike 10 Dec '15

10 Dec '15

On the Network tab for my probe, there is a section named, "Probe Address Discovery". It shows the addresses on my probe, placing a green check mark next to the one(s) it thinks are the public address(es) for the probe. For my probe, the IPv4 address shown in the IP Echo Service row has a green check mark. Unfortunately, that IPv4 address was replaced about a month ago by another IPv4 address, and it can no longer be considered to be an address for my probe. Additionally, the IPv6 address for the IP Echo Service is also incorrect, but that one doesn't have a green check mark next to it. Is it a problem that these addresses are incorrect? Is there a way to refresh them, or have them refreshed, with the correct IP addresses? thanks.

1 0

What is the Aggregator on Map of DNS Measurements
by Klaus Darilion 09 Dec '15

09 Dec '15

Hi! The MAP of DNS Measurements contains an "Aggregator" option. Unfortunately the online help (Enter a regular expression ....) does not help much. Is this feature somewhere described in detail? I do not understand it. Thanks Klaus

2 2

CAIDA BGP Hackathon 6-7 Feb 2016 -- Call for Participation
by Vesna Manojlovic 09 Dec '15

09 Dec '15

Hi everyone, as a continuation of our own successful RIPE Atlas events, we are now taking part in CAIDA's BGP "live" hackahton, by providing data, measurements platform, expertise -- and you ;-) RIPE NCC's services, such as RIS & RIPE Atlas, will be "remixed" with other BGP-related data sources & tools, to create wonderful new hacks. As participants in RIPE Atlas community, you are very much invited to take part in this event. Details are below. Regards, Vesna -------- Forwarded Message -------- Subject: [mat-wg] CAIDA BGP Hackathon 6, 7 Feb 2016 -- Call for Participation Date: Tue, 8 Dec 2015 20:37:49 -0800 From: Alberto Dainotti <alberto(a)caida.org> To: mat-wg(a)ripe.net What: CAIDA BGP Hackathon, Call for Participation (CFP) When: Feb 6-7, 2016 Where: the San Diego Supercomputer Center (SDSC) on the University of California at San Diego (UCSD) campus. Who: Parties interested in hacking on live BGP data. Inquiries: bgp-hackathon-info(a)caida.org Important Deadline: Dec 22, 2015 for travel grant requests Apply to attend: http://www.caida.org/workshops/bgp-hackathon/1602/ CAIDA, in cooperation with CSU, USC, UFMG, FORTH, Route Views, RIPE NCC, will host a BGP Hackathon on the 6-7th of February 2016 at UC San Diego (La Jolla, CA, USA). The theme of the hackathon is “live BGP measurements and monitoring”. We will provide participating teams with access to data sources and a toolbox: live streaming of BGP data, the new BGPMon interface, BGP processing tools and APIs such as the opensource BGPStream software framework, the PEERING testbed, RIPE RIS, visualization tools, and data-plane active measurement platforms such as CAIDA Ark and RIPE Atlas. Participating teams will work on "challenges" that extend, integrate and demonstrate the utility of these platforms/data for understanding or solving practical problems (e.g., detecting BGP prefix hijacking, evaluating anycast performance, effectively visualizing phenomena). The hackathon will be held in San Diego the weekend immediately preceding the NANOG conference and the AIMS academic Internet measurement workshop. The hackathon aims to: - bring together these different communities, e.g., to discuss problems operators face that academics may want to research; - advertise tools (e.g., PEERING peering.usc.edu, BGPStream bgpstream.caida.org) to the communities and get people familiar with using them, and encourage further use in the future; - get people working together on interesting/important problems, hopefully spurring further collaboration on these problems; - provide extra incentive for students to attend NANOG. ### FORMAT Each team of 2-4 people will work on a "challenge". The organization committee will propose a set of challenges to bootstrap feedback and refinement based on community input: participants can propose totally new challenges, modifications to existing ones, and express their preferences. The set of potential challenges is described in the event website at https://github.com/CAIDA/bgp-hackathon/wiki/List-of-Challenges and will continuously evolve in the days preceding the hackathon. On Saturday morning, participants will very briefly introduce their interests and ideas and teams will be officially formed. On Saturday and Sunday, participants will work together in teams to hack and develop their ideas, culminating in very short presentations to the jury on Sunday evening and a party to announce the winning teams and celebrate everyone's participation. During the event, domain-experts will provide support to the teams. Participants are free to work on drafted challenges and on their own ideas in the days preceding the hackathon. A mailing list and documentation will provide support on the platforms/tools/data used in the hackathon. However, for the teams to compete in the hackathon for prizes, they will have to demonstrate that substantial work was done during the two-day event. ### PARTICIPATION AND TRAVEL GRANTS Application to participate in the hackathon is open from December 8, 2016. Application does not guarantee participation. There is no application fee, and no participation fee. We will accept applications until one week before the hackathon, or until capacity is reached. However, the deadline to apply for a travel grant (through the hackathon application form) is 22 December 2015. Travel grants reimburse flights and hotel expenses. Food and drinks will be provided throughout the two-day event. http://www.caida.org/workshops/bgp-hackathon/1602/

1 0