Unbound, stubby or dnscrypt-proxy


#1

I’ve been reading about the choices on this and other forums, but found no convincing answer to this question, so I decided to test them all myself (ongoing). After a while, I figured out how to run them all together, thus getting DNS privacy by obscurity.

Here is my setup:
I’m still only using ipv4, my provider refuses to exchange the docsis cable modem to a v3 modem.
I’m still running the production version of pihole, so no FTLDNS yet, because dnsmasq2.80test2 has a fix for DNSSEC. FTLDNS, based on dnsmasq2.79, doesn’t have that fix.
DNSSEC is handled by dnsmasq, this to be able to identify (false) BOGUS dns entries, using the pihole admin page and the dnsmasq log. Also, it is recommended to keep DNSSEC evaluation as close to the client as possible, dnsmasq is the entry point for clients.

I’m still in the process of optimizing the configs, but here is what I got so far:

the dnsmasq config (/etc/dnsmasq.d/04-servers.conf) . As you know, you can add multiple configuration files to this folder, so I removed all server settings from /etc/dnsmasq.d/01-pihole.conf and created a separate file for servers:

server=127.10.10.1#5551
server=127.10.10.2#5552
server=127.10.10.3#5553

As you know, dnsmasq has a built in mechanism to determine the fastest server available.
you can change the defaults, if you want to, by changing

#define FORWARD_TEST 50 /* try all servers every 50 queries */
#define FORWARD_TIME 20 /* or 20 seconds */

in the source, (/dnsmasq-2.80test2/src/config.h) before compiling dnsmasq. You cannot change these settings, once compiled.
This implies, dnsmasq will test all specified resolvers every 50 queries OR every 20 seconds. Notice the entries in the log:

dnsmasq[10498]: 14986 192.168.2.228/64790 forwarded nav.smartscreen.microsoft.com to 127.10.10.1
dnsmasq[10498]: 14986 192.168.2.228/64790 forwarded nav.smartscreen.microsoft.com to 127.10.10.2
dnsmasq[10498]: 14986 192.168.2.228/64790 forwarded nav.smartscreen.microsoft.com to 127.10.10.3

That’s the speed test. The domain name will be different, It’s just the domain name you are trying to resolve when the (timer) conditions are met.

Another thing you can change, before compiling dnsmasq, is the maximum cache size, by changing:

if (size < 0)
      size = 0;
else if (size > 10000)
      size = 10000;

in the source (/dnsmasq-2.80test2/src/option.c). Change the value to, for example 65535 (twice). Once everything is up and running, including pihole, you can than increase the cache size by changing the value in /etc/dnsmasq.d/01-pihole.conf and restart dnsmasq. Remember, 01-pihole.conf reverts to default (10000) whenever you run ‘pihole -r’ or pihole -up’. The result (in the dnsmasq log):

dnsmasq[29727]: started, version 2.80test2 cachesize 65535

I try to keep all my configuration files intact, including comments. for the sake of keeping things small, I ran

sed '/^[[:blank:]]*#/d;s/#.*//' <filename>

before pasting them in this topic. This implies, the configurations also lists the default (original) settings.

The unbound setup and config:
I followed this wiki to setup unbound, and modified the configuration (/etc/unbound/unbound.conf.d/pi-hole.conf) as follows:

server:
    logfile: /var/log/unbound.log
    verbosity: 1
    interface: 127.10.10.2
    port: 5552
    do-ip4: yes
    do-udp: yes
    do-tcp: yes
    do-ip6: no
    root-hints: "/var/lib/unbound/root.hints"
    harden-glue: yes
    use-caps-for-id: no
    cache-min-ttl: 3600
    cache-max-ttl: 86400
    prefetch: yes
    num-threads: 1
    so-rcvbuf: 1m
    edns-buffer-size: 1472
    private-address: 192.168.0.0/16
    private-address: 172.16.0.0/12
    private-address: 10.0.0.0/8

‘edit’
ref: added comment from @mibere, see below
changed the setting ‘use-caps-for-id: no’
added the setting ‘edns-buffer-size: 1472’
‘/edit’

