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

    `No response` for self-hosted DNS in `Diagnostics/DNS Lookup`

    Scheduled Pinned Locked Moved
    DHCP and DNS
    3
    9
    343
    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.
    • R
      roki_
      last edited by

      I want to use a self-hosted DNS (AdGuard Home) as an upstream DNS for pfSense but I can't seem to get it to work.
      I followed this guide and got it working for Cloudflare DNS servers but not with the self-hosted one.

      I'd be thankful for any tips on how I can debug this and get the self-hosted DNS to respond to pfSense.

      Debugging

      Debugging with kdig gave the following results, so the self-hosted DNS should be good.
      I'm also using the self-hosted DNS with DoT on my phone, where it works fine.

      I've censored the IP and hostname for the self-hosted DNS as [SERVER-IP] and [SERVER-DOMAIN-NAME].
      The hostname is adguard.domain.tld in case it matters, that I'm using a subdomain.

      > kdig -d @[SERVER-IP] +tls-ca +tls-host=[SERVER-DOMAIN-NAME] cool.com
;; DEBUG: Querying for owner(cool.com.), class(1), type(1), server([SERVER-IP]), port(853), protocol(TCP)
;; DEBUG: TLS, imported 129 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, CN=[SERVER-DOMAIN-NAME]
;; DEBUG:      SHA-256 PIN: j2BTYgmU92RTuyhHZ4JxPZVXis2PQGiHorWzJHSnFjo=
;; DEBUG:  #2, C=US,O=Let's Encrypt,CN=R3
;; DEBUG:      SHA-256 PIN: jQJTbIh0grw0/1TkHSumWb+Fs0Ggogr621gT3PvPKG0=
;; DEBUG: TLS, skipping certificate PIN check
;; DEBUG: TLS, The certificate is trusted.
;; TLS session (TLS1.3)-(ECDHE-X25519)-(ECDSA-SECP384R1-SHA384)-(AES-128-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 42472
;; Flags: qr rd ra; QUERY: 1; ANSWER: 2; AUTHORITY: 0; ADDITIONAL: 1

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

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

;; ANSWER SECTION:
cool.com.               300     IN      A       3.33.130.190
cool.com.               300     IN      A       15.197.148.33

;; Received 69 B
;; Time 2023-06-14 16:26:13 CEST
;; From [SERVER-IP]@853(TCP) in 92.3 ms

      > kdig -d @1.1.1.1 +tls-ca +tls-host=one.one.one.one cool.com
;; DEBUG: Querying for owner(cool.com.), class(1), type(1), server(1.1.1.1), port(853), protocol(TCP)
;; DEBUG: TLS, imported 129 system certificates
;; DEBUG: TLS, received certificate hierarchy:
;; DEBUG:  #1, C=US,ST=California,L=San Francisco,O=Cloudflare\, Inc.,CN=cloudflare-dns.com
;; DEBUG:      SHA-256 PIN: GP8Knf7qBae+aIfythytMbYnL+yowaWVeD6MoLHkVRg=
;; 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-X25519)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 54671
;; Flags: qr rd ra; QUERY: 1; ANSWER: 2; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 1232 B; ext-rcode: NOERROR
;; PADDING: 395 B

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

;; ANSWER SECTION:
cool.com.               300     IN      A       3.33.130.190
cool.com.               300     IN      A       15.197.148.33

;; Received 468 B
;; Time 2023-06-14 16:28:48 CEST
;; From 1.1.1.1@853(TCP) in 65.2 ms

      Diagnostics/DNS Lookup

      diagnostics-dns-lookup

      Settings related to DNS

      dns-server-settings

      dns-forwarder

      dns-resolver-general

      dns-resolver-advanced

      dns-resolver-status

      V 1 Reply Last reply Reply Quote 0
      • V
        viragomann @roki_
        last edited by

        @roki_
        As other devices, pfSense use the DNS servers in the order they are stated. By default the first of the list is used. The second is only accessed if the first cannot be reached. And the third only if access to both other fails.

        So if you want pfSense to use your own server put it to the top.

        R 1 Reply Last reply Reply Quote 0
        • R
          roki_ @viragomann
          last edited by roki_

          @viragomann changed the order but the problem persists

          41c0d4c9-460f-4430-893f-4c75a3c81bbf-image.png

          70862720-abbe-4fc7-981c-1c0df744eb5b-image.png

          V 1 Reply Last reply Reply Quote 0
          • V
            viragomann @roki_
            last edited by

            @roki_ said in `No response` for self-hosted DNS in `Diagnostics/DNS Lookup`:

            changed the order but the problem persists

            Which problem??

            Your screenshot is showing that the host name is successfully resolved by the localhost.

            R 1 Reply Last reply Reply Quote 0
            • R
              roki_ @viragomann
              last edited by roki_

              @viragomann I thought, that No response means that pfSense can't communicate with the DNS because even after I added the Quad9 servers, there was a query time for every DNS (2 Cloudflare + 2 Quad9) except the self hosted one.

              I removed every DNS except the self hosted one, restarted the service (to flush the cache) and nslookup still works. I guess I should've tried that before...

              Although I'm still confused, because the DNS Lookup shows No response, event with just the self-hosted DNS in the list.
              Could it be, that the "Diagnostics/DNS Lookup" tool only supports unencrypted DNS queries? I think the Cloudflare and Quad9 servers support that but the self-hosted one doesn't.

              > kdig -d @[SERVER-IP] cool.com
