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

    unbound not resolving some names

    Scheduled Pinned Locked Moved DHCP and DNS
    7 Posts 2 Posters 1.1k 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.
    • A
      an-erd
      last edited by

      Hi,
      I'm using pfSense Version 2.4.5-RELEASE-p1 with pfBlockerNG-devel 3.0.0_7 installed. A VPN is configured (nordvpn).

      I experience some issues that specific names cannot be resolved. The example I use for testing is dennenbos.nl and sometimes it also occurs with daserste.de. If I connect my notebook directly to my ISP router with no pfSense in between, I can access the web sites without any problems.
      If I connect using pfSense I get the message DNS_PROBE_FINISHED_NXDOMAIN in the browser.

      DNS Lookup
      c721c6f5-66d3-4e34-9b05-a93d32c39441-image.png

      nslookup from PC
      fffd26a6-fa6c-4d42-9e60-f7d560880c44-image.png

      dig from pfSense router
      04cfb037-d048-408f-9b4b-a29069e55e4b-image.png

      Configuration (General setup)
      42cd873f-e019-45f1-b2c6-3883deb90cec-image.png

      Configuration (DNS Resolver)
      51c3e389-5425-4f0a-b99e-4e542fe44fa0-image.png

      b6a4e316-5cf3-438d-9b56-4d2e15e2c659-image.png

      d552932b-5d2e-4349-b3cd-4e297e53b17b-image.png

      From the unbound logs
      fd884381-be60-43e9-b0fa-4d2ee50ec540-image.png

      DNSSEC debugger
      d80d8543-4746-4640-b4cf-29c5e2391c05-image.png

      There are no log entries from pfBlockerNG in the logs wrt. this issue.

      What is the best way to follow up on this issue?

      Regards Andreas

      DaddyGoD 1 Reply Last reply Reply Quote 0
      • DaddyGoD
        DaddyGo @an-erd
        last edited by

        @an-erd said in unbound not resolving some names:

        What is the best way to follow up on this issue?

        Hi,

        I would do this as a first debugging step:

        Try without VPN, - through the pfSense... to ISP
        (since you can see the domain in question is resolved , -Lookup on BOX)
        set an interface where there is no VPN as outbound interface

        like here:
        LAN w/o VPN
        VPNPT w ExpVPN

        8a4da72b-3964-4262-9b5a-605ba2694eda-image.png

        BTW:

        why are you using DoT on your internal network?

        9514c25e-2e45-47bd-95ca-00a1461ece9f-image.png

        Cats bury it so they can't see it!
        (You know what I mean if you have a cat)

        1 Reply Last reply Reply Quote 0
        • A
          an-erd
          last edited by an-erd

          I did tests now with the following scenarios (checked with traceroute):

          1. All traffic routed directly to WAN without VPN
          2. Traffic routed through VPN

          For 1) I can resolve the domain names correctly, although dig @103.86.96.100 dennenbos.nl shows some issues if used with +trace option.

          pi@raspberrypi:~ $ dig @103.86.96.100 dennenbos.nl

; <<>> DiG 9.10.3-P4-Raspbian <<>> @103.86.96.100 dennenbos.nl
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31645
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;dennenbos.nl.                  IN      A

;; ANSWER SECTION:
dennenbos.nl.           3600    IN      A       167.71.67.196

;; AUTHORITY SECTION:
dennenbos.nl.           3600    IN      NS      ns2.mundofy.com.
dennenbos.nl.           3600    IN      NS      ns1.mundofy.com.

;; ADDITIONAL SECTION:
ns1.mundofy.com.        172800  IN      A       104.248.90.27
ns2.mundofy.com.        172800  IN      A       134.209.88.180

;; Query time: 52 msec
;; SERVER: 103.86.96.100#53(103.86.96.100)
;; WHEN: Thu Jan 07 16:45:07 GMT 2021
;; MSG SIZE  rcvd: 136

          and

          pi@raspberrypi:~ $ dig @103.86.96.100 dennenbos.nl +trace

