go version: go1.9beta2 linux/amd64 quic-go: Latest commit 3157e2d

Error log: go get -u github.com/pforemski/dingo

github.com/pforemski/dingo

../src/github.com/pforemski/dingo/https.go:39:15: undefined: h2quic.QuicRoundTripper

Hi Pawel,

Lately OpenDNS seems to give an error (latest version of code):

$ ./dingo -port=53 -odns:workers=10 -gdns:workers=0 2017/01/05 14:29:40 starting 10 OpenDNS client(s) querying server 67.215.70.81 2017/01/05 14:29:40 dingo ver. 0.13 listening on 127.0.0.1 UDP port 53 2017/01/05 14:29:43 resolving index.hu./A 2017/01/05 14:29:43 http.Do(): Get https://67.215.70.81/A/index.hu.: http2: could not negotiate protocol mutually

Google works all right.

Also, thanks for the great software, keep up the good work!

Go supports H/2 natively, but only if we don't touch the defaults, which isn't the case: dingo spoofs the SNI string in TLS handshakes, which is why Go selects the HTTP/1.1 transport instead of HTTP/2.

I don't have much experience with golang, but I just read the following on the net/http2 docs: This package is low-level and intended to be used directly by very few people. Most users will use it indirectly through the automatic use by the net/http package (from Go 1.6 and later).

Also see the following (bottom of page): The http package has transparent support for the HTTP/2 protocol when using HTTPS.

I know it maybe not a problem of dingo. I download dingo and try to use it. On my terminal , I get many outputs which like these: 2021/12/15 00:52:03 resolving cn.archive.ubuntu.com./AAAA 2021/12/15 00:52:03 resolving cn.archive.ubuntu.com./A 2021/12/15 00:52:04 resolving security.ubuntu.com./AAAA 2021/12/15 00:52:04 resolving security.ubuntu.com./A 2021/12/15 00:52:04 resolving dl.google.com./A 2021/12/15 00:52:04 resolving dl.google.com./AAAA 2021/12/15 00:52:08 resolving _http._tcp.cn.archive.ubuntu.com./SRV It seems dingo works. But My nslookup only ;; connection timed out; no servers could be reached

What configuration do I miss or what's wrong with my ubuntu 21? It's wired to me, since it seems that none of dingo user get the error when I search an answer on the web.

I have no idea on how does this work, so maybe I search the wrong place using the wrong key.

I hope someone here can help me. Thanks a lot.

Hello,

First of all, let me thank you for your great work with dingo, I'm currently finding it quite useful!

I was wondering if you had any plans of adding multiple server support for dingo. Something along the lines of what dnsmasq does, but simpler. The idea would be allowing the user to specify multiple servers, and one strategy for which one to use: Query all of them and return the fastest response, random/round robin, or fallback on error.

I can probably work on a PR implementing this if you find it interesting.

This also changes the default server to cloudflare, by decreasing the worker count on gdns to 0. That might not be optimal for consistency reasons. Someone could also combine the common parts of cfdns and gdns to to use the same / inherited structures.
I have very little experience with go(*this is the first go project i ever touched) and just needed this to work on my router as a static binary, so i'm not the best person to do that.

PS: Thanks you for your work. Have been using dingo for over a year with google and i'm very happy with it. :) PPS: I'm not so happy with google. I just happend to notice today that their server failed to resolve some domains and had to switch to another. I do hope cloudflare does fare better.

Running dig @127.0.0.1 -p 8853 rrsig debian.org pointed to dingo gives this log:

$ dingo-linux-amd64 -port 8853
2017/09/24 03:38:07 starting 10 Google Public DNS client(s) querying server 216.58.195.78
2017/09/24 03:38:07 dingo ver. 0.13 listening on 127.0.0.1 UDP port 8853
2017/09/24 03:38:11 resolving debian.org./RRSIG
2017/09/24 03:38:11 Pack() failed: dns: nil rr

And does not return any data, check what should be returned by running dig @8.8.8.8 rrsig debian.org

secureoperator has the same bug here

https://github.com/chenhw2/google-https-dns seems to work for RRSIG