You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Please note that for VPN use cases or internal domains, we specify that fallback must not be done:
1. An Exclusive Direct Resolver, such as a resolver provisioned by a VPN, with domain rules that include the hostname being resolved. If the resolution fails, the connection will fail. See Section 3.2 and Section 6.
Perhaps it makes sense to do the same for the case of local authority, i.e. (2):
2. A Direct Resolver, such as a local router, with domain rules that are known to be authoritative for the domain containing the hostname. If the resolution fails, the connection will try the next resolver configuration based on this list.
Changing to if the resolution fails, the connection will fail.
Yeah that is better. If we say NXDomain is a failure should we not also say the same about NoError/NoData? I guess happy eyeballs will ask AAAA and A, so getting that answer will not be uncommon.
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.
The text was updated successfully, but these errors were encountered: