Re: [atlas] Delays?

[Stephane Bortzmeyer]

On Mon, May 13, 2024 at 09:51:14PM +0200,
 Ernst J. Oud  wrote 
 a message of 22 lines which said:

> I experience delays on creating measurements.
> 
> Even after 2 minutes, a measurement is not running, eventually it will but it 
> used to take a couple of seconds.

Same here. With blaeu, I use the option --measurement-ID because,
after "some" time, the measurement is done so it is just a matter of
patience.

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Confused by the documentation

[Stephane Bortzmeyer]

On Fri, Apr 05, 2024 at 10:13:14AM +0200,
 Christopher Amin  wrote 
 a message of 44 lines which said:

> As a workaround, you can look at the response documentation for "GET
> /api/v2/measurements" -- all of the type-specific fields that are
> marked with .e.g [http] or [dns] are options which can be included
> when creating the measurement.

OK, I did not look at the right place. Speaking of these options, what
are the possible paths for a HTTP requests at an anchor? I assume the
only supported one is "/"?


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Empty responses for HTTP tests with a non-existing path?

[Stephane Bortzmeyer]

On Fri, Apr 05, 2024 at 01:53:02PM +0200,
 Robert Kisteleki  wrote 
 a message of 36 lines which said:

> Thank you for pointing this out, it has been fixed: the anchors
> respond with a proper 404 now.

Indeed, thanks.

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

[atlas] Confused by the documentation

[Stephane Bortzmeyer]

I confess I have a lot of problems finding something in the
documentation in its current state. For instance, I assume that HTTP
requests can have a "method" parameter to switch from GET, HEAD, etc
but where is it documented?

Not here:

https://atlas.ripe.net/docs/apis/rest-api-manual/measurements/types/type_specific_attributes.html

Not here:

https://atlas.ripe.net/docs/apis/rest-api-reference/#measurements


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

[atlas] Empty responses for HTTP tests with a non-existing path?

[Stephane Bortzmeyer]

It seems the anchors, when receiving a HTTP request for a non-existing
path, instead of a 404, send a broken response:

