Step 1: create a protocol group called DNS:
Next, create a port forward rule to redirect the internal traffic. Choose the source, here Green. You can create a group as well.
You can do the same for the NTP protocol.
3 Likes
@cfusco you are awesome and a gentleman!
I’ve done as you instructed, and it appears to have done the trick. Website that was not working before is resolving now. And DNS resolving is fast now!
If I do dig facebook.com, the SERVER section near the end is now pointing to the IPFire box.
Thank you so much! 
Also see:
FYI - I am not sure about adding DNS over TLS / port 853 to the DNS group for protocol. I seem to remember that being bad to add to the DNS group above. I’ll see if I can find my notes!
EDIT: It is somewhere in this post! (lots to read!)
4 Likes
Thank you Jon,
Perhaps this article is also slightly relevant on the topic.
[edit] I removed this part I had written in my lack of knowledge:
on how DNS over TLS is not that great.
Thank you @cfusco and @bonnietwin, you are of course right in your posts below. Link here to what cfusco said, and link to what Adolf said – for future readers.
Thanks
1 Like
I think I understand why. Indeed, including TLS 853 in the same DNAT rule for DNS traffic may not be appropriate. Port 853 is used for DNS over TLS, which is a secured version of DNS. If I redirect this traffic to a standard DNS resolver that doesn’t support TLS, the connection will fail. It’s better to handle DNS over TLS separately and ensure that the target of the DNAT rule for port 853 is capable of handling DNS over TLS.
1 Like
I disagree, it does exactly what it is designed to do. No scheme can create a trust-less DNS with the current design. By encrypting the message, at least you remove one party from knowing what we are doing. The provider.
2 Likes
You are right.
My excuse is I know very little 
Thank you.
That blog post is not saying that DNS over TLS is not great and should not, by implication, be used.
It is saying that you need to realise that the end point, ie the DNS provider, can still access your data.
So you need to choose carefully who your DNS provider is going to be and figure out for yourself who you will trust and who not.
I don’t use google or cloudflare as they aim to monetise what they provide so if you are not paying money directly for it, you are paying in some other way.
Later in that blog post it says
For any alternative it again makes sense to use DNS over TLS.
So it is not saying don’t use it, but it is saying that you should understand what it is protecting you from and what it is not protecting you from.
4 Likes
Thank you Adolf and @cfusco for the guidance and advise. This is great knowledge and I am thankful to you guys 
Believe me, the depth of my ignorance I REALLY big. So, don’t worry, say whatever you feel important or relevant.
This is how I frame the issue, we learn by error correction, as neural networks do. If I do not acknowledge my ignorance, I cannot correct the error, and a stupid AI model will be more intelligent than I am. I can’t let this happen. So I expose myself to showing my ignorance to the community, and because of this I can learn, see my error and be slightly better than an AI.
This thread is the perfect representation of this dynamic. I gave a wrong suggestion, Jon pointed that out (thanks @jon) and now I know more than before.
3 Likes
How is using FW rules different from setting other DNS servers in the Network / Domain Name System / dialogue?
FW rule is to force users to use FW DNS server.
So user request google DNS.
IPfire intercept DNS
IPfire makes DNS53 or DNST request ( depending on your Domain name system settings)
IPfire returns DNS53 to user pretending to be Google DNS.
User is transparently redirected to IPfire DNS.
No user bypass
Without FW redirected user can directly bypass your Filtered DNS. And request anything.
2 Likes
But I do not use Googles DNS.
I do not know what DNS53 or DNST is, I have only read the general reasons stated in many places, like in IPFires Wiki, on why not to use just any DNS but some other provider.
So, if I understand it correctly, regardless of if I tell IPFire to use a specified DNS for all Internet Connections - which I thought was enough by doing in the Domain Name System settings - you still need a FW rule to tell the computers that are connected in my network to do just that?
DNS53 = DNS on port 53
DNST = DNS over TLS
DNSH = DNS over HTTPS
Example.
I’m a PC on your network
Turn on PC.
PC network asks for network setup info
IPfire answers back.
Gives you a ip to use (192.168.1.55)
It also gives you the gatway info.(192.168.1.1 )
(IPfire is the gatway)
It also tells me to use 192.168.1.1 as my DNS
Now I’m on the network ready to reach the world
But
What if your a school and I’m a smart kid.
I Change My PC DNS to 1.1.1.1
Well IPfire let’s you bypass its DNS
And I Can reach the Web without IPfire’s DNS protection and filtering.
So th FW rule is to silently grab the port 53 DNS request and run it through IPfire and send response back as if it was 1.1.1.1
The only problem is this is only part of the solution.
Blocking DNSH is very hard
Blocking users from DNST easy.
3 Likes
Ah, ok Thanks.
So it is in order to prevent users changing their DNS on their local computers in a network that by default gets the DNS servers set by IPFire, but do not prevent that change of local DNS.
Damn nasty users.
1 Like
@jon Jon I wrote to you on priv, you probably don’t remember 
I read the topic provided and did a simple test using the YogaDNS program.
Below are the results
After adding port 853 to the group
Regards
1 Like
Hello,
Based on what @jon and @cfusco wrote, I split the firewall group and then made a copy of the firewall rule and adjusted them. Now the settings look like this:
Please advise if this is the correct way now.
I did some tests, and when my DNS is Cloudflare’s 1.1.1.1 I do get DoT. But with Hetzner DoT does not work. My DNS servers are like this at the moment.
Thanks,
Based on @tphz post above, I don’t believe this is correct.
With DNS over TLS I think there are two choice, you call Allow it (basically no firewall rule needed) or you can block it.
If you decide it needs to be blocked then Rule 1 - “Redirect DNS with TLS (port 853) to IPFire” changes from a redirect to a drop. And you end up dropping port 853 from getting from Green to the Internet.
Out of curiosity, is there some reason you want to block DNS over TLS (DoT) with Port 853?
Hello @jon
Thank you so much
I deactivated the firewall rule for DoT, applied the change. Then disabled Cloudflare’s DNS servers.
Here’s a test I ran (command and result):
$ echo | openssl s_client -connect '1.1.1.1:853'
CONNECTED(00000003)
Can't use SSL_get_servername
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert TLS Hybrid ECC SHA384 2020 CA1
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = cloudflare-dns.com
verify return:1
---
Certificate chain
0 s:C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = cloudflare-dns.com
i:C = US, O = DigiCert Inc, CN = DigiCert TLS Hybrid ECC SHA384 2020 CA1
a:PKEY: id-ecPublicKey, 256 (bit); sigalg: ecdsa-with-SHA384
v:NotBefore: Jan 12 00:00:00 2023 GMT; NotAfter: Jan 11 23:59:59 2024 GMT
1 s:C = US, O = DigiCert Inc, CN = DigiCert TLS Hybrid ECC SHA384 2020 CA1
i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
a:PKEY: id-ecPublicKey, 384 (bit); sigalg: RSA-SHA384
v:NotBefore: Apr 14 00:00:00 2021 GMT; NotAfter: Apr 13 23:59:59 2031 GMT
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIF9TCCBXygAwIBAgIQA8JqRlvV7Wjej2b5dc4uXzAKBggqhkjOPQQDAzBWMQsw
CQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMTAwLgYDVQQDEydEaWdp
Q2VydCBUTFMgSHlicmlkIEVDQyBTSEEzODQgMjAyMCBDQTEwHhcNMjMwMTEyMDAw
MDAwWhcNMjQwMTExMjM1OTU5WjByMQswCQYDVQQGEwJVUzETMBEGA1UECBMKQ2Fs
aWZvcm5pYTEWMBQGA1UEBxMNU2FuIEZyYW5jaXNjbzEZMBcGA1UEChMQQ2xvdWRm
bGFyZSwgSW5jLjEbMBkGA1UEAxMSY2xvdWRmbGFyZS1kbnMuY29tMFkwEwYHKoZI
zj0CAQYIKoZIzj0DAQcDQgAE8WA8mNsEQxx1/IvfcBNZj/HOWGEFoHH5gLTJQ+mD
iQ3+ItaqCY7TT+R/picYF5ljVow7R7jn6iCxMFkVjXChG6OCBA4wggQKMB8GA1Ud
IwQYMBaAFAq8CCkXjKU5bXoOzjPHLrPt+8N6MB0GA1UdDgQWBBRkutjX+1Qhhwjz
soJm+Z5fS3AE8jCBpgYDVR0RBIGeMIGbghJjbG91ZGZsYXJlLWRucy5jb22CFCou
Y2xvdWRmbGFyZS1kbnMuY29tgg9vbmUub25lLm9uZS5vbmWHBAEAAAGHBAEBAQGH
BKKfJAGHBKKfLgGHECYGRwBHAAAAAAAAAAAAEAGHECYGRwBHAAAAAAAAAAAAERGH
ECYGRwBHAAAAAAAAAAAAAGSHECYGRwBHAAAAAAAAAAAAZAAwDgYDVR0PAQH/BAQD
AgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjCBmwYDVR0fBIGTMIGQ
MEagRKBChkBodHRwOi8vY3JsMy5kaWdpY2VydC5jb20vRGlnaUNlcnRUTFNIeWJy
aWRFQ0NTSEEzODQyMDIwQ0ExLTEuY3JsMEagRKBChkBodHRwOi8vY3JsNC5kaWdp
Y2VydC5jb20vRGlnaUNlcnRUTFNIeWJyaWRFQ0NTSEEzODQyMDIwQ0ExLTEuY3Js
MD4GA1UdIAQ3MDUwMwYGZ4EMAQICMCkwJwYIKwYBBQUHAgEWG2h0dHA6Ly93d3cu
ZGlnaWNlcnQuY29tL0NQUzCBhQYIKwYBBQUHAQEEeTB3MCQGCCsGAQUFBzABhhho
dHRwOi8vb2NzcC5kaWdpY2VydC5jb20wTwYIKwYBBQUHMAKGQ2h0dHA6Ly9jYWNl
cnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFRMU0h5YnJpZEVDQ1NIQTM4NDIwMjBD
QTEtMS5jcnQwCQYDVR0TBAIwADCCAX0GCisGAQQB1nkCBAIEggFtBIIBaQFnAHUA
7s3QZNXbGs7FXLedtM0TojKHRny87N7DUUhZRnEftZsAAAGFqCecuAAABAMARjBE
AiAdA/2qx7A3w0Jn7vVuS/qJjfHQURcg1UbQ4JG9wjDBXAIgYsXLQjjc4KaK6y+g
vU+HP4Ow41mj3tiDSp/6GrZCJzEAdwBIsONr2qZHNA/lagL6nTDrHFIBy1bdLIHZ
u7+rOdiEcwAAAYWoJ5zeAAAEAwBIMEYCIQCbW0qSTa+OBqRPNVxEjsAlZ7O31yxx
hRQI5t1UjU97AgIhAJJGLQBjwKVLAul//qX6KKnN/aJDzUSe+i9AeNvCU61+AHUA
O1N3dT4tuYBOizBbBv5AO2fYT8P0x70ADS1yb+H61BcAAAGFqCec6QAABAMARjBE
AiBP/2dqsY1syhBOL5tOc6a6JDzAchfFlDSd6W8DKerZ3QIgZUQUM4nYFlyMBRxn
YfTXn63X/m5ViNBrV/z1GSPzJ5IwCgYIKoZIzj0EAwMDZwAwZAIwP/iWG6Wa0U8A
dDjvbUOxXdI6WgQXwVng/Wrs2G3P2CPXyDi8y4D523XfIYDdY3KQAjA0t0mL62JA
NgpCMd3y7oOrMz01u/FQVel18mXq+PAkEYB6S+9BJOxjGcKGIEXtMxg=
-----END CERTIFICATE-----
subject=C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = cloudflare-dns.com
issuer=C = US, O = DigiCert Inc, CN = DigiCert TLS Hybrid ECC SHA384 2020 CA1
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2889 bytes and written 373 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
Server public key is 256 bit
This TLS version forbids renegotiation.
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
DONE
Out of curiosity, is there some reason you want to block DNS over TLS (DoT) with Port 853?
It was my lack of understanding. I do now have a vague idea, and that is because of yours and @cfusco’s excellent explanations in this thread; for which I am forever grateful.
Thanks,
Arslan