Hi
Ok, just for reference
- the "DoH" is DNS-resolutions/queries/responses-over-HTTPS, and this https "secure" session is between the dns-clientbet-querier and the dns-server (that supports DoH). And the point to note is this https session is using the standard TCP/443 port
- the "DoT" is dns-session (for dns-resolution-query-response-etc) that is "DNS over TLS" which uses TCP/853. This secure TLS DoT session is established between the dns-client-querier and the dns-server (that supports DoT)
Now your deployment is as below:
PC1(192.168.1.2)------192.168.1.1vlan1[RV260]wan-----[isp-router]----------[DNS-server: DoH/DoT]----{internet}
And in this above deployment there are 2 parts:
1. The RV260 connects to ISP and gets its wan-ipaddress assigned thru DHCP (in which case the public-dns-server ipaddr is also assigned to RV260 thru this dhcp-connection on the wan-interface - OR maybe the wan-interface is configured with a public static-ip-address assigned by the ISP and alongwith it the dns-server-ipaddr is also configured - generally in the "/etc/resolv.conf" file on the router
a) now lets assume that this public-isp dns-server/dns-resolver ipaddress (say for example ) is 202.202.202.5 and lets assume that it support DoH (using https on tcp/443) and DoT (using TLS on TCP/853) and also if the dns-client sends a dns-query/request that is unencrypted/plain, it will also resolve the dns-query
b) Now on the this RV260, there "maybe" be some "applications" that would "initiate" connections (tcp/udp) from the RV260 itself to some remote-servers and these connection requests "could" be to a FQDN (such as some update-server with fqdn say for example "updateserver.cisco.com") and this FQDN needs to be resolved to a actual IP-address, and So now what would happen is that:
- either the "application" running on the RV260 would be intelligent enough to have support for sending by itself a dns-query to resolve this FQDN, and therefore simply get the dns-server ipaddress from the resolv.conf file AND send the dns-query/request to the dns-server
- or maybe the application may depend on a underlying dns-client-resolver service that would use the dns-server ipaddress configured in the resolv.conf file and send the dns-query and update the local application with the response from the dns-server
c) And sometimes there will be certain services that are run on the RV260 such as "DNS-Proxy" for the dns-queries recieved from lan-dhcp-clients that are forwarded onto the actual public-dns-server-ipaddress configured in the /etc/resolv.conf file on RV260
d) Or when we say run a ping on RV260 to a destination using a FQDN...and this fqdn is resolved by the underlying dns-client-service on the RV260
So the present state on RV260 is that none of the dns-queries/requests sent "from the RV260" (arising out of above scenarios in points1a-1d) are encrypted and the dns-request initiated/originating "from RV260 itself" PRESENTLY DO NOT HAVE SUPPORT FOR DNS-over-HTTPs(DoH) or DNS-over-TLS(DoT)
2. The second part after RV260 connects to ISP and configures the wan-ipaddr AND the public/isp dns-server-ipaddress (got either from ISP or configured by the user) are configured in the resolv.conf file, is the process of the lan-hosts connected to this RV260 and the lan-hosts are assigned their "ipaddress/def-gw and dns-server-ipddressses" from the dhcp-server running on RV260 vlanX-lan-interface
a) So in the dhcp-server on RV260 there are 3 options for assigning the dns-server-ipaddresses to the lan-client-pcs:
- use dns-proxy (this will result in the lan-clients configured with the dns-ipaddr the same as the default-gw ipaddress which is the RV260-vlanX-lan-interface-ipaddress. This is the default setting
- usp dns-from-isp (this will be the same dns-server ipaddresses configured in the /etc/resolv.conf file on RV260)
- use-these-dns-servers (and configure them manually/explicitly by the user). In this case the user will configure explicitly the public-dns-server ipaddresses and these will be assigned to the lan-pc thru the dhcp
b) So in this case if you refer to the brief description of "DoH/DoT" functionality, its the "applications(such as Firefox/Chrome/Edge browsers), and maybe if supported the underlying os-specific dns-client-resolver service/application on the lan-pc that would be "initiating" the dns-queries/requests to the configured dns-server ipaddress
- And these dns-queries/requests originating/initiated from the lan-pc would be IF SUPPORTED using DoH and/or DoT features for secure connections between the lan-pc and the dns-server
c) And if the dns-server is on the internet (or in ISP-network) and supports DoH/DoT, then the corresponding dns-queries from the LAN-PCs behind the RV260 would be basically https(tcp/443) and tls (tcp/853) connections that will be NATed/Masqueraded and routed/forwarded across the RV260 simply as https/TLS connections.
d) So generally for all DoH/DoT dns-queries flowing between the Lan-PCs and the remote-wan-public DNS-servers, the RV260 is not all involved except for forwarding/routing these traffic as https/tls connections as any other similar connections between the lan-pc and the internet hosts
e) The above point is true for most times, EXCEPT WHEN THE "USE DNS-PROXY" SETTING IS SELECTED IN THE DHCP-SERVER CONFIG ON RV260 FOR LAN-HOSTS
- This is the default-setting, and in this case what's happening is that although the lan-pc (applications running on the PC) are having support for initiating dns-queries using DoH/DoT, the dns-server to which the lan-hosts are sending the DoH-DoT requests is the RV260 lan-interface ipaddress (say in this example 192.168.1.1)....and these dns-requests are proxied by RV260 and further sent to the dns-server as plain-unencrypted(normal dns queries using udp/53 and/or tcp/53). So in this case since the dns-client on RV260 does not itself have support for DoH/DoT, the dns-request within DoH/DoT sessions from the lan-pc will fail and not get established
So in summary you should not configure "use dns-proxy" and maybe try with the other 2 settings for LAN-PCs to start using DoH/DoT sessions to the internet-DNS-server...across the RV260
- And as for any dns-queries from RV260, there is NO support as of now for DoH/DoT and therefore you will see plain dns-sessions originating out of RV260
