Force dns on https-dns-proxy not working

hap1 · January 22, 2024, 7:29am

I installed https-dns-proxy and out of curiosity I wanted to see if the force dns option was working. I ran tcpdump -n -i eth0 port 53 on the router and saw quite a bit of entries including this one:

23:16:02.962184 IP 192.168.1.140.48117 > 8.8.8.8.53: 36+ A? pushproxy-usa4.eufylife.com. (45)
23:16:02.970043 IP 8.8.8.8.53 > 192.168.1.140.48117: 36 1/0/0 A 18.221.14.3 (61)

This is coming from a smart camera which probably has Google DNS hardcoded. It looks like it successfully made a call and received a response? I thought it should reject or redirect any traffic on port 53 or 853. I do not have Google as one of my DoH resolvers.

My config

root@OpenWrt:/etc/config# cat https-dns-proxy

config main 'config'
        option canary_domains_icloud '0'
        option canary_domains_mozilla '1'
        option dnsmasq_config_update '*'
        option force_dns '1'
        list force_dns_port '53'
        list force_dns_port '853'
        option procd_trigger_wan6 '0'

config https-dns-proxy
        option bootstrap_dns '1.1.1.1,1.0.0.1'
        option resolver_url 'https://cloudflare-dns.com/dns-query'
        option listen_addr '127.0.0.1'
        option listen_port '5053'
        option user 'nobody'
        option group 'nogroup'

config https-dns-proxy
        option bootstrap_dns '8.8.8.8,8.8.4.4'
        option resolver_url 'https://dns.quad9.net/dns-query'
        option listen_addr '127.0.0.1'
        option listen_port '5054'
        option user 'nobody'
        option group 'nogroup'

When I run nft list ruleset I do see these dns related entries which seem related

chain forward_lan {
                tcp dport 853 counter packets 67 bytes 5128 jump handle_reject comment "!fw4: ubus:https-dns-proxy[instance1] rule 1"
                udp dport 853 counter packets 0 bytes 0 jump handle_reject comment "!fw4: ubus:https-dns-proxy[instance1] rule 1"
...
}

and

        chain dstnat_lan {
                tcp dport 53 counter packets 0 bytes 0 redirect to :53 comment "!fw4: ubus:https-dns-proxy[instance1] redirect 0"
                udp dport 53 counter packets 1039 bytes 83302 redirect to :53 comment "!fw4: ubus:https-dns-proxy[instance1] redirect 0"
        }

It appears that the config is right, but why do I still see entries with tcpdump?

frollic · January 22, 2024, 7:39am

you might need https://openwrt.org/docs/guide-user/firewall/fw3_configurations/intercept_dns

hap1 · January 23, 2024, 1:19am

I found this thread [Solved] User Guide: DNS hijacking - #4 by efahl
It mentions that the LAN clients will see DNS replies as if it's coming from their hardcoded DNS provider. I'm not sure if this applies to the output of tcpdump but it might explain things?

efahl · January 23, 2024, 2:52am

I think since you're using tcpdump -i eth0 (I assume that's the wan NIC?) that tcpdump is showing you real traffic leaking past the DNS blocker.

hap1 · January 23, 2024, 5:28am

Yes that's the wan NIC. I changed my windows network settings to use Google DNS and disabled secure DNS in edge. I ran a DNS leak test and in the tcp dump output I see a bunch of Google DNS addresses scroll by. However the result of the DNS leak tests show Cloudflare and WoodyNet (Quad 9) so it appears to be working I think.

I agree that it is weird tcpdump isn't showing the redirected traffic though

efahl · January 23, 2024, 3:23pm

Just to confirm my thoughts, I ran a leak experiment on my setup. From the workstation at 10.1.1.186, I did an nslookup specifying google for the DNS server:

workstation$  nslookup quad9.net 8.8.8.8
Non-authoritative answer:
Server:  dns.google
Address:  8.8.8.8

Name:    quad9.net
Addresses:  2620:0:871:9000::77
          216.21.3.77

Just before that, I started tcpdump on the WAN interface of the router, waited until the above response was seen and then killed it. No traffic on port 53...

rtr00$ tcpdump -ni eth0 port 53
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
^C

0 packets captured
0 packets received by filter
0 packets dropped by kernel

Restarted tcpdump on the LAN interface and re-ran the lookup. As I had suspected, we now see the pre/post-NAT traffic...

rtr00$ tcpdump -i br-lan dst port 53
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on br-lan, link-type EN10MB (Ethernet), snapshot length 262144 bytes

