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)