Strong doubts about the option "DNS recursion"
I fear that the option "recursion_desired" <https://atlas.ripe.net/doc/measurement-creation-api/> does not work as expected. Here was my experiment. I registered a new domain name which never appeared before, d7b16b2a97627e8ccbcccf93e773ec3f.cosmogol.fr. Because of its unreadability, there is zero chance it has ever been in a DNS cache. I then ask Atlas probes to dig it, with "recursion_desired" set to false: {'definitions': [{'query_class': 'IN', 'use_probe_resolver': True, 'af': 4, 'query_argument': 'd7b16b2a97627e8ccbcccf93e773ec3f.cosmogol.fr', 'query_type': 'TXT', 'type': 'dns', 'is_oneoff': True, 'recursion_desired': False, 'description': 'DNS resolution of d7b16b2a97627e8ccbcccf93e773ec3f.cosmogol.fr'}], 'probes': [{'requested': 10, 'type': 'area', 'value': 'WW'}]} But all the probes got the content of this TXT record! Measurement #1034372 if you want to check (unfortunately, this parameter is not displayed in <https://atlas.ripe.net/atlas/udm.html?msm_id=1034372>). It seems wrong, they should all have retrieved an empty answer (here, with dig, the behaviour I expected): % dig +norecurse @MYSERVER TXT d7b16b2a97627e8ccbcccf93e773ec3f.cosmogol.fr ; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +norecurse @relay1 TXT d7b16b2a97627e8ccbcccf93e773ec3f.cosmogol.fr ; (2 servers found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 33141 ;; flags: qr ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 21 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;d7b16b2a97627e8ccbcccf93e773ec3f.cosmogol.fr. IN TXT ;; AUTHORITY SECTION: fr. 165392 IN NS d.ext.nic.fr. fr. 165392 IN NS d.nic.fr. ...
On Fri, Oct 25, 2013 at 12:15:28PM +0200, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote a message of 35 lines which said:
{'definitions': [{'query_class': 'IN', 'use_probe_resolver': True, 'af': 4, 'query_argument': 'd7b16b2a97627e8ccbcccf93e773ec3f.cosmogol.fr', 'query_type': 'TXT', 'type': 'dns', 'is_oneoff': True, 'recursion_desired': False, 'description': 'DNS resolution of d7b16b2a97627e8ccbcccf93e773ec3f.cosmogol.fr'}], 'probes': [{'requested': 10, 'type': 'area', 'value': 'WW'}]}
I created a second domain by the same method, changed only the recursion_desired option and got exactly the same result (measurement #1034374): {'definitions': [{'query_class': 'IN', 'use_probe_resolver': True, 'af': 4, 'query_argument': 'ea4f6f5b9176b3d55061e5bd85410c1b.cosmogol.fr', 'query_type': 'TXT', 'type': 'dns', 'is_oneoff': True, 'recursion_desired': True, 'description': 'DNS resolution of ea4f6f5b9176b3d55061e5bd85410c1b.cosmogol.fr'}], 'probes': [{'requested': 10, 'type': 'area', 'value': 'WW'}]} So, it seems as if recursion_desired is ignored and the reality is that the RD bit is always set. By the way, this investigation was done because some people, to monitor the content of the DNS caches, use open resolvers (<https://indico.dns-oarc.net//getFile.py/access?contribId=7&resId=1&materialId=slides&confId=1> and <http://samarudge.github.io/dnsyo/>) and I tought it would be better to use Atlas probes. But the tests may have to be run without RD, otherwise you risk "poisoning" the caches, if you use the measurement to test a hijacking, for instance, as in the first example mentioned.
Hi Stephane, On 2013/10/25 12:41 , Stephane Bortzmeyer wrote:
So, it seems as if recursion_desired is ignored and the reality is that the RD bit is always set.
By the way, this investigation was done because some people, to monitor the content of the DNS caches, use open resolvers (<https://indico.dns-oarc.net//getFile.py/access?contribId=7&resId=1&materialId=slides&confId=1> and <http://samarudge.github.io/dnsyo/>) and I tought it would be better to use Atlas probes. But the tests may have to be run without RD, otherwise you risk "poisoning" the caches, if you use the measurement to test a hijacking, for instance, as in the first example mentioned.
The RD bit is set because Atlas is supposed to do active measurements and not probe the host's systems. One obvious bug is that this behavior is not documented. Whether setting this flag is a good idea is of course subject to debate. Another thing is that just silently setting the flag is not optimal, maybe the measurement should have been rejected instead. Philip
On Fri, Oct 25, 2013 at 01:14:41PM +0200, Philip Homburg <philip.homburg@ripe.net> wrote a message of 25 lines which said:
One obvious bug is that this behavior is not documented.
It is much worse: it _is_ documented and the documentation is wrong. I spent two hours on that this morning and, as you can imagine, I'm not happy.
Another thing is that just silently setting the flag is not optimal,
It is not "not optimal", it is _wrong_.
maybe the measurement should have been rejected instead.
And the documentation fixed!
On 2013/10/25 13:59 , Stephane Bortzmeyer wrote:
On Fri, Oct 25, 2013 at 01:14:41PM +0200, Philip Homburg <philip.homburg@ripe.net> wrote a message of 25 lines which said:
One obvious bug is that this behavior is not documented.
It is much worse: it _is_ documented and the documentation is wrong. I spent two hours on that this morning and, as you can imagine, I'm not happy.
To avoid further confusion, which part of the documentation did you read? The measurement API? (https://atlas.ripe.net/doc/measurement-creation-api/) Philip
On Fri, Oct 25, 2013 at 02:04:57PM +0200, Philip Homburg <philip.homburg@ripe.net> wrote a message of 16 lines which said:
which part of the documentation did you read? The measurement API? (https://atlas.ripe.net/doc/measurement-creation-api/)
Yes: Name Description Default Required? Price Modifier recursion_desired false
On 2013/10/25 14:07 , Stephane Bortzmeyer wrote:
On Fri, Oct 25, 2013 at 02:04:57PM +0200, Philip Homburg <philip.homburg@ripe.net> wrote a message of 16 lines which said:
which part of the documentation did you read? The measurement API? (https://atlas.ripe.net/doc/measurement-creation-api/)
Yes:
Name Description Default Required? Price Modifier recursion_desired false
The documentation is now updated to reflect the actual behavior. Philip
On Fri, Oct 25, 2013 at 03:12:09PM +0200, Philip Homburg <philip.homburg@ripe.net> wrote a message of 17 lines which said:
The documentation is now updated to reflect the actual behavior.
OK, it makes sense, thanks.
On Fri, 25 Oct 2013 13:59:12 +0200 in <20131025115912.GA2543@nic.fr>, Stephane Bortzmeyer <bortzmeyer@nic.fr> wrote:
Another thing is that just silently setting the flag is not optimal,
It is not "not optimal", it is _wrong_.
maybe the measurement should have been rejected instead.
And the documentation fixed!
Give us the source code also, the software will be also fixed in less than one hour. Does RIPE plan to release source code or not ? How can a user (its working on whatever you what) trust a measurement system that just do not give the basic level of transparency that a measurement system *need* to be trusted ? The availability of the source code to every single user ! the code can be modified or not, I just do not care about license issue, what I care about is the measurement system transparency, the rest is poetry for brainless persons). -- Jérôme Benoit aka fraggle OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D
Hi Jérôme, It is there: https://atlas.ripe.net/get-involved/source-code/ /vty On 10/26/13 6:20 AM, Jérôme Benoit wrote:
Give us the source code also, the software will be also fixed in less than one hour. Does RIPE plan to release source code or not ?
How can a user (its working on whatever you what) trust a measurement system that just do not give the basic level of transparency that a measurement system *need* to be trusted ? The availability of the source code to every single user ! the code can be modified or not, I just do not care about license issue, what I care about is the measurement system transparency, the rest is poetry for brainless persons).
On Sat, 26 Oct 2013 10:54:51 +0200 in <526B835B.8070901@ripe.net>, Viktor Naumov <vnaumov@ripe.net> wrote:
Hi Jérôme,
It is there: https://atlas.ripe.net/get-involved/source-code/
Great ! Should have search before posting :) ++ -- Jérôme Benoit aka fraggle OpenPGP Key ID : 9FE9161D Key fingerprint : 9CA4 0249 AF57 A35B 34B3 AC15 FAA0 CB50 9FE9 161D
On Sat, Oct 26, 2013 at 09:04:41PM +0200, Jérôme Benoit <jerome.benoit@grenouille.com> wrote a message of 34 lines which said:
It is there: https://atlas.ripe.net/get-involved/source-code/
Great ! Should have search before posting :)
It is very recent, many people asked for it in the previous years. Also, I believe it is "only" the Atlas probe's source code, not the C&C source code.
participants (4)
-
Jérôme Benoit -
Philip Homburg -
Stephane Bortzmeyer -
Viktor Naumov