07:12:03.284715 IP 10.1.1.186.62108 > 8.8.8.8.53:       1+ PTR?     8.8.8.8.in-addr.arpa. (38)
07:12:03.285433 IP 8.8.8.8.53       > 10.1.1.186.62108: 1  1/0/0    PTR dns.google.       (62)
07:12:03.285851 IP 10.1.1.186.62109 > 8.8.8.8.53:       2+ A?       quad9.net.lan.        (37)
07:12:03.286963 IP 8.8.8.8.53       > 10.1.1.186.62109: 2  NXDomain 0/0/0                 (37)
07:12:03.287263 IP 10.1.1.186.62110 > 8.8.8.8.53:       3+ AAAA?    quad9.net.lan.        (37)
07:12:03.287924 IP 8.8.8.8.53       > 10.1.1.186.62110: 3  NXDomain 0/0/0                 (37)
07:12:03.288213 IP 10.1.1.186.62111 > 8.8.8.8.53:       4+ A?       quad9.net.            (27)
07:12:03.288417 IP 8.8.8.8.53       > 10.1.1.186.62111: 4  1/0/0    A 216.21.3.77         (43)
07:12:03.290612 IP 10.1.1.186.62112 > 8.8.8.8.53:       5+ AAAA?    quad9.net.            (27)
07:12:03.291370 IP 8.8.8.8.53       > 10.1.1.186.62112: 5  1/0/0    AAAA 2620:0:871:9000::77 (55)

And just to verify, I redid the lookup but changed the DNS server to a nonsense address of 4.3.2.1, which should fail if the NAT redirect doesn't happen.

workstation$ nslookup quad9.net 4.3.2.1
Non-authoritative answer:
Server:  UnKnown
Address:  4.3.2.1

Name:    quad9.net
Addresses:  2620:0:871:9000::77
          216.21.3.77

With the dump on LAN showing:


07:12:05.494251 IP 10.1.1.186.62113 > 4.3.2.1.53:       1+ PTR?     1.2.3.4.in-addr.arpa. (38)
07:12:05.494982 IP 4.3.2.1.53       > 10.1.1.186.62113: 1  NXDomain 0/0/0                 (38)
07:12:05.495379 IP 10.1.1.186.62114 > 4.3.2.1.53:       2+ A?       quad9.net.lan.        (37)
07:12:05.496367 IP 4.3.2.1.53       > 10.1.1.186.62114: 2  NXDomain 0/0/0                 (37)
07:12:05.496867 IP 10.1.1.186.62115 > 4.3.2.1.53:       3+ AAAA?    quad9.net.lan.        (37)
07:12:05.498191 IP 4.3.2.1.53       > 10.1.1.186.62115: 3  NXDomain 0/0/0                 (37)
07:12:05.498483 IP 10.1.1.186.62116 > 4.3.2.1.53:       4+ A?       quad9.net.            (27)
07:12:05.498751 IP 4.3.2.1.53       > 10.1.1.186.62116: 4  1/0/0    A 216.21.3.77         (43)
07:12:05.500723 IP 10.1.1.186.62117 > 4.3.2.1.53:       5+ AAAA?    quad9.net.            (27)
07:12:05.501367 IP 4.3.2.1.53       > 10.1.1.186.62117: 5  1/0/0    AAAA 2620:0:871:9000::77 (55)

For reference, here are all of my DNS rules, which reside in the dstnat_lan chain (my DNS configuration is all hand-built, I don't use any of the canned packages).

rtr00$ cat /usr/share/nftables.d/chain-post/dstnat_lan/90-redirect.nft
# DNS redirects.
# Quad9 also serves standard DNS on 9953, should we grab that here, or block like 853?
# Likewise, several services reply on 5353 (familyshield.opendns.com), block them, too?  Nah, breaks mDNS...
meta l4proto { tcp, udp }  th dport 53                          counter  \
                                                                redirect \
                                                                comment "EF-DNS: Redirect all standard DNS to local server."

# DNS blocks.
# *** All of the following should probably be in raw_prerouting chain, so they are rejected before polluting conntrack. ***
meta l4proto { tcp, udp }  th dport 853                         counter  \
                                                                reject   \
                                                                comment "EF-DNS: Block all DoT."

meta l4proto { tcp, udp }  th dport 443  ip  daddr @doh_ipv4    counter  \
                                                                update @doh_ipv4 { ip  daddr } \
                                                                reject   \
                                                                comment "EF-DNS: Block IPv4 DoH by selective IPv4 address."
meta l4proto { tcp, udp }  th dport 443  ip6 daddr @doh_ipv6    counter  \
                                                                update @doh_ipv6 { ip6 daddr } \
                                                                reject   \
                                                                comment "EF-DNS: Block IPv6 DoH..."

hap1 · January 24, 2024, 1:27am

I double checked my network configuration and saw that my wan is eth1 and not eth0

You even alluded to that in your message and I confidently answered incorrectly without triple checking first. Sorry for wasting your time and thanks for your patience.

I double checked the tcpdump on the eth1 and I only saw requests to cloudflare and quad9 which is expected. I also did the nslookup to an invalid resolver and that worked as well with quad9 responding. That was a good test to make sure the DNS redirect is working.

Thanks again!

stangri · January 25, 2024, 7:59am

I'm glad you got it resolved (with the help of @efahl). As a maintainer of https-dns-proxy, I'd appreciate if you edited the thread subject as to not to unintentionally mislead people about the working status of force dns of https-dns-proxy.

system · February 4, 2024, 8:01am

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.