Indicator that DoT is active is missing in DNS configuration

pslpsl · 23 July 2023 13:10

Domain Name System (dns.cgi) page has no indicator that DNS over TLS (DoT) is active. hostname of certificate can be configured in setup form but that domain name is not visible in configuration overview. There is no indicator that TLS hostname is correct and that TLS is used. When I use “check DNS”, DNSSEC is verified but no information related to TLS is shown.

I would like to see an icon when DoT is used.

UPDATE. My DNS was configured wrong, I was living with false beleive that I use DoT but I was not using it… The trick is to switch from UDP or TCP connection to TLS, this is global configuration for all DNS configurations in IPfire. This important point is not clear from IPfire wiki and I found that information from instructions for “Quad9 setup guide for IPfire”… When you are DNS expert, then this is clear but it is not clear for someone who has no experience with DoT or DoH…

Once TLS is active, then DNS check button verifies if connection is working and error is shown when hostname for certificate is wrong…

Quad9 is in the list of not recommended DNS services but that is probably the only service that has instructions for IPfire… Screenshot at IPfire wiki has not recommended Quad9 in the example

Good video on YT why to use DNS over TLS and why to use Quad9 DNS.

bonnietwin · 23 July 2023 13:35

You can see the protocol that has been selected as here where it shows TLS

Screenshot_2023-07-23_15-30-18
This tells you that TLS is active.

If the TLS hostname is incorrect then the DNS Status for that server will show Error.

That is because 9.9.9.9 filters your DNS requests. The 9.9.9.10 DNS Server is said to not filter the DNS requests.

pslpsl · 23 July 2023 13:44

OK. I fixed my configuration error, I switched from UDP to TLS…

When I “check DNS servers” in TLS mode, from time to time I see an error for DNS that is configured correctly, like the check is not reliable…

bonnietwin · 23 July 2023 14:05

Then you should place the mouse pointer over the Error label and after a second or so you will see an information message on what is causing the Error message. It can be that the DNS Server is not available for a short period.

You can also look in the DNS Server System Logs for more details.

bbitsch · 23 July 2023 14:09

I think, DNS over TLS ( DoT! ) is referenced clearly in wiki.
If you feel, there should be an explicit remark ( for non-experts also ), you are invited to contribute that. Your credentials for the community are working in the wiki also.

EDIT: Added link to wiki page.

pslpsl · 23 July 2023 14:52

I checked wiki again and I cannot see it there, I am sorry…

My confusion was based on assumption that each DNS server can be configured as unencrypted DNS or DoT DNS, that it is option for each server and the switch is field “TLS hostname”, when it is filled that IPfire will try to use TLS. That was wrong, there is a global switch that affects all configurations.

DoT is new for me, IPcop was too old to have support for DoT. I have some experience with DNSCrypt and DNSCrypt proxy (OpenDNS supported DNSCrypt long before DoT was standardized)

My eyes were opened once I read Quad9 setup guide for IPfire

pslpsl · 23 July 2023 15:12

When I hoover mouse over “Error” status I see message like this one (not limited to 9.9.9.9):
TLS peer has closed connection; cannot receive reply from 9.9.9.9@853(TCP)

I cannot find this error in any log file:

[root@ipfire log]# find /var/log -type f -exec grep -l "TLS peer" {} +
[root@ipfire log]#

peppetech · 24 July 2023 20:19

I didn’t know that quad9 has a setup guide for IPfire,

if I remember right, Quad9 actually had a rep here in the community. I have to search and find his handle.

I have been also wondering how "check DNS Servers " works in IPFire.
perhaps just querying with “dig” and analyzing flags??

dig ipfire.org @9.9.9.9 +dnssec

by the way I watched the YT video you posted above, and I am not getting an impression that quad9 is in the DNS business for purely “Not for profit” . It appears that they have a large PR budget.
but I don’t know anything about them.

I also found the discussion with their rep:

I use some of the recommended DNS servers in Wiki,
You will notice that “the not for profit” ones, are slower than the “for profit” ones like 1.1…1. or 2.2.2.

g70p · 25 July 2023 00:00

