Skip to content
This repository has been archived by the owner on Aug 28, 2019. It is now read-only.

DNS requirements for OONI #5

Open
bassosimone opened this issue Dec 12, 2018 · 4 comments
Open

DNS requirements for OONI #5

bassosimone opened this issue Dec 12, 2018 · 4 comments

Comments

@bassosimone
Copy link
Member

(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
Copy link
Member Author

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
Copy link
Member Author

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

@darkk
Copy link

darkk commented Dec 13, 2018

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
Copy link
Member Author

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

@bassosimone bassosimone transferred this issue from measurement-kit/measurement-kit Apr 25, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants