Navigation

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

    pfSense as a private DNS resolver

    DHCP and DNS
    2
    17
    243
    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.
    • T
      techtester-m last edited by techtester-m

      Hi,

      According to the docs "By default, the DNS Resolver queries the root DNS servers directly".

      So I disabled forwarding mode in the resolver, disabled DNS server override, cleared the DNS cache and performed a DNS leak test. The result was my real IP. With pfSense being the resolver itself maybe that's what I should see, but how can I know for sure that my ISP's DNS is not being used? How can I know for sure that the only thing happens behind the scenes is my pfSense querying the root servers? Is there any way to see the exact routes?

      Edit: I just saw a post on this forum where @johnpoz answered this on a similar question: "if your using unbound as resolver, then yeah its going to show your IP. Since its resolving not forwarding."

      So, if pfSense acts as the resolver and it asks the root servers (obviously it knows their IPs lol) I should see my real IP in the DNS leak tests, right?

      Thank you,

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

        Yes when you resolve you walk down from roots, so yes the IP you use to talk to the nameservers is what is "leaked"..

        Unbound asks roots hey roots what is NS of .com
        Hey NS of .com, what is the NS of domain.com
        Hey NS of domain.com what is the IP of host.domain.com

        If you want to see how it works, do a simple dig whatever +trace..

        Here example, I made sure to only use IPv4 and had it not return any dnssec info so its cleaner to look at..

        [2.4.4-RELEASE][admin@sg4860.local.lan]/: dig -4 www.pfsense.org +trace +nodnssec 
        
        ; <<>> DiG 9.12.2-P1 <<>> -4 www.pfsense.org +trace +nodnssec
        ;; global options: +cmd
        .                       60706   IN      NS      e.root-servers.net.
        .                       60706   IN      NS      h.root-servers.net.
        .                       60706   IN      NS      l.root-servers.net.
        .                       60706   IN      NS      i.root-servers.net.
        .                       60706   IN      NS      a.root-servers.net.
        .                       60706   IN      NS      d.root-servers.net.
        .                       60706   IN      NS      c.root-servers.net.
        .                       60706   IN      NS      b.root-servers.net.
        .                       60706   IN      NS      j.root-servers.net.
        .                       60706   IN      NS      k.root-servers.net.
        .                       60706   IN      NS      g.root-servers.net.
        .                       60706   IN      NS      m.root-servers.net.
        .                       60706   IN      NS      f.root-servers.net.
        ;; Received 239 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms
        
        org.                    172800  IN      NS      a2.org.afilias-nst.info.
        org.                    172800  IN      NS      b2.org.afilias-nst.org.
        org.                    172800  IN      NS      b0.org.afilias-nst.org.
        org.                    172800  IN      NS      d0.org.afilias-nst.org.
        org.                    172800  IN      NS      c0.org.afilias-nst.info.
        org.                    172800  IN      NS      a0.org.afilias-nst.info.
        ;; Received 474 bytes from 192.33.4.12#53(c.root-servers.net) in 11 ms
        
        pfsense.org.            86400   IN      NS      ns1.netgate.com.
        pfsense.org.            86400   IN      NS      ns2.netgate.com.
        ;; Received 91 bytes from 199.19.56.1#53(a0.org.afilias-nst.info) in 44 ms
        
        www.pfsense.org.        300     IN      A       208.123.73.69
        pfsense.org.            300     IN      NS      ns1.netgate.com.
        pfsense.org.            300     IN      NS      ns2.netgate.com.
        ;; Received 167 bytes from 162.208.119.38#53(ns2.netgate.com) in 34 ms
        
        [2.4.4-RELEASE][admin@sg4860.local.lan]/: 
        

        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
        2440 2.4.5p1 | 2x 3100 2.4.4p3 | 2x 3100 22.01 | 4860 22.05

        T 2 Replies Last reply Reply Quote 1
        • T
          techtester-m @johnpoz last edited by

          @johnpoz Yeah...and this "leak" is basically the DNS leak test website asking to resolve a url and who ever resolves it for him is listed in the results. I had to think about for few moments and also do a test where I'm connected directly to my ISP's Modem/Router (bridge mode) and then the results were 10+ DNS servers belong to my ISP.

          Thank you for the explanation nonetheless :)

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

            Keep in mind that while on a new resolve unbound will walk down from roots, but once stuff is cached it will not have to walk down the whole tree again.

            Once it caches say the NS for domain.tld, when you ask for something.domain.tld it will talk directly too one of the NS listed for that domain, it will not have to ask walk down to find the authoritative NS for domain.tld

            Same goes for the tld nameservers - once it has those cached, it will just ask one of the NS for say .org, hey what is the nameserver for something.org

            It also keeps track at which NS respond faster for a specific domain/tld - and will try and talk to those first, etc. You can look into that by directly asking unbound for that info..

            unbound-control -c /var/unbound/unbound.conf

            What you can do with that is listed here
            https://nlnetlabs.nl/documentation/unbound/unbound-control/

            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
            2440 2.4.5p1 | 2x 3100 2.4.4p3 | 2x 3100 22.01 | 4860 22.05

            1 Reply Last reply Reply Quote 1
            • T
              techtester-m @johnpoz last edited by

              @johnpoz said in pfSense as a private DNS resolver:

              Keep in mind that while on a new resolve unbound will walk down from roots, but once stuff is cached it will not have to walk down the whole tree again.

              Yeah, I knew that.

              @johnpoz said in pfSense as a private DNS resolver:

              It also keeps track at which NS respond faster for a specific domain/tld - and will try and talk to those first

              Sweet...That's the spirit lol. I asked exactly that on a different post but received only lazy condescending answers from people with 10x my experience in networking...well...what can you do haha

              @johnpoz said in pfSense as a private DNS resolver:

              ou can look into that by directly asking unbound for that info..

              Ask it via the unbound control?

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

                Yeah you can query unbound for information about what it is in its cache, what it would use to lookup whatever.domain.tld, etc. etc.. Look over the documentation of unbound-control for what info you can gleen and stuff you can do with it, etc.

                [2.4.4-RELEASE][admin@sg4860.local.lan]/: unbound-control -c /var/unbound/unbound.conf status
                version: 1.9.1
                verbosity: 1
                threads: 4
                modules: 2 [ validator iterator ]
                uptime: 466951 seconds
                options: control(ssl)
                unbound (pid 30791) is running...
                [2.4.4-RELEASE][admin@sg4860.local.lan]/: 
                

                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
                2440 2.4.5p1 | 2x 3100 2.4.4p3 | 2x 3100 22.01 | 4860 22.05

                T 1 Reply Last reply Reply Quote 1
                • T
                  techtester-m @johnpoz last edited by

                  @johnpoz I would like to ask you another question if you may.
                  If I have a default "allow LAN to any" rule with a VPN set as its gateway (NO_WAN_EGRESS) and I know your opinion about VPN and security paranoia lol but still...What would be the behavior when DNS requests are sent from this LAN to the pfSense? Would this rule make the resolver communicate with the root servers via the VPN gateway like the rest of the traffic, OR would the resolver has its "own channel" for that, apart from the rest of traffic generated by the LAN?

                  Thanks,

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

                    Unbound would generate its own traffic.. This is traffic from "pfsense" not from the client.. Your lan rules have zero to do with what unbound/pfsense can do. your lan rules would just prevent client from talking to unbound in the first place - if your policy routing traffic out a vpn, your lan client wouldn't even be able to talk to unbound in the first place. Unless you had a rule above the policy route to allow it.

                    Client asks unbound for something, unbound either returns it from its cache or resolves it. If it needs to resolve it - then it makes its own connection for that through how pfsense is setup to connect.

                    Limiting or controlling pfsense or unbound to only use a vpn connection is difficult, your best bet if you insist on resolving through a vpn is to place your resolver inside your network, and then policy route it just like you would any other client.

                    There is a hidden rule, high up in the list that allows pfsense to go anywhere it wants..

                    pfctl -sr

                    pass out inet all flags S/SA keep state allow-opts label "let out anything IPv4 from firewall host itself"
                    

                    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
                    2440 2.4.5p1 | 2x 3100 2.4.4p3 | 2x 3100 22.01 | 4860 22.05

                    T 1 Reply Last reply Reply Quote 1
                    • T
                      techtester-m @johnpoz last edited by

                      Please bear with me haha I promise to learn quick :)
                      @johnpoz said in pfSense as a private DNS resolver:

                      if your policy routing traffic out a vpn, your lan client wouldn't even be able to talk to unbound in the first place

                      But it's currently the setup I'm testing and it's using unbound with no problem at all...what am I missing?

                      @johnpoz said in pfSense as a private DNS resolver:

                      Unless you had a rule above the policy route to allow it

                      How to regard the unbound in this rule? What would be the source/destination?

                      @johnpoz said in pfSense as a private DNS resolver:

                      place your resolver inside your network

                      Do you mean a separate physical device used only for DNS tasks?

                      @johnpoz said in pfSense as a private DNS resolver:

                      There is a hidden rule, high up in the list that allows pfsense to go anywhere it wants..

                      Ok...I don't wanna mess with that functionality. DNS over the VPN gateway is not a must but at least I want the resolver to use DoT or any other encryption (stick it to the ISP) when it communicates with the root/tld/ns servers. Any idea?

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

                        What are the rules on your lan? Or floating?

                        If you want unbound to use dot, then set it to use dot.. But you can not resolve doing that - only forward.

                        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
                        2440 2.4.5p1 | 2x 3100 2.4.4p3 | 2x 3100 22.01 | 4860 22.05

                        T 1 Reply Last reply Reply Quote 0
                        • T
                          techtester-m @johnpoz last edited by techtester-m

                          @johnpoz said in pfSense as a private DNS resolver:

                          What are the rules on your lan? Or floating?

                          1 floating rule: NO_WAN_EGRESS

                          These are the LAN rules at the moment:
                          Screen Shot 2019-12-03 at 15.49.07.png

                          @johnpoz said in pfSense as a private DNS resolver:

                          then set it to use dot.. But you can not resolve doing that

                          So resolving the way pfSense intended will always be "clean" and unencrypted requests to the root servers?

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

                            Blocking bogon on your local network is just freaking pointless!!! In what scenario would you have bogon's on your network? And your rule for lan net would only allow lan net anyway..

                            Do you have any floating rules - because in those rules you are not allowing clients to talk to pfsense IP other than on ports 443 and 80.. So no you wouldn't be able to talk to unbound on 53.

                            If you setup forwarding, it will not resolve... You can not do both..

                            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
                            2440 2.4.5p1 | 2x 3100 2.4.4p3 | 2x 3100 22.01 | 4860 22.05

                            T 1 Reply Last reply Reply Quote 0
                            • T
                              techtester-m @johnpoz last edited by techtester-m

                              @johnpoz said in pfSense as a private DNS resolver:

                              Blocking bogon on your local network is just freaking pointless!!! In what scenario would you have bogon's on your network?

                              Don't know lol I'm quite new to networking and especially pfSense. It had the option to choose a harmless and at the same time maybe pointless blocking rule so I did...Indeed, it made much more sense on the WAN interface haha

                              @johnpoz said in pfSense as a private DNS resolver:

                              Do you have any floating rules

                              Screen Shot 2019-12-03 at 16.03.55.png

                              @johnpoz said in pfSense as a private DNS resolver:

                              So no you wouldn't be able to talk to unbound on 53.
                              If you setup forwarding, it will not resolve... You can not do both..

                              I'm sorry but I don't understand. It worked just fine when I enabled forwarding mode and is working just fine now when it's set as a "pure" resolver...

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

                                My bad, you wouldn't be able to talk to other local networks if you policy route, but your any any rule with gateway like that would allow you to talk to pfsense IPs.. Since it doesn't need to route them anywhere..

                                Not clean doing it that way, if your going to policy route I like to explicit allow what you want and deny what you don't - and then route everything else out the gateway that your going to allow.

                                The not able to talk to other vlans comes up all the time when users policy route.

                                The rules say allow any any, if need to route it send it out X... Well it doesn't need to "route" to get there - so its allowed to talk to pfsense IPs with such a rule.

                                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
                                2440 2.4.5p1 | 2x 3100 2.4.4p3 | 2x 3100 22.01 | 4860 22.05

                                T 1 Reply Last reply Reply Quote 0
                                • T
                                  techtester-m @johnpoz last edited by

                                  @johnpoz said in pfSense as a private DNS resolver:

                                  The not able to talk to other vlans comes up all the time when users policy route.

                                  Yeah...I forgot that VPN isolates you in a virtual local network of its own. Perhaps I'll separate it into more than one rule. Thanks.

                                  So, what's the conclusion about DNS requests? Either use a separate resolver located inside/behind the network or except the way pfSense does it?

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

                                    If your routing pfsense traffic out your vpn, then unbound would use that.. What happens when the vpn fails not sure.. But if you have unbound only bound to the vpn interfaces that will sure fail.. But can also cause issues when pfsense is booting and vpn is not up yet and unbound tries to bind to the interface, etc. Why you normally just bind unbound to the loopback.

                                    If you want to be in complete control and sure that dns is never going to do anything other than go out your vpn, then put it on your local network and policy route.

                                    If your going to use dot, doesn't matter how unbound gets to the internet - its always going to be encrypted..

                                    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
                                    2440 2.4.5p1 | 2x 3100 2.4.4p3 | 2x 3100 22.01 | 4860 22.05

                                    T 1 Reply Last reply Reply Quote 0
                                    • T
                                      techtester-m @johnpoz last edited by techtester-m

                                      @johnpoz said in pfSense as a private DNS resolver:

                                      What happens when the vpn fails not sure.. But if you have unbound only bound to the vpn interfaces that will sure fail.. But can also cause issues when pfsense is booting and vpn is not up yet and unbound tries to bind to the interface, etc. Why you normally just bind unbound to the loopback

                                      That won't be a problem. I set the Outgoing Network Interfaces in the resolver to be just Localhost as you suggested before. Also, set the WAN to be the default gateway so pfSense will use it for its internal needs etc. without any consideration to the VPN (up or down). When VPN fails, only interfaces that should use it, should be affected.

                                      @johnpoz said in pfSense as a private DNS resolver:

                                      then put it on your local network and policy route

                                      1. Are you talking about a seperate physical device for DNS resolving?

                                      @johnpoz said in pfSense as a private DNS resolver:

                                      If your going to use dot, doesn't matter how unbound gets to the internet - its always going to be encrypted

                                      1. I'm sorry but now I'm a bit confused. You said before that unbound won't be able to resolve using DoT, so you're talking here about forwarding to an external DNS (like Cloudflare) and use DoT?

                                      @johnpoz said in pfSense as a private DNS resolver:

                                      If your routing pfsense traffic out your vpn, then unbound would use that

                                      1. That's exactly what I want. DNS requests coming from X interface should be encrypted via DoT or simply go through the VPN gateway or even both lol. I don't care about the rest...let pfSense do its thing.
                                        So can I be 100% sure that for DNS requests coming from the LAN net, the unbound will also go through the VPN gateway just like the rest of the traffic originated from LAN net?
                                        EDIT: Sorry, I think I misunderstood you. By pfSense traffic you mean the entire thing using the VPN as opposed to just certain interfaces?
                                      1 Reply Last reply Reply Quote 0
                                      • First post
                                        Last post