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

web_connectivity, websteps: missing CNAME answers #1516

Closed
fortuna opened this issue Nov 22, 2020 · 6 comments
Closed

web_connectivity, websteps: missing CNAME answers #1516

fortuna opened this issue Nov 22, 2020 · 6 comments
Assignees
@bassosimone
Labels
2024-01-data-quality-cleanup Data quality issues addressed on 2024-01 bug Something isn't working data quality fixed-by-webconnectivity-lte The next version of webconnectivity fixes this issue ooni/probe-engine priority/medium

Comments

@fortuna
Copy link

fortuna commented Nov 22, 2020

Describe the bug
I see a number of domains that use CNAMEs, but they are not showing in the data.

To Reproduce
www.womenonweb.org in Venezuela:
https://explorer.ooni.org/measurement/20201122T050113Z_webconnectivity_VE_21826_n1_LACPJgpwQTaxRod3?input=https%3A%2F%2Fwww.womenonweb.org%2F
Expected CNAME to womenonweb.org

www.match.com in Venezuela:
https://explorer.ooni.org/measurement/20201122T030018Z_webconnectivity_VE_6306_n1_6Yt8fLhai0soukEe?input=http%3A%2F%2Fwww.match.com%2F
Expected CNAME to the regional address.

Additional context
Collecting the CNAMEs allows us to expand the coverage of the control. For example, I could use any resolution of telegram.org for www.telegram.org.
@fortuna
Copy link
Author

fortuna commented Nov 22, 2020

Some measurements seem to have CNAMES: https://explorer.ooni.org/measurement/20201122T005930Z_webconnectivity_US_20115_n1_omO9WYr9lTVLEILS?input=http%3A%2F%2Fwww.match.com%2F

It could be the resolver, but it could also be an issue with the probe.

@bassosimone
Copy link
Contributor

The measurements with CNAME are legacy probes. We don't support CNAME in probe-engine. Implementing CNAME is a large task because we need to implement it for the default resolver as well as for custom resolvers.

@bassosimone bassosimone transferred this issue from ooni/probe-engine Jun 7, 2021
@hellais
Copy link
Member

hellais commented Jun 10, 2021

Sometimes censorship is implemented by returning a CNAME record, as can be seen in these examples: https://explorer.ooni.org/measurement/20180727T095622Z_AS17670_ryQ3v3ZDI2X8YI7FKTxeG9L5PEmgc0Z5N3bDIU7uusFaaIcuql?input=http://www.bglad.com
https://explorer.ooni.org/measurement/20180315T084438Z_AS133357_LeDGv9wMP20hFNfN2nqsvJxL1vUKOFZ0grMlnMJXACYHkmPLNB?input=http://transsexual.org
https://explorer.ooni.org/measurement/20190301T020519Z_AS55666_zcD5kLAL3QHZypge7Kppqp2ysd5p76afVPmvC7XlZ8zol52iEl?input=http://ilga.org/

@bassosimone bassosimone added the bug Something isn't working label Jul 6, 2021
@bassosimone bassosimone changed the title web_connectivity probes missing CNAME answers web_connectivity, websteps: missing CNAME answers Nov 11, 2021
@bassosimone
Copy link
Contributor

This specific issue, which has been open for quite some time, has also been mentioned in the feedback that @fortuna and @ohnorobo provided to me when I discussed websteps' design with them.

bassosimone added a commit to ooni/probe-cli that referenced this issue Aug 22, 2022
@bassosimone
cleanup(model): remove UnderlyingNetworkLibrary
20bcc89 
We were using this type to write tests ~one year ago but, as of
today, this type is mostly unused. Make it actually unused, which
helps moving ooni/probe#1516 forward.
bassosimone added a commit to ooni/probe-cli that referenced this issue Aug 22, 2022
@bassosimone
feat(dns): expose raw response message
1addcf8 
This diff extends measurexlite's extractor to include into the
DNS response we submit the raw response we received.

The reference issue is ooni/probe#1516
bassosimone added a commit to ooni/probe-cli that referenced this issue Aug 22, 2022
@bassosimone
feat(dnsovergetaddrinfo): enable collecting CNAME
4cd8a79 
Rather than discarding the CNAME, make sure we can actually
get the CNAME inside of the main LookupHost function.

Part of ooni/probe#1516.
bassosimone added a commit to ooni/probe-cli that referenced this issue Aug 22, 2022
@bassosimone
feat(netxlite): support extracting the CNAME
7f0a821 
Useful for ooni/probe#1516
This was referenced Aug 22, 2022
Merged
Closed
Closed
Closed
Closed
@bassosimone
Copy link
Contributor

This issue is fixed in webconnectivity v0.5. We'll close this issue when we'll have migrated all users to this new version of webconnectivity.

@bassosimone bassosimone added the fixed-by-webconnectivity-lte The next version of webconnectivity fixes this issue label Feb 1, 2023
@bassosimone
Copy link
Contributor

We have implemented CNAME in Web Connectivity v0.5. We can close this issue now.

@bassosimone bassosimone added the 2024-01-data-quality-cleanup Data quality issues addressed on 2024-01 label Jan 26, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@bassosimone bassosimone

Labels
2024-01-data-quality-cleanup Data quality issues addressed on 2024-01 bug Something isn't working data quality fixed-by-webconnectivity-lte The next version of webconnectivity fixes this issue ooni/probe-engine priority/medium
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@fortuna @bassosimone @hellais