commonshost / playdoh Goto Github PK

Should relay the client's IP to the DNS server.

EDNS0-Client-Subnet (GeoDNS)

DNS-over-HTTPS supports EDNS0-Client-Subnet protocol, which submits part of the client's IP address (/24 for IPv4, /56 for IPv6 by default) to the upstream server. This is useful for GeoDNS and CDNs to work, and is exactly the same configuration as most public DNS servers.

Keep in mind that /24 is not enough to track a single user, although it is precise enough to know the city where the user is located. If you think EDNS0-Client-Subnet is affecting your privacy, you can set no_ecs = true in /etc/dns-over-https/doh-client.conf, with the cost of slower video streaming or software downloading speed.

To ultilize ECS, X-Forwarded-For or X-Real-IP should be enabled on your HTTP service muxer. If your server is backed by unbound or bind, you probably want to configure it to enable the EDNS0-Client-Subnet feature as well.

https://github.com/m13253/dns-over-https#edns0-client-subnet-geodns

RFC 7871 – Client Subnet in DNS Queries – defines a mechanism for recursive resolvers like Google Public DNS to send partial client IP address information to authoritative DNS name servers. Content Delivery Networks (CDNs) and latency-sensitive services use this to give accurate geo-located responses when responding to name lookups coming through public DNS resolvers.

The RFC describes ECS features that authoritative name servers must implement; but implementers don’t always follow those requirements. There are also ECS operational and deployment issues the RFC does not address that can cause problems for resolvers like Google Public DNS that auto-detect ECS support in authoritative name servers, as well as resolvers that require ECS whitelisting, like OpenDNS.

https://developers.google.com/speed/public-dns/docs/ecs

Would be nice to support JSON as an alternative data format. Much easier to work with as developers or looking at the traffic in curl/inspector. Should be supported for parsing incoming requests (content-type header) as well as generating/translating responses (accept header).

RFC 8427 Representing DNS Messages in JSON

• https://datatracker.ietf.org/doc/rfc8427/
• https://developers.cloudflare.com/1.1.1.1/dns-over-https/json-format/ (note: wrong MIME type)
• https://www.iana.org/assignments/media-types/application/dns+json

Reference:
https://docs.travis-ci.com/user/languages/javascript-with-nodejs/#specifying-nodejs-versions

Test against various DOH clients. So far Firefox 64 (Nightly) works fine.

https://github.com/curl/curl/wiki/DNS-over-HTTPS#supported-in-browsers-and-clients

Draft here: https://tools.ietf.org/html/draft-pauly-dprive-oblivious-doh-01

The gist of it:

Oblivious DoH requires, at a minimum:

   o  Two DoH servers, where one can act as an Oblivious Proxy, and the
      other can act as an Oblivious Target.

   o  Public keys for encrypting DNS queries that are passed from a
      client through a proxy to a target (Section 6).  These keys
      guarantee that only the intended Oblivious Target can decrypt
      client queries.

   o  Client ability to generate random [RFC4086] one-time-use symmetric
      keys to encrypt DNS responses.  These symmetric keys ensure that
      only the client will be able to decrypt the response from the
      Oblivious Target.  They are only used once to prevent the
      Oblivious Target from tracking clients based on keys.

Never did dgram stuff before. Does this ever close the stream? What if mkDnsQuery is called multiple times, are the answers matched with the queries somehow?

function mkDnsQuery( buf: Buffer ) {
  return new Promise(function( resolve, reject ) {
    socket.send(buf, 0, buf.length, 53, '192.168.1.1' )
    socket.on( 'message', function( message ) {
      resolve( message )
    })
    socket.on( 'error', function( err ) {
      reject( err );
    })
  })
}