Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    FYI: DNS over TLS works for Cloudflare like a charme

    Scheduled Pinned Locked Moved 2.4 Development Snapshots
    13 Posts 7 Posters 3.5k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • G
      gsmornot
      last edited by

      @behemyth:

      So for this to work with 2.4.4, do you have to enable both checkboxes for "DNS Query Forwarding?"

      There are two boxes in there, one to Enable Forwarding Mode, and one for using SSL/TLS for quaries, which states that Enable Forwarding Mode must be enabled before quaries over SSL/TLS will be sent.

      Just making sure this is set up right.

      If you want to use TLS you will need to check both boxes. The forwarding addresses go on the general page and need to support TLS.

      1 Reply Last reply Reply Quote 0
      • P
        pfcode
        last edited by

        @gsmornot:

        @behemyth:

        So for this to work with 2.4.4, do you have to enable both checkboxes for "DNS Query Forwarding?"

        There are two boxes in there, one to Enable Forwarding Mode, and one for using SSL/TLS for quaries, which states that Enable Forwarding Mode must be enabled before quaries over SSL/TLS will be sent.

        Just making sure this is set up right.

        If you want to use TLS you will need to check both boxes. The forwarding addresses go on the general page and need to support TLS.

        Does this setting work with pfBlockerNG DNSBL functions?

        Release: pfSense 2.4.3(amd64)
        M/B: Supermicro A1SRi-2558F
        HDD: Intel X25-M 160G
        RAM: 2x8Gb Kingston ECC ValueRAM
        AP: Netgear R7000 (XWRT), Unifi AC Pro

        1 Reply Last reply Reply Quote 0
        • G
          gsmornot
          last edited by

          @pfcode:

          @gsmornot:

          @behemyth:

          So for this to work with 2.4.4, do you have to enable both checkboxes for "DNS Query Forwarding?"

          There are two boxes in there, one to Enable Forwarding Mode, and one for using SSL/TLS for quaries, which states that Enable Forwarding Mode must be enabled before quaries over SSL/TLS will be sent.

          Just making sure this is set up right.

          If you want to use TLS you will need to check both boxes. The forwarding addresses go on the general page and need to support TLS.

          Does this setting work with pfBlockerNG DNSBL functions?

          Yes because it hits the resolver first before the forward.

          1 Reply Last reply Reply Quote 0
          • D
            dwasifar
            last edited by

            Is it normal for this to be substantially slower than ordinary DNS?

            A host query from a machine on the local subnet takes quite a lot longer when put through pfSense's DNS over TLS.

            For instance, these are the kind of times I would ordinarily get:

            dwasifar@Oberon ~ $ host -v simple.com 192.168.1.2   #Debian with dnsmasq
Trying "simple.com"
Using domain server:
Name: 192.168.1.2
Address: 192.168.1.2#53
Aliases: 

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 285
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;simple.com.			IN	A

;; ANSWER SECTION:
simple.com.		300	IN	A	151.101.0.205
simple.com.		300	IN	A	151.101.64.205
simple.com.		300	IN	A	151.101.128.205
simple.com.		300	IN	A	151.101.192.205

Received 92 bytes from 192.168.1.2#53 in 35 ms
Trying "simple.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55050
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;simple.com.			IN	AAAA

;; AUTHORITY SECTION:
simple.com.		900	IN	SOA	ns-616.awsdns-13.net. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

Received 112 bytes from 192.168.1.2#53 in 40 ms
Trying "simple.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44224
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;simple.com.			IN	MX

;; ANSWER SECTION:
simple.com.		3600	IN	MX	10 aspmx.l.google.com.
simple.com.		3600	IN	MX	20 alt1.aspmx.l.google.com.
simple.com.		3600	IN	MX	30 alt2.aspmx.l.google.com.
simple.com.		3600	IN	MX	50 aspmx2.googlemail.com.
simple.com.		3600	IN	MX	50 aspmx3.googlemail.com.

Received 158 bytes from 192.168.1.2#53 in 34 ms

            Versus this with DNS over TLS:

            dwasifar@Oberon ~ $ host -v simple.com 192.168.1.3   #pfSense with DNS over TLS
Trying "simple.com"
Using domain server:
Name: 192.168.1.3
Address: 192.168.1.3#53
Aliases: 

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58942
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;simple.com.			IN	A

;; ANSWER SECTION:
simple.com.		300	IN	A	151.101.128.205
simple.com.		300	IN	A	151.101.192.205
simple.com.		300	IN	A	151.101.64.205
simple.com.		300	IN	A	151.101.0.205

Received 92 bytes from 192.168.1.3#53 in 380 ms
Trying "simple.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49702
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;simple.com.			IN	AAAA

;; AUTHORITY SECTION:
simple.com.		900	IN	SOA	ns-616.awsdns-13.net. awsdns-hostmaster.amazon.com. 1 7200 900 1209600 86400

