Add DDR experiment spec

[frcroth]

Checklist

• I have read the contribution guidelines
• reference issue for this pull request: New experiment request: DDR queries probe#2819
• related ooni/probe-cli pull request: Add ddr experiment probe-cli#1675
• If I changed a spec, I also bumped its version number and/or date

Description

Please, insert here a more detailed description.

[hellais]

For these keys I believe we should be able to re-use the existing dnst data format with some additional extensions.

This is something that we will need also for implementing a full ECH test, since that also relies on the lookup of SVCB records.

We could introduce an additional query_type and answer_type called SVCB and encode it as follows:

{
    "engine": "getaddrinfo",
    "failure": null,
    "hostname": "_dns.example.net",
    "query_type": "SVCB",
    "raw_response": "dUuBgAABAAEAAAAAB2V4YW1wbGUDY29tAAABAAHADAABAAEAAE2IAARduNgi",
    "resolver_hostname": null,
    "resolver_port": null,
    "resolver_address": null,
    "t0": 0.001145,
    "t": 0.06544,
    "transaction_id": 2,
    "answers": [{
        "answer_type": "SVCB",
        "svcb_raw": "B64ENCODING_OF_SVCB_RECORD",
        "ttl": null
    }],
},

If we care also parse the svcb records, we can probably place the keys you have now in the ddr_responses list inside of the answers_list as a list key that contains the parsed values of the SVCB records, but ideally it would be general enough to also support other SVCB records (such as the ECH configuration ones as well).

As for resolver configuration, this is something already supported by the existing data format. During the initial test bootstrap phase we lookup the resolver that probe is using and log it to the resolver_ip field (see: https://github.com/ooni/spec/blob/master/data-formats/df-000-base.md). This will match the public IP of the recursive resolver used when using a getaddrinfo engine.

In the event of custom resolver, we should use the existing resolver_address field to encode it.

[frcroth]

Thank you for your response. I understand your reasoning and agree with you that all this information should be placed in the preexisting DNS answer type.

Do you think it would be better to have the svcb raw response in the answer or parse the SVCB response completely? For my part I think parsing would be cleaner, but of course I do not have much experience with this project.
I thought something like this for the probe implementation would work, which is protocol agnostic and does not care about DDR at all.

// ArchivalDNSAnswer is a DNS answer.
type ArchivalDNSAnswer struct {
	ASN        int64     `json:"asn,omitempty"`
	ASOrgName  string    `json:"as_org_name,omitempty"`
	AnswerType string    `json:"answer_type"`
	Hostname   string    `json:"hostname,omitempty"`
	IPv4       string    `json:"ipv4,omitempty"`
	IPv6       string    `json:"ipv6,omitempty"`
	TTL        *uint32   `json:"ttl"`
	SVCB       *SVCBData `json:"svcb,omitempty"` // SVCB-specific data
}

// SVCBData represents details of an SVCB record.
type SVCBData struct {
	Priority   uint16            `json:"priority"`
	TargetName string            `json:"target_name"`
	Params     map[string]string `json:"params,omitempty"` // SvcParams key-value pairs
}