;; DEBUG: Querying for owner(cool.com.), class(1), type(1), server([SERVER-IP]), port(53), protocol(UDP)
;; WARNING: response timeout for [SERVER-IP]@53(UDP)
;; DEBUG: retrying server [SERVER-IP]@53(UDP)
;; WARNING: response timeout for [SERVER-IP]@53(UDP)
;; DEBUG: retrying server [SERVER-IP]@53(UDP)
;; WARNING: response timeout for [SERVER-IP]@53(UDP)
;; ERROR: failed to query server [SERVER-IP]@53(UDP)

              8a5c3a9e-2c28-456c-beb8-0f9ea6e51c31-image.png

              V 1 Reply Last reply Reply Quote 0
              • V
                viragomann @roki_
                last edited by

                @roki_ said in &#x60;No response&#x60; for self-hosted DNS in &#x60;Diagnostics/DNS Lookup&#x60;:

                Could it be, that the "Diagnostics/DNS Lookup" tool only supports unencrypted DNS? I think the Cloudflare and Quad9 servers support unencrypted queries but the self-hosted one doesn't.

                Yes, this might be the case. Also dig in pfSense isn't capable of doing DoT lookups.
                The other might also allow unencrypted access. You can verify this by capturing the traffic on WAN. Or you can simply block WAN outbound on port 53 with a floating rule.

                According to your setup, the DNS Resolver forward all traffic to the DNS servers stated in General Setup. So if there is your own server at the top or the only one, it should work.
                You can also verify this by sniffing the traffic on the interface facing to the server, or even check the server log.

                R 1 Reply Last reply Reply Quote 1
                • R
                  roki_ @viragomann
                  last edited by roki_

                  @viragomann I did a tcpdump port 853 (with the self-hosted DNS being the only one) on the pfSense box, followed by a nslookup on my computer and everything went to the self-hosted DNS so it is working as intended. Also there was no traffic on port 53.

                  As soon as I added a Quad9 server to the list, there was traffic on port 53 which disappeared after I added this rule

                  22cfc3e0-a1b0-4205-8df9-9cb4a4d84243-image.png

                  The "Diagnostics/DNS Lookup" tool still manages to generate traffic on port 53 and as expected there is no response from the self-hosted DNS. There is no traffic at all on port 853 when using the "Diagnostics/DNS Lookup" tool.

                  > tcpdump -vv port 53
tcpdump: listening on vtnet0, link-type EN10MB (Ethernet), capture size 262144 bytes
23:20:16.778036 IP (tos 0x0, ttl 64, id 17316, offset 0, flags [none], proto UDP (17), length 54)
    192.168.178.2.48731 > [SERVER-HOST-NAME].domain: [udp sum ok] 61673+ A? cool.com. (26)
23:20:21.793232 IP (tos 0x0, ttl 64, id 57347, offset 0, flags [none], proto UDP (17), length 54)
    192.168.178.2.25995 > [SERVER-HOST-NAME].domain: [udp sum ok] 61673+ A? cool.com. (26)
23:20:26.873296 IP (tos 0x0, ttl 64, id 29229, offset 0, flags [none], proto UDP (17), length 54)
    192.168.178.2.6517 > [SERVER-HOST-NAME].domain: [udp sum ok] 61673+ A? cool.com. (26)
23:20:31.905867 IP (tos 0x0, ttl 64, id 36985, offset 0, flags [none], proto UDP (17), length 54)
    192.168.178.2.39942 > one.one.one.one.domain: [udp sum ok] 27440+ A? cool.com. (26)
23:20:31.919905 IP (tos 0x0, ttl 58, id 55581, offset 0, flags [DF], proto UDP (17), length 86)
    one.one.one.one.domain > 192.168.178.2.39942: [udp sum ok] 27440 q: A? cool.com. 2/0/0 cool.com. A 3.33.130.190, cool.com. A 15.197.148.33 (58)

                  Thanks a lot for the help!

                  Edit: Corrected port numbers

                  johnpozJ 1 Reply Last reply Reply Quote 0
                  • johnpozJ
                    johnpoz LAYER 8 Global Moderator @roki_
                    last edited by

                    @roki_ said in `No response` for self-hosted DNS in `Diagnostics/DNS Lookup`:

                    There is no traffic at all on port 853 when using the "Diagnostics/DNS Lookup" tool.

                    Why would you think the normal dns client in pfsense would use dot? If you want to use dot, then you need to setup unbound to use dot via forwarding, and ask it.

                    An intelligent man is sometimes forced to be drunk to spend time with his fools
                    If you get confused: Listen to the Music Play
                    Please don't Chat/PM me for help, unless mod related
                    SG-4860 24.11 | Lab VMs 2.7.2, 24.11

                    R 1 Reply Last reply Reply Quote 0
                    • R
                      roki_ @johnpoz
                      last edited by

                      @johnpoz I thought the DNS Lookup tool would support DoT because pfSense 'supports' DoT by using unbound and I didn't know better.
                      Looking at the source, I now know it uses drill (/src/usr/local/www/diag_dns.php#L111) which doesn't support DoT.

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