How do I use the dnscrypt with adblocker

I would like to use the dnscrypt along with adblocker.

Is this something that has been tested? Does anyone have any experience?

I read it wasn’t supported. Is that right?


1 Like

That seems unlikely to have been tested (but maybe some such person replies).

I personally prefer DNS-over-TLS, as it’s standardized in IETF, and that’s why it got implemented in knot-resolver. The default version in current Omnia RC does support that. I expect no problems combining that (or a dnscrypt proxy) with the adblock package.

1 Like

Would be nice to see DNSCrypt support; The founder of dnscrypt actually abandoned the project in favor of dns over tls; however there is a lot of conflicting information out there regarding what is the better choice…
for example

Why use DNSCrypt?
thumb_up Encrypts and authenticates the DNS traffic
thumb_up Specifically designed for DNS
thumb_up Has been battle tested
thumb_up A good amount of servers support the protocol
thumb_up Includes mitigations against DNS amplification attacks
thumb_up Can use UDP and TCP for transport
thumb_up Inherently supports reordering, parallelism and priorities
thumb_up Keeps a minimal number of states server-side
thumb_up Very simple to implement; requires only two standard cryptographic constructions
thumb_up Doesn’t require a TLS stack, which vastly reduces the attack surface
thumb_up Doesn’t have any insecure parameters
thumb_up Doesn’t rely on X509 certificates and Certificate Authorities
thumb_up Cannot be MITM’d by standard tools
thumb_up Enforces certificate signatures
thumb_up Has a complete specification since 2013
thumb_up Regular DNS and DNSCrypt can share the same port (although port 443 is recommended due to routers frequently hijacking port 53)
thumb_up Post-quantum version in developement, intent to ship in the forthcoming weeks
thumb_down Does not have an RFC

DNS over TLS (RFC7858)
thumb_up Full encryption of the DNS protocol
thumb_up Has an increasing number of servers in deployment
thumb_up Partially specified as a RFC
thumb_upMany implementations completed at various stages
thumb_down Uses a dedicated port (853) likely to be blocked or monitored in situations where DNS encryption is useful
thumb_down Initial connection is slow due to the long handshake (until TLS 1.3 is deployed)
thumb_down Not well understood even by its proponents. It is a truck, as it is heavy and slow to load, but most if not all implementations perform a full round trip for every packet (even the excellent miekg/dns library as used by Tenta).
thumb_down Padding rules haven’t been specified besides a draft that doesn’t have any implementations
thumb_down Requires a full TLS stack, introducing a large attack surface
thumb_down Difficult to implement securely. Validating TLS certificates in non-browser software is the most dangerous code in the world
thumb_down Readily compatible with industry-standard TLS interception/monitoring devices. Having people install additional root certificates is easier than custom software.
thumb_down Requires TCP
thumb_down Requires sessions tracking on the server
thumb_down TLS is a generic transport mechanism. It doesn’t support reordering and parallelism and doesn’t include any ways to manage priorities. New mechanisms need to be invented and implemented to do so.
thumb_down Key management can be surprisingly hard especially if public key pinning is used by clients
thumb_down Allows insecure algorithms and parameters
thumb_down Questionable practical benefits over DoH

What do you think?

This leaves me feeling it would be a great to see a script for installing the latest dnscrypt package on the Turris so people have options, as this new trend for encrypted/secure dns continues to evolve.

So far as I can tell, Stubby is looking like the most feature rich resolver for dns over tls at the time of this post; however as mentioned here in this excellent article which I quote in relation to stubby “Even in the case of authoritative resolvers, extensions to DNS such as EDNS0 Client Subnet may reveal information about the user’s IP address or subnet to authoritative DNS servers higher in the DNS hierarchy.”

Half the thumb-downs don’t really apply (not to knot-resolver or not anymore). Some of the remaining ones seem subjective/questionable IMHO.

I believe Stubby is meant to run on your end-user machines (say notebook), sending DNS to your router or some other not-too-far machine. AFAIK it has no cache and no DNSSEC validation, though you can achieve that via combining with a full resolver.

Of course, everyone can decide what (s)he prefers and submit a dnscrypt proxy support or something…

1 Like

@vcunat, Stubby is in the repos of entware on my router and others as well; it can be installed in windows also. Thank you so much for sharing your thoughts; I’ll definitely take that into consideration.

Anybody figure this one out yet? There are dozens of unique independent resolvers around the world that use DNScrypt, would be nice to see a script for installing this on the Turris; and not be forced only to use Dns over TLS with Knot on NSA jurisdiction systems like google & cloudflare