; <<>> DiG 9.10.3-P4-Raspbian <<>> @103.86.96.100 dennenbos.nl +trace
; (1 server found)
;; global options: +cmd
.                       328448  IN      NS      g.root-servers.net.
.                       328448  IN      NS      k.root-servers.net.
.                       328448  IN      NS      c.root-servers.net.
.                       328448  IN      NS      i.root-servers.net.
.                       328448  IN      NS      e.root-servers.net.
.                       328448  IN      NS      b.root-servers.net.
.                       328448  IN      NS      h.root-servers.net.
.                       328448  IN      NS      f.root-servers.net.
.                       328448  IN      NS      m.root-servers.net.
.                       328448  IN      NS      a.root-servers.net.
.                       328448  IN      NS      l.root-servers.net.
.                       328448  IN      NS      j.root-servers.net.
.                       328448  IN      NS      d.root-servers.net.
.                       518400  IN      RRSIG   NS 8 0 518400 20210120050000 20210107040000 42351 . JD5rhQdUsJ9zkDTJl/FOgKg4azCLthLFBkKAVu8ABX0ZAjhdVYt6QK42 sKyttJZJ7iRwFXrbSzzdJmTZDeoKUGYNkr13gx8XTUSMxWmoXTUzpM2B +KAGmGtLu0bHAmY+jmvTbTxfns9BLHVVO2j3xd4Rb76Tg5EhSUSUItgt f+Kqd/cnjybmCUU2xAUpNRFB37cehu12tv2O6u39sZBKyAl6pJ4mXzXL qdQ76HpMQm52zUtaZEZH0+dxVD4itXpnrBtobVKImKKTa7Au6ICFk4I2 /VTp3GAgUaqUYF5J0DZ0YXlFVCW7qd3ql0emr0slHt7Shkfmk9gr3Zf8 ci5uKA==
;; Received 775 bytes from 103.86.96.100#53(103.86.96.100) in 10 ms

nl.                     172800  IN      NS      ns1.dns.nl.
nl.                     172800  IN      NS      ns2.dns.nl.
nl.                     172800  IN      NS      ns3.dns.nl.
nl.                     86400   IN      DS      34112 8 2 3C5B5F9B3557455C50751A9BE9EBE9238C88E19F5F07F930976917B5 1B95CD22
nl.                     86400   IN      RRSIG   DS 8 1 86400 20210120050000 20210107040000 42351 . Z8mHfWrJmJ8MlcJ6UxhecqFuVfs4/h2iSX6yHhyboAnFyJo4fBIyYvsL +c87YBmHTVcd+oL2vx+H7DYdSrJ+lQOhn+TvcnmFq949c9Bngyq2jY+g z6+w6/G9WOnguKyVtTaWWLyRBuJB8TpvvqUO7w3xrCpTm6QSXia2u95f G6BvSLa6InnONo4yLluamSYHKR3yvF2ZGQ0X7hYduVYiDPP7HooCO21d WMrKLkWf+y8ix0PSiExJVwkUlReKl3eoyn36wP4fTC72CeAzg575feP2 rYWwJRgUms0Zt11Y2FJt5QWRGb0qN3xQsZ4/eYBFMUC7bsLhaxT+3tet dMBd7Q==
;; Received 566 bytes from 199.9.14.201#53(b.root-servers.net) in 22 ms