The stubby setup and config:
I followed this and this wiki to setup stubby, and modified the configuration (/etc/stubby.yml) as follows:

resolution_type: GETDNS_RESOLUTION_STUB
dns_transport_list:
  - GETDNS_TRANSPORT_TLS
tls_authentication: GETDNS_AUTHENTICATION_REQUIRED
tls_query_padding_blocksize: 256
edns_client_subnet_private : 1
idle_timeout: 10000
listen_addresses:
  - 127.10.10.3@5553
round_robin_upstreams: 1
upstream_recursive_servers:
  - address_data: 145.100.185.15
    tls_auth_name: "dnsovertls.sinodun.com"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: 62lKu9HsDVbyiPenApnc4sfmSYTHOVfFgL3pyB+cBL4=
  - address_data: 145.100.185.16
    tls_auth_name: "dnsovertls1.sinodun.com"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: cE2ecALeE5B+urJhDrJlVFmf38cJLAvqekONvjvpqUA=
  - address_data: 185.49.141.37
    tls_auth_name: "getdnsapi.net"
    tls_pubkey_pinset:
      - digest: "sha256"
        value: foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=

As you can see, I’m still using the default resolvers, awaiting suggestions…

The dnscrypt-proxy setup and config:
I followed wiki to setup dnscrypt-proxy, and modified the configuration (/opt/dnscrypt-proxy/dnscrypt-proxy.toml) as follows:

server_names = ['scaleway-fr', 'de.dnsmaschine.net']
listen_addresses = ['127.10.10.1:5551', '[::1]:5551']
max_clients = 250
ipv4_servers = true
ipv6_servers = false
dnscrypt_servers = true
doh_servers = true
require_dnssec = true
require_nolog = true
require_nofilter = true
force_tcp = false
timeout = 2500
keepalive = 30
lb_strategy = 'p2'
log_level = 0
log_file = '/var/log/dnscrypt-proxy.log'
cert_refresh_delay = 240
dnscrypt_ephemeral_keys = true
tls_cipher_suite = [52392, 49199]
fallback_resolver = '208.67.222.222:53'
ignore_system_dns = false
log_files_max_size = 10
log_files_max_age = 7
log_files_max_backups = 1
block_ipv6 = false
cache = false
cache_size = 512
cache_min_ttl = 600
cache_max_ttl = 86400
cache_neg_min_ttl = 60
cache_neg_max_ttl = 600
[query_log]
  format = 'tsv'
[nx_log]
  format = 'tsv'
[blacklist]
[ip_blacklist]
[whitelist]
[schedules]
[sources]
[sources.'public-resolvers']
urls = ['https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/public-resolvers.md', 'https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md']
cache_file = 'public-resolvers.md'
minisign_key = 'RWQf6LRCGA9i53mlYecO4IzT51TGPpvWucNSCh1CBM0QTaLn73Y7GFO3'
refresh_delay = 72
prefix = ''
[static]

Here, I’ve done some research. I want, as you can see in the configuration, servers with the following options: ‘no filter’, ‘no logging’ and ‘DNSSEC’.
A lot of the servers, listed here, seem to match the criteria, however, a lot of these servers also have a problem with DNSSEC. I found 2 ipv4 servers that don’t seem to have this problem: ‘scaleway-fr’ and ‘de.dnsmaschine.net

The result, after running this for 24 hours:

Inevitable questions:

Q: How to get the resolvers names in the graph?
A: Simply add the resolvers names to /etc/hosts

# dnscrypt-proxy v2
127.10.10.1	dnscrypt-proxy-v2
# unbound
127.10.10.2	unbound
# stubby
127.10.10.3	stubby

Q: Why so many local requests?
A: I’ve added two files to the dnsmasq config, to resolve internal IP addresses.
/etc/localdns.list, don’t forget to change the domain name (localdomain), format (example):

192.168.2.57	raspberry57.localdomain		wpad.localdomain	raspberry57	wpad
192.168.2.68	macbook.localdomain		macbook
192.168.2.99	tx-l42d25e.localdomain		tx-l42d25e
192.168.2.100	ps3.localdomain			ps3

