REST API Problems for DNS measurements with DO and TCP
Hi! I managed to create DNS measurements via the REST API, but fail to set the DO and protocol:TCP option. According to the documentation (https://atlas.ripe.net/doc/measurement-creation-api/) the relevant properties are use_EDNS0 and use_tcp. So I tried it with { "definitions": [ { "is_public": true, "is_oneoff" : false, "target": "194.0.25.13", "description": "a.dns.nic.versicherung_IP4_TCP_noDO", "type": "dns", "af": 4, "interval": 300, "use_EDNS0": false, "use_TCP": true, "use_probe_resolver": false, "use_NSID": true, "query_class": "IN", "query_type": "SOA", "query_argument": "versicherung", "udp_payload_size": 1024, "protocol": "TCP", "do": true } ], } but that does not work - the generated measurements do not use TCP and DO. When I create the measurement via the web interface and review the measurement via the REST API, I see that other properties are set: "do" and "protocol". E.g: # curl https://atlas.ripe.net/api/v1/measurement/1027747/ {"all_scheduling_requests_fulfilled": true, "can_visualise": false, "creation_time": 1380018470, "description": "TEST via WEB", "do": true, "dst_addr": "194.0.25.13", "dst_asn": "1921", "dst_name": "194.0.25.13", "interval": 240, "is_oneoff": true, "is_public": true, "msm_id": 1027747, "nsid": true, "participant_count": 1, "protocol": "TCP", "query": {"class": "IN", "type": "SOA", "value": "versicherung."}, "resolve_on_probe": false, "resolved_ips": ["194.0.25.13"], "result": "/api/v1/measurement/1027747/result/", "start_time": 1380018470, "status": {"id": 7, "name": "Failed"}, "stop_time": 1380018904, "type": {"id": 6, "name": "dns"}, "udp_payload_size": 512} So I tried to create measurements with the "do" and "protocol" properties, but these properties are again ignored. If I am doing something wrong, so please give me some hints. Otherwise the API documentation is wrong and these properties can not be set via REST, only via the web interface - and should be fixed. Thanks Klaus
On Tue, Sep 24, 2013 at 01:05:34PM +0200, Klaus Darilion <klaus.mailinglists@pernau.at> wrote a message of 57 lines which said:
Hi! I managed to create DNS measurements via the REST API, but fail to set the DO and protocol:TCP option.
TCP worked for me (launched from the API). See public measurement #1025096, TCP is set. I just tried again (public measurement #1027850) with the attached program, launched as: python perf-dns.py -t -6 2001:678:c::1 and it seems to work
On Wed, Sep 25, 2013 at 10:17:44AM +0200, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote a message of 16 lines which said:
I just tried again (public measurement #1027850) with the attached program,
Really attached, this time.
On 09/24/2013 01:05 PM, Klaus Darilion wrote:
Hi! I managed to create DNS measurements via the REST API, but fail to set the DO and protocol:TCP option. According to the documentation (https://atlas.ripe.net/doc/measurement-creation-api/) the relevant properties are use_EDNS0 and use_tcp. So I tried it with
This was a mistake in our API (my bad). There was some confusion as to what should be used (|use_EDNS0|, |use_DO|, |do|, etc.) and it caused some unpredictability in the code. I have now gone through and (hopefully) changed everything to use |do| and nothing else. I've also updated the API doc. So, for the record, the request that started this thread should look like this: |{ "definitions": [ { "is_public": true, "is_oneoff" : false, "target": "194.0.25.13", "description": "a.dns.nic.versicherung_IP4_TCP_noDO", "type": "dns", "af": 4, "interval": 300, "use_TCP": true, "use_probe_resolver": false, "use_NSID": true, "query_class": "IN", "query_type": "SOA", "query_argument": "versicherung", "udp_payload_size": 1024, "protocol": "TCP", "do": true } ], ... }| If there are questions, or if you think that I've missed something, just let me know :-)
Hi Daniel! Thanks for the fast response. The usage of 'do' works now fine and the description is consistent with the usage. However there are still problems with 'protocol'/'use_tcp'. According to the API description, the property to use is 'use_tcp'. And using this property works when creating measurements. E.g. "use_tcp": "true", "protocol": "UDP", will use TCP for querying. But when reviewing the measurement, the property is called 'protocol', e.g. see https://atlas.ripe.net/api/v1/measurement/1028085/ <object> <status type="hash"> <id type="integer">1</id> <name>Scheduled</name> </status> <protocol>TCP</protocol> ... IMO, this should be consistent too. Thanks Klaus On 25.09.2013 12:35, Daniel Quinn wrote:
On 09/24/2013 01:05 PM, Klaus Darilion wrote:
Hi! I managed to create DNS measurements via the REST API, but fail to set the DO and protocol:TCP option. According to the documentation (https://atlas.ripe.net/doc/measurement-creation-api/) the relevant properties are use_EDNS0 and use_tcp. So I tried it with
This was a mistake in our API (my bad). There was some confusion as to what should be used (|use_EDNS0|, |use_DO|, |do|, etc.) and it caused some unpredictability in the code. I have now gone through and (hopefully) changed everything to use |do| and nothing else. I've also updated the API doc.
So, for the record, the request that started this thread should look like this:
|{ "definitions": [ { "is_public": true, "is_oneoff" : false, "target": "194.0.25.13", "description": "a.dns.nic.versicherung_IP4_TCP_noDO", "type": "dns", "af": 4, "interval": 300, "use_TCP": true, "use_probe_resolver": false, "use_NSID": true, "query_class": "IN", "query_type": "SOA", "query_argument": "versicherung", "udp_payload_size": 1024, "protocol": "TCP", "do": true } ], ... }|
If there are questions, or if you think that I've missed something, just let me know :-)
On Thu 26 Sep 2013 11:08:28 AM CEST, Klaus Darilion wrote: IMO, this should be consistent too. You know what, you‘re totally right. I had a rough time setting this all up in the beginning and this one slipped through the cracks. I’ve now gone ahead and made the change to the API to use |protocol| instead of |use_tcp|. New appropriate values include |TCP| or |UDP|. *Using the old method will no longer work*, and the documentation has been appropriately updated. Thanks for catching this, and my apologies to those of you who may be using |use_tcp|. I'm sure you can all agree though that consistency is best for something like this.
On 26.09.2013 14:11, Daniel Quinn wrote:
On Thu 26 Sep 2013 11:08:28 AM CEST, Klaus Darilion wrote:
IMO, this should be consistent too.
You know what, you‘re totally right. I had a rough time setting this all up in the beginning and this one slipped through the cracks. I’ve now gone ahead and made the change to the API to use |protocol| instead of |use_tcp|. New appropriate values include |TCP| or |UDP|. *Using the old method will no longer work*, and the documentation has been appropriately updated.
Thanks for catching this, and my apologies to those of you who may be using |use_tcp|. I'm sure you can all agree though that consistency is best for something like this.
I tested it and it works now as you describe. Thanks Klaus
participants (3)
-
Daniel Quinn -
Klaus Darilion -
Stephane Bortzmeyer