pforemski/dingo

A DNS client in Go that supports Google DNS over HTTPS

dingo's Issues

dnstap support

• easy way for submission to Farsight SIE Passive DNS?

support Response Policy Zones?

https://dnsrpz.info/
https://tools.ietf.org/html/draft-vixie-dns-rpz-00

web interface for diagnostics & management

Like in syncthing

CoreDNS middleware?

This is more a feature request.

Would you be willing to port this over to a CoreDNS middleware?

I think it would be awesome to include this (somehow) in the existing proxy middleware. Not sure how much work that would be though.

Also re-resolving dns.google.com every so often is an interesting problem.

Ubuntu repository

...and a package & scripts that work out-of-the-box after apt-get install

Call to undefined method Illuminate\Routing\Route::getUri()

support other than Google Public DNS servers

This is in progress: allow modules to implement clients for other servers & APIs (e.g. OpenDNS would be nice).

How to use cloudflare instead of google?

Dingo was mean to be Google DNS over HTTPS but is it possible to change it to Cloudflare DNS over HTTPS ?

If so then how?

Automatic selection of closest Google servers

...just query them for dns.google.com & use the output for further queries

Support for specifying multiple servers

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.

independent DNSSEC validation

fix caching

Currently, dingo just caches DNS rrsets for 10 seconds, which generally isn't a bug, but is largely suboptimal in many cases.

support dns-api.org

need proxy support

can you add an option to use proxy connect to dns.google.com?

OpenDNS error: "http2: could not negotiate protocol mutually"

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!

May be this lrucache can fix the TTL issue?

https://github.com/cloudflare/golibs/blob/master/lrucache/lrucache.go

compile error...

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

RRSIG support

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

per-user config?

If dingo runs on loopback, it might be possible to get the remote process and user id through Linux socket diagnostics, using the NETLINK_INET_DIAG api (like ss(8)). This way we could change dingo behavior depending on who makes the query.

HTTP/2 support

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.

QUIC support

DNS over QUIC is the reason why I started the project. Implementation would require a decent QUIC client library for Go, which I believe isn't available yet.

why nslookup not recieve dingo response?

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.

https.go:39: undefined: h2quic.RoundTripper

still seems broken in master

https.go:39: undefined: h2quic.RoundTripper

How to use dingo on OpenWrt?

Hello, is there any way to use dingo on OpenWrt / LEDE?

CODE FIX -- A better method for secure random padding the DNS payload

Currently the padding takes only one random char and duplicates it to pad the DNS request payload. Ideally, each padding char should be randomized and the payload should also fill up to the MAX size of the DNS request size allowed, such that all DNS queries received are the same size MAX. This is to deter statistical analysis of the HTTPS payload for short domains such as foo.com versus really-long-domain-name-here.com. Here is some sample code to fix the current padding issue that can be patched up a little and integrated back to resolve the current problem. You can also see the sample output of the current versus the new solution. The padding is also updated to include the allowed padding chars for the Google DNS over HTTPS API.

package main

import "fmt"
import "math/rand"
import "time"
import "strings"

const padChars = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789-._~"

func main () {
  /* BAD PADDING */
  fmt.Printf("%s","BAD: ")
  fmt.Printf("%s",strings.Repeat(string(65+rand.Intn(26)), rand.Intn(500)))

  /* BETTER PADDING */
  initRand()
  fmt.Printf("\n\n%s","BETTER: ")
  fmt.Printf("%s\n",getPaddedStr(500))
}

func getPaddedStr(n int) string {
    s := make([]byte, n)
    for i := range s {
        s[i] = padChars[rand.Intn(len(padChars))]
    }
    return string(s)
}

func initRand() {
    rand.Seed(time.Now().UnixNano())
}

$ go run test.go
BAD: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

BETTER: SdS8ZICmhenQ6F1ILVG.Z959tj223~bWK-oo0sqd.K-uy5vwZAeSAeWRuvhgwXIH8-jBqRWmPCrfXpEv-f4K-x538W-yFhrTebczuZ0I2pH5AwM_opFztlek0cFb_~noZKWHeRwMJSUs3D~nIMqS-.yMge3ix610kygd2nSWTm736eGbFkOa5x_PjCNkTn7zqe47s44WgChnnSV6-IyuDJMM1aUYYT3OroObdkD8-chcM2TfPOLdZ61qmpaz_GYmz2FaLmBXCghp06~oNFIfv413LZC2M.BJpcW~HJ0Gp2vbLn5IAJ7GAwctodLXUxH4b12xrC3PCXGUJW3YKlP_VAnONcf3NSTdWTjpNqp1oEemKEUegaRqUWatpoy463mzMx~-oFD2yD28PRt.I-yJv0v8TEnQVc6K32ZY88lwKEgT-2jFMVhLwFt7dLrb-P7VX0kurl0Wx7iUleqpNEx4h71HfMpyslGEyx.8iYMrcigmBk1KJ306

Add optional command line flag to use other resolvers

It would be great to have an optional command line flag to specify a HTTPS revolver other than Google's

avoid parallel lookups for same name

During today's DynDNS outage I noticed dingo will issue a query for the same name in all threads given enough applications ask for it (eg. github.com). We should avoid this, eg by letting the query go back / timeout before trying in another thread.

Latency issue grows by number of workers On Start, improve the cost of first query

improve the cost of first query
On Start the first query is slow because delay of worker Connection waiting created, so do it After init instantly and keepalive to be ready for querys.
Or workaround with a Pseudo query / HTTP2 WritePing To establish Connection directly After worker starts within the for worker Start loop!

Connection TLS Handshake RTT latencys

do Not Push query To worker that is Not ready!
may ping them every 5 minutes to verify they Are still alive and actually WORKING waiting for work (query.)

#35

dingo actually uses HTTP/2.0 already?

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.

Pack() failed: dns: nil rr

Some DNS requests appear to be "stuck" due to an error from dingo.

To reproduce:
dig 122.141.76.110.in-addr.arpa

Error from dingo:
Pack() failed: dns: nil rr

Other public resolvers just return no answer for that query. Dingo should do the same, because the current behavior prevents certain applications to work (eg. KakaoTalk on Mac).