search

measurement-kit / engine

[DEPRECATED] Measurement Kit engine written in Go
https://measurement-kit.github.io/
BSD 3-Clause "New" or "Revised" License
0 stars 0 forks source link

DNS requirements for OONI #5

Open bassosimone opened 5 years ago

bassosimone commented 5 years ago

(This ticket will consolidate other existing tickets that discuss DNS matters.)

In OONI we have at least the following requirements:

  1. we can resolve domain names in IP addresses and canonical names

  2. we can issue, at least, A and AAAA UDP queries

  3. we can specify a custom nameserver, which may possibly be a custom nameserver but may also possibly be the platform specific nameserver (this means that we should make our code for getting such nameserver less brittle, especially on Android devices)

  4. we can save the sent and received DNS messages (hence we can gather the precise error code sent to us by the server #1576, which makes it useless to map error codes per #990 because we will be saving raw datagrams)

  5. we can save the timing of messages

  6. we can gather network errors

  7. we can perform a parasitic traceroute

  8. we can send queries over TCP

  9. we can send other queries than A and AAAA

  10. we can measure duplicate responses (see #1449)

  11. we can perform non stub resolutions, DNSSEC validation, etc

  12. we can perform some of the above on Android and iOS

As we concluded with @irl in the recent PATHspider hackathon, not all these requirements could be implemented using the same library. A previous ticket suggested that we used getdns (see #1495) but some of the requirements are not possible with getdns. We also considered using c-ares, and again some of this stuff is not super easy with c-ares. It has also been suggested that we could manage directly our sockets and use either c-ares or ldns to write/parse messages. (All this paragraph encompasses what has been briefly written in #1430, furthermore implementing a low level DNS engine will make #1011 irrelevant because new code will be written).

I am going to close the issues mentioned above as superseded by this overarching issue.

bassosimone commented 5 years ago

I have added this issue to be part of MK v0.11.0. I do not believe it will be possible to have all the above mentioned functionality in such release. But we'll start working in this direction as part of that.

Specifically, today I've published on github measurement-kit/mkudns, which I started developing during the PATHspider hackathon, and which implements points 0-6 above using c-ares as backend. We will start by including this functionality in MK as part of v0.11.0 and then we'll collect some data, learn more, and decide how to further move forward our DNS engine.

bassosimone commented 5 years ago

Added also to MK future, because this is not gonna be finished in v0.11.0.

darkk commented 5 years ago

I think, there is one bit possibly missing from bullet point no. 2:

we can specify a custom nameserver

I believe, it should be written as

we can specify both a custom nameserver and a "platform-provided" nameserver

I say so, as I remember you saying that getting nameserver IP address* from the platform may be non-trivial. But I also recognize that it may be out of scope of this ticket, so maybe I'm wrong.

*) or legacy IPv4 address if the network still uses IPv4. And I'm not trolling here, cellular networks across the world are adopting IPv6 as we speak. And OONI will have lots of fun with DNS64.

bassosimone commented 5 years ago

@darkk thank you, I have updated the proper entry accordingly!