/etc/dnsmasq.d/06-localdns.conf

domain=localdomain
expand-hosts
local=/localdomain/
addn-hosts=/etc/localdns.list

Windows 10 keeps querying wpad.localdomain and my other windows machines. This explains the high local query count. This behavior started as soon as I configured a domain in pfsense (mandatory).

You can eliminate a timeout on the wpad request by adding it to the localdns.list (see above) and placing a reply (/var/www/html/wpad.dat) in the pihole webservers directory

function FindProxyForURL(url, host)
{
return "DIRECT";
}

Q: How to compile dnsmasq from source (on raspbian)
A: Run the following script (sudo). Don’t do this if you’re running FTLDNS!

#!/bin/bash

# Make sure only root can run our script
if [ "$(id -u)" != "0" ]; then
  echo "This script must be run as root" 1>&2
  exit 1
fi

# install build-essential from STRETCH
sudo DEBIAN_FRONTEND=noninteractive apt-get -yq install build-essential

# install necessary system packages for dnsmasq
# the packages required to build from source are specified under Build-depends in the file debian/control
sudo apt-get -yq install gettext
sudo apt-get -yq install libnetfilter-conntrack-dev
sudo apt-get -yq install libidn11-dev
sudo apt-get -yq install libdbus-1-dev
sudo apt-get -yq install libgmp-dev
sudo apt-get -yq install nettle-dev
sudo apt-get -yq install libbsd-dev
sudo apt-get -yq install liblua5.2-dev

# dnsmasq
file=dnsmasq-2.80test2
mkdir -p dnsmasq
cd dnsmasq
wget http://www.thekelleys.org.uk/dnsmasq/test-releases/$file.tar.gz
tar xzf $file.tar.gz
cd $file
fakeroot debian/rules binary
cd ..
sudo dpkg -i dnsmasq*.deb
cd ..

Q: How many dns queries where performed during the test?
A: I use this software to preform load tests, I run them simultaneously on multiple machines. Pihole stats:
Total queries (6 clients): 4169
Queries blocked: 555
Domains on block list: 601791

I’m NOT a Linux savy, I’m just really good at implementing wiki’s and find solutions in duckduckgo. Therefore, I’m willing to answer any question, however, no promises made…

‘edit’ Typo’s ‘/edit’

discuss…


Unbound breaking FTLDNS?
IPv6 and unboud/stubby/dnscrypt-proxy
IPv6 and unboud/stubby/dnscrypt-proxy
Top List Showing IP vs Hostname
#2

My DNSCrypt server dnscrypt.me was affected. After writing with @jpgpi250 and Frank Denis there are two changes in my Unbound configuration now:

previous settings:

edns-buffer-size: 1252
use-caps-for-id: yes

current/new settings:

edns-buffer-size: 1472
use-caps-for-id: no

@jpgpi250 was so kind to test the server again, with positive test results.

In my opinion the change of use-caps-for-id solved the DNSSEC issues.
I recommend to disable (the default value is no) this option in unbound.conf.


#3

I can confirm the dnscrypt-proxy server ‘dnscrypt.me’, info here , is now behaving as expected.

I’ve asked Simon Kelley, the dnsmasq developer, to comment on the changed unbound settings. His comment:
‘quote’
Increasing the edns buffer size should avoid fallback to TCP, which is good.
‘use-caps-for-id’ may interact badly with some authoritative servers, it’s probably not going to affect dnsmasq.
‘/quote’

Since I’m also using unbound as a recursive dns sever, see wiki, and the implementation description above, I’ve also changed these settings in my unbound config.

I’ve updated/added the settings in the first entry of this topic, this to avoid errors for those who copy/paste them entirely.

@DL6ER change it in the wiki?


#4

What do you want me to change exactly?

This?

I have no objections against just removing use-caps-for-id as it defaults to No. It’s just that the majority of unbound tutorial out there seem to suggest it hence I added it as it didn’t show a negative effect in my use case.

EDIT I already removed it, do you think any further changes are required? @jpgpi250


#5

It’s surely a good feature, and I would like to use it, but I now follow the many footnotes that use-caps-for-id may cause problems.

