mozilla-extensions / dnssec-interference Goto Github PK

Cu.reportError is considered deprecated, and we are working on moving away from it and using console.error instead.

We believe the only difference between the two when used in single-argument form is that console.error may get additionally logged to stdout if a certain preference is set.

We'd like to run a few more diagnostic tests:

• A per-client webextension query (webext-A-U)
• The addonVersion, to verify we don't have some kind of collision with telemetry not updating.
• The apexDomain, to more easily generate validation for each key

In our last experiment, we saw that although the order of queries didn't seem to impact the NEW* failure rate, there was a noticeable difference between queries to dnssec-experiment-moz.net and any subdomain (either the per-client ones or the shared ones).

I think we could run one more experiment to test a few possible theories:

1. There is some kind of behavior that differs for subdomains vs the apex domain
2. There is something about the DNS requests from the fetch request and/or the webext requests that result in cache contamination that our custom A queries do not cause
3. There is something specific to dnssec-experiment-moz.net

In order to support additional analysis that correlates data on our end with queries on the NS side, we'd like to add an additional set of queries for per-client domains, as well as some record types we weren't previously checking (specifically DS and A with the NOEDNS flag set).

This will involve some changes to our tables in the data pipeline for the new keys. Additionally, we'd like to send errors that resulted as part of attempting to send a query as part of the final payload instead of separately.

Experimenter link: https://experimenter.services.mozilla.com/experiments/dnssec-interference-measurement-with-per-client-measurements-v4/

The idea here is to see if this is causing problems.

We forgot last time.

Specifically we want to check if recursive resolvers are caching responses for A requests that are incorrectly used to respond to our custom range record queries. This involves adding some queries for domains in various orders (A first, NEWONE first, etc.)

We also want to capture order and timestamp information in a new section of the payload, dnsQueryInfo