Hi @peppetech wondering if QAD9 TLS is compatible with recursive unbound? I think it has something to do with CNAMES that unbound calls.witch can result in unexpected behaviour of the DNS resolver. As well the forward.conf must be filled with something like this :
unbound.conf (as the unbound conf is pulling forward configurations from an external file in local.d this must be filled:
forward-zone:
name: “.”
forward-tls-upstream: yes
forward-addr: ...#******** dns.resolver quad. etc
forward-addr: (ipv6 DNS not used in Ipfire)
forward-addr: ...#*********.dns.nextdns.io
forward-addr:
but the problem regarding DOT and unbound is explained in this external link, altough it’s related to another dns resolver: Consider disabling CNAME scrubbing for forwarded queries · Issue #132 · NLnetLabs/unbound · GitHub
Regards G70P

pslpsl · 25 July 2023 02:54

My IPfire has this config file, it was generated by scripts (no manual modification). I configured two Quad9 DNS servers during weekend in WUI, DoT mode is active.

[root@ipfire ~]# cat /etc/unbound/forward.conf 
# This file is automatically generated and any changes
# will be overwritten. DO NOT EDIT!

forward-zone:
	name: "."
	forward-tls-upstream: yes
	forward-addr: 9.9.9.9@853#dns.quad9.net
	forward-addr: 149.112.112.112@853#dns.quad9.net

9.9.9.9 and 149.112.112.112 do some “censorship/filtering”, to remove hostnames misused by malware, etc. These are called as secured
9.9.9.10 and 149.112.112.10 should not filter anything. These are called unsecured. There is written in documenation that there is no DNSSEC on unsecured servers… details

IPfire doesn’t show that “unsecured” service miss DNSSEC:

pslpsl · 25 July 2023 03:26

I think this should not be real issue because IPfire has DNS cache (unbound); the first query could be slower but following queries are served from the IPfire cache (until the information in the cache expires and has to be queried again)

g70p · 27 July 2023 00:51

Hi @pslpsl altough the file will be overwritten by the use of the webGUi, the local.d directory is the place to create a file to be included in unbound parameters. In /etc/unbound/local.d/touch forward.conf with the creation of this file unbound.conf will include what’s inside local.d not altering the forward.conf at the /etc/unbound/ directory. At the end of the nano unbound.conf file says: include etc/unbound/local.d/. touch there the file and writte the parameters for the TLS DNS’s
Regards
G70P

bbitsch · 27 July 2023 08:25

@g70p , What do want to say with this?

ummeegge · 27 July 2023 08:29

Hi all,

by checking dns10.quad9.net for both IPs via e.g.

kdig -d @9.9.9.10 +dnssec +tls-ca=/etc/ssl/certs/ca-bundle.crt +tls-host=dns10.quad9.net www.isoc.org &&
kdig -d @149.112.112.10 +dnssec +tls-ca=/etc/ssl/certs/ca-bundle.crt +tls-host=dns10.quad9.net www.isoc.org

the response shows the AD flag but includes also the RRSIG . Could it be that IPFires check is beyond the Quad9 documentation ?

Best,

Erik

$ kdig -d @9.9.9.10 +dnssec +tls-ca=/etc/ssl/certs/ca-bundle.crt +tls-host=dns10.quad9.net www.isoc.org &&
kdig -d @149.112.112.10 +dnssec +tls-ca=/etc/ssl/certs/ca-bundle.crt +tls-host=dns10.quad9.net www.isoc.org
;; DEBUG: Querying for owner(www.isoc.org.), class(1), type(1), server(9.9.9.10), port(853), protocol(TCP)
;; DEBUG: TLS, imported 137 certificates from '/etc/ssl/certs/ca-bundle.crt'
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, C=US,ST=California,L=Berkeley,O=Quad9,CN=*.quad9.net
;; DEBUG:      SHA-256 PIN: /SlsviBkb05Y/8XiKF9+CZsgCtrqPQk5bh47o0R3/Cg=
;; DEBUG:  #2, C=US,O=DigiCert Inc,CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1
;; DEBUG:      SHA-256 PIN: e0IRz5Tio3GA1Xs4fUVWmH1xHDiH2dMbVtCBSkOIdqM=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted. 
;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 36229
;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 3; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: do; UDP size: 512 B; ext-rcode: NOERROR

;; QUESTION SECTION:
;; www.isoc.org.       		IN	A

;; ANSWER SECTION:
www.isoc.org.       	300	IN	A	104.18.11.177
www.isoc.org.       	300	IN	A	104.18.10.177
www.isoc.org.       	300	IN	RRSIG	A 13 3 300 20230728171858 20230726151858 34505 isoc.org. PvSus1F6al9y+oO8SVydpp6k2ghl0g7CT4GpvZhpwDLtE8UG+jZ1cdCrQ+bMnu4cmWv7r/dIBlxeNrOjRbelHA==

;; Received 177 B
;; Time 2023-07-27 18:18:58 CEST
;; From 9.9.9.10@853(TCP) in 323.1 ms
;; DEBUG: Querying for owner(www.isoc.org.), class(1), type(1), server(149.112.112.10), port(853), protocol(TCP)
;; DEBUG: TLS, imported 137 certificates from '/etc/ssl/certs/ca-bundle.crt'
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, C=US,ST=California,L=Berkeley,O=Quad9,CN=*.quad9.net
;; DEBUG:      SHA-256 PIN: /SlsviBkb05Y/8XiKF9+CZsgCtrqPQk5bh47o0R3/Cg=
;; DEBUG:  #2, C=US,O=DigiCert Inc,CN=DigiCert TLS Hybrid ECC SHA384 2020 CA1
;; DEBUG:      SHA-256 PIN: e0IRz5Tio3GA1Xs4fUVWmH1xHDiH2dMbVtCBSkOIdqM=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted. 
;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 63205
;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 3; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: do; UDP size: 512 B; ext-rcode: NOERROR

;; QUESTION SECTION:
;; www.isoc.org.       		IN	A

;; ANSWER SECTION:
www.isoc.org.       	300	IN	A	104.18.11.177
www.isoc.org.       	300	IN	A	104.18.10.177
www.isoc.org.       	300	IN	RRSIG	A 13 3 300 20230728171858 20230726151858 34505 isoc.org. JzAgIdPd4dl8T5i3H2IfDOzAnmYCs/eyufx+Tn956bDV4TFQRGiijBTY5h+D82b9a9eXd6IMBNrMbOtlg4muaw==

;; Received 177 B
;; Time 2023-07-27 18:18:58 CEST
;; From 149.112.112.10@853(TCP) in 139.7 ms

g70p · 27 July 2023 10:38

@bbitsch open unbound.conf file and scroll down. There’s the line to include extras. If local.d is empty you need to create de the file.
Bye
G70P

pslpsl · 27 July 2023 16:54

This is the default, I confirm it. I have not touched manually my unbound configuration…

[root@rpifire ~]# tail -3 /etc/unbound/unbound.conf 

# Import any local configurations
include: "/etc/unbound/local.d/*.conf"

[root@rpifire ~]# ls -l /etc/unbound/local.d/
total 0

jon · 27 July 2023 19:38

Erik Kapfer:

by checking dns10.quad9.net for both IPs via e.g.
kdig -d @9.9.9.10 +dnssec +tls-ca=/etc/ssl/certs/ca-bundle.crt +tls-host=dns10.quad9.net www.isoc.org &&
kdig -d @149.112.112.10 +dnssec +tls-ca=/etc/ssl/certs/ca-bundle.crt +tls-host=dns10.quad9.net www.isoc.org
the response shows the AD flag but includes also the RRSIG . Could it be that IPFires check is beyond the Quad9 documentation ?

Hey Erik!

Can you explain this in a little more detail - Why did you add +tls-ca and +tls-host?

and why did you mention the RRISG?

I am curious and hoping to learn new stuff!

ummeegge · 28 July 2023 08:11

Hello Jon,
since the topic asks for an indicator if DNS-over-TLS is active i queried also TLS with a certificate validation (+tls-ca) but used also TLS to a remote server hostname check (+tls-host).
RRSIG is the DNSSEC signature attached to the record. If the DNS resolver does not support DNSSEC, it will not look for a signature. This is equivalent to “falling back” to not using DNSSec.
For more information according kdig, please see → kdig – Advanced DNS lookup utility — Knot DNS 2.6.9 documentation

As an more specific information according to this topic: IPFires dns.cgi uses nearly the same command in Perl → git.ipfire.org Git - ipfire-2.x.git/blob - html/cgi-bin/dns.cgi to check if DoT is active or not.

Best,

Erik

ummeegge · 31 July 2023 19:26

No answers ? Can this topic be seen as “solved” ?

Best,

Erik

jon · 17 February 2024 13:51

4 posts were split to a new topic: With kdig what tells the user the DoT is working?