You should use use-caps-for-id: no in your own tutorials and configuration.


#6

I would suggest to change the ‘use-caps-for-id: no’, since it may cause problems, ref @mibere’s footnotes.

I also would suggest to add ‘edns-buffer-size: 1472’. Explanation:
When using the command ‘dig @127.10.10.1 -p 5551 +dnssec www.raspberrypi.org’, e.g. talk to dnscrypt-proxy (or any other resolver solution - unbound - stubby) you often see the message ‘;; Truncated, retrying in TCP mode.

It looks like adding ‘edns-buffer-size: 1472’ to the unbound configuration eliminates this. This appears to be the conclusion of Simon Kelley
‘quote’
Increasing the edns buffer size should avoid fallback to TCP, which is good.
‘/quote’

Anyway, your wiki, your choice…


#7

Well, I consider it more as “our” wiki, so I’m happy to optimize it as much as possible with the help of the community.

I already removed this before the two of you replied, I guess you just have missed by edit message. Do you think it is a good idea to include it with the option explicitly set to “no”?

Okay, I see your point, but why 1472? So far I don’t see an explanation for this seemingly random number. Having said that, I’m happy to include it as well, and I know that a number like 2048 may be arbitrary as well, but at least we’re more used to power-of-two numbers.


#8

If you include it set to “no” you should also comment why “no” is the recommended setting.
Maybe a simple “To prevent DNSSEC issues”.

See the official Unbound documentation

   edns-buffer-size: <number>
          Number of bytes size to advertise as the EDNS reassembly  buffer
          size.   This  is  the  value put into datagrams over UDP towards
          peers.  The actual buffer size is determined by  msg-buffer-size
          (both  for  TCP  and  UDP).   Do not set higher than that value.
          Default is 4096 which is RFC recommended.  If you have  fragmen-
          tation  reassembly  problems,  usually  seen as timeouts, then a
          value of 1472 can fix it.  Setting to 512 bypasses even the most
          stringent  path  MTU problems, but is seen as extreme, since the
          amount of TCP fallback generated is excessive (probably also for
          this resolver, consider tuning the outgoing tcp number).

#9

Okay, thanks. I will edit it soon. The wikis are scheduled to move to our new documentation space anyway, so I will probably just edit it there.


#10

Okay, done. See https://docs.pi-hole.net/guides/unbound/


#11

Hey, i setup my Pihole with this Guide.

It works but i have this errors:

When i use sudo apt-get update && sudo apt-get upgrade && sudo apt-get autoremove:

“Fehl:1 http://archive.raspberrypi.org/debian stretch InRelease
»archive.raspberrypi.org« konnte nicht aufgelöst werden.
Fehl:2 http://raspbian.raspberrypi.org/raspbian stretch InRelease
»raspbian.raspberrypi.org« konnte nicht aufgelöst werden.
Ign:3 http://giteduberger.fr rpimonitor/ InRelease
Holen:4 http://giteduberger.fr rpimonitor/ Release [1.396 B]
Es wurden 1.396 B in 1 s geholt (789 B/s).
Paketlisten werden gelesen… Fertig
W: Fehlschlag beim Holen von http://raspbian.raspberrypi.org/raspbian/dists/stretch/InRelease »raspbian.raspberrypi.org« konnte nicht aufgelöst werden.
W: Fehlschlag beim Holen von http://archive.raspberrypi.org/debian/dists/stretch/InRelease »archive.raspberrypi.org« konnte nicht aufgelöst werden.
W: Einige Indexdateien konnten nicht heruntergeladen werden. Sie wurden ignoriert oder alte an ihrer Stelle benutzt.”

and i have many local requests:

