Conversation
bassosimone
force-pushed
the
feature/doh
branch
from
682b261 to
afbf64f
Compare
|
|
||
| # Expected impact | ||
|
|
||
| Result of resolving domain names using a specific DoH server. |
There was a problem hiding this comment.
Maybe provide a link to the relevant RFC?
| "software_version": "0.1.0-dev", | ||
| "test_keys": { | ||
| "failure": "", | ||
| "url": "https://mozilla.cloudflare-dns.com/dns-query", |
There was a problem hiding this comment.
Shouldn't there also be some keys related to the HTTP requests that were performed?
There was a problem hiding this comment.
I believe so. I have been debating with myself whether we want:
-
to implement the HTTP base data format; or
-
provide the netx events; or
-
both
Later you ask me about timing. This is a given with the netx data format, because it does not show results, rather events that happened at a specific time.
| The key `test_keys` key object will be added to the report. | ||
|
|
||
| The `test_keys.failure` scalar will be `null` if there was no error or | ||
| a string indicating the error that occurred. |
There was a problem hiding this comment.
The x-addresses key is missing from here.
I also think you should add a reference to the HTTP requests that are being performed and what the responses look like.
It's also probably a good idea to collect some timing information pertaining to the query time.
There was a problem hiding this comment.
The x-addresses key is missing from here.
I'd rather remove it from here. This is an experimental key and we don't want its presence to cause confusion or expectations into the reader.
The reason why this JSON lacks so many details is that I'm blocking on a couple of large code reviews before I'm able to write PoC code that contains more information. I am also not super convinced whether we should document and include the full netx event stream as a parent data format, or whether we should just include it as an x- key for now.
3 participants
No description provided.