Effect of "Resolve on Probe"-option
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
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
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 mail@timwattenberg.de +49 1578 8248731 2017-12-01 10:45 GMT+01:00 Robert Kisteleki <robert@ripe.net>:
Hi everyone,
I think I don’t quite understand the effect of the „Resolve on Probe“
On 2017-11-30 20:27, Tim Wattenberg wrote: 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
On Fri, Dec 01, 2017 at 03:44:22PM +0100, Tim Wattenberg <mail@timwattenberg.de> 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 <https://atlas.ripe.net/docs/api/v2/reference/#!/measurements/Dns_Type_Measurement_List_POST> 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-aaaa-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" ]
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":"2oiEAAABAAEAAAAAA3d3dwRyaXBlA25ldAAAAQABwAwAAQABAABUYAAEwQAGiw==","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
participants (4)
-
Philip Homburg -
Robert Kisteleki -
Stephane Bortzmeyer -
Tim Wattenberg