Replies: 1 comment 6 replies
-
|
Yes, you do. Try then you will know. |
Beta Was this translation helpful? Give feedback.
-
|
There is no block/allow lists reloading at all in the program. And, I guess you are saying |
Beta Was this translation helpful? Give feedback.
-
|
Yes I mean with “*” |
Beta Was this translation helpful? Give feedback.
-
|
Honestly I don't know what's wrong. NSLOOKUP command is reflecting the blocklist file "real-time" changes after restarting the proxy....the browsers don't. I have also flushed the DNS cache of both Safari and Firefox but realtime changes on the blocklist txt files are not caught as I described above |
Beta Was this translation helpful? Give feedback.
-
|
Long connection reused? Did you restart the browser? |
Beta Was this translation helpful? Give feedback.
-
|
I think I found the root cause. On MacOS the mDNSResponder daemon is the system-wide DNS resolver. From this manual definition I desume that it acts as "hub" for all the DNS queries started from the various apps...so flushing mDNSResponder cache (sudo killall -HUP mDNSResponder) after restarting the dnscrypt proxy it seems to solve the issue. I'm still testing it |
Beta Was this translation helpful? Give feedback.
-
Didn’t find an exact answer in the wiki. Let’s say I have set a cron for a script to update every day a blocklist external txt file. Do I need to launch the dnscrypt-proxy service restart command as well? In other words if I change the content of the blocklist.txt do I need to restart the dnscrypt-proxy?
Beta Was this translation helpful? Give feedback.
All reactions