You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Aug 28, 2019. It is now read-only.
(This ticket will consolidate other existing tickets that discuss DNS matters.)
In OONI we have at least the following requirements:
we can resolve domain names in IP addresses and canonical names
we can issue, at least, A and AAAA UDP queries
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)
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)
we can save the timing of messages
we can gather network errors
we can perform a parasitic traceroute
we can send queries over TCP
we can send other queries than A and AAAA
we can measure duplicate responses (see #1449)
we can perform non stub resolutions, DNSSEC validation, etc
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.
The text was updated successfully, but these errors were encountered:
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.
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.
(This ticket will consolidate other existing tickets that discuss DNS matters.)
In OONI we have at least the following requirements:
we can resolve domain names in IP addresses and canonical names
we can issue, at least, A and AAAA UDP queries
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)
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)
we can save the timing of messages
we can gather network errors
we can perform a parasitic traceroute
we can send queries over TCP
we can send other queries than A and AAAA
we can measure duplicate responses (see #1449)
we can perform non stub resolutions, DNSSEC validation, etc
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.
The text was updated successfully, but these errors were encountered: