Thanks. That's something to think about.
While I was messing around with uninstalling and re-installing DoH from this guide:
I get the following error (which wasn't there when I initially installed it) when running sudo systemctl status cloudflared
pi@raspberry:/etc/cloudflared $ sudo systemctl status cloudflared
● cloudflared.service - Argo Tunnel
Loaded: loaded (/etc/systemd/system/cloudflared.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2020-10-10 01:21:06 AEDT; 1 day 18h ago
Main PID: 462 (cloudflared)
Tasks: 12 (limit: 2065)
CGroup: /system.slice/cloudflared.service
└─462 /usr/local/bin/cloudflared --config /etc/cloudflared/config.yml --origincert /etc/cloudflared/cert.pem --no-autoupdate
Oct 11 01:05:33 raspberry cloudflared[462]: ERROR[2020-10-11T01:05:33+11:00] failed to connect to an HTTPS backend "https://1.1.1.1/dns-query": failed to perform an HTTPS request: Post "https://1.1.1.1/dns-query": net/http: request cancele
Oct 11 01:05:33 raspberry cloudflared[462]: ERROR[2020-10-11T01:05:33+11:00] failed to connect to an HTTPS backend "https://1.1.1.1/dns-query": failed to perform an HTTPS request: Post "https://1.1.1.1/dns-query": net/http: request cancele
Oct 11 01:05:33 raspberry cloudflared[462]: ERROR[2020-10-11T01:05:33+11:00] failed to connect to an HTTPS backend "https://1.1.1.1/dns-query": failed to perform an HTTPS request: Post "https://1.1.1.1/dns-query": net/http: request cancele
Oct 11 01:05:33 raspberry cloudflared[462]: ERROR[2020-10-11T01:05:33+11:00] failed to connect to an HTTPS backend "https://1.1.1.1/dns-query": failed to perform an HTTPS request: Post "https://1.1.1.1/dns-query": net/http: request cancele
Oct 11 01:05:33 raspberry cloudflared[462]: ERROR[2020-10-11T01:05:33+11:00] failed to connect to an HTTPS backend "https://1.1.1.1/dns-query": failed to perform an HTTPS request: Post "https://1.1.1.1/dns-query": net/http: request cancele
Oct 11 01:05:33 raspberry cloudflared[462]: ERROR[2020-10-11T01:05:33+11:00] failed to connect to an HTTPS backend "https://1.1.1.1/dns-query": failed to perform an HTTPS request: Post "https://1.1.1.1/dns-query": net/http: request cancele
Oct 11 18:54:11 raspberry cloudflared[462]: ERROR[2020-10-11T18:54:11+11:00] failed to connect to an HTTPS backend "https://1.1.1.1/dns-query": failed to perform an HTTPS request: Post "https://1.1.1.1/dns-query": net/http: request cancele
Oct 11 18:54:13 raspberry cloudflared[462]: ERROR[2020-10-11T18:54:13+11:00] failed to connect to an HTTPS backend "https://1.1.1.1/dns-query": failed to perform an HTTPS request: Post "https://1.1.1.1/dns-query": context deadline exceeded
Oct 11 18:54:16 raspberry cloudflared[462]: ERROR[2020-10-11T18:54:16+11:00] failed to connect to an HTTPS backend "https://1.0.0.1/dns-query": failed to perform an HTTPS request: Post "https://1.0.0.1/dns-query": net/http: request cancele
Oct 11 19:04:32 raspberry systemd[1]: cloudflared.service: Current command vanished from the unit file, execution of the command list won't be resumed.
How do I fix this?
I'll then look at removing this and read about Unbound.
EDIT:
After adjusting some line breaks to improve readability in your output, it seems those errors would have occured over a larger time span in the past, so they might just be pulled from log files.
I don't know your current time (of course), but the service itself is reporting as active(running), so does not seem to be in an error state currently?
sorry about the line breaks. I'm using the default settings of Con-Emu and I don't know how to adjust it.
My time zone is AEST, which is +10 UTC time.
I followed the manual removal process and re-installed it and now it's ok.
Following the guide you kindly provided for unbound, I get this error after running: sudo apt install unbound
I read the instructions again and what got me to stop was:
The guide for installing DoH shows to use a custom DNS 127.0.0.1#5053
The unbound guide shows to use a custom DNS 127.0.0.1#5335
How to proceed from here if both make use of custom DNS 1 but using different ports?
understood.
so both methods provide some layer of privacy, but when it comes to which one is better, what would be the criteria to judge upon?
For someone new like me, if I need to choose one or the other, it's not easy to follow the pros/cons of each method.
Unbound as a local recursive resolver eliminates a third party upstream DNS service. Cloudlfared does not. In my opinion that makes unbound preferable for privacy. You control your own resolver, no filtering, no third party has your DNS history.
I tried to highlight that in the short paragraphs that triggered this topic.
DoT or DoH would secure your connections to your DNS provider. While preventing your DNS traffic from third-party eaves-dropping, it does little in terms of privacy: Your chosen DNS provider still has your full DNS history.
Because unbound could also be configured to use DoT instead of acting as a recursive resolver, it's clearly the superior solution.
It won't do away with the fact that you have to decide for one way or the other, though. Both approaches - recursive resolver and DoT/DoH - offer some benefits the respective other cannot.
pi@raspberry:/etc/unbound $ journalctl -xe
Oct 19 01:34:51 raspberry systemd[1]: Started Unbound DNS server via resolvconf.
-- Subject: A start job for unit unbound-resolvconf.service has finished successfully
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit unbound-resolvconf.service has finished successfully.
--
-- The job identifier is 4214.
Oct 19 01:34:51 raspberry package-helper[7998]: [1603031691] unbound-checkconf[8000:0] error: Could not open /etc/unbound/unbound.conf: No such file or directory
Oct 19 01:34:51 raspberry systemd[1]: unbound-resolvconf.service: Main process exited, code=exited, status=1/FAILURE
-- Subject: Unit process exited
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- An ExecStart= process belonging to unit unbound-resolvconf.service has exited.
--
-- The process' exit code is 'exited' and its exit status is 1.
Oct 19 01:34:51 raspberry systemd[1]: unbound-resolvconf.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- The unit unbound-resolvconf.service has entered the 'failed' state with result 'exit-code'.
Oct 19 01:34:51 raspberry systemd[1]: unbound.service: Service RestartSec=100ms expired, scheduling restart.
Oct 19 01:34:51 raspberry systemd[1]: unbound.service: Scheduled restart job, restart counter is at 5.
-- Subject: Automatic restarting of a unit has been scheduled
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- Automatic restarting of the unit unbound.service has been scheduled, as the result for
-- the configured Restart= setting for the unit.
Oct 19 01:34:51 raspberry systemd[1]: Stopped Unbound DNS server.
-- Subject: A stop job for unit unbound.service has finished
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A stop job for unit unbound.service has finished.
--
-- The job identifier is 4274 and the job result is done.
Oct 19 01:34:51 raspberry systemd[1]: unbound.service: Start request repeated too quickly.
Oct 19 01:34:51 raspberry systemd[1]: unbound.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- The unit unbound.service has entered the 'failed' state with result 'exit-code'.
Oct 19 01:34:51 raspberry systemd[1]: Failed to start Unbound DNS server.
-- Subject: A start job for unit unbound.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit unbound.service has finished with a failure.
--
-- The job identifier is 4274 and the job result is failed.
Oct 19 01:34:51 raspberry systemd[1]: unbound-resolvconf.service: Start request repeated too quickly.
Oct 19 01:34:51 raspberry systemd[1]: unbound-resolvconf.service: Failed with result 'exit-code'.
-- Subject: Unit failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- The unit unbound-resolvconf.service has entered the 'failed' state with result 'exit-code'.
Oct 19 01:34:51 raspberry systemd[1]: Failed to start Unbound DNS server via resolvconf.
-- Subject: A start job for unit unbound-resolvconf.service has failed
-- Defined-By: systemd
-- Support: https://www.debian.org/support
--
-- A start job for unit unbound-resolvconf.service has finished with a failure.
--
-- The job identifier is 4334 and the job result is failed.
for sudo /usr/sbin/unbound -ddd -vvv -c /etc/unbound/unbound.conf
output:
[1603031834] unbound[8117:0] error: Could not open /etc/unbound/unbound.conf: No such file or directory
[1603031834] unbound[8117:0] warning: Continuing with default config settings
[1603031834] unbound[8117:0] debug: increased limit(open files) from 1024 to 4152
[1603031834] unbound[8117:0] debug: creating udp6 socket ::1 53
[1603031834] unbound[8117:0] debug: creating tcp6 socket ::1 53
[1603031834] unbound[8117:0] error: can't bind socket: Address already in use for ::1 port 53 (len 28)
[1603031834] unbound[8117:0] fatal error: could not open ports
For sudo grep -v '^\s*#\|^\s*$' -R /etc/unbound/unbound.conf*
Output:
If your absolutely sure, than you have another very serious issue if a file is disappearing. /etc/unbound/unbound.conf comes with that unbound package that you installed per instructions:
pi@raspberry:/etc/unbound $ sudo apt install --reinstall unbound
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 1 not upgraded.
Need to get 671 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://mirror.internode.on.net/pub/raspbian/raspbian buster/main armhf unbound armhf 1.9.0-2+deb10u2 [671 kB]
Fetched 671 kB in 2s (336 kB/s)
(Reading database ... 148716 files and directories currently installed.)
Preparing to unpack .../unbound_1.9.0-2+deb10u2_armhf.deb ...
Unpacking unbound (1.9.0-2+deb10u2) over (1.9.0-2+deb10u2) ...
Setting up unbound (1.9.0-2+deb10u2) ...
Job for unbound.service failed because the control process exited with error code.
See "systemctl status unbound.service" and "journalctl -xe" for details.
Job for unbound.service failed because the control process exited with error code.
See "systemctl status unbound.service" and "journalctl -xe" for details.
invoke-rc.d: initscript unbound, action "restart" failed.
● unbound.service - Unbound DNS server
Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Mon 2020-10-19 01:54:06 AEDT; 40ms ago
Docs: man:unbound(8)
Process: 9166 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code=exited, status=1/FAILURE)
Process: 9169 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_update (code=exited, status=1/FAILURE)
Process: 9172 ExecStart=/usr/sbin/unbound -d $DAEMON_OPTS (code=exited, status=1/FAILURE)
Main PID: 9172 (code=exited, status=1/FAILURE)
Processing triggers for man-db (2.8.5-2) ...
Processing triggers for systemd (241-7~deb10u4+rpi1) ...