% curl -v http://fr-par-as2486.anchors.atlas.ripe.net/nonono
*   Trying 2001:67c:217c:4::2:80...
* Connected to fr-par-as2486.anchors.atlas.ripe.net (2001:67c:217c:4::2) port 
80 (#0)
> GET /nonono HTTP/1.1
> Host: fr-par-as2486.anchors.atlas.ripe.net
> User-Agent: curl/7.81.0
> Accept: */*
> 
* Empty reply from server
* Closing connection 0
curl: (52) Empty reply from server

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

[atlas] Atlas weather report: bad day

[Stephane Bortzmeyer]

As reported by , indeed, measurements timeout
today.


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

[atlas] "Thinking About Internet History"

[Stephane Bortzmeyer]

Among the things to preserve for future studies of Internet
infrastructure and connectivity, this interesting article mentions
Atlas measurements.

https://content.cooperate.com/post/internet_history/

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Atlas fully down..

[Stephane Bortzmeyer]

On Wed, Sep 20, 2023 at 12:02:19PM +0200,
 Ernst J. Oud  wrote 
 a message of 34 lines which said:

> Yes, I also don’t understand Robert’s remark. All user defined
> measurements, new or existing do not give any results.

May be the situation is complicated and not fully understood yet. Good
luck for the technical team, anyway.


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Atlas fully down..

[Stephane Bortzmeyer]

On Wed, Sep 20, 2023 at 07:43:20AM +0200,
 Robert Kisteleki  wrote 
 a message of 42 lines which said:

> All else (continuing to run existing measurements, creating new ones, 
> real-time streaming of the results, APIs, UI, ...) are running undisturbed.

This is not what I observe. For instance, asking for 100 probes in
France yields a "No suitable probes" (see measurement #60181887). So,
"completely down" seems a fair summary to me.



-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Easy way to view DNS results?

[Stephane Bortzmeyer]

On Tue, Jul 25, 2023 at 09:40:34AM +0200,
 Robert Kisteleki  wrote 
 a message of 88 lines which said:

> We're not parsing and inserting all the bits from the raw response
> into the JSON mostly because it would inflate the size of the
> results enormously, while users are generally only interested in
> specific bits.

Also:

1) The DNS format continues evolving, for instance with new EDNS
options, so it would require the Atlas team to follow.

2) Sometimes, people are interested in invalid DNS answers, that
cannot be parsed.

> The "abuf" is always in there, so consumers of the results can parse
> that (as you already know, and as Seth does below). There are abuf
> parsers out there, and if you're using Python then I'd recommend
> using Sagan

Or use Blaeu
:

% blaeu-resolve --measurement-ID 57629583 check.ns1.dtc.dnssec.lab.nic.cl.
[::2] : 3 occurrences 
[] : 1 occurrences 
Test #57629583 done at 2023-07-25T00:15:02Z



-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Probe 24434 down but pingable

[Stephane Bortzmeyer]

On Fri, Dec 30, 2022 at 10:04:35AM +0100,
 Dave  wrote 
 a message of 43 lines which said:

> One of my probes is pingable but the status is disconnected for over
> a day.

Could it be also that the probe is indeed disconnected but there is
some middlebox in front of it that intercepts ICMP echo requests, and
then replies?

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Proposal: Remove support for non-public measurements [ONLY-PUBLIC]

[Stephane Bortzmeyer]

On Fri, Dec 16, 2022 at 02:57:40PM -0800,
 Randy Bush  wrote 
 a message of 12 lines which said:

> i do not understand the big fuss here.  so a teensie fraction of
> probes are not public.  big deal.

Apparently, the problem is that the cost of private measurements is
not zero: it makes the Atlas backend code much more complex, with
added security issues (ensuring that the private measurementrs stay
private). I'm sure we all agree that complexity is something to be
reduced.

Also, this is not just operators vs. researchers. We are operator (.fr
name registry) and we never use private measurements.


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Proposal: Measure well-known CDNs,[CDN-HTTP]

[Stephane Bortzmeyer]

On Tue, Dec 20, 2022 at 05:48:08PM +0100,
 Lukas Tribus  wrote 
 a message of 60 lines which said:

> - where have those security concerns been previously discussed?

Several times on this list. This is a recurring discussion, for many
years.

> Are you suggesting that people deploy ATLAS probes in security
> sensitive inside parts of corporate networks?

I believe that the concerns were more about the security of the server
than the security of the probe. Nobody wants Atlas to be used as a
botnet against unsuspecting HTTP servers.

> And those security concerns affect only GENERIC-HTTP not other
> currently available measurements like DNS?

For a typical DNS server, the "cost" does not depend on the request
(at least for authoritative DNS servers). On the contrary, for HTTP,
the cost can vary immensely from a static favicon.ico to a request
involving many SQL statements.

> we are talking about small HTTP HEAD and GET requests here.

The GET can be small but incurring a huge cost for the server.


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Proposal: Measure well-known CDNs,[CDN-HTTP]

[Stephane Bortzmeyer]

On Wed, Dec 14, 2022 at 03:02:46PM +0100,
 Robert Kisteleki  wrote 
 a message of 15 lines which said:

> We recently published a RIPE Labs article containing a few proposals:
> https://labs.ripe.net/author/kistel/five-proposals-for-a-better-ripe-atlas/.
> We'd like to encourage you to express your comments about this proposal (if
> you'd like to share them) here.

(In the Cons) "Possible arguments about which provider to include in
this set and which to refuse."

There is a larger problem here, a more strategic one: such a feature
would contribute to the centralisation of the Internet, which is
already too important. Tagging some targets are "important" and
"worthy of measurements" would mean that we consider some HTTP servers
to be more useful than others. That would be a bad message from RIPE.

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] RIPE Atlas down?

[Stephane Bortzmeyer]

On Wed, Jun 22, 2022 at 11:34:09AM +0200,
 Ernst J. Oud  wrote 
 a message of 78 lines which said:

> Checked a probe in Germany, same thing but stopped a couple of hours later it 
> seems.
> 
> Is there some problem?

Indeed, measurements never return results
.


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] How to get DNS return codes and TTLs

[Stephane Bortzmeyer]

On Wed, Jun 08, 2022 at 06:16:30PM -0600,
 Dallan Adamson  wrote 
 a message of 39 lines which said:

> I'm doing research that requires me to use DNS recursive resolvers
> around the world. At a minimum from these recursive resolvers I need
> to know what return code the probe received from the recursive
> resolver as well as the TTL of the record from the same request. I
> haven't found a way to get both of these when doing DNS measurements
> with Ripe Atlas probes, is there a way to do this?

Some DNS information is parsed by Atlas and returned in the JSON
answer (such as the length of the various DNS sections) but, if you
want all the DNS data, you'll have to parse yourself the DNS blob
included in the JSON answer (field "abuf"). You can get inspiration
from the source code of the official client, or from Blaeu's
blaeu-resolve .



-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

[atlas] Discrepancy in documentation?

[Stephane Bortzmeyer]

[Message already sent on 6 june but it never appeared in my
mailbox. Is there some email problem at RIPE?]

In the documentation
, various
HTTP methods are used (for instance DELETE to delete a measurement),
which is nice, but the examples ("Try it") always show the method GET.



-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

[atlas] Problem with DoT measurements?

[Stephane Bortzmeyer]

DoT measurements seem partially broken, only 10 % of the probes do
report. (See for instance #39675721.)


-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Facebook in Russia and a diagnostic problem

[Stephane Bortzmeyer]

On Mon, Mar 14, 2022 at 01:40:02PM +0100,
 Emile Aben  wrote 
 a message of 21 lines which said:

> I find the things the OONI project does very insightful.
> 
> For this particular case:
> https://ooni.org/post/2022-russia-blocks-amid-ru-ua-conflict/

Good reference, thanks, it explains everything.

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] Facebook in Russia and a diagnostic problem

[Stephane Bortzmeyer]

On Mon, Mar 14, 2022 at 10:26:46PM +1100,
 Jen Linkova  wrote 
 a message of 37 lines which said:

> It is. Facebook is officially blocked in Russia [1]
> 
> [1] https://rkn.gov.ru/news/rsoc/news74156.htm

I know but I was asking *how* it is implemented and it is far from
obvious, from the data. Hence my question to network experts: how to
explain what the Atlas probes see?

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

[atlas] Facebook in Russia and a diagnostic problem

[Stephane Bortzmeyer]

Around half of the RIPE Atlas probes in Russia cannot complete a TLS
session with facebook.com
. (All the remaining
tests have been done with the same set of probes, 'type': 'msm',
'value': '39387725'.) They have no problem with YouTube
. I also did TLS tests
with IP addresses instead of names, same result

.

There is no lying DNS resolver .

But traceroute show no connectivity problem either, we can go to the
Facebook AS from Russia 
.

So, I'm a bit lost: what do we observe? It does not look like
censorship but not like a connectivy issue (because of depeering by
Cogent and Lumen) either.

-- 
ripe-atlas mailing list
ripe-atlas@ripe.net
https://lists.ripe.net/mailman/listinfo/ripe-atlas

Re: [atlas] DNS probes: spurious SERVFAIL

[Stephane Bortzmeyer]

On Sun, May 30, 2021 at 02:27:18PM +0200,
 Lukas Tribus  wrote 
 a message of 41 lines which said:

> while troubleshooting DNS issues on the Google network yesterday [1]
> we found that RIPE Atlas probes did not recover after Google fixed the
> issue, we kept seeing SERVFAIL answers on the RIPE Atlas probes.
...
> To reproduce, just try to resolve zoom.us or google.us against 8.8.8.8
> or 1.1.1.1 on your probe.

It works and I don't see one SERVFAIL:

% blaeu-resolve --requested 100 --area North-Central --nameserver 8.8.8.8 
--type A google.us
...
Test #30484765 done at 2021-05-30T12:34:54Z

Re: [atlas] Result delivery issues - 2021-05-11

[Stephane Bortzmeyer]

On Tue, May 11, 2021 at 09:37:51AM +0200,
 Robert Kisteleki  wrote 
 a message of 11 lines which said:

> The RIPE Atlas result storage backend started experiencing issues today at
> around 3am (CEST). The team is working on resolving the issue; we'll provide
> an update when more information is available.

Is it also for this reason that measurements only get very few probes?

{'is_oneoff': True, 'definitions': [{'description': 'DNS resolution of
dnsdist.org/', 'af': 4, 'type': 'dns', 'query_argument':
'dnsdist.org', 'query_class': 'IN', 'query_type': '',
'set_do_bit': True, 'udp_payload_size': 4096, 'set_rd_bit': True,
'protocol': 'UDP', 'use_probe_resolver': True}], 'probes':
[{'requested': 100, 'type': 'area', 'value': 'WW', 'tags': {'include':
['system-ipv4-works', 'system-resolves-a-correctly',
'system-resolves--correctly']}}]}

But measurement #30113470 only got 6 probes.

Re: [atlas] Filtering measurements

[Stephane Bortzmeyer]

On Thu, Apr 22, 2021 at 02:20:20PM +0200,
 Stephane Bortzmeyer  wrote 
 a message of 15 lines which said:

> I'm afraid you'll have to download the raw JSON file
> <https://ftp.ripe.net/ripe/atlas/measurements/>, parse it yourself and
> filter according to the "probes" array.

The small Python program attached gives an example.

% ./read.py meta-20210421.txt 50005
...
Measurement 29755186 uses the probe 50005
Measurement 29755187 uses the probe 50005
Measurement 29755701 uses the probe 50005
Measurement 29755702 uses the probe 50005
Measurement 29755704 uses the probe 50005
Measurement 29756177 uses the probe 50005
Measurement 29756178 uses the probe 50005
...

#!/usr/bin/python3

import json
import sys

filename = sys.argv[1]
probe = sys.argv[2]

f = open(filename)
for line in f.readlines():
data = json.loads(line)
mid = data["msm_id"]
for p in data["probes"]:
if str(p["id"]) == probe:
print("Measurement %s uses the probe %s" % (mid, probe))

Re: [atlas] Filtering measurements

[Stephane Bortzmeyer]

On Thu, Apr 22, 2021 at 02:01:04PM +0200,
 Sanaa GHANDI  wrote 
 a message of 30 lines which said:

> But I have no idea of how to make a filter on the sources as well,
> since all we can access through the measurements are the number of
> anchors requested and not their ids.
> 
> Do you know a way to get access to the sources of a measurement via
> Atlas Cousteau or another Ripe Tool ?

I'm afraid you'll have to download the raw JSON file
, parse it yourself and
filter according to the "probes" array.

Re: [atlas] Spurious "would violate your maximum daily spending limit"

[Stephane Bortzmeyer]

On Wed, Apr 07, 2021 at 10:11:03AM +,
 Ponikierski, Grzegorz  wrote 
 a message of 115 lines which said:

> Atlas takes into account also rate how quickly you spend your
> credits and on base of that it tries to predict if you will hit your
> daily limit and tries to stop measurements which are above such
> trajectory.

I know but I changed nothing, I still have the same periodic
measurements and, for many years, it was not a problem.

Re: [atlas] Spurious "would violate your maximum daily spending limit"

[Stephane Bortzmeyer]

On Sun, Apr 04, 2021 at 10:54:39AM +0200,
 Stephane Bortzmeyer  wrote 
 a message of 23 lines which said:

>  Request","code":102,"errors":[{"source":{"pointer":""},"detail":"Executing
>  this measurement request would violate your maximum daily spending
>  limit of 100.0 credits. Please stop some of your currently
>  running measurements and try again."}

No news? The problem still occurs. Is it only for me?

[atlas] Spurious "would violate your maximum daily spending limit"

[Stephane Bortzmeyer]

I receive a:

 {"error":{"detail":"There was a
 problem with your request","status":400,"title":"Bad
 Request","code":102,"errors":[{"source":{"pointer":""},"detail":"Executing
 this measurement request would violate your maximum daily spending
 limit of 100.0 credits. Please stop some of your currently
 running measurements and try again."}

from the API.

The request is:

{'is_oneoff': True, 'definitions': [{'description': 'DNS resolution of
use-application-dns.net./A from AS #3215', 'af': 4, 'type': 'dns',
'query_argument': 'use-application-dns.net.', 'query_class': 'IN',
'query_type': 'A', 'set_rd_bit': True, 'protocol': 'UDP',
'use_probe_resolver': True}], 'probes': [{'requested': 100, 'type':
'asn', 'value': '3215', 'tags': {'include': ['system-ipv4-works',
'system-resolves-a-correctly', 'system-resolves

Which is very small. I run this sort of requests frequently. My daily
expenditure is small (13,680 credits). Why is it rejected?

Re: [atlas] Probes suffering DNS interception?

[Stephane Bortzmeyer]

On Thu, Dec 10, 2020 at 05:29:46PM +,
 Ray Bellis  wrote 
 a message of 20 lines which said:

> Is there any RIPE policy about whether nodes that are subject to DNS
> interception should be excluded from results (or maybe even dropped
> altogether) ?

I disagree. The point of RIPE Atlas probes is to test the Internet AS
IT IS, not as we would like it to be. (Otherwise, I would drop the
probes behind NAT…)

> While these probes are perhaps still useful for ping and traceroute
> tests, they are effectively useless for DNS related tests other than as
> a proxy measure for how prevalent that practise actually is.

Which is an important use.

> If there was a heuristic that could be applied on the probe itself or
> within the RIPE data collector that tagged the probe as having "bad DNS"
> that would help a lot.

Adding a tag is indeed a good idea, but not excluding or dropping
these probes.

Re: [atlas] Problem today? Measurements do not finish

[Stephane Bortzmeyer]

On Wed, Nov 18, 2020 at 10:02:43AM +0100,
 Alarig Le Lay  wrote 
 a message of 22 lines which said:

> It seems that the delays are still there:

It seems you an recover the data now (note the option
--measurement-ID, to avoid making the measurement again).

% blaeu-traceroute --format --protocol=ICMP --do_lookup --do_reverse_lookup 
--asn=1267 --measurement-ID=28215047 gandi01.ring.nlnog.net
gandi01.ring.nlnog.net returns more then one IP address please select
one
1 - 2001:4b98:dc0:43:216:3eff:fe18:c91a
2 - 92.243.16.165
=>1
Test #28215047 done at 2020-11-18T08:56:55Z
From:  151.62.209.1311267ASN-WINDTRE IUNET, EU
Source address:  192.168.1.192
Probe ID:  19815
1192.168.1.1No PTRNANA[0.927, 0.544, 0.491]
2151.6.165.16No PTR1267ASN-WINDTRE IUNET, EU
[10.84, 8.841, 9.432]
3151.6.192.108No PTR1267ASN-WINDTRE IUNET, EU
[9.006, 8.528, 9.336]
4151.6.192.152No PTR1267ASN-WINDTRE IUNET, EU
[8.521, 8.891, 8.681]
5151.6.2.14No PTR1267ASN-WINDTRE IUNET, EU[10.891,
11.337, 11.093]
6151.6.1.178No PTR1267ASN-WINDTRE IUNET, EU
[11.893, 12.337, 11.764]
762.115.36.84mno-b2-link.telia.net1299TELIANET Telia
Carrier, EU[12.266, 12.081, 12.467]
862.115.116.154prs-bb3-link.telia.net1299TELIANET
Telia Carrier, EU[93.837, 95.279, 93.575]
962.115.113.183prs-b7-link.telia.net1299TELIANET Telia
Carrier, EU[28.453, 28.071, 27.924]
1062.115.183.131gandisas-svc067520-ic351335.c.telia.net
1299TELIANET Telia Carrier, EU[149.543, 292.231, 313.188]
11155.133.187.27core-2.csd4.gandi.net29169GANDI-AS
Domain name registrar - http://www.gandi.net, FR[96.395, 96.562,
96.118]
12['*', '*', '*']
13217.70.176.23ethernet31-1.dcgw-1r.sd6.ip4.gandi.net29169
GANDI-AS Domain name registrar - http://www.gandi.net, FR[92.959,
94.231, 94.673]
14155.133.140.3team505.igw-1-r.sd6.paris.ip4.as203476.net
203476GANDI-AS-2 Domain name registrar - http://www.gandi.net, FR
[27.786, 27.694, 27.51]
1592.243.16.165xvm-16-165.dc0.ghst.net203476GANDI-AS-2
Domain name registrar - http://www.gandi.net, FR[29.324, 29.176,
29.297]

From:  151.41.159.1451267ASN-WINDTRE IUNET, EU
Source address:  192.168.1.102
Probe ID:  24155
1192.168.1.1No PTRNANA[1.568, 0.464, 0.383]
...

[atlas] Problem today? Measurements do not finish

[Stephane Bortzmeyer]

See for instance #28206873. 100 probes, all with "No recent report
available".

[atlas] Extreme slowness today?

[Stephane Bortzmeyer]

23 minutes before Atlas tells me there is no suitable probes with my
criteria (country=SD, which does not surprise me). Same slowness for
all measurements.

Re: [atlas] status-check redirects to itself?

[Stephane Bortzmeyer]

On Wed, Apr 29, 2020 at 08:05:18PM +0200,
 Philip Homburg  wrote 
 a message of 10 lines which said:

> The redirect is to a slightly different URL.

OK, thanks, I did not notice the detail. But it worked before (I use
it in a monitoring script), and the behavior changed somewhere around
29 april, 13:20 UTC.

[atlas] status-check redirects to itself?

[Stephane Bortzmeyer]

Since today, status-check seems to redirect to itself?

% curl -v 
https://atlas.ripe.net/api/v2/measurements/2060427/status-check\?permitted_total_alerts=3
...
< HTTP/1.1 301 Moved Permanently
< Server: nginx/1.16.1
< Date: Wed, 29 Apr 2020 17:57:17 GMT
< Content-Type: text/html; charset=utf-8
< Content-Length: 0
< Connection: keep-alive
< Location: /api/v2/measurements/2060427/status-check/?permitted_total_alerts=3

What's up?

[atlas] Setting the DNS AD bit

[Stephane Bortzmeyer]

It seems there is currently no way to set the AD bit in DNS queries?
(Through the API, we can only control RD, CD and DO bits.)
--- Begin Message ---
Does anyone know of any iterative resolvers one is likely to run into on
some ISP's network, hotel, or WiFi hotspot that will choke on queries
with AD=1, per:

https://tools.ietf.org/html/rfc6840#section-5.7

FWIW, "dig" sets AD=1 by default, and I've never seen a need to use
"+noad" to get the upstream resolver to respond correctly.  But perhaps
I've just not tested in the "wrong" places.

Is there a way to leverage RIPE ATLAS to look for AD=1 (in queries)
intolerance?

The reason I ask, is that the MUSL libc stub resolver has no support for
EDNS and so no DO=1, but Postfix DANE support still needs to see the AD
bit from the local resolver, which is not sent when there's no AD=1 in
the query.

My instinct is that it is now safe to just always send AD=1 in queries,
which would partly resolve the issue, but if that is liable to break
lookups via some extant resolvers, then AD=1 would need to be
configurable via options in /etc/resolv.conf or similar.

-- 
Viktor.
___
dns-operations mailing list
dns-operati...@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
--- End Message ---

Re: [atlas] No Atlas today: bad gateway

[Stephane Bortzmeyer]

On Tue, Mar 31, 2020 at 10:40:28AM +0200,
 Jasper den Hertog  wrote 
 a message of 92 lines which said:

> There definitely was a glitch, we saw it as well.

And it just happened again.

[atlas] No Atlas today: bad gateway

[Stephane Bortzmeyer]

https://atlas.ripe.net/

502 Bad Gateway
nginx/1.16.1

COVID-19 on the server?

Re: [atlas] Reg query of code

[Stephane Bortzmeyer]

On Mon, Feb 24, 2020 at 03:42:05PM +0530,
 Adarsh Pandey  wrote 
 a message of 144 lines which said:

> Can we get the code of ripe atlas server 

As far as I know, it is not public (only the code of the probes is).

Re: [atlas] Using Atlas for Monitoring of Anycast DNS

[Stephane Bortzmeyer]

On Thu, Jan 16, 2020 at 04:33:47PM +0100,
 Klaus Darilion  wrote 
 a message of 48 lines which said:

> - analyze the probe locations (ie. country, continent)

Instead of analyzing it afterwards, why not directly asking probes on
the place you're interested in?

I often use NSID to watch anycast servers, indeed:

% blaeu-resolve --requested 100 --area West --nameserver $(dig +short +nodnssec 
d.nic.fr A) --type SOA --nsid --displayrtt fr
Nameserver 194.0.9.1
[NSID: b'dns.th2.nic.fr' nsmaster.nic.fr. hostmaster.nic.fr. 2225269298 3600 
1800 360 5400] : 34 occurrences Average RTT 146 ms
[NSID: b'dns.fra.nic.fr' nsmaster.nic.fr. hostmaster.nic.fr. 2225269298 3600 
1800 360 5400] : 3 occurrences Average RTT 100 ms
[NSID: b'dns.nyc.nic.fr' nsmaster.nic.fr. hostmaster.nic.fr. 2225269298 3600 
1800 360 5400] : 35 occurrences Average RTT 56 ms
[NSID: b'dns.ix1.nic.fr' nsmaster.nic.fr. hostmaster.nic.fr. 2225269298 3600 
1800 360 5400] : 4 occurrences Average RTT 116 ms
[TIMEOUT] : 2 occurrences Average RTT 0 ms
[NSID: b'dns.mrs.nic.fr' nsmaster.nic.fr. hostmaster.nic.fr. 2225269298 3600 
1800 360 5400] : 10 occurrences Average RTT 156 ms
[NSID: b'dns.ams.nic.fr' nsmaster.nic.fr. hostmaster.nic.fr. 2225269298 3600 
1800 360 5400] : 8 occurrences Average RTT 101 ms
[NSID: b'dns.lon.nic.fr' nsmaster.nic.fr. hostmaster.nic.fr. 2225269298 3600 
1800 360 5400] : 2 occurrences Average RTT 154 ms
[nsmaster.nic.fr. hostmaster.nic.fr. 2225269297 3600 1800 360 5400] : 1 
occurrences Average RTT 24 ms
Test #23843409 done at 2020-01-16T15:43:10Z

Note the wonders of BGP: only a minority of probes use the instance in
New York City (the fastest one) :-(

Note also that the last result comes from a transparent proxy,
redirecting to a cache.

[atlas] Maintenance or incident?

[Stephane Bortzmeyer]

% curl https://atlas.ripe.net/
curl: (7) Failed to connect to atlas.ripe.net port 443: Connection refused

It started around 1015 UTC.

Re: [atlas] Long measurement delays

[Stephane Bortzmeyer]

On Fri, Nov 29, 2019 at 10:07:33PM -0700,
 Steve Gibbard  wrote 
 a message of 35 lines which said:

> I’ve been seeing delayed query responses to one-off measurements
> since November 22, with the exception of November 25.

Isn't it the "synchronizing" problem? (Measurement status is reported
as "{'id': None, 'name': 'synchronizing'}".)

Re: [atlas] Finding the NSID in the measurement results

[Stephane Bortzmeyer]

On Wed, Nov 27, 2019 at 01:09:46PM +,
 Roger Murray  wrote 
 a message of 83 lines which said:

> So far so good, but when we download the raw measurement result data
> we are not able to locate the NSID information.

It's in the DNS blob, you have to parse it.

Example of source code:

https://framagit.org/bortzmeyer/blaeu/blob/master/blaeu-resolve#L301

Example of result:

% blaeu-resolve --measurement-ID 23444279 --type SOA --nsid a.ns.se
[NSID: b's1.stu'] : 10338 occurrences 
[NSID: b's2.stu'] : 10420 occurrences 
[TIMEOUT] : 303 occurrences 
Test #23444279 done at 2019-11-27T09:40:33Z

Re: [atlas] Measurements "synchronizing"

[Stephane Bortzmeyer]

On Fri, Nov 15, 2019 at 04:13:16PM +0100,
 Chris Amin  wrote 
 a message of 30 lines which said:

> Sorry, I *do* see such delays. Looking into it now!

It works now, thanks.

[atlas] Measurements "synchronizing"

[Stephane Bortzmeyer]

It seems that, today, when querying the API about an existing
measurement, I always get:

{'id': None, 'name': 'synchronizing'}

Which I've never seen. (Measurement #23238335 but it's not the only
one.) A recent change? A temporay problem?

Re: [atlas] DNS issue with Atlas or with the ISP?

[Stephane Bortzmeyer]

On Mon, Sep 09, 2019 at 12:25:38PM +0200,
 Bjørn Mork  wrote 
 a message of 42 lines which said:

> BTW, I seriously doubt that *all* other DNS and RDNSS clients got this
> right.  Advertising LL DNS servers seems unnecessary risky outside of
> the lab.

I agree that it is risky, but I'm not the CTO of this specific ISP...

Anyone knows an example of another big ISP doing that?

Also, there is a *rumor* (not substantiated by hard facts) that DNS
resolution at this ISP experiences trouble, but I have currently no
solid proof. (I was trying to use the Atlas probes for that.)

Re: [atlas] DNS issue with Atlas or with the ISP?

[Stephane Bortzmeyer]

On Mon, Sep 09, 2019 at 01:06:48PM +0200,
 Philip Homburg  wrote 
 a message of 20 lines which said:

> The problem is that for a link local address you need a scope. The
> Atlas measurement code doesn't know how to add one and the addresses
> in /etc/resolv.conf don't have one.

I was, too, surprised that it works but some people tested with dig or
drill (I assume it was on monohomed machines, which is the case of
RIPE Atlas probes) and it worked.

Note that RFC 8106 explicitely authorizes it:

   Note: The addresses for RDNSSes in the RDNSS option MAY be link-local
 addresses.  Such link-local addresses SHOULD be registered in
 the Resolver Repository along with the corresponding link zone
 indices of the links that receive the RDNSS option(s) for them.
 The link-local addresses MAY be represented in the Resolver
 Repository with their link zone indices in the textual format
 for scoped addresses as described in [RFC4007].  When a
 resolver sends a DNS query message to an RDNSS identified by a
 link-local address, it MUST use the corresponding link.

Re: [atlas] DNS issue with Atlas or with the ISP?

[Stephane Bortzmeyer]

On Sun, Sep 08, 2019 at 06:53:12PM +0200,
 Stephane Bortzmeyer  wrote 
 a message of 26 lines which said:

> I assume that the "connect failed Invalid argument" is the fault of
> the ISP, which advertises a wrong DNS resolver? Or is the Atlas probe
> unable to query link-local addresses for DNS resolution? 

So, people have tested, and confirm that 1) this ISP advertises
link-local address via RA 2) it works with all DNS clients, but the
RIPE Atlas probes. Any idea?

[atlas] DNS issue with Atlas or with the ISP?

[Stephane Bortzmeyer]

RIPE Atlas Web site displays a lot of "undefined" for the tests in AS
3125. See for instance
 or
 But the DNS
resolution from this AS seems to work.

Checking the raw results in JSON, I see that we have a lot of failures
on one IPv6 resolver:

"dst_name": "fe80::a63e:51ff:fe77:e26",
"error": {
  "socket": "connect failed Invalid argument"
},

We do not see such IPv6 problem in other AS (see for instance
)

I assume that the "connect failed Invalid argument" is the fault of
the ISP, which advertises a wrong DNS resolver? Or is the Atlas probe
unable to query link-local addresses for DNS resolution? 

Even if it is so, is it a good idea for the Atlas Web site to display
"undefined" where the raw results show that other resolvers worked?

Re: [atlas] DNS RTT over TCP: twice as long than UDP?

[Stephane Bortzmeyer]

On Fri, Jul 05, 2019 at 12:33:25PM +,
 Giovane Moura  wrote 
 a message of 26 lines which said:

> My hypothesis is that the field *rtt* on DNS queries on Atlas[1],
> for TCP, is, in fact, measuring 2 RTTs: the RTT of the TCP
> handshake, and the RTT of query/response itself.

I assume (I didn't check with tcpdump) that Atlas starts the clock
when the SYN packet leaves, and dig when the DNS request leaves. That
would explain your observation.

Both make sense, and I disagree when you say that the second method is
the only right one.

In practice, which method is the most relevant depends on whether you
use persistent TCP connections or not.

[atlas] Atlas problems this morning?

[Stephane Bortzmeyer]

#22170557, #22171022 and #22171068 terminate but no results are
available. Is there some problem going on?

Re: [atlas] When to consider a measurement finished

[Stephane Bortzmeyer]

On Tue, Jun 18, 2019 at 08:08:23PM +0200,
 Wouter de Vries  wrote 
 a message of 26 lines which said:

> What heuristics/method do you recommend to determine whether to consider
> a measurement as finished?

Probing until N % of the requested probes replied. This is implemented
in blaeu , you may check the
code
.

Re: [atlas] raspbian.net/raspbian.org ipv6 peering problems

[Stephane Bortzmeyer]

On Tue, Jun 25, 2019 at 09:58:25AM +0200,
 Thomas Schäfer  wrote 
 a message of 17 lines which said:

> Does someone measurements to the server of "raspbian"?

Indeed, it's not perfect (the sad state of IPv6 connectivity):

% blaeu-reach --requested 100 --by_probe 2001:41c9:1:3ce::1:10
99 probes reported
Test #22099153 done at 2019-06-25T10:03:22Z
Tests: 86 successful probes (86.9 %), 13 failed (13.1 %), average RTT: 71 ms

Comparison with a server with good connectivity (F.root-servers.net):

% blaeu-reach --requested 100 --by_probe --old_measurement 22099153  
2001:500:2f::f
Warning: --requested=100 ignored since a list of probes was requested
99 probes reported
Test #22099157 done at 2019-06-25T10:06:11Z
Tests: 99 successful probes (100.0 %), 0 failed (0.0 %), average RTT: 39 ms

Re: [atlas] any clue rtt unreachable packet loss 100% com234.476.249

[Stephane Bortzmeyer]

On Mon, Jun 24, 2019 at 09:35:32AM +0200,
 Dave .  wrote 
 a message of 872 lines which said:

> Your destination is not responding to ICMP (ping/traceroute). This
> is not an Atlas issue.

And, for the services who wrongly block ICMP echo, there is still
hope, Atlas probes can run traceroute with UDP or TCP, which is cool.

A good example:

Re: [atlas] DNS-over-TLS and DNS-over-HTTPS measurement

[Stephane Bortzmeyer]

On Mon, Apr 08, 2019 at 04:36:37PM +0200,
 Petr Špaček  wrote 
 a message of 11 lines which said:

> could you share plans for DNS-over-TLS and DNS-over-HTTPS measurements?
> 
> I had impression that DNS-over-TLS is already supported but now I cannot
> find it in the UI so I'm probably wrong.

DNS-over-TLS works for me:

% blaeu-resolve --verbose --nameserver 9.9.9.9 --tls nic.cz
Blaeu version 1.1.4
{'is_oneoff': True, 'definitions': [{'description': 'DNS resolution of 
nic.cz/ via nameserver 9.9.9.9', 'af': 4, 'type': 'dns', 'query_argument': 
'nic.cz', 'query_class': 'IN', 'query_type': '', 'set_rd_bit': True, 'tls': 
True, 'protocol': 'TCP', 'use_probe_resolver': False, 'target': '9.9.9.9'}], 
'probes': [{'requested': 5, 'type': 'area', 'value': 'WW', 'tags': {'include': 
['system-ipv4-works']}}]}
Measurement #20617896 for nic.cz/ uses 5 probes
Nameserver 9.9.9.9
[2001:1488:0:3::2] : 5 occurrences 
Test #20617896 done at 2019-04-08T14:45:31Z

(Note the 'tls': True in the JSON)

[atlas] DNS measurements broken today?

[Stephane Bortzmeyer]

It seems all DNS measurements (not just mine, checked on
 return only an
empty array today...

% curl -s https://atlas.ripe.net/api/v2/measurements/20566896/results/
[]% 

Re: [atlas] Data in the Internet Maps

[Stephane Bortzmeyer]

On Tue, Dec 18, 2018 at 01:58:30PM +0800,
 Davey Song  wrote 
 a message of 117 lines which said:

> 

It works for me, I receive messages.

Re: [atlas] Need help: launching a periodical atlas measurement

[Stephane Bortzmeyer]

On Thu, Jul 19, 2018 at 10:47:54AM -0500,
 Yihao Jia  wrote 
 a message of 192 lines which said:

> I am a little confused because all example on documents is one-off. I guess
> error might happen around "is_oneoff", "interval", "spread".
> source code for this test is below and in the attachment.

"is_oneoff" is off by default. 

"interval" is documented as "In normal (not one-off) measurements, this
value represents the number of seconds between measurements by a
single probe."

I never tried "spread".

I don't know the exact JSON you sent but this one worked (5 minutes, 1
minute between each test):

{'definitions': [{'target': 'fr-ilm-as57119.anchors.atlas.ripe.net', 'af': 4, 
'interval': 60, 'packets': 1, 'type': 'ping', 'description': 'Ping 
fr-ilm-as57119.anchors.atlas.ripe.net'}], 'start_time': 1532026200, 
'stop_time': 1532026500, 'probes': [{'requested': 1, 'type': 'area', 'value': 
'WW'}]}

And it gave this measurement:

https://atlas.ripe.net/measurements/15297080/

Re: [atlas] Global Traceroute

[Stephane Bortzmeyer]

On Tue, Jul 17, 2018 at 08:58:15PM +0300,
 Vladislav V. Prodan  wrote 
 a message of 57 lines which said:

> Firstly, your utility requires API-keys, which have problems getting
> them.

Fair enough. On the other hand, this means that the Web site needs
credits and anonymous Web clients can eat them at will, so it may not
be sustainable.

> # pkg install net/py-ripe.atlas.tools
...
> The process will require 124 MiB more space.
> 
> While the biggest utility is lynx has a size of 5.43MiB

Well, Blaeu

may be smaller but, anyway, is 124 MiB really important (and many
packages are shared with other stuff), these days?

Re: [atlas] Global Traceroute

[Stephane Bortzmeyer]

On Mon, Jul 16, 2018 at 11:49:44PM +0300,
 Vladislav V. Prodan  wrote 
 a message of 50 lines which said:

> 6) I want to work correctly in the console programs curl, lynx and wget.

Why? If you're a command-line fan like me, why not using the regular
programs using the API?

%  blaeu-traceroute -r 1 -c BD --format 2001:67c:370:1998:9819:4f92:d0c0:e94d 
Measurement #15260300 Traceroute 2001:67c:370:1998:9819:4f92:d0c0:e94d from BD 
uses 1 probes
1 probes reported
Test #15260300 done at 2018-07-17T17:10:40Z
From:  2403:4000:1::f24122BDCOM-BD-AS-AP BDCOM Online Limited, BD
Source address:  2403:4000:1::f
Probe ID:  12148
12403:4000:1::124122BDCOM-BD-AS-AP BDCOM Online Limited, BD
[0.535, 0.572, 0.539]
22403:4000:0:2::124122BDCOM-BD-AS-AP BDCOM Online Limited, BD
[0.95, 1.024, 0.898]
32403:9300:80:7::158587FIBERATHOME-BD Fiber@Home Limited, BD
[1.353, 1.351, 1.35]
42403:9300:0:8::3d58587FIBERATHOME-BD Fiber@Home Limited, BD
[1.71, 1.56, 1.931]
52001:5a0:2300:300::96453AS6453 - TATA COMMUNICATIONS (AMERICA) 
INC, US[52.887, 52.6, 52.654]
62001:5a0:2300:300::156453AS6453 - TATA COMMUNICATIONS (AMERICA) 
INC, US[179.184, 179.201, 183.813]
72001:5a0:2000:500::16453AS6453 - TATA COMMUNICATIONS (AMERICA) 
INC, US[176.36, 176.342, 176.36]
82001:5a0:2000:500::2e6453AS6453 - TATA COMMUNICATIONS (AMERICA) 
INC, US[294.366, 292.972, 293.035]
92001:5a0:4500:100::96453AS6453 - TATA COMMUNICATIONS (AMERICA) 
INC, US[294.013, 294.865, 293.539]
102001:5a0:12:100::196453AS6453 - TATA COMMUNICATIONS (AMERICA) 
INC, US[287.969, 287.927, 288.095]
112001:5a0:12:100::726453AS6453 - TATA COMMUNICATIONS (AMERICA) 
INC, US[288.075, 287.996, 287.941]
122001:5a0:3900::26453AS6453 - TATA COMMUNICATIONS (AMERICA) INC, 
US[297.65, 297.437, 297.388]
132001:56b:a002:f::3852ASN852 - TELUS Communications Inc., CA
[310.554, 309.815, 309.328]
142001:56b:8000:101::10852ASN852 - TELUS Communications Inc., CA
[320.198, 320.096, 320.565]
152001:67c:370:1998:9819:4f92:d0c0:e94d56554IETF-MEETING IETF 
Meeting Network, CH[403.806, 404.518, 394.054]

Re: [atlas] DNS measurement using the Probe's resolvers

[Stephane Bortzmeyer]

On Fri, Jul 06, 2018 at 04:30:11PM -0400,
 Rami Al-Dalky  wrote 
 a message of 27 lines which said:

> I have a question about using the probe's list of resolvers when
> creating a DNS measurement. It is unclear to me whether the probe
> would send the query to all resolvers at the same time or not!

By default, to all resolvers. Look at measurement #15260120, for
instance. Probe 25020 used three resolvers, 2001:730:3e42:1000::53,
192.168.178.1, and 2001:730:3e42::53, and you can see the results for
all three. On the other hand, probe 17929 has just one resolver,
8.8.8.8, so you see only one object in the resultset array.

With blaeu, you can display results for all the resolvers or only for
the first one:

% blaeu-resolve -r 10 --measurement-ID=15260120   atlas.ripe.net

[2001:67c:2e8:22::c100:69e] : 10 occurrences 
Test #15260120 done at 2018-07-17T16:55:55Z

% blaeu-resolve -r 10 --measurement-ID=15260120 --severalperprobe  
atlas.ripe.net 
[2001:67c:2e8:22::c100:69e] : 17 occurrences 
[NETWORK PROBLEM WITH RESOLVER] : 1 occurrences 
Test #15260120 done at 2018-07-17T16:55:55Z

(More results in the second case, since some probes have more than one 
resolver.)

> Is DNS eyeball implemented in the probes?

I don't know.

Re: [atlas] No probes working today?

[Stephane Bortzmeyer]

On Tue, Jun 12, 2018 at 03:50:25PM +0200,
 Robert Kisteleki  wrote 
 a message of 21 lines which said:

> The data storage backend had a few hickups today, meaning results
> were queued and served with a delay around 10:00, 11:30 and
> 13:30-15:00. No results were lost.

I confirm it now works. Thanks.

[atlas] No probes working today?

[Stephane Bortzmeyer]

DNS measurements don't start today, no probes are selected for a long
time.

See for instance  (long
delay) or
 (no probes)

Re: [atlas] CLI

[Stephane Bortzmeyer]

On Sun, Jun 03, 2018 at 04:53:36PM +0430,
 Milad Afshari  wrote 
 a message of 115 lines which said:

> Thanks for your suggestion, I have installed the " blaeu" and It is working
> better now.

Since many people use the streaming interface without problems, I
suspect a local MiTM TLS interceptor doing something nasty.

Re: [atlas] CLI

[Stephane Bortzmeyer]

On Wed, May 30, 2018 at 11:13:11AM +0430,
 Milad Afshari  wrote 
 a message of 97 lines which said:

> Exception in thread Thread-1 (most likely raised during interpreter shutdown):
> Traceback (most recent call last):
>   File "/usr/lib/python2.7/threading.py", line 801, in __bootstrap_inner
>   File "/usr/lib/python2.7/dist-packages/socketIO_client/heartbeats.py", line 
> 27, in run
>   File "/usr/lib/python2.7/dist-packages/socketIO_client/__init__.py", line 
> 192, in _ping
>   File "/usr/lib/python2.7/dist-packages/socketIO_client/transports.py", line 
> 159, in send_packet
> : 'NoneType' object is not callable
> Unhandled exception in thread started by 
> sys.excepthook is missing
> lost sys.stderr

It seems a bug in the tool, to me, may be triggered by some MiTM TLS
interceptor. In the case it is specific to the streaming interface,
you may try a tool which does not use this interface (weaknesses can
be strengths :-)
:

% blaeu-reach --probes 33717 9.9.9.9
1 probes reported
Test #13596250 done at 2018-05-30T06:46:37Z
Tests: 3 successful tests (100.0 %), 0 errors (0.0 %), 0 timeouts (0.0 %), 
average RTT: 130 ms

Or with your measurement (which indeed worked):

% blaeu-reach --measurement-ID 13595420 --probes 33717 9.9.9.9 
Warning: --probes ignored since we use probes from a previous measurement
Test #13595420 done at 2018-05-30T06:29:04Z
Tests: 3 successful tests (100.0 %), 0 errors (0.0 %), 0 timeouts (0.0 %), 
average RTT: 130 ms

If you have time to test, tell me if it works better.

Re: [atlas] TLS error when the certificate is expired?

[Stephane Bortzmeyer]

On Mon, Apr 16, 2018 at 03:02:50PM +0200,
 Philip Homburg  wrote 
 a message of 33 lines which said:

> What is typically the case is that the server side has all kinds of
> restrictions on the ciphers that it is willing to accept.
> 
> I recently made some changes to support a server where the sslcert
> measurement would also fail.

The strange thing is that sometimes, it depends on the probe. For
instance, in #12283468, most probes succeeded but some got "{'level':
2, 'description': 40}". It is not a firewall issue since otherwise we
would get a different message. It does not come from the probe type
either, since I asked only system-v3 probes.

[atlas] TLS error when the certificate is expired?

[Stephane Bortzmeyer]

I'm reasonably certain that it has been possible to use 'sslcert'
measurements even when the certificate is expired.

Today, I try to use 'sslcert' with trigger-happy.eu and it fails:

"alert": {
  "description": 40,
  "level": 2
},

And no certificate in the JSON output (this is measurement #12166428)

40 is the very general "handshake failure" of
TLS. 


Was there a change in Atlas recently? The TLS server does reply:

% gnutls-cli trigger-happy.eu
Processed 167 CA certificate(s).
Resolving 'trigger-happy.eu:443'...
Connecting to '51.254.210.94:443'...
- Certificate type: X.509
- Got a certificate list of 2 certificates.
- Certificate[0] info:
 - subject `CN=trigger-happy.eu', issuer `CN=Let's Encrypt Authority X3,O=Let's 
Encrypt,C=US', serial 0x0359a66c5eb5da799afe079f87416f8d9641, RSA key 2048 
bits, signed using RSA-SHA256, activated `2018-01-13 10:46:26 UTC', expires 
`2018-04-13 10:46:26 UTC', key-ID 
`sha256:8216c7a7f221f3efcf7e7c3eb1760275d6ebf38d153b74992ee7864147b54435'
Public Key ID:
sha1:668c4506a393d9bb633590b68c05d878734d7ffe

sha256:8216c7a7f221f3efcf7e7c3eb1760275d6ebf38d153b74992ee7864147b54435
Public key's random art:
+--[ RSA 2048]+
|   +. o++|
|  o +*.=..   |
|   .=o* . . .|
| * B   o |
|. = S   .|
|   = .   .   |
|  +   E  |
| . . |
| |
+-+

- Certificate[1] info:
 - subject `CN=Let's Encrypt Authority X3,O=Let's Encrypt,C=US', issuer `CN=DST 
Root CA X3,O=Digital Signature Trust Co.', serial 
0x0a014142015385736a0b85eca708, RSA key 2048 bits, signed using RSA-SHA256, 
activated `2016-03-17 16:40:46 UTC', expires `2021-03-17 16:40:46 UTC', key-ID 
`sha256:60b87575447dcba2a36b7d11ac09fb24a9db406fee12d2cc90180517616e8a18'
- Status: The certificate is NOT trusted. The certificate chain uses expired 
certificate. 
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.
*** handshake has failed: Error in the certificate.

Re: [atlas] Effect of "Resolve on Probe"-option

[Stephane Bortzmeyer]

On Fri, Dec 01, 2017 at 03:44:22PM +0100,
 Tim Wattenberg  wrote 
 a message of 123 lines which said:

> In my measurement I activated the option to use the probes
> resolver(s) and left the option to resolve on the probe deactivated.

The documentation

appears misleading here, for the specific case of DNS.

For DNS measurements:

'use_probe_resolver': True means using the probe's resolver(s),
typically obtained through DHCP

'use_probe_resolver': False means you have to indicate a name server
(resolver or authoritative) as a target.

Atlas rejects 'use_probe_resolver': False if you did not specify a
target:

Status 400, reason 
"{"error":{"status":400,"errors":[{"source":{"pointer":"/definitions/0"},"detail":"`target`
 cannot be null if `use_probe_resolver` is not 
specified"}],"code":102,"detail":"There was a problem with your 
request","title":"Bad Request"}}"

'resolve_on_probe' seems ignored.

Examples with atlas-resolve:

1) Use the probe's resolver(s):

% atlas-resolve -r 5 -v thepiratebay.org
{'definitions': [{'protocol': 'UDP', 'description': 'DNS resolution of 
thepiratebay.org', 'af': 4, 'query_argument': 'thepiratebay.org', 'query_type': 
'A', 'query_class': 'IN', 'set_rd_bit': True, 'type': 'dns', 
'use_probe_resolver': True}], 'is_oneoff': True, 'probes': [{'requested': 5, 
'type': 'area', 'value': 'WW', 'tags': {'include': 
['system-resolves-a-correctly', 'system-resolves--correctly', 
'system-ipv4-works']}}]}
Measurement #10397465 for thepiratebay.org/A uses 5 probes
[104.27.216.28 104.27.217.28] : 4 occurrences 
[213.46.185.10] : 1 occurrences 
Test #10397465 done at 2017-12-03T16:18:22Z

2) Use an external server (here, Quad9, option -e):

% atlas-resolve -r 5 -v -e 9.9.9.9 thepiratebay.org 
{'definitions': [{'protocol': 'UDP', 'description': 'DNS resolution of 
thepiratebay.org via nameserver 9.9.9.9', 'af': 4, 'query_argument': 
'thepiratebay.org', 'query_type': 'A', 'query_class': 'IN', 'target': 
'9.9.9.9', 'set_rd_bit': True, 'type': 'dns', 'use_probe_resolver': False}], 
'is_oneoff': True, 'probes': [{'requested': 5, 'type': 'area', 'value': 'WW', 
'tags': {'include': ['system-ipv4-works']}}]}
Measurement #10397471 for thepiratebay.org/A uses 5 probes
Nameserver 9.9.9.9
[104.27.216.28 104.27.217.28] : 5 occurrences 
Test #10397471 done at 2017-12-03T16:19:41Z

In the case 1), measurement #10397465, the "dst_addr" field will indicate
the address of the resolver:

% wget -q -O - 
https://atlas.ripe.net/api/v2/measurements/10397465/results/ | jq 
"map(.resultset) | flatten(1) | map(.dst_addr)" 
[
  "172.29.253.203",
  "172.29.254.203",
  "80.58.61.250",
  "80.58.61.254",
  "62.179.104.196",
  "213.46.228.196",
  "217.11.217.3",
  "217.11.217.13",
  "192.168.10.2",
  "208.67.222.222"
]

In the case 2), measurement #10397471:

 %  wget -q -O - https://atlas.ripe.net/api/v2/measurements/10397471/results/ | 
jq "map(.dst_addr)"
[
  "9.9.9.9",
  "9.9.9.9",
  "9.9.9.9",
  "9.9.9.9",
  "9.9.9.9"
]

Re: [atlas] dig +trace equivalency

[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.

Re: [atlas] Trying to measure Quad9 latency

[Stephane Bortzmeyer]

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.

Re: [atlas] Trying to measure Quad9 latency

[Stephane Bortzmeyer]

On Wed, Nov 22, 2017 at 06:27:42PM +,
 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

[atlas] Recent TLS supported by probes?

[Stephane Bortzmeyer]

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?

Re: [atlas] Can Atlas probe handle Truncated response ?

[Stephane Bortzmeyer]

On Tue, Sep 05, 2017 at 11:33:23AM +0800,
 Davey Song  wrote 
 a message of 102 lines which said:

> I once setup a measurement of DNS UDP to see if the number of
> timeout increase due to large response. The answer is yes. But I
> wonder if the timeout is no answer after three times of retries or
> also includes TCP fallback.

The Atlas DNS test apparently tries only once, and, by default, does
not fallback to TCP. (Source: tcpdump.)

I don't think tou can ask for several tests. (Source:
)

[atlas] [rfc-edi...@rfc-editor.org: RFC 8193 on Information Model for Large-Scale Measurement Platforms (LMAPs)]

[Stephane Bortzmeyer]

This recent RFC on the data model for Internet measurements platform
is of course of interest for RIPE Atlas.

Note that their model separates controller and collector, which are
one in Atlas.
--- Begin Message ---
A new Request for Comments is now available in online RFC libraries.


RFC 8193

Title:  Information Model for Large-Scale Measurement 
Platforms (LMAPs) 
Author: T. Burbridge, P. Eardley,
M. Bagnulo, J. Schoenwaelder
Status: Standards Track
Stream: IETF
Date:   August 2017
Mailbox:trevor.burbri...@bt.com, 
philip.eard...@bt.com, 
marc...@it.uc3m.es, 
j.schoenwael...@jacobs-university.de
Pages:  53
Characters: 124022
Updates/Obsoletes/SeeAlso:   None

I-D Tag:draft-ietf-lmap-information-model-18.txt

URL:https://www.rfc-editor.org/info/rfc8193

DOI:10.17487/RFC8193

This Information Model applies to the Measurement Agent within an
LMAP framework.  As such, it outlines the information that is
configured or preconfigured on the Measurement Agent or exists in
communications with a Controller or Collector within an LMAP
framework.  The purpose of such an Information Model is to provide a
protocol- and device-independent view of the Measurement Agent that
can be implemented via one or more Control and Report Protocols.

This document is a product of the Large-Scale Measurement of Broadband 
Performance Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-edi...@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC


___
lmap mailing list
l...@ietf.org
https://www.ietf.org/mailman/listinfo/lmap
--- End Message ---

[atlas] [ripe-atlas-tools] Anyone had success with renderer aggregate_ping?

[Stephane Bortzmeyer]

I cannot make the renderer aggregate_ping work:

https://github.com/RIPE-NCC/ripe-atlas-tools/issues/186

[atlas] TLS tests with login.live.com

[Stephane Bortzmeyer]

TLS tests from the Atlas probes work for me, for every server... *but*
login.live.com, for which I always get timeouts (it works with other
TLS clients).

Measurement #8775150 if someone has an idea...

Re: [atlas] DNS and recursion

[Stephane Bortzmeyer]

On Mon, May 22, 2017 at 02:15:54PM +0200,
 Chris Amin  wrote 
 a message of 89 lines which said:

> This behaviour is still
> documented in the manual:
> https://atlas.ripe.net/docs/api/v2/manual/measurements/types/type_specific_attributes.html

OK, I see, there was a problem in my tests, sorry. Indeed, if I set
use_probe_resolver to false, *and* set_rd_bit to false, I get no recursion:

17:10:25.438994 IP (tos 0x0, ttl 64, id 16851, offset 0, flags [DF],
proto UDP (17), length 79)
192.168.2.8.58886 > 80.67.169.12.53: [udp sum ok] 13066 A? 
hdsfdfsqgsqdfysq.bernardtapie.com. (51)

(Measurement #8772374)

If use_probe_resolver is true, I always have recursion enabled,
set_rd_bit is indeed silently ignored. (Something that could be
documented in
)

[atlas] DNS and recursion

[Stephane Bortzmeyer]

API v1 had a field recursion_desired when performing DNS
measurements. If I remember correctly (but I cannot find the reference
right now), it worked only when querying a specific name server, and
not when using the probe's own resolver, to avoid cache snooping.

API v2 has instead a set_rd_bit. Documentation

does not indicate its default value.

Anyway, my experience with the API is that the RD (Recursion Desired)
bit is always set, whether with 'set_rd_bit': False or with
'set_rd_bit': True, and independant of use_probe_resolver.

I can understand this choice for privacy reasons (RFC 7626, section
2.3). But, in that case, the documentation should be fixed.

Anything I missed?

(Here, a request by a probe, the + after the Query ID - here, 52379 -
means the RD bit is set

12:22:23.170304 IP (tos 0x0, ttl 64, id 2287, offset 0, flags [DF], proto UDP 
(17), length 65)
192.168.2.8.45955 > 212.27.40.240.53: [udp sum ok] 52379+ ? 
uucp.bortzmeyer.org. (37)

Re: [atlas] DNS over TCP problems?

[Stephane Bortzmeyer]

On Tue, Mar 21, 2017 at 05:10:02PM +0100,
 Stephane Bortzmeyer <bortzme...@nic.fr> wrote 
 a message of 204 lines which said:

> [I did not test it myself.]

According to DNSmon, there is indeed a problem since 14 March:

https://atlas.ripe.net/dnsmon/group/fr.?dnsmon.session.color_range_pls=0-10-10-50-100=true=zone-servers=fr.=undefined=1488974400=1490112000=false=both=true

Re: [atlas] Cannot understand the daily limit

[Stephane Bortzmeyer]

On Tue, Mar 21, 2017 at 03:11:46PM +0100,
 Stephane Bortzmeyer <bortzme...@nic.fr> wrote 
 a message of 15 lines which said:

> But I'm still puzzled about exactly what happened. I checked my
> previous measurements (such as #7932387) and they were clearly
> marked "This is a one-off measurement" (otherwise, I would have
> burned all my credits for a long time!)

And the official documentation disagrees with
you. 
<https://atlas.ripe.net/docs/api/v2/reference/#!/measurements/Measurement_List_POST>
lists is_oneoff both at the top-level of the JSON object, and under
"definitions".

[atlas] DNS over TCP problems?

[Stephane Bortzmeyer]

[I did not test it myself.]
--- Begin Message ---
It appears that RIPE ATLAS is having issues with the ability to do TCP-based 
DNS queries as part of their probes.

Anyone else able to confirm this issue?

Here's an image of RIPE ATLAS saying that all of L-Root is unreachable on TCP.

-Jacob Zack
DNS Architect - CIRA (.CA TLD)



___
dns-operations mailing list
dns-operati...@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-operations mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-operations--- End Message ---

Re: [atlas] Cannot understand the daily limit

[Stephane Bortzmeyer]

On Tue, Mar 21, 2017 at 12:30:05PM +0100,
 Viktor Naumov  wrote 
 a message of 20 lines which said:

> The system thinks that you are creating a recurrent measurements
> which costs above 1M. You're putting the one-off flag inside
> definitions but it must be outside. Like {"is_oneoff": true,
> "definitions": [

OK, it works, thanks, I can now ask measurements with a lot of probes.

But I'm still puzzled about exactly what happened. I checked my
previous measurements (such as #7932387) and they were clearly marked
"This is a one-off measurement" (otherwise, I would have burned all my
credits for a long time!)

Re: [atlas] Cannot understand the daily limit

[Stephane Bortzmeyer]

On Tue, Mar 21, 2017 at 12:30:05PM +0100,
 Viktor Naumov  wrote 
 a message of 20 lines which said:

> The system thinks that you are creating a recurrent measurements
> which costs above 1M. You're putting the one-off flag inside
> definitions but it must be outside. Like {"is_oneoff": true,
> "definitions": [

It worked before, I guess it changed with API v2. OK, I modify.

[atlas] Trivia of the day: Atlas probes and alternative DNS roots

[Stephane Bortzmeyer]

A quick test with a thousand probes seem to indicate that less than a
dozen of all the probes use an alternative DNS root (or, more stricly,
use a DNS resolver which is configured for an alternative root).

The only alternative root used seems to be OpenNIC.

Measurements #7865679 #7865870 #7865872 #7865873

[atlas] Atlas API down?

[Stephane Bortzmeyer]

RIPEAtlas.RequestSubmissionError: Status 405, reason
"{"error":{"status":405,"code":104,"detail":"Method \"POST\" not
allowed.","title":"Method Not Allowed"}}"

Just when I wanted to investigate pool.ntp.org failure :-(

Re: [atlas] ripe.atlas.net issues

[Stephane Bortzmeyer]

On Wed, Oct 05, 2016 at 01:54:59PM +0200,
 Max Mühlbronner  wrote 
 a message of 8 lines which said:

> "Oops - this page experienced an error while loading." My atlas / My probe
> does not work, the checks are failing. (Since ~12 minutes)

RIPE Atlas Web site works for me (but ripe.atlas.net is indeed very
slow :-)

Re: [atlas] "Invalid target" error for RFC 1918 space

[Stephane Bortzmeyer]

On Sun, Sep 18, 2016 at 10:19:52AM -0500,
 Yang Yu  wrote 
 a message of 9 lines which said:

> I got "Invalid target" error when I tried to create a measurement to
> see how far some RFC 1918 prefixes got propagated (carrier not
> properly filtering customer announcement). What is considered
> invalid for each measurement type?

Security/privacy reasons: without this rule, people could scan private
networks where a probe is hosted.

[atlas] Alternative to jq: gron

[Stephane Bortzmeyer]

It seems many people here use jq to browse JSON files. I've been
referred recently to gron  which is
quite different: less features but probably simpler to use for
beginners. Unlike jq, gron does not have a filtering language: it just
formats the JSON in a way that makes simple to use traditional grep.

Here is an example with measurement #4477822, a DNS one:

% gron 4477822.json|more   
json = [];
json[0] = {};
json[0].from = "178.248.214.8";
json[0].fw = 4730;
json[0].group_id = 4477822;
json[0].lts = 18;
...

Selecting the values of the serial number is as simple as:

% gron 4477822.json | grep SERIAL
json[0].resultset[0].result.answers[0].SERIAL = 2223898795;
json[0].resultset[1].result.answers[0].SERIAL = 2223898793;
json[1].resultset[0].result.answers[0].SERIAL = 2223898790;
json[1].resultset[1].result.answers[0].SERIAL = 2223898792;
json[1].resultset[2].result.answers[0].SERIAL = 2223898795;
json[2].resultset[0].result.answers[0].SERIAL = 2223898791;
...

And you can turn back the result of the filtering into JSON.

[atlas] Implementing structured error reports ("Problem Details for HTTP APIs")?

[Stephane Bortzmeyer]

Hello,

IETF approved the future RFC draft-ietf-appsawg-http-problem "Problem
Details for HTTP APIs" which standardize structured error reports (in
JSON) to add machine-readable information to HTTP error codes.

Would it be a good idea to convert current Atlas reports
({"error":{"status":400,"code":104,"detail":"__all__: Your selected
prefix is not covered by our network.","title":"Bad Request"}}) to the
new and standard format?

Re: [atlas] integrity checks for the Atlas software?

[Stephane Bortzmeyer]

On Tue, Jan 12, 2016 at 06:54:09AM -0500,
 Tanner Ryan  wrote 
 a message of 52 lines which said:

> I think that is completely possible.

No, for the reasons explained by Micha and Dario.

For a detailed survey (using the PC as an example), see this excellent
review 

Re: [atlas] more than 10 concurrent measurements to the same target

[Stephane Bortzmeyer]

On Wed, Dec 09, 2015 at 07:38:52PM +0100,
 Klaus Darilion  wrote 
 a message of 12 lines which said:

> 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.

I believe that the counter is global (not just your measurements). I
often see this error when measuring 8.8.8.8 (a very popular target).

Re: [atlas] Support for arbitrary DNS queries

[Stephane Bortzmeyer]

On Wed, Dec 09, 2015 at 08:51:21PM +0200,
 Micha Bailey  wrote 
 a message of 48 lines which said:

> > A partial workaround is to use ANY as a query_type.
> >
> > Not necessarily:
> https://tools.ietf.org/html/draft-jabley-dnsop-refuse-any-00#section-8 and
> http://blog.cloudflare.com/deprecating-dns-any-meta-query-type/, for
> example.

I know the semantics of ANY, thanks :-)

That's why I called it a "partial" workaround.

[atlas] DNSmon "not indicative of what happens to normal traffic" claims the root ops

[Stephane Bortzmeyer]

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

Re: [atlas] [Request] System tags for DNS resolution

[Stephane Bortzmeyer]

On Sun, Nov 15, 2015 at 09:32:09AM +0200,
 Chris Amin  wrote 
 a message of 64 lines which said:

> I think what is happening here is that all of those probes except
> for 17854 have at least *one* resolver which does respond to
> queries.

OK, I get it. I modified resolve-name

to continue if the fist resolver returns REFUSED or SERVFAIL

Thanks for the explanations.

> why it has the tag "Doesn't Resolve A".

Do note that many tags documented in
 do not work
(reported as [ripe.net #1195138]).

> I would be interested to hear your (or anybody else's) thoughts on
> whether you would use such a reliable/stable DNS resolution tag, and
> what kind of criteria you would expect for it to be applied.

The current system is not bad, once it is explained and the above bug
fixed.

Re: [atlas] Spoofing measurenment

[Stephane Bortzmeyer]

On Tue, Nov 17, 2015 at 07:01:24PM +0100,
 Peter Koch  wrote 
 a message of 10 lines which said:

> while this may sound tempting, I think it would be more helpful in
> the long run to maintain atlas probes as a tool to map the Internet
> rather than as "spy in the house".

Hmmm, the Atlas probe already learns a lot about the house and
publishes it:

* "this house uses Google Public DNS"
* "this house uses a validating DNS resolver"
* "this house uses IPv6 ULA"

Re: [atlas] [Request] System tags for DNS resolution

[Stephane Bortzmeyer]

On Thu, Nov 12, 2015 at 10:41:03AM +0100,
 Chris Amin  wrote 
 a message of 75 lines which said:

> > For instance, probes 16659, 17072, 17620, 17854 use a resolver
> > which yields a REFUSED for any request and probe 19948, 20065 one
> > with systematic SERVFAIL.
...
> The above probes are mostly tagged as "resolves-a[aaa]-correctly"
> because they managed to resolve certain A records (e.g. MSM ID
> 1698856).  Can you provide the measurement ID(s) where you see the
> REFUSED and SERVFAIL responses?

Probes 19948, 20065 now seems OK. But 16659, 17072, 17620, 17854 still
return REFUSED: measurements #2928193 and #2928199.

[atlas] [Request] System tags for DNS resolution

[Stephane Bortzmeyer]

[Is there a better way to record enhancement requests for Atlas? Atlas
has no public issue tracker, if I'm correct?]

It would be cool to have system (automatic) tags for DNS resolution
because some probes are using broken DNS resolvers. For instance,

system-dns-works (modeled on IPv6's system tag) would be fine. Or may
be system-dns-resolver-works (longer but more accurate).

For instance, probes 16659, 17072, 17620, 17854 use a resolver which
yields a REFUSED for any request and probe 19948, 20065 one with
systematic SERVFAIL.

[Is the maintainer of the probe automatically notified when there is
such an issue?]

[atlas] Any way to select the probes from upstream AS (not origin AS)?

[Stephane Bortzmeyer]

Is there an easy way to select probes, not on the origin AS, but on an
AS upstream? Example: probe 23865, IP prefix announced by AS 56339
which currently has only one provider, AS 16080. Currently, Atlas
tells me there are no probes in AS 16080...

Re: [atlas] VM probes

[Stephane Bortzmeyer]

On Mon, Nov 09, 2015 at 12:49:19PM +,
 Colin Johnston  wrote 
 a message of 30 lines which said:

> one vote for vmware virtualisation

Strong -1 against any proprietary technology. Free software or
nothing. (But, like most people here, I'm not interested in VM probes
and even less in VM anchors.)

Re: [atlas] Any way to select the probes from upstream AS (not origin AS)?

[Stephane Bortzmeyer]

On Wed, Nov 11, 2015 at 04:43:49PM +0100,
 Robert Kisteleki  wrote 
 a message of 14 lines which said:

> No, we don't have direct support for this. I guess one could
> download latest traceroute results for a (random) built-in
> measurement, map IPs to ASNs and use that -- but I have to admit
> it's not easy.

I understand. Also, a probe has one origin AS but may have several
upstream AS and you don't know which one will be used when the probe
fires a packet to the target.

Re: [atlas] Read on RIPE Labs about the newest features & the community efforts

[Stephane Bortzmeyer]

On Thu, Nov 05, 2015 at 10:36:11AM +0100,
 Vesna Manojlovic  wrote 
 a message of 9 lines which said:

> https://labs.ripe.net/Members/kistel/ripe-atlas-update-http-measurements-cli-tools-domainmon-and-more

Apparently, there is no link to the documentation of the API v2. Where
is it? I need it to modify my programs (one more thing to do :-(