May 18 11:04:13 dnsmasq[3751]: 17308 192.168.178.23/61196 query[A] pi.hole from 192.168.178.23
May 18 11:04:13 dnsmasq[3751]: 17308 192.168.178.23/61196 /etc/pihole/local.list pi.hole is 192.168.178.30
May 18 11:04:13 dnsmasq[3751]: 17309 192.168.178.23/61897 query[AAAA] pi.hole from 192.168.178.23
May 18 11:04:13 dnsmasq[3751]: 17309 192.168.178.23/61897 cached pi.hole is NODATA-IPv6
May 18 11:04:15 dnsmasq[3751]: 17310 192.168.178.23/57480 query[A] pi.hole from 192.168.178.23
May 18 11:04:15 dnsmasq[3751]: 17310 192.168.178.23/57480 /etc/pihole/local.list pi.hole is 192.168.178.30
May 18 11:04:15 dnsmasq[3751]: 17311 192.168.178.23/59768 query[AAAA] pi.hole from 192.168.178.23
May 18 11:04:15 dnsmasq[3751]: 17311 192.168.178.23/59768 cached pi.hole is NODATA-IPv6
May 18 11:04:18 dnsmasq[3751]: 17312 192.168.178.23/57765 query[A] pi.hole from 192.168.178.23
May 18 11:04:18 dnsmasq[3751]: 17312 192.168.178.23/57765 /etc/pihole/local.list pi.hole is 192.168.178.30
May 18 11:04:18 dnsmasq[3751]: 17313 192.168.178.23/60483 query[AAAA] pi.hole from 192.168.178.23
May 18 11:04:18 dnsmasq[3751]: 17313 192.168.178.23/60483 cached pi.hole is NODATA-IPv6
May 18 11:04:20 dnsmasq[3751]: 17314 192.168.178.23/61899 query[A] pi.hole from 192.168.178.23
May 18 11:04:20 dnsmasq[3751]: 17314 192.168.178.23/61899 /etc/pihole/local.list pi.hole is 192.168.178.30
May 18 11:04:20 dnsmasq[3751]: 17315 192.168.178.23/57892 query[AAAA] pi.hole from 192.168.178.23
May 18 11:04:20 dnsmasq[3751]: 17315 192.168.178.23/57892 cached pi.hole is NODATA-IPv6
May 18 11:04:22 dnsmasq[3751]: 17316 192.168.178.23/64382 query[A] pi.hole from 192.168.178.23
May 18 11:04:22 dnsmasq[3751]: 17316 192.168.178.23/64382 /etc/pihole/local.list pi.hole is 192.168.178.30
May 18 11:04:22 dnsmasq[3751]: 17317 192.168.178.23/62163 query[AAAA] pi.hole from 192.168.178.23

my localdns.list:
192.168.178.30 pihole pi.hole PiHole pihole.localdomain wpad.localdomain wpad

what is wrong with my setup?


#12

This means you’re unable to resolve raspbian.raspberrypi.org, so the resolver configuration is NOT correct.

Test:
dig @127.10.10.1 -p 5551 +dnssec www.raspberrypi.org

replace the IP with the ip you used, and the port with the port you used. This should give a result. If you configured multiple resolvers, run the test again for instance I have (example IP’s and ports - you need to change them to match your config!!!):

dig @127.10.10.2 -p 5552 +dnssec www.raspberrypi.org
dig @127.10.10.3 -p 5553 +dnssec www.raspberrypi.org
dig @127.10.10.4 -p 5554 +dnssec www.raspberrypi.org

they should produce the same result


#13

dig @127.10.10.3 -p 5553 +dnssec www.raspberrypi.org

; <<>> DiG 9.10.3-P4-Raspbian <<>> @127.10.10.3 -p 5553 +dnssec www.raspberrypi.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60234
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.raspberrypi.org. IN A

