Clarification on Opportunistic with respect to dns://resolver.arpa

[mstojens]

Issue migrated from DEER repo: tfpauly/draft-pauly-adaptive-dns-privacy#163

[mstojens]

magicalo said...

Can you clarify why dns://resolver.arpa would matter in an Opportunistic scenario, or at least in a subset of Opportunistic options.

Couldn't a DNS client simply attempt DoH on the same IP address(es) as Do53 (ideally in parallel)
and if the certificate returned during the DoH exchanges meets the criteria (matching IPs listed in the SAN, cert validation, etc.) then it would simply attempt the upgrade, never having to consider/engage dns://resolver.arpa

Maybe I have misunderstood this section or the role dns://resolver.arpa would play here. Could you clarify please.

[mstojens]

tfpauly said...

The purpose of the SVCB record information in the "opportunistic" scenario is getting extra metadata about the resolvers. This is particularly important or useful for DoH, where the URI path and HTTP authority would not otherwise be known. The client could guess, but it may not be able to form a valid HTTP request.

The DoT ports, etc, could also be different, but that's often less useful.

[mglt]

I apology for re-opening the discussion.

opportunistic discovery for DoT

When a client is advertised a nonpublic IP address for an unencrypted resolver.
The resolver.arpa tells the client if a potential encrypted resolver is available or not and associated parameters - excluding a different IP address.

It seems that DoT in an opportunistic mode doesn't need that resolver.arpa request and that a clientHello is sufficient. If I am not missing anything, some text may describe this and specify that the additional DNS request is only needed for non DoT use cases - i.e. DoH for example.
 
As a  side note, I am wondering if we could define a doh path and why this has not been defined in the DoH spec.

[mstojens]

It seems that DoT in an opportunistic mode doesn't need that resolver.arpa request and that a clientHello is sufficient.

This is correct; however, this guidance helps to standardize an approach instead of leaving that "you can just try it" part unspoken. There is active discussion on this point being requested on the list @mglt so I think you contributing there would be appreciated.

[tfpauly]

I don't see what's different here between our existing text:

Opportunistic Privacy is defined for DoT in Section 4.1 of [RFC7858] as a mode in which clients do not validate the name of the resolver presented in the certificate. A client MAY use information from the SVCB record for "dns://resolver.arpa" with this "opportunistic" approach (not validating the names presented in the SubjectAlternativeName field of the certificate) as long as the IP address of the Encrypted Resolver does not differ from the IP address of the Unencrypted Resolver. This approach can be used for any encrypted DNS protocol that uses TLS.

[mstojens]

Closing this with lack of discussion; the existing text covers how the SVCB record can be used and refers to RFC7858, which itself talks about how to do unauthenticated DoT (which requires no SVCB record).