-
Notifications
You must be signed in to change notification settings - Fork 142
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.
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
netxlite: land improvements from websteps winter 2022 repo #2096
Comments
This diff imports the parallel resolver from websteps winter 2022 edition, which was originally implemented here: bassosimone/websteps-illustrated@55231d7 See ooni/probe#2096
This diff imports the parallel resolver from websteps winter 2022 edition, which was originally implemented here: bassosimone/websteps-illustrated@55231d7 See ooni/probe#2096
This diff fixes the short-circuit-IP-addr resolver to correctly handle IP addrs during LookupHTTPS. The original diff was: bassosimone/websteps-illustrated@2b51d14 See ooni/probe#2096 While there, add unit tests for IPv6.
This diff fixes the short-circuit-IP-addr resolver to correctly handle IP addrs during LookupHTTPS. The original diff was: bassosimone/websteps-illustrated@2b51d14 See ooni/probe#2096 While there, add unit tests for IPv6.
I've seen some measurements returning some IP addresses for HTTPSSvc queries but not returning any ALPN value. For example: ```JSON % d4 decoding DNS round trip 0: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57768 ;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;psiphon.ca. IN HTTPS ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57768 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;psiphon.ca. IN HTTPS ;; ANSWER SECTION: psiphon.ca. 121 IN A 31.13.85.53 ``` Now, the response is clearly bogus. At the time of this writing that IP address belongs to Facebook. This measurement has been collected in China, so it's expected for the GFW to behave like this. Yet, I don't feel like it's accurate to report this measurement as a "no answer" response. Rather, this response is a valid one containing a clearly invalid IP address and should be flagged as such. Originally: bassosimone/websteps-illustrated@57a023b See ooni/probe#2096
I've seen some measurements returning some IP addresses for HTTPSSvc queries but not returning any ALPN value. For example: ``` % d4 decoding DNS round trip 0: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57768 ;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;psiphon.ca. IN HTTPS ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57768 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;psiphon.ca. IN HTTPS ;; ANSWER SECTION: psiphon.ca. 121 IN A 31.13.85.53 ``` Now, the response is clearly bogus. At the time of this writing that IP address belongs to Facebook. This measurement has been collected in China, so it's expected for the GFW to behave like this. Yet, I don't feel like it's accurate to report this measurement as a "no answer" response. Rather, this response is a valid one containing a clearly invalid IP address and should be flagged as such. Originally: bassosimone/websteps-illustrated@57a023b See ooni/probe#2096
This error occurred for example when querying kazemjalali.com in websteps measurements run from Iran. This error is relatively uncommon, but it still makes sense to create a specific mapping rule for it. Originally: bassosimone/websteps-illustrated@4269e82 See ooni/probe#2096
This error occurred for example when querying kazemjalali.com in websteps measurements run from Iran. This error is relatively uncommon, but it still makes sense to create a specific mapping rule for it. Originally: bassosimone/websteps-illustrated@4269e82 See ooni/probe#2096
This diff has been extracted from bassosimone/websteps-illustrated@c2f7cca See ooni/probe#2096
This diff has been extracted from bassosimone/websteps-illustrated@c2f7cca See ooni/probe#2096
This diff has been extracted from bassosimone/websteps-illustrated@c2f7cca See ooni/probe#2096
This diff has been extracted from bassosimone/websteps-illustrated@c2f7cca See ooni/probe#2096
This diff has been extracted from bassosimone/websteps-illustrated@c2f7cca See ooni/probe#2096 While there, export DecodeReply to decode a raw reply without interpreting the Rcode or parsing the results, which seems a nice extra feature to have to more flexibly parse DNS replies in other parts of the codebase.
This diff has been extracted from bassosimone/websteps-illustrated@c2f7cca See ooni/probe#2096 While there, export DecodeReply to decode a raw reply without interpreting the Rcode or parsing the results, which seems a nice extra feature to have to more flexibly parse DNS replies in other parts of the codebase.
This diff has been extracted from bassosimone/websteps-illustrated@8848c8c See ooni/probe#2096 While there, perform comprehensive netxlite code review and apply minor changes and improve the docs.
This diff has been extracted and adapted from bassosimone/websteps-illustrated@8848c8c The reason to prefer composition over embedding is that we want the build to break if we add new methods to interfaces we define. If the build does not break, we may forget about wrapping methods we should actually be wrapping. I noticed this issue inside netxlite when I was working on websteps-illustrated and I added support for NS and PTR queries. See ooni/probe#2096 While there, perform comprehensive netxlite code review and apply minor changes and improve the docs.
This diff has been extracted from bassosimone/websteps-illustrated@eb0bf38. See ooni/probe#2096. While there, skip the broken tests caused by issue ooni/probe#2098.
This diff has been extracted from bassosimone/websteps-illustrated@eb0bf38. See ooni/probe#2096. While there, skip the broken tests caused by issue ooni/probe#2098.
Previously, the DNS decoded did not check whether it was parsing a DNS query or a DNS response, which was wrong. As a side note, it seems I am using "reply" in the codebase instead of "response", which seems bettern DNS terminology. This diff has been extracted from bassosimone/websteps-illustrated@9249d14 See ooni/probe#2096.
Previously, the DNS decoder did not check whether it was parsing a DNS query or a DNS response, which was wrong. As a side note, it seems I am using "reply" in the codebase instead of "response". The latter seems correct DNS terminology. This diff has been extracted from bassosimone/websteps-illustrated@9249d14 See ooni/probe#2096.
This diff modifies the system resolver to use a getaddrinf transport. Obviously the transport is a fake, but its existence will allow us to observe DNS events more naturally. A lookup using the system resolver would be a ANY lookup that will contain all the resolved IP addresses into the same response. This change was also part of websteps-illustrated, albeit the way in which I did it there was less clean than what we have here. Ref issue: ooni/probe#2096
This diff modifies the system resolver to use a getaddrinf transport. Obviously the transport is a fake, but its existence will allow us to observe DNS events more naturally. A lookup using the system resolver would be a ANY lookup that will contain all the resolved IP addresses into the same response. This change was also part of websteps-illustrated, albeit the way in which I did it there was less clean than what we have here. Ref issue: ooni/probe#2096
Acknowledge that transports MAY be used in isolation (i.e., outside of a Resolver) and add support for wrapping. Ensure that every factory that creates an unwrapped type is named accordingly to hopefully ensure there are no surprises. Implement DNSTransport wrapping and use a technique similar to the one used by Dialer to customize the DNSTransport while constructing more complex data types (e.g., a specific resolver). Ensure that the stdlib resolver's own "getaddrinfo" transport (1) is wrapped and (2) could be extended during construction. This work is part of my ongoing effort to bring to this repository websteps-illustrated changes relative to netxlite. Ref issue: ooni/probe#2096
Acknowledge that transports MAY be used in isolation (i.e., outside of a Resolver) and add support for wrapping. Ensure that every factory that creates an unwrapped type is named accordingly to hopefully ensure there are no surprises. Implement DNSTransport wrapping and use a technique similar to the one used by Dialer to customize the DNSTransport while constructing more complex data types (e.g., a specific resolver). Ensure that the stdlib resolver's own "getaddrinfo" transport (1) is wrapped and (2) could be extended during construction. This work is part of my ongoing effort to bring to this repository websteps-illustrated changes relative to netxlite. Ref issue: ooni/probe#2096
These are the diffs we still need to import into netxlite:
|
This issue is about landing netxlite patches developed in the websteps winter 2022 repository. See https://github.com/bassosimone/websteps-illustrated/tree/a65f3e8579b59565789a1f38c468b0a9646783cd/internal/netxlite.
The text was updated successfully, but these errors were encountered: