and if you do nslookup yourblockedsite.com localhost on the router ?
I'm not at home rn but I'll try it when i get there.
Just got home!
root@OpenWrt:~# nslookup [site] localhost
Server: localhost
Address: ::1#53
Name: [name]
Address 1: [ip1]
Address 2: [ip2]
*** Can't find [site]: No answer
And from my pc:
nslookup [name]
Server: 192.168.1.1
Address: 192.168.1.1#53
Non-authoritative answer:
Name: [name]
Address: [ip1]
Name: [name]
Address: [ip2]
Seems like it is using port 53 instead of the 5054 that DoH is runnig on.
What should I do?
Edit:
This is from the global dns settings
by the looks of it, your dnsmasq isn't talking to the https-dns-proxy, or something's not up and running.
Tue Feb 8 16:53:40 2022 daemon.info dnsmasq[14669]: using nameserver 127.0.0.1#5053
Tue Feb 8 16:53:40 2022 daemon.info dnsmasq[14669]: using nameserver 127.0.0.1#5054
Its seems like its up and running and using the right servers but Its seems that it does not work anyway.
this might be worth reading Questions about installing DNS over HTTPS with Dnsmasq and https-dns-proxy
1 Like
I read the entire thread and the only possibility that I can think of is that the router is using a cached dns? Idk if this makes sense. Is there a way to flush all cache? I a reboot enough ?
restart the service.
If I were you, I'd doublecheck the syntax, especially the port, for having dnsmasq connecting to the
upstream dns, in your case, the localhost https-to-dns proxy. I'm not sure it should be # 5053.
2nd thing would be to check if there's something listening on 5053.
Did you set up two proxies, since you configure two upstream 127.0.01 DNSes ?
But I don't use it myself, so I'm only guessing.
Its is the default configuration applied automatically.
And dnsmask is using those servers.
And I reloaded the service already...
It is possible that something is forcing my clients to revert to plain DNS and I have to manually block it in firewall rule?
You're not using OpenDNS, I guess those defaults came with the package ...
Have you (re)started the https-dns-proxy service post install ?
Check if it's actually listening on port 5053...
DNS hijacking is possible, but it should still work from within the router.
Another option is to intercept (hijack) all outgoing UDP/TCP traffic on port 53,
and redirect it to port 5053, completely bypassing the dnsmasq.
You're right, I forgot that I changed from GoogleDNS to OpenDNS as I dont like google very much...
Yep. A couple of times
How could I do that?
How could I do it?
Shouldn't really matter, tracking's done by cookies, not IPs.
Since they've removed telnet, try nc localhost 5053.
Don't, until we know it's actually working/running 
I think you found the start of the problem, netcat returns a connection refused:
root@OpenWrt:~# nc localhost 5053
nc: can't connect to remote host: Connection refused
in that case, is the https-dns-proxy enabled ?
if yes, ssh to the router, do a ps, to see if the process' running.
try doing /etc/init.d/https-dns-proxy restart
not sure of the name ----------^
try the nc afterwards.
it might be a race condition ...
I was already ssh'd in the router to run nc, I was not supposed to do it like that?
yes, you were, just trying to make the instructions as clear as possible
Great! But then it seems like the package is not working well.
root@OpenWrt:~# /etc/init.d/https-dns-proxy restart
Stopping https-dns-proxy 2021-11-22-1 ✓
Starting https-dns-proxy 2021-11-22-1 ✓✓
root@OpenWrt:~# nc 127.0.0.1 5053
nc: can't connect to remote host (127.0.0.1): Connection refused
It has the same output with localhost than with 127.0.0.1
ok, so it appears to start, do the ps, to be sure.
you might need to check what port it's actually listening to.
try nc to port 5054 too.
Well, another turn of events, seems like a netcat problem (?).
root@OpenWrt:~# netstat -tunlp | grep '5054'
udp 0 0 127.0.0.1:5054 0.0.0.0:* 21542/https-dns-pro
root@OpenWrt:~# netstat -tunlp | grep '5053'
udp 0 0 127.0.0.1:5053 0.0.0.0:* 21543/https-dns-pro
Also, netcat is refusing the connection and the thing is that netstat doesn't list it as listening like others, for example:
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 21503/dnsmasq
ah, UDP ... >face palm<
sorry.
ok, so it's there, then you could try to catch all outgoing calls and redirect them to the 5053 or 5054.