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

2017-12-04 Thread Philip Homburg 
On 2017/12/03 17:36 , Stephane Bortzmeyer wrote:
> 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.
> 

> 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

It may be worth pointing out that resolve_on_probe has effect if two
conditions are met:
1) use_probe_resolver is false
2) the measurement target is a dns name (as opposed to an IP address
literal)

In your quad-9 example, the target is a literal, so resolve_on_probe has
no effect.

The following DNS measurement uses resolve_on_probe:
https://atlas.ripe.net/measurements/10404214/

Here is an example measurement result:
{"af":4,"dst_addr":"193.0.9.7","from":"73.34.225.118","fw":4780,"group_id":10404214,"lts":38,"msm_id":10404214,"msm_name":"Tdig","name":"manus.authdns.ripe.net","prb_id":21675,"proto":"UDP","result":{"ANCOUNT":1,"ARCOUNT":0,"ID":55944,"NSCOUNT":0,"QDCOUNT":1,"abuf":"2oiEAAABAAEAA3d3dwRyaXBlA25ldQABwAwAAQABAABUYAAEwQAGiw==","rt":131.954,"size":46},"src_addr":"192.168.29.154","stored_timestamp":1512385062,"timestamp":1512385044,"type":"dns"}

The probe reports that it resolved 'name' manus.authdns.ripe.net to
'dst_addr' 193.0.9.7

Philip

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

2017-12-03 Thread 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] Effect of "Resolve on Probe"-option

2017-12-01 Thread Tim Wattenberg 
Robert, thanks for your explanations. I now do understand this for all
measurements exept for those of type DNS.
DNS measurements with a central resolver somehow seem not that useful to
me. Am I missing the use case here?

Context: I want to measure the consistency of DNS records or how they are
seen inside the probes networks.
In my measurement I activated the option to use the probes resolver(s) and
left the option to resolve on the probe deactivated.
Does this simulate the scenario of a client asking its local DNS resolver
(e.g. assigned by DHCP)?

Thanks, Tim

Tim Wattenberg
m...@timwattenberg.de
+49 1578 8248731

2017-12-01 10:45 GMT+01:00 Robert Kisteleki :

>
> On 2017-11-30 20:27, Tim Wattenberg wrote:
> > 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
>
> Hi,
>
> When you measure something given with a DNS name and leave this option
> to its default settings, then the DNS resolution happens once, in the
> infrastructure (somewhere in Amsterdam, NL), and the probes are told to
> measure towards the resolved *IP*. This is more efficient, prevents DNS
> errors on the edges, but only works if DNS can only give one answer.
>
> If you turn on "resolve on probe", then the probes get to measure the
> *name* you entered, and do the DNS resolution themselves every single
> time they measure. This has a somewhat higher chance of failure, but
> it's needed if the resolved IP depends on the location of the vantage
> point.
>
> Hope this helps,
> Robert
>
>

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

2017-12-01 Thread Robert Kisteleki 

On 2017-11-30 20:27, Tim Wattenberg wrote:
> 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

Hi,

When you measure something given with a DNS name and leave this option
to its default settings, then the DNS resolution happens once, in the
infrastructure (somewhere in Amsterdam, NL), and the probes are told to
measure towards the resolved *IP*. This is more efficient, prevents DNS
errors on the edges, but only works if DNS can only give one answer.

If you turn on "resolve on probe", then the probes get to measure the
*name* you entered, and do the DNS resolution themselves every single
time they measure. This has a somewhat higher chance of failure, but
it's needed if the resolved IP depends on the location of the vantage point.

Hope this helps,
Robert