dennenbos.nl.           3600    IN      NS      ns1.mundofy.com.
dennenbos.nl.           3600    IN      NS      ns2.mundofy.com.
4q39dndh55ru1qmltiugutcm8cpm9jud.nl. 600 IN NSEC3 1 1 5 673E58266D988DA4 4Q39F5H7MJI61GVNA77NCDJU3BVMJP6P NS SOA TXT RRSIG DNSKEY NSEC3PARAM
4q39dndh55ru1qmltiugutcm8cpm9jud.nl. 600 IN RRSIG NSEC3 8 2 600 20210110175349 20201227124017 4309 nl. o9QZnT62dPI+F4mDl2DU5t/cvy5+g1fTMCWHAc2VSCk+D+k9x9vT9Yha H9iNthkUWQYyZIEdWMR6qwY+sbSUmPVrrR5m8mcztaZwWTOrjvrRxUFp EcW/qMnW9zNeQW67XW7UslFun1AnIdrnZI2Etov8C/vkFpCC0D8l+uJc EjE=
3qvg9ojtik95bbmoa0rhrbegl132i8g4.nl. 600 IN NSEC3 1 1 5 673E58266D988DA4 3QVGT9NIGUKCAUJTSMCKNB4ARGJ2R6Q8 NS DS RRSIG
3qvg9ojtik95bbmoa0rhrbegl132i8g4.nl. 600 IN RRSIG NSEC3 8 2 600 20210110205953 20201227164014 4309 nl. QZ8ZsYwu30mqc5mH5DLMZ4Gu+DwedilPpU+uajKlFE8hRJ8hdkOh56oq acWhcI5nfzPSPsWxUdDjpNmBYk1Xjwgcbs3y6klHTQ2500fBuQ59GwbF 5rOssFEKJCasFt3XyIZeki+9Jotzifew/+pMEKvJ8FsY3bqO1hxvg3nN kSg=
couldn't get address for 'ns1.mundofy.com': failure
couldn't get address for 'ns2.mundofy.com': failure
dig: couldn't get address for 'ns1.mundofy.com': no more
pi@raspberrypi:~ $

          I get the same results when using DNS 1.1.1.1.

          For 2) I don't get it resolved with the VPN providers DNS Server

          But when using 1.1.1.1 or 8.8.8.8 or so everything works (with the issue shown above when using +trace option.

          pi@raspberrypi:~ $ dig @103.86.96.100 dennenbos.nl

; <<>> DiG 9.10.3-P4-Raspbian <<>> @103.86.96.100 dennenbos.nl
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 11892
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;dennenbos.nl.                  IN      A

;; Query time: 33 msec
;; SERVER: 103.86.96.100#53(103.86.96.100)
;; WHEN: Thu Jan 07 16:43:44 GMT 2021
;; MSG SIZE  rcvd: 41

pi@raspberrypi:~ $ dig @1.1.1.1 dennenbos.nl

; <<>> DiG 9.10.3-P4-Raspbian <<>> @1.1.1.1 dennenbos.nl
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45472
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;dennenbos.nl.                  IN      A

;; ANSWER SECTION:
dennenbos.nl.           2926    IN      A       167.71.67.196

;; Query time: 23 msec
;; SERVER: 1.1.1.1#53(1.1.1.1)
;; WHEN: Thu Jan 07 16:43:49 GMT 2021
;; MSG SIZE  rcvd: 57

pi@raspberrypi:~ $

          I do have this issue not only for this site, sometimes I get it for amazon.de, daserste.de and other frequently used sites.

          I don't want to use 1.1.1.1 as an additional DNS server to not provide any DNS leaks.

          (I unchecked DoT again, I did some tests whether the problem was caused by this option.)

          Any ideas?

          Regards Andreas

          DaddyGoD 1 Reply Last reply Reply Quote 0
          • DaddyGoD
            DaddyGo @an-erd
            last edited by

            @an-erd said in unbound not resolving some names:

            For 2) I don't get it resolved with the VPN providers DNS Server

            so it is clear that the VPN is causing this behavior...
            this also happens to us in some domain cases (ExpVPN), not all web site operators like VPN IPs :-)

            we use CloudFlare DNS servers because we have a lot of services at CloudFlare (CDN, etc.)

            no leaks or we just think hahaha 😉

            you do not need to use DoT on the internal network (LAN), except if you configured the clients for this (853)

            try forwarding to 1.1.1.1 with DoT

            04b07fa7-0af9-4dfc-a2bc-0aefa774e521-image.png

            Cats bury it so they can't see it!
            (You know what I mean if you have a cat)

            1 Reply Last reply Reply Quote 0
            • A
              an-erd
              last edited by

              Ok, I forwarded this issue to the VPN provider, and in the meantime I'll use CloudFlare (or just skip the non-working domains)

              Thanks
              Andreas

              DaddyGoD 1 Reply Last reply Reply Quote 0
              • A
                an-erd
                last edited by

                In addition, since there are only a few static adresses I'm missing, I use a Firewall / Alias.

                1 Reply Last reply Reply Quote 0
                • DaddyGoD
                  DaddyGo @an-erd
                  last edited by

                  @an-erd said in unbound not resolving some names:

                  Ok, I forwarded this issue to the VPN provider

                  you will not achieve much with this 😉

                  (all VPN service providers indicate in their operating conditions (general terms of service) that the use of VPN in many cases causes some websites to be unusable)

                  you have to live with it or you can do tricks

                  Cats bury it so they can't see it!
                  (You know what I mean if you have a cat)

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