A few general considerations perhaps which basically apply to any service provided by 3rd parties, e.g. VPN:

  • those 2 providers mentioned probably are best to be avoided for the apparent reasons
  • alternatives are run/operated/managed by whom exactly since it could be any eavesdropping agent in disguise or someone with an affiliation to any such agent?
  • alternatives been audited respectively being frequently audited?
  • if such audits then by whom, who paid for the audits and are the audits conducted unannounced or had the party being audited time to prepare (change settings/records) in advance?
  • is the party being audited fully/wholesomely transparent in releasing the audits?
  • how is the implementation of the service provided by alternatives, e.g. their software up-to-date or eventually suffering exploits/leaks?
  • how secure are the protocols in comparison, e.g. DNSCrypt vs. TLS 1.2 and TLS 1.3 respectively?
  • how is the performance of the protocols in comparison?
  • how is the performance of the service provider in general, e.g. down time, redundancy (some of the DNSCrypt nodes are hardly reliable at all)?

In the end it probably bears down to due diligence and/or gut feeling.

For many of the mentioned reasons I would not trust VPN providers but rather deploy my own remote node whilst being aware that once the traffic exits that node it is exposed as any other traffic whilst being publicly routed (in transit) to the destination node.

As for DNSCrypt the unbound has decent support for it and since I am being a stout unbound user I am not familiar with kresd and its ability to manage DNSCrypt.

1 Like

There’s no support in knot-resolver and we don’t plan to add it. In the worst case you can always make kresd forward to a proxy or some such combinations.

If you are that worried then you could make your own and advertise it, as security is enhanced in numbers. If you are that concerned pick a resolver operating out of a country that has strict laws and does not operate with in the various “eyes” countries. Same concerns go for any dns resolver no matter if it is operates via dns over tls or dnscrypt.

It is important to do your research prior to if you really care about your security, or use your own; and if you implement it loglessly there is no privacy issue; the problem with only one or two persons using a dnscrypt server, is those results can potentially monitored by an adversary monitoring request from an upstream server; security is in numbers, unless there are secure methods of downloading the entire authoritative global list of DNS domain names in total at regular intervals over a secure connection. Otherwise if tens of thousands of people are using a dnscrypt server, and an attack was successful between the recursive resolver and the dnscrypt server, only random attacks would be possible against the clients, not targeted attacks. Meaning one in 10,000 people would be randomly affected or something as such, just as one example. Dnscrypt prevents any identifying information that could reveal the identity of the client from reaching upstream resolvers.

As for dnscrypt security vs the competition, look here:

it outdoes the competition by a long shot, its faster as it functions over the udp protocol & does not have to parse and modify dns parameters

jedisct1, the programmer behind dnscrypt explains the performance & security benefits of dnscrypt over tls/https here:

Here is a few important snippets from dnscrypt programmer to consider from the second link just for convenience sake “TLS session tickets allow DNS operators to track devices no matter what their IP are. TCP sessions allow DNS operators to fingerprint devices sharing the same external IP. From a privacy perspective, this is effectively a regression over plain DNS. So for people who care about this, you need to add the ability to disable these. Performance will be terrible, but that’s what you get for using a transport protocol that was never designed for DNS. This can be partially mitigated with DoH using forthcoming HTTP/2 extensions. But for raw TLS that doesn’t allow much except send() and receive() packets, there’s no hope without reinventing HTTP.”

Sorry for the double updated post I thought the previous one was deleted, it will be shortly. The current resolver that I have chosen includes No forwarding to external/upstream DNS servers (recursive)

The only way to ensure there is no effective tampering between the client and the recursive resolver on the other side of the dnscrypt/tls/doh server… is dnssec. Dnssec is used on a per domain basis, if the user opt’s their domain to include dnssec protections. Dnssec is then implemented at the root authoritative dns recursive server level globally, meaning it is impossible for someone to fabricate or tamper with these records no matter who gets their hands on them. The problem is only one in a thousand, or one in 10,000 websites use this, not even google or facebook implement dnssec. I found one random porn site in 2-3 days worth of dns records that was actually validated by dnssec. For now its mostly just a burden for speed. It should be mandatory for all registrars and domains!

These arguments are quite biased IMO, but I won’t digress on that.

BTW, I can’t see how DNSSEC is related to this thread, as that’s a different mostly orthogonal aspect of security.

1 Like