We explain that the most specific Web PvD should be chosen; but we need to handle the case in which two have exactly the same match. Is a timestamp the best here? Can the explicitly acknowledge one another?

I hesitate to suggest this, but it might be a compromise that would really help deployment.

The idea would be a dnszone found on a locally designated (i.e. via RA) server could opt-in to being looked up over plaintext 53. probably opt-in via an attribute in dohNS and be signed.

The idea being that a legacy setup could transition to internet doh while not having to setup a new server for intranet stuff thus making it easier to swallow. Definitely a trade-off, but maybe a winner. discuss!

We should describe how multiple aDNS connections should be used to distribute and further obfuscate traffic patterns.

We should describe how the client handles resolution/connectivity failures:

• VPN resolution fails or is blocked
• DoH connections fail, or resolution over DoH fails
• Oblivious DoH fails

Please keep the numeric SvcParamKey values as ? in the text until IANA confirms a value. Choosing fixed values creates a risk of confusion for future readers who come across this draft. (The numeric values you've chosen also collide with values in the SVCB draft.)

Oblivious Resolution

For all privacy-sensitive connection queries for names that do not correspond
to a Designated DoH Server, the client SHOULD use Oblivious DoH to help
conceal its IP address from eavesdroppers and untrusted resolvers.

We learn from the Hostname Resolution Algorithm that step 4, Oblivious Resolution, should be used for all queries, not just the ones that are privacy-sensitive. Therefore should we remove the term "privacy-sensitive" from the statement above?

The only difference with privacy-sensitive queries is how we respond to failure.

Testing github linking to slack, by opening an issue.

From @enygren:

We need to be careful to call how clients handle and partition
caches. For example, if you query a DRR for example.com
and ask for "www.example.com" and get back:

  www.example.com CNAME www.bad-example.net.
  www.bad-example.net AAAA 2001:db8::f00d

then while it might be reasonable to assume this is a fine response
for "www.example.com" it's important that the client not use the
"www.bad-example.net" record in-cache for other lookups. (This is
creating a weirdly blurred line between recursives and
authoritatives and puts a bunch of complexity into the client to
make things safe, at least unless clients DNSSEC validate everything
which may not be a reasonable assumption.)

From @enygren:

We need to crisply define the scope of "designation" for DRRs
(designated recursive resolver) as well as what answers
from them can be trusted. Along with this, we should
be crystal clear about which SVCB record designations
for DRRs are designating for which domains.
For example, if I have:

  www.example.com  CNAME  svc.example.net.
  svc.example.net	HTTPSSVC  1 svc2.example.net. ( dohuri=https://doh.example.org/query [...] )

when which domains does that dohuri correspond to?
And which lookups can and should then go to which resolvers?
For example, does that dohuri apply to www.example.com,
svc.example.net, or svc2.example.net, or some mixture of those?

It would be really nice if example.net can specify a DRR
that gets used for svc2.example.net and/or all of example.net.
One possibility would be that HTTPSSVC records don't themselves
include dohuri or odnskeys but instead reference others.
For example, the parameter might be "drrdomain=example.net,example.com"
which would then prompt the client to do SVCB lookups for _drr.example.com
and _drr.example.net.

From @enygren:

When saying "issue a SVCB query" we should say what
SVCB query they should issue. I'd suggest that it
should generally be for a special label associated
with a domain. For example:

 _drr.example.com SVCB 1 {something} ( dohuri=https://doh.example.org/query [...] )

would designate a DRRs (designated recursive resolver)
for example.com. A question here is what should be used
as the SvcDomainName field for this stand-alone case?
I'm not sure what the right answer is? (Maybe just "."
although that has otherwise defined meaning.)

doh is defined on a resource level rather than the server level. that's why its configuration primitive is a URI (template) instead of a .well-known. You can totally have multiple doh servers on the same origin.. perhaps they have different policies (one for filtered and one for not.. one that represents a bl or some kind of database rather than ip addresses like the spam bl.. etc..)

that's a http best practice

having the doh server pvd use a well-known breaks that level of indirection. Maybe this pvd request can be done with a particular method or headers or something to the DoH URI instead?

Reference 8484 for DoH and explain that PvD provisions using a URI template

From @enygren:

Do we want/need to have Network Change events impact
the DRR cache? What are the risks (eg, linkability)
of not doing so?

Beyond providing basic DoH server functionality, server nodes SHOULD
offer a set of extended configuration to help clients discover the default
set of domains for which the server is designated, as well as other
capabilities offered by the server deployment.

Some server operators will not like the thought that their customer list can be probed in this way. Perhaps it can be fixed with a MAY and some considerations..

What happens if proxies decide to stop proxying? What happens if there are no proxies left?

For multi-CDN names that want to control the spilt of traffic (say, 90/10 split), we should spell out the recommended deployment model.

Off the top of my head, this would involve having a third-party (or one of the CDNs) be responsible for doing all of the DNS resolution and doing the balancing.

We should have pretty diagrams for protocol flows and flow charts for resolution.

It would be useful to give some scenarios for:

• Private domains in enterprise networks
• Networks that need to blacklist certain names, and how they advertise that

Step #3 in the client behavior section seems problematic. Does it not allow an authenticated provider that wants DNS interception to simply offer encrypted DNS as a service and slurp up all client queries? For example, it seems that the current algorithm would urge clients to send DNS queries for apple.com to facebook.com if they only had an authoritative WebPVD for facebook.com (no direct PVD and no PVD for apple.com). If that's the correct interpretation, I'm not sure it's desirable behavior. Let's discuss!

8484 defines how various methods are used. what's the motivation for obfuscated doh to change that?

From the call with network operators today, the topic came up of how a device admin might specify that a given DoH server should be used regardless of which network is currently being used.

While I agree this can't be universal due to a slew of edge cases, this document could call this out as a possibility as it would be a good supportive feature for privacy-centric users (namely, that if a user wants to trust one DNS provider in the general case, they can specify that once rather than per network they connect to). For example, today in iOS I believe I can only specify manual DNS servers per network.

The point being the doc state today doesn't prevent supporting this, but stating it as the requirement would create a more privacy friendly experience across all platforms that adopt this.

The document currently requires every designated doh server also be willing to act as a proxy server and target server.. this is tacitly a commitment to serve arbitrary amounts of recursive traffic in order to be able to authoritatively serve any domain over adaptive dns.

I expect that to be too much to ask of many folks to be successful.

And even among the folks that can offer that kind of service, they might reasonably want to provision it into different origins and infrastructures than they use for the authoritative designated doh server traffic.

The lack of quality control would also be a factor.

I suggest we filter the potential obfuscating servers by a new 'isProxy' attribute on their signed DOHNS RRs. Further,. we can bootstrap the system with a set of well known Proxies and Targets downloadable from a well known URL: https://www.doh-root-servers.net/proxyList - each proxy in that list would need a corresponding DOHNS with the isProxy attribute. It seems that URL could be looked up in a privacy insensitive way.

We should add an explanation about why having "sensitive" flows isn't a privacy risk.
Specifically, that information isn't visible off the device at all and can't be fingerprinted, so an attacker can't identify which flows should be targeted with extra energy.

Only the non-sensitive flows get to be seen on the local network and there is no difference between a sensitive flow that didn't get queried and one that didn't exist.

(We should also make sure that this is true, current top risk seems to be that someone on the local network "i.e. the router itself" can see things that didn't ask it and never resulted in a connection, ideally those are still okay because other things that did resolve via a Web PvD even non-sensitive would look the same way if they reuse a connection)

This is about the hostname resolution algorithm (3.3). If we think NXDomain is a failure which it is not in DNS then we will leak this name to all further resolvers we try. If we believe that for the enterprise case have a PVD from the network with the private domain that continuing the resolution when getting an NXDomain is the wrong thing from a privacy perspective.

We should mention NAT64 synthesis

We should update the guidance on ODoH nonces; using all zeros has caused some confusion

When reading the drafts it wasn't clear to me how the Hostname Resolution Algorithm is intended to work for a client sitting behind a captive portal.

One option is that Adaptive DNS is not intended to come into play until after the captive portal process has been completed.

Another option is that it should always be used. When "captive" I would expect this to result in failure of step 1 (Exclusive Direct Resolver). Would step 2 (Direct Resolver) sometimes work, for example if the local router published a domain that was also the one the client was asking for? If it didn't work, we carry on through and know that on reaching step 5 then it should work, assuming the captive portal detection domain should never be thought of as privacy-sensitive.

Some values, like the Query ID in aDNS, are random values. This should be described as a secure random.

A Web PvD can host a proxy for being an MPTCP endpoint, rather than using a local proxy on the cellular/wifi link

Section 6.2.4 (Network-Based Filtering) says:

Clients that receive indication of filtering requirements SHOULD NOT use any other
resolver for the filtered domains, but treat the network as claiming authority. However,
since this filtering cannot be authenticated, this behavior SHOULD NOT be done
silently without user consent.

This presents two scenarios.

1. The network says filtering is optional.

The client needs to ask the user whether it should use that filtering or not. How is the user to make that decision? I think the protocol needs a way to communicate the reason why this optional filtering is made available. For example a PvD key could say "If you use our DNS service, we'll prevent access to all the malware domains that we know about." There should also be a way to confirm to the user whose DNS service this is, e.g. cryptographic assurance that this is supplied by Large Company X. The name on the TLS certificate is one obvious way to supply that, but it's possible there are better ways, particularly if the entity responsible for filtering could be distinct from the name on the certificate.

2. The network says filtering is required.

The client needs to ask the user whether to proceed on this network or not. In a similar way to the first case, I think the protocol needs a way to communicate some statement from the named responsible entity on why filtering is required.

We should consider defining the concept of "where I'm trying to go" beyond just a domain, which is what we use today. Probably something like endpoint?

a DOHNS record needs to be
1] dnssec signed
2] for something more specific than an eTLD

what's the rationale for 2 if we have 1?

I can think of 2 reasons to remove it
1] dealing with the PSL is complicated and full of state. And the PSL is pretty inaccurate anyhow
2] don't we want to look up eTLD records over doh directly? e.g. us.com is considered an eTLD and it also has an A record and a valid https://us.com site.

