dnscrypt can't reach 208.67.220.220:443 anymore
dnscrypt doesn't work currently:
sudo /usr/local/opt/dnscrypt-proxy/sbin/dnscrypt-proxy --user=nobody --resolver-name=opendns
[NOTICE] Starting dnscrypt-proxy 1.4.0
[INFO] Initializing libsodium for optimal performance
[INFO] Generating a new key pair
[INFO] Done
[ERROR] Unable to retrieve server certificates
[INFO] Refetching server certificates
[ERROR] Unable to retrieve server certificates
[INFO] Refetching server certificates
[ERROR] Unable to retrieve server certificates
[INFO] Refetching server certificates
[ERROR] Unable to retrieve server certificates
[INFO] Refetching server certificates
[ERROR] Unable to retrieve server certificates
[INFO] Refetching server certificates
[ERROR] Unable to retrieve server certificates
[INFO] Refetching server certificates
[ERROR] Unable to retrieve server certificates
[INFO] Refetching server certificates
[ERROR] Unable to retrieve server certificates
[INFO] Refetching server certificates
[ERROR] Unable to retrieve server certificates
[INFO] Refetching server certificates
[ERROR] Unable to retrieve server certificates
[INFO] Refetching server certificates
[ERROR] Unable to retrieve server certificates
[INFO] Refetching server certificates
but a normal lookup will work:
host www.google.com 208.67.220.220
Using domain server:
Name: 208.67.220.220
Address: 208.67.220.220#53
Aliases:
www.google.com has address 173.194.34.113
www.google.com has address 173.194.34.114
www.google.com has address 173.194.34.115
www.google.com has address 173.194.34.112
www.google.com has address 173.194.34.116
www.google.com has IPv6 address 2a00:1450:4001:c02::67
In wireshark I see dnscrypt-proxy sending packets to 208.67.220.220:443 and not getting any answer.
Is my provider blocking 208.67.220.220:443 but not 208.67.220.220:53 or is something down at opendns?
-
The "normal" lookup was wrong for your purpose. The host command doesn't seem to support port numbers. Try this:
nslookup -port=443 www.google.com. 208.67.220.220
- or -
dig -p 53 www.google.com @208.67.220.220
-
Sorry, I meant to write: dig -p 443 www.google.com @208.67.220.220
-
Yes, I known, I did a normal lookup to see if the server was up and running. The dig command doesn't work either, as expected. The question is: is 208.67.220.220 down on port 443 or does my provider blocks only port 443 to this IP and not 53? (doesn't make sense actually, but who knows)
It's the same with 208.67.222.222.
[14:15]:dig -p 443 www.google.com @208.67.220.220
; <<>> DiG 9.8.3-P1 <<>> -p 443 www.google.com @208.67.220.220
;; global options: +cmd
;; connection timed out; no servers could be reached[14:15]:dig -p 443 www.google.com @208.67.222.222
; <<>> DiG 9.8.3-P1 <<>> -p 443 www.google.com @208.67.222.222
;; global options: +cmd
;; connection timed out; no servers could be reached -
Most likely no problem with OpenDNS, because otherwise the forum would be full with related threads.
That said, something blocks at least port 443 to the OpenDNS resolver addresses, this is fact. You still can see if this is for both, UDP and TCP.
dig +vc -p 443 www.google.com @208.67.220.220 (test with TCP)
Hard to judge from somewhere else whether it is your ISP or maybe your firewall (router) or what...
Simply try with either port 53 or port 5353 which all are supported. You just need to start the dnscrypt-proxy with the related argument / parameter. You may test with dig before to see if it would work.
-
There were issues with OpenDNS where port 443 was filtered by mistake at some datacenters.
@hobbes444 can you try with another provider also using port 443 such as okturtles, CloudNS or dnscrypt.eu?
Also, if you send a TXT query to 208.67.222.222, if should return the OpenDNS datacenter you are routed to. Mind sharing which one it is?
-
So, TCP to 443 works and the opendns server is 1.ams.
With dnscrypt.eu, it's the same: UDP fails, TCP works, on port 443.dig +vc -p 443 www.google.com @208.67.220.220
; <<>> DiG 9.8.3-P1 <<>> +vc -p 443 www.google.com @208.67.220.220
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37679
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.google.com. IN A
;; ANSWER SECTION:
www.google.com. 300 IN A 173.194.67.106
www.google.com. 300 IN A 173.194.67.103
www.google.com. 300 IN A 173.194.67.147
www.google.com. 300 IN A 173.194.67.99
www.google.com. 300 IN A 173.194.67.104
www.google.com. 300 IN A 173.194.67.105
;; Query time: 51 msec
;; SERVER: 208.67.220.220#443(208.67.220.220)
;; WHEN: Thu Jun 12 10:01:49 2014
;; MSG SIZE rcvd: 128dig which.opendns.com txt @208.67.220.220
; <<>> DiG 9.8.3-P1 <<>> which.opendns.com txt @208.67.220.220
;; global options: +cmd;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6937
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;which.opendns.com. IN TXT
;; ANSWER SECTION:
which.opendns.com. 0 IN TXT "1.ams";; Query time: 1065 msec
;; SERVER: 208.67.220.220#53(208.67.220.220)
;; WHEN: Thu Jun 12 10:02:53 2014
;; MSG SIZE rcvd: 53 -
Even with port 53 dnscrypt still doesn't work:
sudo dnscrypt-proxy --user=nobody --resolver-name=opendns --resolver-address=208.67.222.222:53
[NOTICE] Starting dnscrypt-proxy 1.4.0
[INFO] Initializing libsodium for optimal performance
[INFO] Generating a new key pair
[INFO] Done
[ERROR] Unable to retrieve server certificates
[INFO] Refetching server certificates -
"This is clearly a problem in my corporate network."
Ah, this was new but essential information for us! If you had said this initially, my first approach would have been to test from a home network too or to simply not to use dnscrypt in the network...
Who could have known that you talked about your work network where you probably don't have administrative rights. Unlike in home networks, it's common practice that nearly every direct passthrough traffic is blocked in corporate networks, but everything goes through proxies, NAT devices and other filters. I would not have assumed that parts of dnscrypt work nevertheless. There's evidently a security flaw in this network if you can configure alternative DNS services and are not bound to use the internal DNS servers...
That said, every condition is so much different in corporate networks. You even don't need to think about comparing these with home networks and to be able using everything like at home.
-
Sorry about that. Should have started with this. Since google public DNS worked (and some days opendns works too) I assumed dnscrypt should work too, but it seems this assumption was wrong. Anyway, I give up, if it's an issue with the corporate network and not with dnscrypt, I can't do anything about it. I don't want to use the corporate DNS for my private surfing (I am legally allowed to privately use the internet at work), but I guess using something like zenmate is probably simpler.
Please sign in to leave a comment.
Comments
12 comments