Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Make OONI Probe testing more resilient to network outages #88

Closed
bassosimone opened this issue Oct 7, 2019 · 1 comment
Closed

Make OONI Probe testing more resilient to network outages #88

bassosimone opened this issue Oct 7, 2019 · 1 comment
Assignees
@bassosimone
Labels
epic A collection of issues

Comments

@bassosimone
Copy link
Contributor

No description provided.

@bassosimone bassosimone added P0 epic A collection of issues labels Oct 7, 2019
@bassosimone bassosimone self-assigned this Oct 7, 2019
@bassosimone bassosimone changed the title Be more resilient to outages 1.5.2 Make OONI Probe testing more resilient to network outages Oct 7, 2019
@hellais hellais removed OTFy2 labels Oct 7, 2019
@bassosimone bassosimone mentioned this issue Oct 29, 2019
Merged
bassosimone added a commit to ooni/netx that referenced this issue Oct 30, 2019
@bassosimone
nervousresolver: use cloudflare IP address
469549b 
We should probably introduce a longer chain of fallbacks in the
nervous resolver, but, for now, using the IP address is good enough
because it can protect us against the whole DNS being down.

This happened to me in Italy, when "Vodafone rete sicura" had
several hours of outage and the default DNS was not working as
intended, while there was IP connectivity.

Reference issue: ooni/probe-engine#88
@bassosimone bassosimone mentioned this issue Oct 30, 2019
Merged
bassosimone added a commit to ooni/netx that referenced this issue Oct 30, 2019
@bassosimone
nervousresolver: use cloudflare IP address (#94)
1ec4f0b 
We should probably introduce a longer chain of fallbacks in the
nervous resolver, but, for now, using the IP address is good enough
because it can protect us against the whole DNS being down.

This happened to me in Italy, when "Vodafone rete sicura" had
several hours of outage and the default DNS was not working as
intended, while there was IP connectivity.

Reference issue: ooni/probe-engine#88
@hellais hellais changed the title 1.5.2 Make OONI Probe testing more resilient to network outages Make OONI Probe testing more resilient to network outages Oct 31, 2019
bassosimone added a commit to ooni/netx that referenced this issue Oct 31, 2019
@bassosimone
Merge nervousresolver chaining with stable code
1e281c3 
Now, rather than using nervousresolver as an opt-in that is not
so easy to use, you can chain as many resolvers as you wish.

Xref: ooni/probe-engine#88
@bassosimone bassosimone mentioned this issue Oct 31, 2019
Merged
bassosimone added a commit to ooni/netx that referenced this issue Oct 31, 2019
@bassosimone
Merge nervousresolver chaining with stable code (#106)
c29f7ee 
Now, rather than using nervousresolver as an opt-in that is not
so easy to use, you can chain as many resolvers as you wish.

Xref: ooni/probe-engine#88
bassosimone added a commit to ooni/netx that referenced this issue Oct 31, 2019
@bassosimone
porcelain: Implement automatic DNS fallback
099ad99 
Xref:
- ooni/probe-engine#87
- ooni/probe-engine#88
@bassosimone bassosimone mentioned this issue Oct 31, 2019
Merged
bassosimone added a commit to ooni/netx that referenced this issue Oct 31, 2019
@bassosimone
porcelain: Implement automatic DNS fallback (#108)
894dd76 
Xref:
- ooni/probe-engine#87
- ooni/probe-engine#88
This was referenced Nov 1, 2019
Closed
Closed
Closed
@bassosimone
Copy link
Contributor Author

I have implemented this functionality in https://github.com/ooni/netx, a more low-level library where this functionality was better placed. I have uses https://github.com/ooni/jafar to calibrate timeouts and retransmissions, and have concluded the following (see also ooni/netx@9a94f46)

  1. we should configure conservative timeouts (e.g. 30s for connect)

  2. we should use Go deadlines to terminate operations that are running for too long time

This is better than using just short timeouts to guarantee that the whole duration of an operation is bounded, because it gives a bad network time to breathe in case of interference. More on the field testing is probably required to validate this assumption.

Another aspect related to this issue is the implementation of automatic DNS fallback. It was devised for #87 but it is actually also useful here. In more than one instance, I have been in networks in which measurements needed to be run, where the DNS was not well provisioned, therefore MK failed quite often. The automatic fallback to other DNS servers using DoT and DoH, and the fact that, for several of them we use hardcoded IP addresses, implies that, if the DNS does not always reply, then we'll have a fallback and we'll still be able to use the network.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@bassosimone bassosimone

Labels
epic A collection of issues
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@bassosimone @hellais