Folks can always look at sizes and timing patterns. If that's undesirable, use padding or be smarter about timing.

it would probably be good to define http errors for

• proxy doesn't want to forward this (403? 404?)
• target can't decrypt this (400?)

The ODOH document says the cipher suite is passed by the client along with the symmetric key, but the struct doesn't seem to include this. Also, is there any negotiation of this? What if a suite becomes deprecated?

From @enygren:

I really, really do NOT like how :authority is having its meaning
altered in the ODNS draft. This breaks HTTP semantics and this
breaks a bunch of assumptions on how CDN servers do hostname-based
service multiplexing. It would require having separate IP addresses
for DoH servers from CDN servers, for example. (Which has worse
privacy properties.) I'd propose instead that ODNS followes adds
some path elements. For example:

:method = POST
:authority = dnsproxy.example.net
:path = /dns-query?targethost=dnstarget.example.net&targetpath=/dns-query
...

makes this be normal HTTPS semantics. It also avoids problems if the
proxy and target have different DoH template URI paths which
I don't believe the current draft handles?

if a proxy and target collude then the client address and DNS information are trivially correlated.

If a single entity has more than one origin in the list of known targets then a client will eventually route a 'blinded' request through both of them creating an unfortunate liability.

it seems useful to have some way of marking this kind of redundancy.

we might also want to encourage doh servers to use anycast and/or geo-dns to minimize origin names and the potential for conflict.

better latency properties than others. To optimize performance, clients SHOULD
maintain statistics to track the performance characteristics and success rates of
particular pairs.

If taken literally this would often mean picking 2 servers located very close to the client - which could be almost as identifying as the IP address we're trying to hide.

I think we need to update the security considerations.

In obfuscated DOH you are explicitly not trusting either name server, s.t. no one server can know both the client IP and the name the client wants resolved.
But if you don’t trust the Obfuscation Target, it can still get the client IP indirectly. The Target can just give out some man-in-the-middle IP address to the client for the given name. Then when the client connects to that address, the man-in-the-middle server just forwards the connection to the real server. The man-in-the-middle server doesn’t actually terminate the client HTTPS, but it does have enough info to (reasonably) reliably associate client IP to name it resolved. This works much better with V6, since you’d need 1 man-in-the-middle IP per name.

These servers aren't good obfuscation proxies because they are highly correlated with the actual client so little blinding is accomplished.

We currently say:

The client MAY also issue queries for the [] record for more specific names to discover
further Designated DoH Servers.

We should clarify when this ought to be done.