;; ANSWER SECTION:
www.raspberrypi.org. 73 IN CNAME lb.raspberrypi.org.
www.raspberrypi.org. 73 IN RRSIG CNAME 10 3 300 20180615171717 20180516163457 55760 raspberrypi.org. sH/tw9uTm/KqOUqvdgi4Aual94zgzm+uaUs+45jHLu8gsNwhJ89tv+WZ Uf5/Dy5S9vf7HmhZ8RsJdQrHrGB2DweotyaC8DJOTIAc2sdXVgIJ5dnf nwltK5FN2Y8M6gucpoOZkoVYhoDiZaya5nHPOXpKY8Ciu0pUlYcfCaDi cMlO+UzhVLENDlKEjDobhdKu/gnfGnRTMTRjTEwfWQVsI+ZtTKrqJeVy 2ctPIELLW8eBBi5Q0ANEc7mbwX0kh8CwmZmn2RmElrBNSFpHjMB62Xup keQIg9PVmQ7X9wL/6wK394xfLOJ2tZpmX+BjHpbrzCvdchXU7E8twBqx 3BER5Q==
lb.raspberrypi.org. 278 IN A 46.235.227.11
lb.raspberrypi.org. 278 IN A 93.93.128.133
lb.raspberrypi.org. 278 IN A 93.93.128.211
lb.raspberrypi.org. 278 IN A 93.93.128.230
lb.raspberrypi.org. 278 IN A 93.93.130.39
lb.raspberrypi.org. 278 IN A 93.93.130.104
lb.raspberrypi.org. 278 IN A 93.93.130.214
lb.raspberrypi.org. 278 IN A 93.93.135.188
lb.raspberrypi.org. 278 IN RRSIG A 10 3 300 20180615171555 20180516163456 55760 raspberrypi.org. zWIbthFIAyaoflEZRD+JA8/n3DgQqtR23M5s/pkbqLshemDBU0dkKxAr DabZliuMt40teCQqqivMJVUVJFBTLOqF6d8IzSaiMENv7yLAJvnqLNAU 4fTUvbXwuzZVxIFBlreI1C8OFCUIJ53v3QOmS3NvN3rCBR3/d4ppnr5O ZSIAdjx7LeE/bNZBMslOFEALFC4sBVNe3wgpeJLiz1RxBxbeXpm0cOXy /cK0F4vCW3n9twwsddHOuBgOT397FCeOIVXWqiCjeWzaMMY7Pj2550hm zBiPiqnK1EBfSYw0N8KBGrSQIfzbKzBT2vVCMyGP9FmlzEioMPn3RhPQ f1b1Sw==

;; Query time: 2856 msec
;; SERVER: 127.10.10.3#5553(127.10.10.3)
;; WHEN: Fri May 18 15:15:52 CEST 2018
;; MSG SIZE rcvd: 1014

dig @127.10.10.2 -p 5552 +dnssec www.raspberrypi.org
dig @127.10.10.3 -p 5553 +dnssec www.raspberrypi.org
the same result


#14

you’ve got ‘dig @127.10.10.3 -p 5553 +dnssec www.raspberrypi.org’ twice. Do you have two resolvers or three as in the article?


#15

Hey, i use the same settings from your guide:

127.10.10.1#5551
127.10.10.2#5552
127.10.10.3#5553

all the same results:
; <<>> DiG 9.10.3-P4-Raspbian <<>> @127.10.10.3 -p 5553 +dnssec www.raspberrypi.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60234
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 11, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;www.raspberrypi.org. IN A

