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

Add DDR experiment spec #300

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from
Draft

Add DDR experiment spec #300

Changes from 1 commit
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
8c104c3
Add DDR experiment spec
frcroth Jan 21, 2025
8fa1983
Update DDR spec to use DNS data format with SVCB key
frcroth Jan 31, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
138 changes: 138 additions & 0 deletions nettests/ts-041-ddr.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,138 @@
# Specification version number

2025-01-21-000

* _status_: experimental

# Specification name

ddr

# Test preconditions

* An internet connection

# Expected impact

Query the DDR protocol at the local recursive resolver, thus gathering information about DoE services in designated resolvers available and suggested to the user.

# Expected inputs

This experiment does not require inputs. It will by default query the system-configured recursive resolver. On Linux systems, this is the recursive resolver that is configured in the `/etc/resolve.conf` file.

This experiment can be configured to use a custom resolver. In this case, this resolver will be used. In this case the CustomResolver configuration property must be set to a domain or and IP-address, optionally providing a port. When no port is supplied, the default DNS port of 53 is used.

# Test description

The DDR (Discovery of Designated Resolvers) protocol is used for client to establish the connection to a encrypted DNS resolver. In most cases, DNS queries from the client are not configured with encryption by default, such as when only an IP is supplied by DHCP. With DDR a client can query a DNS recursive resolver for designated resolvers (encrypted resolvers). The recursive resolver will respond with a list of designated resolvers with their supported protocols.

This experiment issues such a DDR query and reports the result.

# Expected output

## Semantics

The `test_keys` key of the measurement has such a structure:

```JSON
{
"ddr_responses": [],
"supports_ddr": false,
"resolver": "1.1.1.1",
"failure": null
}
```

The `resolver` key includes the IP address or domain of the resolver used. In DDR the IP address of the resolver is important information, since the DoE resolvers need to have that IP address in their TLS certificate subjectAltName property to pass the verification step (as per the DDR specification, if the verification fails the resolver should not be used automatically).
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Author

@frcroth frcroth Jan 31, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
}

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hellais What do you think about this?


The `supports_ddr` key is set to `true` only when the resolver returned a valid DDR response. It does not provide information about wether the designated resolver are valid.

The key `ddr_responses` is an array that includes one object per SVCB record returned from the server in this format:

```JSON
{
"priority": 1,
"target": "one.one.one.one.",
"keys":{
"alpn":"h2,h3",
"dohpath":"/dns-query{?dns}",
"ipv4hint":"1.1.1.1,1.0.0.1",
"ipv6hint":"2606:4700:4700::1111,2606:4700:4700::1001",
"port":"443"
}
}
```

The priority and target keys are directly from the SVCB record, where priority specifies the priority among the records at which use this record and target specifies the designated resolver. The key `keys` is a map from string to string, that includes the keys that were specified for the SVCB record.
In the case of this example, the `keys` map includes this information:

- `alpn`: The protocol this designated resolver uses, so in this case HTTP2 or HTTP3 for DNS over HTTPS
- `dohpath`: How the URL needs to be constructed to send a DoH query to the designated resolver.
- `ipv4hint`: How to reach the resolver via IPv4
- `ipv6hint`: How to reach the resolver via IPv6
- `port`: The port at which to reach the resolver

## Example output sample

```JSON

{
"annotations": {
"architecture": "amd64",
"engine_name": "ooniprobe-engine",
"engine_version": "3.25.0-alpha",
"go_version": "go1.22.2",
"platform": "linux",
"vcs_modified": "false",
"vcs_revision": "8ddec182caff7c1f9d49aa76a69d2fd10733e613",
"vcs_time": "2024-12-19T14:59:47Z",
"vcs_tool": "git"
},
"data_format_version": "0.2.0",
"input": null,
"measurement_start_time": "2025-01-21 10:51:54",
"probe_asn": "AS3320",
"probe_cc": "DE",
"probe_ip": "127.0.0.1",
"probe_network_name": "Deutsche Telekom AG",
"report_id": "20250121T105154Z_ddr_DE_3320_n1_wBucNYynSBRislw1",
"resolver_asn": "AS42",
"resolver_ip": "74.63.24.236",
"resolver_network_name": "WoodyNet, Inc.",
"software_name": "miniooni",
"software_version": "3.25.0-alpha",
"test_keys": {
"ddr_responses": [
{
"priority": 1,
"target": "dns.quad9.net.",
"keys": {
"alpn": "dot",
"ipv4hint": "9.9.9.9,149.112.112.112",
"ipv6hint": "2620:fe::fe",
"port": "853"
}
},
{
"priority": 2,
"target": "dns.quad9.net.",
"keys": {
"alpn": "h2",
"dohpath": "/dns-query{?dns}",
"ipv4hint": "9.9.9.9,149.112.112.112",
"ipv6hint": "2620:fe::fe",
"port": "443"
}
}
],
"supports_ddr": true,
"resolver": "192.168.10.1:53",
"failure": null
},
"test_name": "ddr",
"test_runtime": 0.015617922,
"test_start_time": "2025-01-21 10:51:54",
"test_version": "0.1.0"
}

```