Received 109 bytes from 192.168.1.3#53 in 134 ms
Trying "simple.com"
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65371
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;simple.com.			IN	MX

;; ANSWER SECTION:
simple.com.		3535	IN	MX	10 aspmx.l.google.com.
simple.com.		3535	IN	MX	20 alt1.aspmx.l.google.com.
simple.com.		3535	IN	MX	30 alt2.aspmx.l.google.com.
simple.com.		3535	IN	MX	50 aspmx2.googlemail.com.
simple.com.		3535	IN	MX	50 aspmx3.googlemail.com.

Received 158 bytes from 192.168.1.3#53 in 123 ms

            Both of these servers resolve upstream to Cloudflare.

            I like the idea of DNS over TLS, but not if it's five to ten times slower.  Is this consistent with everyone else's experience, or should I be looking for a configuration error?

            1 Reply Last reply Reply Quote 0
            • B
              behemyth
              last edited by

              I haven't seen the massive spike in time that you are seeing - that's weird. Are you using both the ipv6 ipv4 servers at cloudflare? You also have to keep in mind that the DNS entry is going to be cached, so if it is slower, then it'll only happen the first time.

              1 Reply Last reply Reply Quote 0
              • I
                iqjet
                last edited by

                I don't see any remarkable delays. I use only cloudflare DNS. When using cloudflare and Quad9 together,
                then I noticed delays.

                1 Reply Last reply Reply Quote 0
                • H
                  Harvy66
                  last edited by

                  Could this be due to not having a ready connection and the round trips required to establish one vs UDP DNS just being a request and a response? More of an issue for a cold cache. I also had a 34ms response time for the first call to resolve simple.com, the second was 0ms.

                  1 Reply Last reply Reply Quote 0
                  • D
                    dwasifar
                    last edited by

                    @Harvy66:

                    Could this be due to not having a ready connection and the round trips required to establish one vs UDP DNS just being a request and a response? More of an issue for a cold cache. I also had a 34ms response time for the first call to resolve simple.com, the second was 0ms.

                    No, it's definitely not a ready connection problem.  The Debian server is going out through the same connection, and in fact its connection is THROUGH the pfSense box.

                    I'm aware that it caches.  The times I showed were first query to that destination from each box.

                    Doing the query a second time comes back instantly.  The Debian box caches too, and it also comes back instantly if the query is repeated.  But the times on the initial pfSense query are just unacceptably slow.

                    1 Reply Last reply Reply Quote 0
                    • H
                      Harvy66
                      last edited by

                      @dwasifar:

                      @Harvy66:

                      Could this be due to not having a ready connection and the round trips required to establish one vs UDP DNS just being a request and a response? More of an issue for a cold cache. I also had a 34ms response time for the first call to resolve simple.com, the second was 0ms.

                      No, it's definitely not a ready connection problem.  The Debian server is going out through the same connection, and in fact its connection is THROUGH the pfSense box.

                      I'm aware that it caches.  The times I showed were first query to that destination from each box.

                      Doing the query a second time comes back instantly.  The Debian box caches too, and it also comes back instantly if the query is repeated.  But the times on the initial pfSense query are just unacceptably slow.

                      No, it's definitely not a ready connection problem.  The Debian server is going out through the same connection, and in fact its connection is THROUGH the pfSense box.

                      What? I'm not sure what kind of connection you're talking about, but I mean a ready TCP connection that is already established. TCP connections have a 3 way handshake. With a 34ms RTT, that makes it 51ms just to create a connection.  Another 68ms to establish a new TLS session, then you can make your request. You can shave off 34ms when resuming a TLS session.

                      That would bring TCP+TLS-resume down to 85ms. Then you make your query, which is an additional 34ms just for the round trip, or 119ms. This is very close to 123ms.

                      Again, my question is can you capture packets and see what's going on when you make a request?

                      1 Reply Last reply Reply Quote 0
                      • Y
                        yellowbrick
                        last edited by

                        I tried the unbound TLS option as well. The current implementation does not appear to re-use TLS connections (you can check in the firewall states with each query). It adds a perceptible delay to fresh queries.

                        However, I have since moved to using a raspberry pi with pihole on the network. The pihole is configured to forward to a local clouflared / argo-tunnel dns proxy. The cloudflared in turn uses DNS over HTTPS (DoH), as opposed to DNS over TLS, to forward requests to 1.1.1.1. Also it definitely keeps the https/TCP connection around for a while, and the additional latency is much less perceptible.

                        Would be worth trying the unbound TLS option again at some point when it can be configured to re-use connections/set a keep-alive.

                        1 Reply Last reply Reply Quote 0
                        • H
                          Harvy66
                          last edited by

                          I guess that would make sense. The simplest implementation of TLS would be to just create a new connection per request. Connection pooling adds a fair bit of complexity. If using an HTTPS library, you get that for free.

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.