;; ANSWER SECTION:
www.raspberrypi.org. 73 IN CNAME lb.raspberrypi.org.
www.raspberrypi.org. 73 IN RRSIG CNAME 10 3 300 20180615171717 20180516163457 55760 raspberrypi.org. sH/tw9uTm/KqOUqvdgi4Aual94zgzm+uaUs+45jHLu8gsNwhJ89tv+WZ Uf5/Dy5S9vf7HmhZ8RsJdQrHrGB2DweotyaC8DJOTIAc2sdXVgIJ5dnf nwltK5FN2Y8M6gucpoOZkoVYhoDiZaya5nHPOXpKY8Ciu0pUlYcfCaDi cMlO+UzhVLENDlKEjDobhdKu/gnfGnRTMTRjTEwfWQVsI+ZtTKrqJeVy 2ctPIELLW8eBBi5Q0ANEc7mbwX0kh8CwmZmn2RmElrBNSFpHjMB62Xup keQIg9PVmQ7X9wL/6wK394xfLOJ2tZpmX+BjHpbrzCvdchXU7E8twBqx 3BER5Q==
lb.raspberrypi.org. 278 IN A 46.235.227.11
lb.raspberrypi.org. 278 IN A 93.93.128.133
lb.raspberrypi.org. 278 IN A 93.93.128.211
lb.raspberrypi.org. 278 IN A 93.93.128.230
lb.raspberrypi.org. 278 IN A 93.93.130.39
lb.raspberrypi.org. 278 IN A 93.93.130.104
lb.raspberrypi.org. 278 IN A 93.93.130.214
lb.raspberrypi.org. 278 IN A 93.93.135.188
lb.raspberrypi.org. 278 IN RRSIG A 10 3 300 20180615171555 20180516163456 55760 raspberrypi.org. zWIbthFIAyaoflEZRD+JA8/n3DgQqtR23M5s/pkbqLshemDBU0dkKxAr DabZliuMt40teCQqqivMJVUVJFBTLOqF6d8IzSaiMENv7yLAJvnqLNAU 4fTUvbXwuzZVxIFBlreI1C8OFCUIJ53v3QOmS3NvN3rCBR3/d4ppnr5O ZSIAdjx7LeE/bNZBMslOFEALFC4sBVNe3wgpeJLiz1RxBxbeXpm0cOXy /cK0F4vCW3n9twwsddHOuBgOT397FCeOIVXWqiCjeWzaMMY7Pj2550hm zBiPiqnK1EBfSYw0N8KBGrSQIfzbKzBT2vVCMyGP9FmlzEioMPn3RhPQ f1b1Sw==


#16

OK, what I do, to find the ‘bad’ resolver:

change the dnsmasq configuration (file in /etc/dnsmasq.d), so that you’re only using one (1) resolver. so start with only 127.10.10.1#5551, comment out (#) the rest, and restart dnsmasq (sudo service dnsmasq restart). once dnsmasq has restarted, you should verify that (sudo systemctl status dnsmasq) try to ‘sudo apt-get update’. If the resolver is working, that should get you a proper result. If the result is bad, there is something wrong with the resolver.

If you’re first resolver is already ‘bad’, test the second one first, before starting to search for the error with the first one, there may be something else that’s failing (not a resolver), as indicated by your dig results…


#17

i change the dnsmasq configuration file:

server=127.10.10.1#5551 = don’t works
server=127.10.10.2#5552 = works
server=127.10.10.3#5553 = don’t works


#18

This means that unbound is working, dnscrypt-proxy and stubby aren’t.

I hope you’re sure there aren’t any other ‘server=’ settings active in any configuration file.
You can verify this by looking at the /var/log/pihole.log content. the number of resolvers is mentioned at the bottom, that is at the bottom immediately after dnsmasq restart.

I don’t really know very much about stubby, still learning myself, I can only say you should verify the configuration files.

For dnscrypt-proxy, there is something else you can do. In my example I use only two (2) dnscrypt servers (‘scaleway-fr’ and ‘de.dnsmaschine.net’) I’ve learned there are many dnscrypt resolvers out there that don’t handle DNSSEC very well.
The test I perform:
First ensure dnsmasq only uses the dnscrypt resolver (the dnscrypt-proxy example above is server=127.10.10.1#5551, make sure you enable the correct resolver!). Now ensure dnscrypt-proxy is only using one (1) server (edit this in /opt/dnscrypt-proxy/dnscrypt-proxy.toml) so for example server_names = [‘scaleway-fr’]

now restart dnscrypt-proxy (sudo service dnscrypt-proxy restart) and dnsmasq (sudo service dnsmasq restart). Ensure both are running ( sudo systemctl status dnsmasq.service for dnsmasq, sudo systemctl status dnscrypt-proxy.service for dnscrypt-proxy)

Test again. You’ll find there are a lot of dnscrypt-proxy servers listed, that really don’t support DNSSEC very well.

If you can’t identify the problem, maybe you start debugging without DNSSEC first, DNSSEC tends to make things more complex…


#19

in my /var/log/pihole.log only
127.10.10.1
127.10.10.2
127.10.10.3

i test many servers from the puplic list but all are the same errors

I think i turn my Pihole back without DNScrypt or anything else

Thanky so much for your support!!


#20

what version of dnsmasq are you using, or are you already using FTLDNS

dnsmasq --version